Can the game handle the situation that processing takes longer than 1 frame? Note that the turboR interrupt routine is quite heavy (but not sure whether you still call it).
If it would take more than an interrupt, there will be some flickering at the top of the screen. The only time this might occur is when the score is display (or the game over text).
I've run it on a emulated Turbo-R at full speed for some time, but did not experience crashes.
I wonder if somebody else can do testing on real hardware. Could be this particular Turbo-R has some hardware problem.
This is openMSX running a GT, which shows timing by changing the border color:
yellow: idle
green: game logic/drawing
red: music/sfx
purple: screen buffer dump
There is no way flickering should occur. I have more than enough "idle" time. I am guessing you are running from a slow rom somehow and it messes with timing of the Turbo-R.
Since it is not reproducible on OpenMSX, there is nothing I can do. I can send you the debug version, maybe you can make a video of the timing?
I did some tests on my TR ST with a GR8NET and SofaRun, and it detects the ROM as Linear. But after starting it I see the nop logo in the top of the screen and it resets. This was in Z80 mode, when I run it in R800 ROM mode, the game works but i'm missing the top of the screen (let say first 40 lines), it's just black (intro) or yellow (in the game). This was with 60Hz, with 50Hz game still resets in Z80 mode, but in R800 ROM mode it works and also the top of the screen is working.
Yes the turboR has a heavy penalty on VDP access in R800 mode. It enforces I/O to ports 98H-9BH to be spaced 54 cycles (@ 7.16 MHz) apart by inserting waits. This seems a bit more than strictly necessary; I guess they had their reasons. The wait is adaptive; if you do something else between the I/O, the wait is reduced accordingly, so use that to your benefit.
