If we look at the table I posted from the TMS manual:
- during display area in mode 1 & 2, the VDP wait time can be 8µs max, so 28.63 T-states, which gives the 29 T-states we all know.
- during vblank, the VDP wait time is down to 2µs max, so 7.16 T-states, and that gives 8 T-states. But it's only 4300µs (15392 T-states) after the VBLANK interruption, which is long after the BIOS ISR has ended (the average BIOS ISR on MSX1 takes about 6700 T-states). That's why it's not safe.
It's probably the reason why some of them worked in 50Hz. The time of the interrupt rouitne and vblank may vary depending on the MSX used.
If we look at the table I posted from the TMS manual:
- during vblank, the VDP wait time is down to 2µs max, so 7.16 T-states, and that gives 8 T-states. But it's only 4300µs (15392 T-states) after the VBLANK interruption, which is long after the BIOS ISR has ended (the average BIOS ISR on MSX1 takes about 6700 T-states). That's why it's not safe.
I think the table has to be interpreted differently (the word "after" is deceiving) :
That 4300 µs is your total Vblank time (on a 60hz 9918) and in that timeframe (from interrupt until 4300 µs after interrupt) you have no "speedlimit".
I think the troubles gdx mentioned here come from games that thought they were still in Vblank, but actually weren't. This may be the case when you program and test on a 50 hz machine (with a much longer Vblank period) and then run it on a 60hz machine; or it may be caused by differences in length of the BIOS ISR (e.g. if you wait untill the jiffy variable changes, you are not at the start of Vblank anymore, but some 6700 (and this might differ on different machines?) T-states underway)
I think the table has to be interpreted differently (the word "after" is deceiving) :
That 4300 µs is your total Vblank time (on a 60hz 9918) and in that timeframe (from interrupt until 4300 µs after interrupt) you have no "speedlimit".
I did not interpret the table that way, but indeed, it might be the case ...
I did not interpret the table that way, but indeed, it might be the case ...
Ok, then I misinterpreted your interpretation, haha
But anyway, I'm 99,9% sure that if you use unrolled OUTI or OTIR during the VBlank period that you are safe and good to go. Things go wrong when you think you are still in VBlank, but in reality the beam is already on the screen again...
Looking back at this thread: https://www.msx.org/forum/msx-talk/development/is-a-msx2-machine-slower-than-a-msx1-one?page=0 the ISR can take somewhere from 871 cycles up to 5310 cycles. So the usable Vblank period after your ISR may be varying from about 26500 cycles on a 50hz msx1 (best case) to 10000 cycles on a 60 hz msx2 (worst case). That is a big difference !
that's why I'm not a BIOS ISR person.
I really think that 4300micro is the non-visible screen part. In normal case, that's right after vblank. now, change r#23 (vertical scroll), and things change. (MSX2, I know, but for arguments sake)
Doing some rough math.
1/50 of a second a whole screen gets refreshed. That's 0,02sec.
With 256 screen lines that makes 0,02/256=78,125microSec per line
4300/78,125=55 -> those are the non-visible lines approx. (192 visible lines iirc)
so yeah, makes sense.
One line takes 228 CPU cycles (63.7 µs) on both PAL and NTSC. Horizontal scan frequency is 15700 Hz. Calculate as 3579545 Hz / 228.
PAL vertical height is 313 lines, with 192 display lines this leaves 121 lines invisible in the border.
NTSC vertical height is 262 lines, with 192 display lines this leaves 70 lines invisible in the border.
PAL vertical blanking lasts 27588 CPU cycles (7.71 ms). Calculate as 121 * 228.
NTSC vertical blanking lasts 15960 CPU cycles (4.46 ms). Calculate as 70 * 228.
PAL display frequency is 50,16 Hz (19.94 ms). Calculate as 15700 Hz / 313.
NTSC display frequency is 59,92 Hz (16.69 ms). Calculate as 15700 Hz / 262.
This applies to all MSX VDPs, it is the same for Texas Instruments, Toshiba and Yamaha ones. The line counts and horizontal scan cycle count can be found in the application manuals.
Yes, but in practice it's a bit more complicated. ISR routine may be slightly different from MSX to MSX and I/O instructuctions may take more or less time. So we also have to plan wide so as not to exceed the vblank.
