Subject: Feature Tests

After devising a tortuous byte sequence to determine 65816 mode and automatic host identification, I've considered various sequences to automatically determine host processor. This would allow, for example, block copy instructions to be used, if present, and alternative functionality, if not. Indeed, I hope that it is possible to provide a bitmask of processor bugs, bitmask of processor features, outline memory map and platform ABI revision. In the worst case, it should be possible to switch to an extended 65C02 virtual machine or similar. In this topic, I concentrate on differentiating NMOS 6502, 65C02, 65CE02 and 65816, with and without Rockwell bit tests. Apologies if I omit other useful cases. Likewise, I am likely to make errors. Apologies in advance and thank you for back-checking.

On 65CE02 and 65816, opcode $F4 pushes 16 bit immediate on stack. This is a three byte sequence. On other processor variants, opcode $F4 is usually a two byte NOP. Therefore, LDY #0 // TSX // $F4 // INY // INY // INY // INY // INY // TXS should restore stack while counting the length of the opcode. On 65CE02 and 65816, RegY should be three. In all other known cases, RegY should be four.

To distinguish between 65CE02 and 65816, opcode $BB either performs LDZ abs,X or TYX. Therefore, LDX #1 // LDY #0 // $BB // INX // INX // INX // INX // INX leaves RegY as zero on 65CE02 or sets ReyX to one on 65816. (A similar test is described in the Transputer Handbook.) As a further back-check, RegX should be four or six on known variants.

To distinguish between NMOS 6502 and 65C02, merely use unconditional branch (opcode $80). On NMOS 6502, this is a two byte NOP.

So far, these three tests distinguish NMOS 6502, 65C02, 65CE02 and 65816. However, this is only the basics. It does not cover processor bugs, individual features (such as Rockwell bit test extension) or other processor variants.

It is preferable to avoid random stack manipulation or random writes. Therefore, a load opcode is preferable. In this case, to test unrelated functionality including Rockwell extension, use opcode $A7 and a spare location in zero page. Opcode $A7 has very distinct action on different classes of 6502 processor architecture:-

• On NMOS 6502, $A7 is an illegal instruction which simultaneously loads RegA and RegX. Specifically, LAX zp.
• On an [url=XXX]architecture where illegal instructions are routed to a second accumulator[/url], opcode $A7 performs LDB zp.
• On CMOS 6502 without Rockwell extension, it is a two byte NOP.
• On CMOS 6502 with Rockwell extension, it sets bit two in a zero page location. Specifically, SMB2 zp.
• On 65816, it specifies 24 bit indirection via zero page. Specifically, LDA [d].
• On other variants, such as 32 bit extensions, it is likely to have unrelated functionality, such as instruction prefix.

My technique to distinguish variations in functionality is to start with a candidate sequence, such as LDA #0 // STA <TEMP // $A7 <TEMP // ORA <TEMP and then assemble and disassemble fuzzed sequences until something useful emerges. In this case, LDY #0 // LDA #4 // STA <TEMP // LDA #7 // LDB <TEMP // INY // INY // INY // INY // INY // AND #2 // STA <TEMP // STB <TEMP // INY // INY // INY // INY // INY should be suitably perverse. (Feel free to devise smaller versions but the gains are minimal.)

• On NMOS 6502 this will be ... // LDA #4 // STA <TEMP // LAX <TEMP // ... // AND #2 // ... // SAX <TEMP // ... which will store zero.
• On a processor with second accumulator, this will store four, as expected.
• On CMOS 6502 without Rockwell extension, unknown instructions are NOPs of the appropriate length and it will store two.
• On CMOS 6502 with Rockwell extension (and 65CE02), the sequence ends with STA <TEMP // SMB2 <TEMP // ... which will store six.
• On 65816, operations intended for RegB are substituted with 24 bit indirection. Suitable set-up can be used to handle an unrelated value.
• On other variants, RegY can be used to determine the length of the opcode. Other tests may be required.

As an example of a 64 bit extension test, 65CE02 and XR1600 can be distinguished by testing opcode $17 to determine bit operation or prefix extension. Specifically, LDA #0 // $17 $A9 // $17 $A9 only leaves RegA zero on 65CE02. It is either executed as LDA #0 // RMB1 <$A9 // RMB1 <$A9 or it is executed as LDA #0 // LDA.W #$A917. Tests for competing architecture extensions are most likely to test one or more $x7 or $xF opcodes.

Arguably, this is not feature testing but merely cleaving processor architectures into known cases. Therefore, I include a fairly basic feature test around PHX/PLX. If you are really pedantic, you can repeat it on PHY/PLY. On NMOS 6502, these are one byte NOPs. Therefore, LDX #1 // PHX // LDX #0 // PLX will correctly distinguish the presence of this basic CMOS functionality.

These tests generally destroy every available register. Regardless, I believe these tests and others yet to be devised would be useful if they were collected together and used to set bitmasks held within zero page. If this action is statically bound to an application and occurs at start-up, it may add less than 200 bytes to an application but allow guards which perform simultaneous feature tests before invoking one or more fall-backs. The only limit to this scheme is that a Rockwell bit test should not be used to determine the presence of Rockwell bit tests!

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

It is possible to perform processor architecture tests ahead of processor feature tests. This allows, for example, meta-data in Acorn or Ruby filing systems, such as load address and execution address to work across multiple processor architectures.

I have concentrated on 6502 interoperability with 6800, 6809 and Z80 although techniques may be extended to 8088, MC68008 or similar. In particular, anyone wishing to explore the 6800 fork of Apple I may switch processor without necessarily switching ROM.

The main problem that I've encountered is choice of opcode which simultaneously meets the criteria of not halting NMOS 6502 while not incurring memory cycle to uninitialized address on Z80 while not incurring illegal instruction exception on 6809.

6800 and 6809 re not binary compatible. However, many of the flow control instructions retain binary compatibility and this is sufficient to allow 6800/6809 to be considered as one case during the initial stage of processor architecture identification. In particular, opcode $7E is jump on 6800 and 6809 while on 6502 it is ROR abs,X. Unfortunately, ROR abs,X with uninitialized RegX does not scribble over the now useless 6800/6809 section of a fat binary. This is due to reverse endian representations.

Cleaving into 6502/Z80 and 6800/6809 is not necessarily the best technique. It may be preferable to split out 6502 first using opcode $4C which is JMP on 6502, a register increment on 6809 and a register transfer on Z80. Alternatively, opcode $2C and opcode $2D have the particularly helpful property of being a one byte instruction on Z80, two byte flow control on 6800/6809 and three byte read operations on 6502. This quickly teases apart representation and ensures that one processor's opcode is another processor's operand.

6502 shares vector locations with 6800 and 6809. Endian representations allow arbitrary choice of page to constrain page offset in the other representation. Unfortunately, there is the further complication that comparable vectors may be shuffled. For example, 6502's IRQ vector is 6809's reset vector. Regardless, vectors to, for example, $FAFB and $FBFA may have appropriate functionality.

Despite ROM vectors being distinct, there remain circumstances where 6502 and 6800/6809 should be distinguished without disrupting registers or flags. For example, where upper and lower byte of ROM vector matches. I found that the sequence $20, $02, $XX, $40 on 6502 is JSR $XX02 // RTI and on 6800/6809 unconditionally branches forward to the end of the sequence. This subroutine-or-skip construct is sufficient for a processor agnostic system.

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

BillG provides an example test to distinguish 6800/6809. This is for the purpose of providing a meaningful error message on the FLEX operating system and exiting when a stray binary is run on the wrong system. This does not cover all cases but, in common cases, it is preferable to a less helpful error message or hang. We may be able to use this sequence and similar sequences for 8080 or Z80 CP/M. The minimum requirement is to output "This is a 6502 binary." and exit. This can be applied to all binaries with no further effort. In a minority of cases, an alternative bytecode interpreter may be very welcome functionality.

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

Opcode $18 might be a good choice, its CLC on the 6502 family and a short range branch on the Z80/8080. If it's followed by an instruction from the first half of the 6502 opcode list, that would translate to a forward branch on the 8080/Z80 and hopefully something harmless on a 6502.

So for example the 6502 sequence:

When seen by a Z80/8080 is:

$18 is one of the new Z80 instructions; it is undefined in the 8080 and 8085.

In the modern emulation scene, execution of machine code from an arbitrary foreign processor can be forced.

In the real world, with wildly incompatible binary file, disk and cartridge formats, there are few cases in which code can be accidentally run on a "wrong" system. Unless the operating system expressly supports loading only the appropriate portions of "fat" binaries or if the hardware contains multiple processors sharing common memory, there is a substantial penalty for loading the code for an alien processor which will never be used.

In the name of intellectual curiosity, this is some code to prevent running 6502 code on a 680x processor:



Edit: fixed endian and conditional branch. Test before, not after posting...

damn!

Serves me right for only checking in Zak's Z80 book. Can I be excused on the grounds I've not written any 8080 code in 30+ years

Anyhow, attempt 2 then since the 8080 doesn't have any relative branches then maybe using on the 6502 JMP would work ?

Opcode 4C is a harmless register move on both Z80 and 8080.

so 6502 becomes Z80and 8080Setting xx to the code's origin page means the &3E offset leaves enough space for the Z80/8080 code to report an error and quit sensibly or launch a different program.

One system where CPU detection like this would be useful a BBC/master with a Z80 co-processor, and a shared hard drive. You could have the boot sequence detect the CPU and setup directories etc appropriately. (Though of course the other code would work there too)