Requirements for running blarggh's tests
Page 1 of 1

Author:  MegaBoyEXE [ Tue Jul 04, 2017 10:40 am ]
Post subject:  Requirements for running blarggh's tests

Hello, I've started my adventures in emulation a few days ago. I still didn't finished implementing all instructions and almost didn't touched PPU stuff yet.
The implemented instructions are enough to get blarggh's tests start running.

But it seems it entered a loop before even starting doing actual tests part. I'm grabbing the link port dbg prints as I don't have a LCD emulation yet, and it keeps looping forever printing the same test name over and over. I know this because I'm buffering the output before printing to console, and clearing right after.

My memory access has very basic stuff yet:
- does not write if address is < 0x8000
- link port dbg:
 if (aAddress == 0xFF02 && aValue == 0x81) { dbgStringBuilder.Append((char)Read8(0xFF01)); }

I tought it was related to register LY, so I added a scanline counter and resetting it when reaching 153 or if code tries to write to 0xFF44, but it seems to not have any effect. (Well, Tetris was looping before, and after LY counter it eventually broke out from the loop and reached some unimplemented instructions, so I know LY does works too)

So I got bored of not knowing if I was missing something and went reading from VRAM to learn how to draw tiles. The LCD does not work, I'm just reading the tileset and rendering tile by tile, completely unrelated to emu itself.


So, is there any other requirement to get blarggh's tests (the individual cpu_instrs ones) running besides instructions and simple memory? Because I don't know if there's actually an error in instructions or if it's just a part required that I'm not doing yet.

Author:  Shonumi [ Wed Jul 05, 2017 5:35 am ]
Post subject:  Re: Requirements for running blarggh's tests

Honestly speaking, the problem could be anywhere. Even if you had all the basic requirements necessary to run blargg's tests (i.e. a complete GBZ80, some interrupts, timers, LCD rendering, etc), if you implemented something incorrectly, that would mess other things up.

I would highly encourage you to make a debugger of some sort, even if it's just command-line only. I can't stress enough to others starting any kind of emulator project: a debugger is one of the first thing you should add. Otherwise you could potentially spend a lot of time running in circles. Ideally, at a minimum, you should be able to step through your emulator one instruction at a time and print out the current register values as well as the opcode. Printing the value of specific memory locations is very helpful as well. Once you have all of that, you can actually see where your emulator is getting stuck in a loop (e.g. it reads a certain memory location that expects a non-zero value, but it's unemulated and you return zero, that's a pretty common issue).

As for your serial port debugger, it looks like it only returns the value of 0xFF01, correct? Or are you putting your own information in 0xFF01 and reading that? If it's the former, I don't think any of blargg's test rely on any serial input-output, so looking at 0xFF01 isn't entirely helpful. In reality, only a small handful of games (like the Japanese game Boxing) require any sort of emulation of the serial port.

Author:  MegaBoyEXE [ Wed Jul 05, 2017 1:25 pm ]
Post subject:  Re: Requirements for running blarggh's tests

Thank you for your reply! I'm following your progress with bar code emulation and RE! Wishes good luck on that! It's pretty inspiring seeing people today still trying to everything available for GB being properly emulatated!

Now about your comments, a simple command line log for CPU state was one of the first things I have done, so I could compare if the jump and ld instructions were actually doing the same as BGB for example. I endorse your recommendations about debbuger being important, and everyone should do it together with the the CPU emulation as you advance.
I'm lacking a properly breakpoint feature, I'm doing a hardcoded check of PC address, but it worked for now.
But as the CPU started running most of the instructions, debugging step-by-step start to become very hard, and this is the right time to add support for breakpoint features.

The current loop it got stuck is pretty big (hundreds of instructions and function calls, that start to repeat after), and it involves several function calls, so it's being a little difficult to compare with BGB to know why BGB breaks out and mine doesn't.

About the serial "debugger", the tests writes the same strings it draws in the screen to the serial port, so I could get the test result even without a properly emulated LCD.
For example, I'm receiving "06-ld r,r\n" from the test, which is actually the test I'm running.
I was expecting to receive "Failed" or "Passed" aftewards, but this is where the loops is occurring. It redo all the same routines and prints again the test name, as if it didn't finished, or is waiting for something (an interrupt maybe, or checking a hardware register that I'm not emulating yet?) That's why I asked if things like interrupt are required to get the test to complete.

But I will finish implement all the instructions first, I'm halfway done (actually found a bug in rla and rra when I was implementing the missing shift and rotates ones: you can see on the screenshot that the "Nintendo" tiles in the set are not right, because the rla/rra instructions were affecting the tiles decompress routine).
After having all instructions done, I will start to write test roms to debug instructions operations (I may have switched register names or forgot to writing to memory back when accessing doing "? [HL]" instructions).

Anyway, thank you very much for your time! Good luck with your emulator too!

Author:  MegaBoyEXE [ Sat Jul 08, 2017 3:45 pm ]
Post subject:  Re: Requirements for running blarggh's tests

Found the big culprist while writing unit tests for instructions!
I was tricked by the mnemonic of instruction "JP (HL)", that actually does PC = HL, and I was doing PC = mem[HL].
I look to myself, and feel pretty dumb now :oops: .

1. Why would I load to PC a 8-bit value????
2. Didn't I noticed that the clock cycles for this instruction is 4, which means that there's no memory access at all????


There are some weird behaviour at the log received (might have more instructions errors of course), but at least the loop issue was fixed!

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group