processor detection

[BigEd]

Interesting that we hit this detection problem today - I was in Hoglet's lab - and we couldn't see a solution for our situation, because not only are there real 6502 chips, but in our case we had Arlet's 6502 core, and also an emulator core, and these might all have different behaviours for undefined parts of the machine.

(Indeed in the case of the emulator they might also have bugs! We were trying to get a version of Bruce's decimal test to run, and of course if you're testing decimal mode then you know it might not be right, so it's maybe not best to try to detect the CPU using decimal mode behaviour...)

The solution in our case was that Dave coded up a menu, so the user can choose whether to test 6502 behaviour or 65C02 behaviour, and whether to test only defined behaviour, or all behaviour.

[Dr Jefyll]

Quote:

Are all unimplemented codes on the C02 NOPs?

The processor thinks they're NOP's, because no flags or registers are altered. But in some cases a data fetch (a fetch other than the instruction fetch) is generated. Depending on the system, that might have potential for a destructive read of an I/O register -- so, perhaps not a NOP from the system's point of view.

On a more positive note, the NOP's are useful for hardware and software hacks. (The software hack, discussed here, uses the NOP to skip a byte or two. It's smaller and may be faster than a BRA.)

The most numerous undefined NOP's have no time for a data fetch, as they are both single-byte and single-cycle. 64 such NOP's are present on older 'C02 processors such as the NCR65C02; their opcodes fill columns $3, $7, $B and $F of the opcode map. Slightly newer C02's including Rockwell use columns $7 and $F to accommodate the bit-manipulation instructions, thus reducing the number of single-byte, single-cycle NOP's to 32. Modern WDC C02's further reduce that number to 30, as the STP and WAI opcodes reside in column $B.

GARTHWILSON wrote:

Jeff has used the single-cycle ones for his fast-I/O tricks.

Yes, the single-byte, single-cycle have great potential for hacking. They're fast, compact and plentiful. And your hardware perhaps won't need to decode the entire opcode -- merely decoding the column may suffice.

That said, the remaining NOP's (non-single-cycle) are the most intriguing, as they give your hardware access to the following address modes (as dictated by an appropriate program):

• Absolute
• Zero-page
• Zero-page,X
• Immediate

For example, your program might include the two-byte instruction $44, $69. $69 is some arbitrary location of interest, and $44 is the opcode for "NOP" Zero-page. At runtime $44, $69 will cause the processor to obligingly fetch whatever's at $69. The processor discards the byte fetched, and it remains only for your hardware to capture it by snooping the data bus. That's how my KK Computer is able to load a Bank Register in only three cycles. (Or two cycles, using "NOP" Immediate.)

For detailed specifics on 'C02 NOP's see here.

-- Jeff

[RichTW]

The really curious one is $5C which is apparently a 3 byte, 8 cycle NOP. That doesn't correspond to any addressing mode, not even the illegal RMW (zp),Y / (zp,X) instructions on the original 6502, which are 8 cycles but only 2 bytes long. Anyone know what the memory access pattern is during NOP $5C?

(Edit: it's in Jeff's link - thanks for the info. Bizarre indeed!)

[Dr Jefyll]

Quote:

I tested the instruction "5C 1234h" (stored little-endian as 5Ch 34h 12h) as an example, and observed the following: 3 cycles fetching the instruction, 1 cycle reading FF34, then 4 cycles reading FFFF.

The pattern for $5C is pure nonsense, I'd say. It certainly doesn't correspond to any legitimate address mode. But we don't expect it to. The single-byte, single-cycle NOP's don't do so, either. Only a minority of the undefined NOP's happen to display semi-meaningful behavior -- and even that is more by fluke than by plan. The only requirement is that the undefined NOP's be benign.

To me it's clear the 'C02 designers wanted to ensure processor registers and flags were unaffected by undefined instructions. They fully met that spec, but they weren't the least bit fussy about how it was done -- they just chose whatever cheesy shortcuts were easiest. It's not surprising that some of the resulting behavior is gobbledygook.

The main shortcut is to throw a wrench in the instruction-fetch procedure when a column-$3 or -$B opcode is fetched. As we know, a 65xx processor's usual procedure for beginning an instruction is to

1. put SYNC high and fetch the opcode byte
2. put SYNC low and fetch at least one more byte

But when a 'C02 detects a -$3 or -$B opcode it simply shrugs it off and restarts the opcode fetch procedure. Here's the 'C02 procedure:

1. put SYNC high and fetch the opcode byte. If it's column-$3 or -$B then GOTO Step 1.
2. put SYNC low and fetch at least one more byte

Evidently the predecode logic is at work here, as the usual pipeline is short-circuited. But it successfully prevents whatever non-benign gobbledygook might otherwise result from the -$3 or -$B opcodes.

[RichTW]

Dr Jefyll wrote:

The pattern for $5C is pure nonsense, I'd say. It certainly doesn't correspond to any legitimate address mode. But we don't expect it to. The single-byte, single-cycle NOP's don't do so, either. Only a minority of the undefined NOP's happen to display semi-meaningful behavior -- and even that is more by fluke than by plan. The only requirement is that the undefined NOP's be benign.

It'd be interesting to see how the 65C02 decode ROM compares to that of the 6502. In column $xC, there are some new instructions (TSB/TRB abs, JMP (ind,X), etc), so I guess it's conceivable $5C ended up with unusual behaviour, and they just added the minimal number of patches to the PLA to ensure that it was benign. I guess we'll only know for sure with a Visual 65C02!

[BitWise]

As I can see the individual cycles it turns out that a single JMP ($FFFF) is all you need to tell the processors apart. Just like Goldilocks.

My dummy boot code is at $1000. A 6502 executes 5 cycles and the address calculation bug means that $FFFF and $FF00 are accessed. Too cold!

Code: Select all

FFFC R 00
FFFD R 10
1000 R 6C
1001 R FF
1002 R FF
FFFF R 00
FF00 R 00

A 65C02 uses an extra cycle re-reading the high byte and accesses $FFFF and $0000. Too hot!

Code: Select all

FFFC R 00
FFFD R 10
1000 R 6C
1001 R FF
1002 R FF
1002 R FF
FFFF R 00
0000 R 00

And a 65C802 doesn't use an extra cycle and accesses the correct addresses. Just right.

Code: Select all

FFFC R 00
FFFD R 10
1000 R 6C
1001 R FF
1002 R FF
FFFF R 00
0000 R 00

[BigDumbDinosaur]

BitWise wrote:

As I can see the individual cycles it turns out that a single JMP ($FFFF) is all you need to tell the processors apart. Just like Goldilocks...And a 65C802 doesn't use an extra cycle and accesses the correct addresses. Just right.

What about the 65C816?

[DerTrueForce]

Wouldn't the '816 behave much the same as the '802?
I'm assuming that the '802 is an '816 that's been wired up differently internally.

[BitWise]

That would be my assumption too. The board can't take a 65c816 to test that hypothesis though.

[whartung]

BitWise wrote:

As I can see the individual cycles it turns out that a single JMP ($FFFF) is all you need to tell the processors apart. Just like Goldilocks.

My dummy boot code is at $1000. A 6502 executes 5 cycles and the address calculation bug means that $FFFF and $FF00 are accessed. Too cold!

How do you detect cycles consumed?

[BitWise]

The various trace outputs show the address bus, W/R signal and data bus content. For a read the data content is provided by the PIC at this stage in the boot process.

Unfortunately there wasn't enough pins to get the RDY signal so after the /RES line is release the code uses the address bus values to determine when the reset vector has been accessed and the first opcode read.

[BigDumbDinosaur]

DerTrueForce wrote:

Wouldn't the '816 behave much the same as the '802?
I'm assuming that the '802 is an '816 that's been wired up differently internally.

A key difference between the two is the '802 lacks the VDA and VPA outputs, which are key to error-free hardware management in 65C816 systems. Hand-and-hand with that is different hardware behavior involving memory accesses. They are not interchangeable parts by any means.

[BigEd]

What differences BDD? I'm inclined to believe it's the same die repackaged.

[GARTHWILSON]

BigEd wrote:

What differences BDD? I'm inclined to believe it's the same die repackaged.

It's the same until they get to the final stages of the wafer fab, and then there are small differences in the final metalization masks, or something like that. IOW, it's slightly more than a bonding difference.

[Dr Jefyll]

GARTHWILSON wrote:

there are small differences in the final metalization masks, or something like that. IOW, it's slightly more than a bonding difference.

That sounds about right. But are the internal details pertinent? What is it we're trying to establish? Didn't the original question have to do with cycle counts?

- the cycle counts ('816 vs '802) are identical AFAIK
- internal differences (ie the die itself) can be described as minor
- the '816 drives A23-16 onto the data bus during PHI2 low, which is non-trivial from an external perspective (ie the motherboard design)