Do instruction exercisers exist for 8086 and 68K (and other) CPUs?

Question

For some of retroCPUs there exist exhaustive instruction exercisers, i.e. programs that are capable of catching the implementation errors when run on the emulator under development or on the newly made hardware like FPGA recreation.

Usually tests run some specific sequence of instructions that should result in the predefined outcome, and if there's miscomparison, the test reports fail. Zexall, which is mentioned below, runs each instruction with all the different input data and collects results by submitting them blindly to the CRC algorithm. The predefined outcome is the correct CRC, which should be the same both on real hardware and on the (probably emulated) host the test is run on.

Examples of such exercisers include i8080 exercisers like this one or the famous Z80 zexall. For DEC CPUs there exist original tests like presented here.

What other CPUs have exhaustive sets of instruction exercisers accessible today?

Of particular interest are tests for 8086 and MC68000.

Answer 1

Throwing some things out there that might fit the bill:

• 6502: AllSuiteA which assembles into a single binary and exits, leaving a failure or success code in memory;
• 6502 and 65C02: Klaus Dormann's test suite also compiles into a single binary per target CPU, but loops in place if it finds an error rather than exiting;
• 6502: Wolfgang Lorenz's tests cover the 6502 plus various other bits of C64 hardware, but they load one test at a time and it's easy to hook in to capture each test's attempts to load the next so you can run just the CPU-related subset, in any order you like;
• 65816: Peter Lemon/krom's tests are natively formulated as if to run one-by-one as a series of separate Super Nintendo cartridges but are nevertheless easy to build a harness around. In particular support of that, full traces of all CPU activity have been posted on the emudev.de site, so you can follow along one instruction at a time;
• Z80: Patrick Rak offers a Z80 tester package that includes general tests plus specific ones for CCF and MEMPTR, the two things that produce or affect classically-undefined flags;
• Z80: FUSE, a ZX Spectrum emulator, comes with a bunch of per-instruction tests that I transcribed to a friendly JSON format here through a desire not to maintain a parser for the custom format;
• 68000: on decoding alone, I used the binary attached here that includes a bitfield of which opcodes should decode to valid instructions and which shouldn't, along with the source programs that generated them;
• 68000: I wrote a random instruction generator, which knows how to produce all valid combinations of instruction and addressing mode, and then appends a bunch of random bytes for the other instruction fields; I then generated a decent number of such examples per opcode and ran the results through a couple of open source emulators; I recorded both the initial setup, and any relevant memory state before and after, into a whole bunch of JSON files here. So, shotgun testing of an instruction set.

Answer 2

I understand the question (now), as asking about self test programs to check a CPU (or its emulation) for correct operation by trying out certain instructions and verifying the results. Does this fit?

Such were plenty. In The Early Days (tm) magazines like Byte, Kilobaud or Micro published such for many new CPUs. It was a very common finger exercise for engineers to write one when adapting to a new CPU. That way one had to look and understand each instruction while creating a clear proof of that understanding. Publishing that was an easy way share (and maybe even earn a few quid).

In addition manufacturers also provided such programs. I remember at least one by Intel for 8085 as part of the ISIS-II system as well as a similar for 6802 by Motorola for their Exorciser (sic!) development system.

So, while Github et.al. may bring some modern recreation, the true treasure trove is as usually buried in all these old magazines of very early days.

---

(On purpose no links to avoid creating a list answer)

---

Fun story to be added:

Some bootstrap ROMs for microcomputers contained rather elaborate CPU self test code, able to separate improved CPU versions from their predecessors. One example might be the Siemens PC-MX, a multibus-based 8086 multi-user Unix system. While at the time performing rather well, having a little more punch would have been appreciated. So when NEC brought the V30, I of course tried to use one - except, the boot ROM denied loading the system because of the 'bad' CPU.

Some disassembly later I found that the ROM contained almost two KiB of code testing many instructions and addressing modes including timing, which of course detected the slightly faster execution of a V30.

So yeah, beefing up an Amstrad PC 1512 was a no-brainer; doing the same with a 5 times as expensive professional system failed badly.

Answer 3

Toni Wilen (of WinUAE fame) has written a CPU tester especially for MC68000: https://eab.abime.net/showthread.php?t=98747

Answer 4

The Modcomp minicomputers were shipped with extensive self-test programs (on nine-track magnetic tape, no less). These were stand-alone programs (no operating system needed) that tested everything from peripherals to memory to CPU.

The CPU tests were in a series, starting with "is it working at all" tests. Each test confirmed a more complex part of the CPU than the previous tests, so later tests could use more of the CPU than did previous tests. You'd run the tests in sequence, and the first one that failed told you what was wrong.

If the system console was working, the tests could inform you of their progress and pass/fail by printing to it. However, they could also use the front panel lights and switches. The switches could be used to select test options, and the lights to inform of failures.