Hi again,
Still having issues with nailing down accuracy on my gb emulator. Most games play, but some like the intro of prehistorik man have issues.
I know that stat mode 3 timing relies on sprites, Ive tried to follow this:
https://gist.github.com/drhelius/3730564but I find it too complex to understand. What I'm doing now is, when mode = 3, draw 1 pixel per cycle, so if a instruction took 12 cycles to execute, draw 12 pixels on that scanline until the lcd pointer reaches the 160 pixels. Since my stat mode 3 lasts 172 cycles, it always has some spare time.
What should be the correct procedure for drawing this, in simpler words than that document ?
Thanks !
No one ?
Ok, so how about how many cycles does it take to serve an interrupt ?
I read in different sources that it uses either none, 8, 12 or 20.
Which is the correct one ?
was wondering about that too.
This dude claims its 5m cycles:
https://github.com/Gekkio/mooneye-gb/bl ... y.markdown
I've seen that doc, which is very useful. But using 20 cycles to attend interrupts, breaks the big scroller demo (and several other games)
Weird that we are in 2015 and that information is not easily available
my gb emulator gets the same output as bgb with the big scroller demo. And im using 5M cycles for interrupts. Can you list more games that break for you if you use 5M for interrupts? Does your emulator pass the timing and cpu instruction test roms by blargg? And also rather than complaining gather your findings in a txt file and post it on emutalk and here.
Are you also aware of this document?
https://github.com/AntonioND/giibiiadva ... TCAGBD.pdf (not relevant to your questions though)
Ok, that was helpful .. indeed I ran that instr_timing test, and it fails, error is : timer doesn't work properly
Now, I've been debugging, and looks like my ff05 register is a little off comparing it to BGB. Weird, since I'm using cycle by cycle processing for memory accesses, and what I think may be off, is the instructions E0 and F0, which are used a lot in that rom to control access timings.
Both instructions take 12 cycles to process, I've tried counting it like this for F0:
add 4 cycles
read memory (reads 05 from immediate operand)
add 4 cycles
read memory and assign to A (read from FF00 + 05)
add 4 cycles
I tried these steps in different order, but still get different increments on the counter on FF05. This screws that test I think.
Im probably having the same issue with opcode E0, which I have it as:
add 4 cycles
read memory (reads 05 from immediate operand)
add 4 cycles
write A to memory FF05
add 4 cycles
Also of note, this rom doesnt use interrupts, so that timing shouldnt affect it.
I tried running the mem_timing rom, and it passes ok ..
Any idea how to accuretely do this ?
Thanks !
Hi,
I'm certain about the interrupt handling being 5 M-cycles. If using that duration breaks something, I'm afraid it means there's some other timings that are off.
I've had similar issues with my emulator a couple of times...it's unfortunately very typical that you change timing one way to fix something, and something else breaks.
I too was shocked that in 2015 we don't fully understand how the Game Boy hardware works. When I started my emulator, I was expecting to find the internet to be full of documentation, so I could just focus on coding the implementation. The developers of Gambatte and BGB have probably the best knowledge of things, but there is no easy to read or comprehensive documentation, and even those emulators are not right about everything.
Now, about your original question about mode 3 timings: no emulator in the world gets these 100% right, so my recommendation is to not focus too much on the precise timings unless you are willing to spend a huge amount of hours on research. I've deliberately left mode 3 timings a bit off in my emulator, because I haven't found any logic that satisfies all my test ROMs!
If you have any questions about how the GB hardware behaves, I encourage you to join #gbdev on Efnet and ask me things. I'm always eager to answer questions, and I will research an answer if I don't immediately know it
BTW, your timings for LDH (n), A and LDH A, (n) seem correct. In terms of M-cycles:
M=0: opcode read
M=1: immediate operand read
M=2: read/write to $FF00 + n
Is your emulator open source? I can take a look if it's on Github or a similar place
Thanks for your quick reply .. Im doing this as an exercise and the code is a mess (and in java), so no, its not public .. if you really want to check it, I can send it to you though.
Nah, that's fine. I understand if you feel a bit uncomfortable about making it public. My emulator was in a private repository for months before I had anything in Github.
So this is what Im doing with interruptions:
if IME is ON:
Turn off IME
4 cycles
4 cycles
Reset bit on memory 0xFF0F of current interrupt.
Write upper byte of pc to stack
4 cycles
Write lower byte of pc to stack
4 cycles
Change pc to interrupt vector
4 cycles
reset halted state to non halted.
if IME is OFF:
Reset halted state to non halted
Still, for some reason, with those 20 cycles, the big scroller demo screws. After drawing 25% of the screen aprox. the squares stop waving for the rest of the frame. If I remove those 20 cycles, it plays flawlessly.
Any ideas ?
Thanks
Anyone ?
I've got my gameboy hooked up to my logic analyser now, let me know exactly what you are after and I'll give you the real world data.
I want to know if the interrupt sequence timings is correct, as seen on my last post.
Thanks !
Can you write me a ROM to flash and then watch run on the scope? something like what you have listed with say, a SRAM read/write at the beginning and end of the routine?
That way I can tell you exactly how many clocks for each instruction, and unusual delays etc