I just spent a few hours researching some of the differences between 6500 family variants and writing a short piece of code that should be able to detect what kind of CPU you're running on top of. I've not tested it thoroughly! It works as expected on a C64 (result of $0c meaning normal NMOS 6502 core) and an NES emulator ($04 meaning NMOS 6502 with no decimal mode) but that's the extent of my testing as I either lack supporting code, knowledge, or access to the platforms in question to test every possibility.

It currently supports detection of these 6500 variants, without crashing (hopefully) during any part of detection:

"Stock" NMOS 6502
WDC 65C02 (and clones)
65816
Very early 6502 with the "ROR bug"
Ricoh 2A03 (NES CPU)
Rockwell R65C02 series (with RMB/SMB opcodes)
Hudson Soft HuC6280 (PC Engine CPU)
Mitsubishi/Renesas 740 MPU/MCU
Renesas 740 MUL/DIV instruction support

It's designed to be built with the ACME assembler, version 0.93 or up, and builds to 96 bytes in size. The result of the tests is stored as flags in a zero-page location which can be easily modified, and testing requires at most two zero-page locations beyond the flags storage location. I hope that someone here finds this little code snippet useful.

Detecting a 65C816 would be problematic because at reset, it comes up as a (mostly) 65C02 and can only be switched to native mode with the XCE instruction. The XCE opcode is $FB, which would behave as a one byte NOP with a 65C02 but would be undefined on all other eight bit MPUs and might result in a crash.

So I think the path to determining if the MPU is an '816 would be to first determine if it is a 65C02. If it is then you could proceed as follows:

Code:

         clc
         xce
         bcs is_816
         ...

Of course, you'd need an actual 65C816 machine to try out this code.

Code:

; Test for Rockwell R65C00 series
; This is pitifully simple: it sets the flag bit for us!
+   !byte $d7   ; SMB5 opcode on R65C00, ignored on 65C02

$D7 is valid on the WDC 65C02 as SMB 5,ZP.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The code already checks for 65816 by first checking for 65C02, and only then using XBA instructions to determine if it's a 65816. As for the SMB5 instruction, you are indeed correct; I've modified the comments to indicate that the detection finds "old" vs. "new" type 65C02 chips. Apparently some 65C02 chips exist without SMB/RMB/BBS/BBR opcodes, and the test checks that. R65C02 and WDC 65C02 appear to have identical opcode matrices, but a datasheet on this site for a California Micro Devices G65SC02 has a matrix with these opcode slots empty. Also, I found a bug where I didn't put zp0 in the SMB5 instruction, and fixed it. This changes the code size to 97 bytes.

I also added a warning, because zp0 will be executed as a 65C02 opcode if the SMB5 opcode test fails. Here's the modified code:

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Performing thread necromancy to point out possibly the single easiest way to distinguish NMOS 6502s from anything later: This works because $80 (BRA) is an undocumented 2-byte NOP on NMOS. Now, whether emulators implement that quirk or not is an open question, but if you *know* you're running on real hardware…

Digging up this thread, I've been trying to make so code to detect if I'm running on a 65816 or not. I don't need the whole suite of finding everything just is-65816 vs not-65816 (but with a complication that it could be a 6502 or a 65C02/12).

With some experimenting, I've come up with this. Does it look robust enough?


Distinct values for is-65816 and not-65816 (with a added 6502/65C02 that I don't need for this task).

So I can then BEQ m816:BNE m02.

_________________
--
JGH - http://mdfs.net

What about detecting a Sally 6502? I imagine it would test as a stock 6502 since MOS made it for Atari. Really, that just adds back a feature that MOS removed since the original die left room for multiplexers to take the 6502 off the bus. That also explains one of the NC pins. I guess they didn't feel like anyone needed to use bus-mastering DMA.

Sally was a modified 6502, B revision, despite it being listed as a C revision in Atari literature.

In response to jgharston, testing NMOS/CMOS/65816 is very easy. It is only complicated if you wish to cover obscure cases. As noted by Chromatix, NMOS is unable to follow BRA and this separates it from everything else. 65816 in emulation mode is only faithful to 65C02 if 65C02 instructions are executed. The extended instructions are always available. Although, register sizes are restricted in emulation mode. In response to jeffythedragonslayer (and being needlessly lambasted again by BigDumbDinosaur), and after considering the use of 65816 REP to clear multiple flags simultaneously (decimal, carry, interrupt), I find that REP can also be used to determine execution on 65816. This works in emulation mode or native mode.

SEC // REP #1 will clear carry on 65816 but leave carry set on 65C02. Unfortunately, while BRA ... SEC // REP #1 // BCC ... splits NMOS/CMOS/65816 into three chronological cases, it fails horribly on obscure processor variants, such as 65CE02. In this case, 65CE02 follows BRA. However, REP and SEP are interpreted as direct page, 16 bit increment or decrement (DEW and INW). The immediate value of REP is interpreted as the lower byte of the 16 bit decrement. Thankfully, carry is unaffected. However, DEW $01 may be incompatible with your operating system's allocation of direct page. In this case, REP can be used with higher values. On 65816, it will clear additional flags. On 65CE02, it will decrement at a higher address. Specifically: +$80 to clear negative flag, +$40 to clear overflow flag, +$08 to clear decimal flag. Or you can get fancy with +$04 to begin an atomic operation. Unfortunately, it is highly inadvisable to use +$20 to set accumulator to 16 bit or +$10 to set index registers to 16 bit because 65816 native mode cannot be assumed.

Do not abbreviate cases by omitting BRA. NMOS/65816 test seems very concise and convenient but it will cause chaos on 6510 and 6509 where REP #1 is illegal instruction LAX (dp,X) and simultaneously loads RegA and RegX. This leaves carry unchanged but may use memory location $0001 as the lower byte of a source address. On 6510 and 6509, LAX ($01,X) may strobe a bank latch before possibly strobing I/O. It is quicker and easier to test BRA rather than guard LAX (dp,X). It also preserves RegA and RegX across all three cases.

The obvious 65816 test is to invoke XCE. That is great if the test passes. However, XCE on NMOS becomes the three byte illegal instruction ISC abs,Y which is INC followed by SBC. In this case, XCE // NOP // NOP will become ISC $EAEA,Y. Worse, XCE on 65CE02 becomes PLZ (pull top of stack to RegZ). Overcoming that side-effect requires PHA // TSX // CLC // XCE // NOP // NOP // TXS // PLA // BCS which is longer, slower, requires two byte instruction sequence which is also a safe address region, destroys the contents of RegX, fails to distinguish NMOS/CMOS (which is partly why we do not use PHX/PLX and preserve RegX) and lacks the option to clear flags on 65816. XCE is otherwise a good choice.

Detecting CMOS/65816 with XBA // DEC // XBA is cunning but it doesn't generalize well. XBA on NMOS becomes the three byte illegal instruction DCP abs,Y which is DEC followed by CMP. This requires two instances of two byte instruction sequence which are also safe address regions. XBA on 65CE02 becomes an abs, 16 bit shift operation.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Hello,

I have designed a small PCB containing a bit of RAM, ROM and a LED interface to run this nice chunk of code checking what 6502 CPU type might disguise in Chinese re-labelled 6502 fake CPUs.

See details on https://www.forum64.de/index.php?thread ... 6502-cpus/

The forum is in German, but the images and the ZIP release file (Gerbers, code, docs, etc.) will be of use for English speaking individuals, too.

After a long while, I had a look at the code again, and I am wondering if the part regarding the detection of Hudson Hu6280 is correct:



This sets bit 5 to 1 which is not correct, I think. That bit is set later via SMB5 on if a R65C02 CPU is detected. The "Hudson Bit" is bit #4, so the parameter for the LDA should be #$10, not #$20 - or am I missing something?

Regards
kinzi

Also relevant to readers of this thread: http://forum.6502.org/viewtopic.php?f=2&t=5931

Since the HuC6280 and 65CE02 both interpret opcode $47 the same way as the Rockwell-extended 65C02, they will be identified as one by my code from that thread (returning ASCII 'C'). If you have reasonably free use of zero-page, I recommend running my code first, using the magic $47 opcode to distinguish between NMOS 'N', CMOS 'S', Rockwell-extended 'C', and 65816 '8' variants. If it comes out as CMOS, run the further test using BRA to check for emulators which treat all undocumented NMOS opcodes as 1-byte NOPs. If it comes out as Rockwell-extended, perform additional tests for the HuC6280 and/or 65CE02. You can then omit the additional test for the Rockwell instructions at the end of your routine.

Provided the presence of Rockwell instructions has already been verified, using REP #$08 to distinguish the HuC6280 looks like it would work. This instruction is harmless on the 65CE02, which interprets it as CPZ #imm. A convenient way to test for the 65CE02 as well would be to insert an CPY #1 between the LDY and REP, and a BNE between the REP and CPY. The 65CE02 initialises its extra Z register to zero, so comparing it to 8 will clear the Zero flag, whereas both the alternatives will have the Zero flag set at that point.

However, REP is opcode $C2 which a Renesas 740 would interpret as WIT (wait for interrupt), and furthermore the Rockwell opcodes are rearranged so that $47 in my first-line test would be interpreted as a 3-byte instruction BBS2 zp,rel. This is highly inconvenient, and implies that I have to put the test for a 740-series first of all.

Putting all of this together: This doesn't yet check for the Renesas 740. This check would probably have to be inserted at the top of the code.