I've found a few 8080 CPU test suites available, but they all assume CP/M or a similar OS is already present and running - they call BDOS for I/O, etc. I'm working towards being able to run CP/M on my 8080 emulator, but for the moment, I'm looking for something that's just going to put the emulated CPU through its paces and output the results.
I'm actually not aware of any major 8080 test suites; everything I've ever found has been for the Z80 rather than its parent.
That aside, I'd heavily suggest you don't discard the CP/M solutions you've found as they're usually pretty trivial to set up as test cases without any of the main substance of a CP/M environment.
For example, to run the CP/M version of Zexall all you need to do is this:
- give your z80 or 8080 64kb of RAM;
- load the raw bytes included in zexall.com to address
- put a RET (opcode
0xc9) at address
- whenever the CPU hits
0x0005, check what's in the
- if it's
9then output a string starting from the address in
DEuntil you find a
- if it's
2then output the single character in
- if it's
- set the PC to
0x0100and let it run until the stack fully unwinds.
Then check your accumulated text output against that you accumulated during a passing run for a pass or fail; use your human judgment until you get to your first passing run.
So what you've effectively done is implement exactly two of the calls exposed via CP/M's
CALL 5 interface, both of which just to append text to a buffer. And that's everything that zexall requires.
Otherwise: FUSE, the Spectrum emulator, provides tests for everything the Z80 does, in an ad hoc text format. I've transcribed those to JSON so that you don't have to write a parser. The full set of files including the original licence is here on Github.
Parse tests.in.json, and you'll get an array of initial CPU states plus bytes to put into memory. Parse tests.expected.json and you'll see both expected bus activity and the expected final state. Within the output there's a value, "tStates" that tells you how many cycles to run for to verify that the initial state turns into the final state.
The counts are in Z80 cycles so there may be some differences there, but most of the tests are very simple — they're just the one or two opcodes long. So you should be able to ignore the tests for opcodes the 8080 doesn't have, and the values for registers that the 8080 doesn't have, and just run until either the PC exits the data you loaded or you hit the expected final state.
You can find some Intel 8080 CPU tests on this website. These can be run with no OS, just a minimal support framework described below:
These binaries should be loaded to memory starting at 0x0100, and at startup, your CPU should jump to 0x0100. You should also put two handlers at addresses 0x0000 and 0x0005:
The handler at 0x0000 signals the end of the test run.
The handler at 0x0005 is used to communicate the values of the registers
Ewith the outside world. Register
Cselects from multiple functions:
C= 0x02 signals printing the value of register
Eas an ASCII value
C= 0x09 signals printing the value of memory pointed to by
'$'character is encountered
The easiest is to put an
OUT instruction at
0x0000 onwards, and an
IN followed by a
0x0005 onwards, and then set your emulator to do the right thing on port writes / reads.
I have implemented this protocol in a testbench for an FPGA Intel 8080 implementation inspired by a software emulator test suite; both of these could be useful references for you in implementing the scaffolding necessary to run these CPU tests without any complicated OS, or even any computer, around your CPU.