As I mentioned in other threads, I'm working on a Gameboy (and later Gameboy Color) emulator. I've got a good bunch of games running but there are still problems that I think could be CPU related and not Gameboy emulation related. On the NES I was able to take advantage of Blargg's CPU Test. I've seen no such thing for Gameboy so I'm wondering if anyone has any good ideas for debugging? I know I can always go through each opcode one by one trying to spot errors but this will take awhile so I was just wondering if anyone had any tips.
Also if you have any ideas of something I could have been confused about and done wrong that I should check for, please let me know.
This tests a good number of instructions (wla-dx source included):
gb_cpu_test.zip
I'm interested to know if the CPU really does have 4 T states to a single cpu cycle or if that was just assumed from some docs. Similar to docs for the z80 that are incorrect and/or don't give the T state counts or reduced/extended T states for some situations.
I'm not sure exactly what you mean, but the Gameboy documents are pretty strange with Cycle counts. Sometimes people say something takes 1 cycle, others say that same opcode takes 4 cycles. Not what you want to get mixed up when you are trying to sync the PPU and CPU. Originally I did this with a 4x gap, so the PPU ran 4 times faster than it should, or you could say the Cpu ran 1/4th the speed it should.
Yeah, I didn't have much luck either trying to find GB/GBC cycle counts. It'd be nice if there was some straight forward documentation about such things.
Well, on the Z80 you have the instructions listed in M cycles. Most docs list M cycle as 3 (or 4 depending on the doc) external clock source cycles, but really M cycles don't show the whole picture. An M cycle is made up of a variable accumulation of T states depending on the operation and also depending on the previous instruction from what I've read.
On the GB docs, they list an M cycle as 4 external clock cycles and instruction timings are given in M cycles. Since the GB cpu is a variant of the z80, who's to say that the same misunderstanding isn't applied to it was well. There are many processor documents with incorrect instruction timing information out there, so this would be the first if it were true.
Is there a list of what the expected values for A and F are for each iteration of the DAA test?
This code matches execution on a DMG/CGB. Flag bit masks below are named by flag name and hex value, for clarity.
Code:
if ( !(flags & N40) )
{
if ( (flags & H20) || (a & 0x0F) > 9 )
a += 6;
if ( (flags & C10) || a > 0x9F )
a += 0x60;
}
else
{
if ( flags & H20 )
a = (a - 6) & 0xFF;
if ( flags & C10 )
a -= 0x60;
}
flags &= ~(H20 | Z80);
if ( a & 0x100 )
flags |= C10;
a &= 0xFF;
if ( !a )
flags |= Z80;
Ah, cool. Now I get "01-- 02". So I take it everything passed, but what does the 02 mean in that case?
This is the correct result:
Code:
01-- 02-- 03-- 04--
05-- 06-- 07-- 08--
09-- 10--
Passed all tests
The -- are where an error code would be printed if that test failed. The test numbers correspond to the files in source/, for example test 02 is instruction timing. It takes a while to run all the tests.
Code:
- nop ; 12
nop
nop
wreg IF,0 ; 20
lda IF ; 12
bit 2,a ; 8
push af ; 28
pop af
jr z,- ; 12
I thought writing 0 to IF would reset all bits in IF. In that case, how is this loop ever supposed to finish? Is it waiting until a timer overflow occurs right after "wreg IF,0"? Because that seems like it could take a while, if it ever happens.
It's just my standard exact-synchronization loop. In timing.a, timing_init sets the timer to run every 96 clocks. The loop takes 92 clocks per iteration, so at most it could take 24 iterations before the timer expires within that critical window. By adjusting the delay after the coarse synchronization loop, worst-case is reduced.
How do you find out which subtest is failing in those tests that doesn't use set_result? E.g. if subtest 02 of test 07 fails, which instruction is that?
Argh, I just noticed I already built each one individually, in the individual/ directory. If a main test fails, run that one individually to get the full output.
On the tests, instructions E8 and F8 fail in both VBA and Goomba Color. What is the correct behavior for those instructions?
Edit: This indeed is for the GB-Z80, not the Z80.
E8 is RET if parity is even, F8 is RET if minus flag is set. Perhaps they're not setting the parity and minus flags properly.
Mods: please split this non-GB-Z80 CPU discussion off.
bumping thread due to an edited post
Oh, GB-Z80. Those are:
E8 ADD SP,+$00
F8 LD HL,SP+$00
Both of these set carry and half-carry based on the low byte of SP added to the UNSIGNED immediate byte. The Negative and Zero flags are always cleared. They also calculate SP + SIGNED immediate byte and put the result into SP or HL, respectively.
Thanks, fixed those instructions in Goomba Color.
Now I just get "Failed 06" in the 01.custom test program.
Looking at source/01.custom.a, I see that is for DAA. So you haven't yet implemented the DAA flag handling I outlined earlier?
Fixed DAA, got everything working except for Timing, which would be because the TIMER isn't emulated correctly.
The weird thing is that now that I've fixed the instruction timings according to pandocs, test 2 (the timing test) never finishes. It even stops generating timer overflows after a while.
If I just change the timing of "ADD HL,rp" to something other than 8 cycles the test will finish (but it obviously fails all those instructions).
For whatever reason, I had set the length of "SBC (HL)" to 2 bytes, so everything went bananas after that.. Now all that's left are a few subtests of tests 6, 7, 8 and 10 (I think my H-flag calculation for SBC might be incorrect, which is causing a few of those errors).
I've made a number of improvements to the CPU tests:
cpu_instrs.zip
instr_timing.zip
mem_timing.zip
- Split instruction timing from CPU behavior tests
- cpu_instrs now tests all instructions except STOP
- instr_timing now tests all instructions except HALT and STOP
- Added new memory access timing tests that test which cycle reads and writes occur (except stack and PC accesses)
- Improved documentation and added summary of how each test works
- Included source has been tested to assemble on its own with wla
- All ROMs also print output to the game link port, and will work even with no LCD support (rather than hanging)
Please note that while I've tested the underying code on the DMG and CGB, I can't test the exact ROMs included since my devcart doesn't have rewritable ROM. Internally I still copy the test code to internal RAM at $D000 before running it there, as my devcart does, so there's very little difference. Even so, having someone test these with a flash cartridge would be appreciated.
Thanks for trying and giving feedback on previous versions of these!
EDIT: fixed ROM header checksums so they work on hardware, and moved to file host that's working.
Quote:
Even so, having someone test these with a flash cartridge would be appreciated.
I might be able to do that next week sometime, unless someone else comes through.
Here are my results (from a CGB):
cpu_instrs: Doesn't run
instr_timing: passes
mem_timing: Doesn't run
By "Doesn't run" I mean that the GAME BOY logo is displayed and the beep is played, then nothing happens. It just continues to show the GAME BOY logo. Maybe something went wrong when I programmed my flash cart, I dunno..
Thanks for testing; I found the problem to be an incorrect checksum in the header. I re-uploaded the fixed files (to a new host).
Any chance of a mirror download to these test ROMs?
all the links seem broken.
Thanks.
Updated links (also updated earlier message):
cpu_instrs.zip
instr_timing.zip
mem_timing.zip
Thank koitsu for providing me reliable space here on parodius.
Brilliant!
Thanks for these!
Again, sorry for the necro, but this board seems to be a graveyard.
During the instruction timing test, I receive an error:
"Failed #255"
I'd really appreciate some clarity on this error (The previous test passes 11/11 also)
Try looking through the source code for that test.
MottZilla wrote:
Try looking through the source code for that test.
Turned out the Timer sync wasn't working properly because I wasn't adding cycles for taken CALL, RET, and JR instructions. But now the test is saying that I'm using extremely large timing values (on the order of 255) instead of the expected times. So, as with all emu dev: fix one thing, break another.
The problem with these tests is if certain things are wrong the test is unreliable anyway. It may be better to test with game software.
It took some doing but I finally figured out the problem, I wasn't handling the cases where more cycles are added to my TIMA frequency timer than were being remove (262,144 hz frequency was doing this, and also happens to be the speed used by the tests). So it all boiled down to changing an if statement to a while statement.
Did you figure out it was the timer by looking through the test's source? Just curious.
I noticed that 262,144hz was pretty fast and checked my timers during runtime, and sure enough there were many unspent cycles.
The source was pretty hard to follow, but I'm not complaining, at least the tests exist