ARTRAG: openMSX (and other emulators) and/or the script you're using are not 100% bugfree, I suspect your game still includes one or more uncaught too fast VDP accesses.
I guess I could add a VBLANK check on MSX2, using one of its status regs (thanks mth for the hint). Useful?Yes. I think that would be very useful.
Well, try it yourself. Take the original script and look how the screen_enabled is done. Add a new variable in_vblank with the proper expression to read the VDP status register and use this variable in the check expression.
Let me know what problems you run into and I'll help you to solve them.
jltursan
thanks for the hint, I will test if disabling custom palette or other "msx2 upgrades" solves on msx1.
hap
I think instead that I'm facing some bit in VDP registers in exotic configuration,
the script actually finds all the outs.
The only register related thing I can think of is bit 7 of register 1 (the 4k/16k bit). That's testable in meisei by setting the VDP to TMS9918A or TMS9929A (file->media->internal).
Note that the Tcl script only checks the timing of writes to IO port 0x98. If you want to check both TMS99x8 ports, you can replace 0x98 with {0x98 0x99} (this syntax sets a watchpoint on a whole range of ports). If you also want to ensure there is enough time between a write and a read, you need to add a read_io watchpoint on the port (or port range) as well.
Also the script checks the time from write-to-write. It does not only count the amount of cycles for the instructions *between* the two OUT instructions. In other words for two OUT (#98),A instructions directly following each other, it reports a time of 12 cycles, not zero cycles. I don't know if these 26 or 29 cycles are from write-to-write or the required time between writes.
Wouter has a good point. If you're mixing out ($98),a out (c),r outi you need to do something slightly different. I do the same tests in blueMSX with a patch I apply when I need to (sorry for not making it a standard feature) and it tries to measure the time of the actual write, not start of the out instructions. Not sure when openMSX triggers. If you want, I can try to run your game with my patched emulator to see if I get a different result.
Another problem I've seen btw, on real HW, is when I do outs in regular program and have an interrupt that e.g. reads status or do some minor vram updates. So you could check that you have di/ei's arround all vram updates (including setting up the vram write pointer).
I do not know what the script measures, as it is an internal aspect of openmsx, anyway
I think that it measures exactly the time between the actual write, as the event seems
triggered on the use of the port and not on the "out" instruction.
About the di/ei problem, it should also randomly happen on the emulators...
Anyway if you are available to test the rom (DDA chart ready) it will be a pleasure to
share it with you.
... I think that it measures exactly the time between the actual write, as the event seems
triggered on the use of the port and not on the "out" instruction.
That's correct, the callback is triggered right after the write to the IO port is done, so somewhere during (near the end of) the OUT instruction, any kind of OUT instruction. Or in other words, the callback is triggered at the exact moment in time, the VDP sees the write.
