Has anyone thought of developing an exerciser for the Intel MCS-51 instruction set and standard onboard peripherals (timers, interrupt controller and serial channel), like ZEXALL for Z80? It would be very helpful for testing MAME and other emulators, and not an outrageously esoteric project considering how old and widespread the MCS-51 architecture is and how grounding the EA pin allows most models to be tested without reprogramming the internal ROM (if they have any).

The 80(C)31 and 80(C)32 have a few undocumented behaviors that might well differ between models and manufacturers, such as the values of ACC and B after dividing by zero, what the "reserved" opcode 0A5H actually does (aside from its documented use in the MCS-251's extended instruction set), and whether or not PSW.1 exists. Those would be worth researching in themselves.

Another tricky MCS-51 question: does PUSH SP push the original value of SP or the incremented value? Intel clearly documents that POP SP does not decrement the popped value, but the description of PUSH SP suggests that it might increment SP first before reading it. (I have only seen this instruction once in a never-called subroutine.)

acvirus.cpp will eventually need the 80C515 and 80C535, which are both 8052s with more I/O ports and peripherals.

http://www.keil.com/dd/docs/datashts/infineon/80x515_um.pdf

That's not too different in concept (adding ports 4 and 5 and a compare/capture unit or two) from Intel's 80C51GB, which I recently identified scm_500 as. There are a countless number of further-enhanced versions of the 80C51 and 80C52, but the only ones that I think might be relevant for the exerciser proposed here are those such as the DS80C320 which have shorter machine cycles of 4 clocks each rather than 12. (There's also the AXC-51 type found in the Monon Color, but that barely even qualifies as a 8051 clone due to having a 16-bit ALU, many new instructions and 100% different on-chip peripherals.)

Is the question about PUSH SP still open? I have a Lauterbach 8051 ICE and could test that. But this thing takes a bit to set it up, so let me know if that would be useful.

Yes, PUSH SP is still open.

One idea I thought of but now consider unimportant was trying to determine the exact sequence of addresses for various instructions' dummy fetches. This, however, would not only be probably very difficult to examine but of practically no utility, since it's the number and timing of dummy fetches that matters for the few 8051 applications that depend on it (most spectacularly Intel's SDK-51, which has an elaborate circuit that counts 8031 instruction cycles to work around the lack of cycle-synchronizing inputs and outputs).

For interrupt and timer testing, it should be possible to set the INT0/INT1/T0/T1/T2/T2EX pins from the port registers and have the peripherals respond to that, given that they're quasi-bidirectional. The serial receiver could be tested similarly in Modes 1 and 3, but Modes 0 and 2 run uncontrollably fast and might only be amenable to cruder tests. (Mode 0 has the best-defined timings anyway.)

I did a test:

set sp to 0x10
set pc to 0x0 which contains 'push sp'

Do a single step:

0x10 is written to DATA RAM:0x11

So it seems to increment the Address, and write the initial SP value to that location.