screen 8 smooth horizontal scrolling

Page 5/11
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

By Grauw

Ascended (10619)

Grauw's picture

13-02-2022, 18:08

Sandy Brand wrote:

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.

Sandy Brand wrote:

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.

By ARTRAG

Enlighted (6862)

ARTRAG's picture

13-02-2022, 15:18

Grauw wrote:

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.

By Grauw

Ascended (10619)

Grauw's picture

13-02-2022, 18:09

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.

By ARTRAG

Enlighted (6862)

ARTRAG's picture

13-02-2022, 15:39

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" ?

By Grauw

Ascended (10619)

Grauw's picture

13-02-2022, 15:48

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).

By PingPong

Prophet (3901)

PingPong's picture

13-02-2022, 15:49

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.

By Grauw

Ascended (10619)

Grauw's picture

13-02-2022, 17:29

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.

By PingPong

Prophet (3901)

PingPong's picture

13-02-2022, 17:43

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

By Grauw

Ascended (10619)

Grauw's picture

13-02-2022, 18:07

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.

By ARTRAG

Enlighted (6862)

ARTRAG's picture

13-02-2022, 18:56

@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

Page 5/11
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10