Fixing obscure 8080 emulator bug?

Question

I'm using cpudiag.bin from http://www.emulator101.com/files/cpudiag.bin to test my emulator. I've already implemented the CP/M CALL function at 0x05, offset the program at 0x100 and fixed the offset at byte 112 + 0x100, as per this site: http://emulator101.com/

I get the error:

 CPU HAS FAILED! ERROR EXIT=78=:

and added myself that there was a JMP to 0000 from 0x698. Here are the last 10 instructions run by the emulator before failing:

Instructions Ran: 79
Program Counter: 016C
Memory Immediate: 0xFA
Instruction: JM adr 71 1
Registers (B/C/D/E/H/L/A): 00 02 00 3D 01 DA 0A
Flags (Z/S/P/C/AC): 1 0 1 0 0
Stack Pointer: 7A7
Cycles: 724
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 80
Program Counter: 0171
Memory Immediate: 0xC6
Instruction: ADI D8 30
Registers (B/C/D/E/H/L/A): 00 02 00 3D 01 DA 0A
Flags (Z/S/P/C/AC): 1 0 1 0 0
Stack Pointer: 7A7
Cycles: 734
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 81
Program Counter: 0173
Memory Immediate: 0xC9
Instruction: RET
Registers (B/C/D/E/H/L/A): 00 02 00 3D 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7A7
Cycles: 741
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 82
Program Counter: 0160
Memory Immediate: 0x5F
Instruction: MOV E, A
Registers (B/C/D/E/H/L/A): 00 02 00 3D 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7A9
Cycles: 751
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 83
Program Counter: 0161
Memory Immediate: 0xC3
Instruction: JMP adr 4E 1
Registers (B/C/D/E/H/L/A): 00 02 00 3A 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7A9
Cycles: 756
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 84
Program Counter: 014E
Memory Immediate: 0x0E
Instruction: MVI C, D8 2
Registers (B/C/D/E/H/L/A): 00 02 00 3A 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7A9
Cycles: 766
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 85
Program Counter: 0150
Memory Immediate: 0xCD
Instruction: CALL adr 5 0
Registers (B/C/D/E/H/L/A): 00 02 00 3A 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7A9
Cycles: 773
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 86
Program Counter: 0005
Memory Immediate: 0xC9
Instruction: RET
Registers (B/C/D/E/H/L/A): 00 02 00 3A 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7A7
Cycles: 790
Interrupt enabled: false
Interrupt op:
-------------------
:Instructions Ran: 87
Program Counter: 0153
Memory Immediate: 0xC9
Instruction: RET
Registers (B/C/D/E/H/L/A): 00 02 00 3A 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7A9
Cycles: 800
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 88
Program Counter: 0698
Memory Immediate: 0xC3
Instruction: JMP adr 0 0
Registers (B/C/D/E/H/L/A): 00 02 00 3A 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7AB
Cycles: 810
Interrupt enabled: false
Interrupt op:
-------------------
Instructions Ran: 89
Program Counter: 0000
Memory Immediate: 0x00
Instruction: NOP
Registers (B/C/D/E/H/L/A): 00 02 00 3A 01 DA 3A
Flags (Z/S/P/C/AC): 0 0 1 0 1
Stack Pointer: 7AB
Cycles: 820
Interrupt enabled: false
Interrupt op:
-------------------
JMP to 0000 from 0x698

I'm new to emulating so could anyone give me a hint or point me in the right direction on how to debug this?

Edit: code https://github.com/hydratedcabbage/space-invaders

Answer 1

The General Advice Answer

For a failure that happens so quickly (at most 89 instructions) I'd recommend simply looking at what your emulator does at each instruction and determine if did everything correctly.

If the error occurs after thousands or millions of instructions then it would be more fruitful to compare it against an 8080 emulator that gets the correct output. Have the correct emulator and yours output the program counter for each instruction executed. When they differ your know your emulator made a mistake and it will likely be at the instruction or a few before it. Though not necessarily. Sometimes a mistake can be made, the results saved into memory and only when read back much later is the difference in program counter apparent. In those cases a full trace showing all register contents and values being read from or written to memory can catch the mistake quicker.

The Very Specific Answer

Here's the first two instructions you posted (slightly abridged):

Instructions Ran: 79
Program Counter: 016C
Memory Immediate: 0xFA
Instruction: JM adr 71 1
Registers (B/C/D/E/H/L/A): 00 02 00 3D 01 DA 0A
Flags (Z/S/P/C/AC): 1 0 1 0 0
-------------------
Instructions Ran: 80
Program Counter: 0171
Memory Immediate: 0xC6
Instruction: ADI D8 30
Registers (B/C/D/E/H/L/A): 00 02 00 3D 01 DA 0A
Flags (Z/S/P/C/AC): 1 0 1 0 0

Look very closely and you'll find that JM did something wrong. I'll tell you what that is at the end of the question to not spoil your examination.

The Using All We Know Answer

There's not really a need to trace. cpudiag.asm is designed to point out the general location of the error. Notice that it will run an 8080 instruction or two and if it doesn't get the results it expects a CALL CPUER is done. That routine is at 0x689 so you could stop your emulator when it reaches there and note the return address indicates which of the many CALL CPUER instructions was hit. Or even just detect CALL CPUER as a special case.

But cpudiag.asm tries to help you as much as possible. Looking at CPUER you can see that it is printing the return address after the CPU HAS FAILED! ERROR EXIT= message. Though instead of a hexadecimal address your emulator printed 78=:. In other words, it would seem your 8080 emulator is failing on the code to convert a binary value to hexadecimal in ASCII. Which is the BYTEO routine and in particular BYT02 which converts the bottom 4 bits of A register into an ASCII character.

However, looking at the 78=: we can come up with a pretty good guess what went wrong. Note that the code looks at the value in A register. If it is less 10 then 0x30 is added to A register. This covers the digits '0' through '9'. But if it is greater than or equal to 10 then we add 7 and then add 0x30. 10 + 7 + 0x30 = 65 which is the letter 'A' so that part is handling digits 'A' through 'F'.

The ASCII value for ':' is 0x3A. So one has to wonder if maybe the test failed and we didn't add the 7. And the '=' would correspond to 'D'. Meanwhile, the '78' seems odd. That is way beyond the end of the program so it can't possibly correspond to a CALL CPUER. In fact, the program fails so quickly I would doubt it has even reached 0x1FF. But if the test is wrong, 7 will be added to the decimal digits. A zero will become '7' and a '1' will become '8'. Aha, that address is probably 0x01DA.

We can immediately conclude that JM is backwards. Perhaps a copy and paste error from JP.

Moreover, we see that the CALL CPUER that failed is this one as its return address will be 0x01DA:

J040:   JNZ J050    ;TEST "JNZ"
        JC  J050    ;TEST "JC"
        JPO J050    ;TEST "JPO"
        JM  J050    ;TEST "JM"
        JMP J060    ;TEST "JMP" (IT'S A LITTLE LATE,BUT WHAT THE HELL!
J050:   CALL    CPUER

There are 4 instructions that jump directly to J050 and a JMP that goes over it. And of those instructions could be wrong, but JMP is likely right. And given that the hexadecimal output showed JM being wrong then I'll bet it is JM that is jumping to the CALL CPUER.

The Very Specific Answer Answer

The JM is taken even though the S flag is not set. That's wrong.

A Final Note

I started out by looking at the cpudiag.asm source code. The significance of CPUER was pretty clear and I got curious about where that exit code came from. Once I figured out it was the return address of the CALL CPUER instruction it got me wondering why your emulator wasn't printing out a hexadecimal address. At that point numerology pointed out JM in the binary to hexadecimal conversion routine and also gave me an address to look at what had actually failed. Then after all that I looked at your instruction trace and noticed by pure luck that the first instruction you listed made a wrong turn.

A reasonable approach, if you're familiar with 8080 code, and especially with writing it so you can see what a program would normally be expected to do. If you're new to 8080, then I think a lower-level inspection, as suggested in the "General Advice" section will be more fruitful.