Gameboy Development Forum

Hi. When a test fails, the test prints a bunch for numbers with diagnostic information before it prints "Failed". If you wait long enough (assuming your emulation is good enough to run the test to completion) you should see "Failed" eventually. Normally, the debug numbers are hex numbers. I would first suspect that something goes wrong in the test's hex conversion function. It looks like this:

; Prints A as two hex chars and updates checksum
; Preserved: BC, DE, HL
print_hex:
     call update_crc
print_hex_nocrc:
     push af
     swap a
     call +
     pop  af
     
+    and  $0F
     cp   10
     jr   c,+
     add  7
+    add  '0'
     jp   print_char_nocrc

If you look at what the garbage characters are, it turns out that they are the ASCII characters directly following 9. (See for example ASCIItable.com for a quick ASCII reference.) This pretty much narrows down the problem to two instructions, and the carry flag in particular: cp xx and jr c,xx.

For example:
cp xx doesn't set the carry flag correctly.
cp xx inverts it from its real value.
jr c, xx always jumps.
jr c, xx only if c is not set (ie the inverse of what it should do).

Btw, Blargg's tests are designed to be useful for emulation development. For this reason, the values written to VRAM are mapped to the corresponding ASCII values. So if you place RAM on $8000-$9FFF, you can just dump $9800-$9BFF as ASCII characters to the console to see the current log output. (Though that wouldn't help in this case since that data would have the same corruption discussed above.) (Or, more like print (value & 0x7F) because there's a second set of characters with inverted colors which are mapped to the corresponding ASCII value but with bit 7 set.)

That does not look right. You are too eager in you bit masking, which makes carry fail for sub/cp. Consider the trivial example of A==0, and executing cp 1. This should set carry. c gets set to carry(0,-1).

Now follow the execution:
(x & 0xFF) == 0
(y & 0xFF) == (-1 & 0xFF) == 0xFF
0xFF & 0x0F00 == 0 which is not greater than 0 and c gets cleared (incorrectly). Rethink your carry function, or maybe have a separate carry function for sub/cp.

If you've got the byte order right, your problem is probably that you're not masking the flag bits. The lower 4 bits of F are always zero. (Or put differently, those bits don't exist but are written as zero when you push AF.) So in push AF try masking like this:

            sp = (sp - 2) & 0xFFFF
            write16(sp, af & 0xFFF0)

Also, word from the wise: if you're planning to make the emulator cycle accurate, you want to perform push/pop as two separate writes, forward the clock and have some sort of planning on how to process events in the middle of an instruction. Consider the following:

You push/pop in VRAM, and VRAM goes from being accessible to inaccessible in the middle of the instruction.

You have SP set to for example IO register space ($FF00-$FF7F) or ROM in one of the MBC regs and push/pop. Which byte gets read/written first and what effect does it have?

These are things that most games don't do, certainly not deliberately, but there sure are test ROMs to call them out, and they might theoretically matter for situations where a game is buggy and crashes in on case and doesn't in the other.