Oh.... I have been working under the assumption that VDP R18 is safe to modify while a command is running as long as sprites are enabled? There seems to be now some contradicting info on http:// map.tni.nl/articles/vdp_guide.php and http://map.grauw.nl/articles/vdp_guide.php ?
The former is the old site location that hasn’t been updated anymore since 2009 when the MAP moved to its new location. It used to redirect to the new location, but I see it doesn’t do that anymore. Anyway, please only use the latter link, I’ve made 589 updates to the MAP since then.
Is this properly emulated on openMSX btw? I've been building some scrolls and experimenting with some more funky stuff and it appears to be safe to change VDP R18 while a VDP command is running and sprites are enabled? (Screen 5 btw).
This isn’t emulated in openMSX.
I just updated the MAP article :).
My theory is that r#18 offsets the timing of the access slots along the line counter, and if a byte was already enqueued and waiting for its slot, its assigned time slot cycle index is updated immediately while the VDP’s display pixel counter latches r#18 at the start of the next line. This misaligns the slot cycle index and makes it conflict with a VDP display VRAM access or refresh and corrupts.
For a while (in the past) I've been experimenting about changing R18 while the raster is in the border during the horizontal retrace (HR set in S2). It seemed to not solve the glitch but I am not able to say if my test code was really correct or if I was setting R18 value too early or too late w.r.t. the horizontal retrace.
If you change the r#18 horizontal offset rapidly during active display, you can see the bottom half of the screen jump up and down a little, too, even though the vertical offset is not changed and also normally only takes effect on the next frame. This suggests that under specific timing conditions, it can cause the VDP to skip (or is it double?) a line.
BTW, I have an off topic curiosity about the name of the flag FH (horizontal scan flag) in S1.
It is set when the VDP scans the line specified by R19....
So why the name "horizontal scan" ?
Because it triggers on the horizontal scan signal (on the left/right side of the screen) as opposed to the vertical scan signal (on the top/bottom side of the screen).
I've just guessed something like this, the correct aligning should occour at the next scanline.
It would be interesting to make a kind of test to prove that.
i think that there should be a small interval from one scanline to the next when the vdp engine is stalled, to ensure the "realigning". Maybe finding the right time to update the R18 after the horizontal retrace could make the problem to disappear?
But i do not know how to make a similar test program.
Here is a test program which cycles through four different stages:
1. Full screen copy while r#18 horizontal offset decrements, sprites enabled.
2. Full screen copy while r#18 horizontal offset increments, sprites enabled.
3. Full screen copy while r#18 horizontal offset decrements, sprites disabled.
4. Full screen copy while r#18 horizontal offset increments, sprites disabled.
As you can see the corruption gets progressively worse. It exists when sprites are enabled, but is worse when they are disabled. Additionally, you can also observe the other quirk that is described on the MAP; when sprites are disabled, some lines blank out (or worse). Lastly you can observe that the height of the display area varies (grows), meaning that with the right timing the VDP starts to draw lines multiple times.
thanks, but my idea was to create a program with the purpose to investigate a way to avoid this (without having to wait for a command end).
Most probably, there is a little chance that even a cpu access could get corrupted but probably due to the slowness of the I/O VDP port protocol no one will observe this
Ah, it wasn’t meant as a reply to your post, for what you wanted to try out.
I wanted to verify the findings I had written down on the MAP originally, which was many many years ago. I think the test gives a nice insight in how the VDP acts under different circumstances. E.g. the lower frequency of the corruption when sprites are enabled probably explains why I had originally thought that it was only a problem when sprites were disabled. And I was also able to confirm that the temporary line “blanking” behaviour does indeed only occur when sprites are disabled, even though that seemed oddly inconsistent.
It may also be useful as a test case to improve emulation.
@Grauw
what about testing HR before setting R#18 ? Something like this
ModifyR18: PROC ld a,2 di out (VDP_PORT_1),a ld a,15 | VDP_REGISTER out (VDP_PORT_1),a waithr: in a,(VDP_PORT_1) and 32 ; HR jr nz,waithr xor a,a ; set Status Register #0 for reading out (VDP_PORT_1),a ld a,15 | VDP_REGISTER ei out (VDP_PORT_1),a ld b,0 ld c,VDP_PORT_1 ld d,18 | VDP_REGISTER ld e,0FH Loop: ld a,b and e reverse: equ $ cpl di out (c),a ei out (c),d djnz Loop ret ENDP
[edit]
Maybe this is not the best test, as the loop would last longer than the horizontal retrace