- on STE it's easy to solve as on Falcon : during your VBL int, just
write the new video address to ff8205/07/09 ; you need to do this before
the end of top border (ie line 63 on 50 Hz screen). These 3 bytes are
not writable on STF but they are on STE.
Oh, right. Nice trick!
- on STF, you must write the new screen address for vbl 'n' during vbl
'n-1', else if you write the new address during vbl int 'n' it will only
be applied when vbl 'n+1' starts.
Indeed.
- the write happens before end of current VBL, then it's ok, it will
be taken immediately when next VBL starts.
What about the other problem I've mentioned - i.e. the frame will be rendered *exactly* at the line 309.9, I set $ffff8201 but then the reload happens and $ffff8203/0d will be ignored? Is it possible to happen on the ST? (it's not rhetorical question, Jo Even could observe the very same thing when developing his game "L'Abbaye des Morts" on Falcon before he started waiting for vbl - the screen would render 99 times okay and then suddenly jump on the 100th time).
this can be a problem because you can't write to the 2nd buffer as it
will be displayed next. but you can't write to the 1st buffer either as
it's possibly being displayed for 1 extra VBL.
Easiest solution : use triple buffering to ensure you always have 3
buffers :
Funny you mention it, I'm testing my triple buffer solution in Hatari in ST/E mode to make sure I got it right (Falcon mode is not precise so I can't rely on it) but wanted to make sure that I get double buffering right first.
I'm really surprised how difficult this is on the ST, I thought that it's just me being dumb. I wonder how it is solved in games which were typically not 1VBL... maybe they got a constant time per frame?