my old test suite now crashes the emu
Closed this issue · 7 comments
http://notaz.gp2x.de/tmp/testpico.bin
IIRC it runs on real hardware and passes all the tests.
Source code to give you an idea what is being done (see t_32x_init()):
https://github.com/notaz/megadrive/blob/master/testpico/main.c#L1743
Seems like it doesn't like the way I initialize the 32X, which is likely different from how the games do it.
Ah ok, it's some different timing. I initialize the run function pointer on frame start, but that's apparently not enough for your test. I need to check if it's really worth to have this pointer at all. In the meantime, here's a kludge:
y.txt
Fixed with 3d7abd6, but I see 5 2 failed tests. Has this worked with older versions?
I tested with every release from 1.93 to 1.99, and none passes all the tests for me.
Has this worked with older versions?
No it hasn't. I used to have a relaxed version for the emu, but this one is the stricter one for hardware.
As for the failing tests, those 2 are timing tests:
- "time z80 vdp" starts z80 at line 0, asks it to read vdp 786 times in a loop and after that write vcounter to zram to see how much time it took. It looks like z80 is penalized for reading vdp too much. Similar test for ROM passes.
- "irq ack h-v" demonstrates that only single "move.l (a0), d0" can execute after VDP irq enable before the interrupt is taken. But this is problematic to do in PD as a comment in videoport.c still states...
- there's now stricter timing in place in several parts of the emu. This leads to "time z80 vdp" being extremely sensitive. It's working fine with a penalty of 2.55 cycles within a range of about 0,5% for the multiplier in cycles_68k_to_z80. That's pretty tight, and it doesn't fit with kabuto's result of about 3.3. Anyway, while I was at it, I also adapted the z80 68k bus r/w to 3.3 cycles, which is working fine.
- I played around with that value in videoport.c. Decreasing it by 1 passes this test, but unfortunately another test fails. I already have lots of problems in other places with not knowing how long the current instruction is taking. Hmm, probably only changing the instruction billing (doing it at the start of the emulated instruction) would help here. After all, the data r/w cycles are normally at the end of the instruction, so this would narrow the range from 4-36 down to 4-8 cycles. Apart from this being quite some work, I'm however pretty much sure it would lead to adjusting some timing all over the place, especially for the vdp.
With f61d0a4 it's down to "irq ack h-v" for me. This also includes better emulation of the z80 scanline calculation and improved wait states for accessing the 68k bus with the z80.
I can't see anything more I can do here for now, and the originally reported bug is resolved. Going to close this.
A remark for the bus access wait states: this should be included in the save state for libretro's runahead and netplay features. But then, save/load needs to be revised for this anyway.