dmg-acid2 VS gb-test-roms

My Game Boy emulator has almost passed dmg-acid2, except that it has the "Eye displayed instead of right chin" failure mode. The README says that this signals an issue with the "window internal line counter," but I don't see where that's documented. Can someone enlighten me?

I tested it with the classic dmg-acid2 test rom and another rom called sprite_priority.gb which is part of the Mooneye Test Suite.

For everything beyond opcodes, and especially graphics, the pandocs go over almost everything you need. For testing graphics, you can use the dmg-acid2 test roms which have tests for most of the common graphics errors.

Adequate PPU emulation (passes dmg-acid2 test). This emulator uses Pixel FIFO, as opposed to common scanline renderer.

acid-dmg, this is a really nice PPU test, you can try to complete it step by step.

Make sure you incorporate testing your implementation with test roms: https://github.com/retrio/gb-test-roms Do this as early in the project as possible. This will save you a huge migraine later on.

Have you tested your emulator against blargg's instruction timing test ROM? I believe this one only checks cycle counts, not memory timings: https://github.com/retrio/gb-test-roms/tree/master/instr_timing

Yeah the source for cpu_instrs is in github. https://github.com/retrio/gb-test-roms/tree/master/cpu_instrs/source

I actually have a question about this. I've been building a Gameboy emulator, the CPU works but when it runs the RET instruction the PC jumps to some really high address like 0x2000 or something when it's meant to jump to somewhere around 0x400 instead (after comparing it with another GB emulator). I think the RET address is meant to be read from HRAM, where the stack is stored, but when I look there it is the value around 0x2000 like I mentioned earlier. Are there any special quirks with this section of memory that I might not have implemented? I'm pretty much just reading and writing from an array for HRAM at the moment. I'm having the issue on one of blarggs cpu-instrs test roms https://github.com/retrio/gb-test-roms/blob/master/cpu_instrs/cpu_instrs.gb

So just start with implementing the CPU's fetch/decode/execute loop and a rudimentary memory bus, so that you can run simple test ROMs. You don't even need a display for many test ROMs (like Blargg's well-known test suite, which writes the results to the serial port as well as the display). After that you can do test-driven development (in a way) and focus on making more and more tests pass. Don't worry about details until you need to.

It looks like the test enables interrupts and then invokes the timer interrupt.