I spent a bit of time today cross-referencing opcode maps to come up with the following routine, 20 bytes long and with no branches whatsoever, which produces a (vaguely) human-readable ASCII code in the accumulator indicating the type of core it's running on: Further work may be needed to identify sub-types within those four families, but the above will usually be enough to identify a mis-labelled CPU from China, provided you can get it to boot in the first place. The old NMOS 6502s with missing ROR and the 65CE02 are rare enough that you're unlikely to encounter them outside of a well-curated collection, and distinguishing a Rockwell 65C02 from a WDC example is tricky in generic code that doesn't know where to find a source of interrupts and timing.

I thought it might be instructive to explain how this code works. As the comments hint, the key is in the "magic" $47 opcode, which behaves differently on all four families. Other opcodes with a similar class of behaviour could have been used, but $47 has some nice properties that make it work particularly well here.

The first 8 instructions, immediately preceding the "magic opcode", set up some zero-page locations with "magic data". These are needed to cause some of the CPUs to behave in useful ways once given the $47 opcode. Address $83 was chosen because it is available to user programs on the BBC Micro, and is a 1-byte NOP on the 65SC02. Any other 1-byte NOP opcode could be substituted for this address, as long as the zeroes stored at $84 and $85 are also moved to follow it. Address $1D is important for a different reason and should not casually be moved; on the BBC Micro it harmlessly clobbers BASIC's DATA pointer. It can be moved out of zero-page if the data stored at $84 is changed to match, but $83 must contain $1D.

An NMOS 6502 interprets $47 $83 as a concatenation of LSR $83 and EOR $83, in that effective order. Since that instruction is immediately followed by another EOR $83, the accumulator is left unchanged from its initial value of ASCII 'N'.

A 65SC02 interprets both $47 and $83 as 1-byte NOPs. The following EOR $83 changes the accumulator to ASCII 'S' using the magic value $1D stored there earlier.

A 65C02 interprets $47 $83 as RMB4 $83 (as written in the listing), which clears bit 4 of that memory location. The subsequent EOR now produces ASCII 'C' in the accumulator; it's a useful coincidence that 'S' and 'C' differ by only one bit. The rare 65CE02 is backwards compatible with the 65C02, and will be identified as one by this routine.

A 65816 (or 65802) interprets $47 $83 as EOR [$83], indirecting through the 3-byte long pointer we set up there earlier. The magic value stored there combines with the $1D magic value to convert 'N' into '8' in ASCII.

I'm sure some of you are now thinking of the "Story of Mel"…

Nice! Thanks for this.

_________________
Bill

And I just found a bug in jsbeeb - it doesn't support the 65C02 that should be in the "parasite" side of the Master Turbo, and in fact seems to have put an NMOS 6502 there. Oops!

This is so truly clever that I am overcome with awe.

Also, it turns out that cheap Chinese vendors are not the only ones doing remarking. It apparently also goes the other way around: py65 claims that its mpu6502 class "simulates the original NMOS 6502 microprocessor," but it's actually a re-marked 65SC02 emulator, at least according to this test. (In case it's not clear, test_chromatix_id is the function that links to. Here is the code under test.)

Oh well. At least he said "simulate" instead of "emulate." :-)

_________________
Curt J. Sampson - github.com/0cjs

It's pretty common for 6502 sims to implement only the documented NMOS opcodes, and leave the undocumented ones as NOPs. Indeed from the py65 README: "At this time, all of the documented opcodes are supported. Support for the illegal opcodes is planned for the future." That would be detected as 65SC02 behaviour, since I don't exercise any of the opcodes that are new on the 65SC02 in this code. So you should mostly use this code on real hardware or accurate sims.

ETA: to give a better result on py65 and similar, try appending the following after EOR $83: A real NMOS 6502 will take the BNE branch. A real 65SC02 will take the BRA. But a sim treating undocumented instructions as NOPs will fall through the BRA (possibly executing the $02 operand byte as another NOP) and end up replacing the accumulator value.

Here's how my 65C02 sim (which tests correctly with Klaus' test suite) runs the extended code above: It correctly produces ASCII 'C' in the accumulator.

And here is a Visual6502 demonstration!

And when it outputs a lower case 'v' ?


This is on my Ruby 816 board. code is running in 8-bit register + memory mode.



The .setcpu is needed as the assembler is called in 816 mode. That just lets the RMB4 opcode assemble. I tried it in emulated 6502 mode and got the same result. Not tried it in 16-bit mode yet.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

It seems that I goofed on the magic constant to stash in $1D. Instead of $25, it should be $6B. Fixing that should make it work as expected with an '816. I've made a couple of judicious edits above to reflect that.

Don't bother trying it in 16-bit mode. Although it'll work in native mode with M set (8-bit accumulator), the immediate operands to LDA will be the wrong size with M clear. It's really intended to be run in emulation mode, on the assumption that you're trying to figure out what a chip is from scratch.

Yup - got "8"

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

What assembler recognize the RMB4 mnemonic ?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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