vdp corruption

Page 2/5
1 | | 3 | 4 | 5

By Thom

Hero (595)

Thom's picture

25-11-2019, 19:14

Have you tried on another real MSX2(+/TR)?

By Victor

Champion (470)

Victor's picture

25-11-2019, 19:54

I think that the problem could be a TOO fast access to the VRAM...

I had in the past a similar issue doing something like this:

OUT (98h),a
OUT (98h),a
OUT (98h),a
OUT (98h),a

By gdx

Prophet (3163)

gdx's picture

26-11-2019, 01:09

Victor wrote:

I think that the problem could be a TOO fast access to the VRAM...

I never had this problem with the V9938 / V9958, only with TMS.

By Grauw

Ascended (8615)

Grauw's picture

26-11-2019, 10:32

I’ve had issues with accessing V9938 too fast on two occasions, it is definitely possible:

1. Writing to VRAM with back-to-back outi in screen 0 width 80. The access timing requirement for this mode is actually slower than the worst of TMS9918 (> 8 ms). otir works fine.

2. Writing to VRAM with back-to-back out (c),r in screen 5 with sprites enabled during VDP command execution. I was outputting sprite attributes like normal, they started to corrupt when I walked to a place where it was doing VDP commands. I’ve since added a single nop between the outs to fix it.

However, since VRAM corruption is permanent and in this case the artifacts only last for one frame, if it is VRAM corruption it must be from something which is rewritten every frame such as the sprite attribute table.

By gdx

Prophet (3163)

gdx's picture

26-11-2019, 10:59

I have already made direct accesses to display texts and I have not noticed any problem even in R800 RAM mode which is the fastest. Maybe the transfers I made are not numerous enough to cause problem. Or, there is another reason (VDP revision or other). By cons I fixed several games (The Cure, etc) because otir caused graphic glitches but in screen 2. So I'm sure that otir causes problem with the TMS9918 at least in screen 2.

It's possible that there are problems during VDP command execution. I may have never tried.

It would be interesting to clarify these issues with examples.

By PingPong

Prophet (3495)

PingPong's picture

26-11-2019, 11:01

@Grauw:

Quote:

1. Writing to VRAM with back-to-back outi in screen 0 width 80. The access timing requirement for this mode is actually slower than the worst of TMS9918 (> 8 ms). otir works fine.

This is as expected in vram timings document. Even i cannot figure why one require to write so fast to vram in a screen mode that manage so small data per screen like screen 0..... fortunately this only happen in screen 0 mode, would be worse if this was an issue on bitmapped modes where one need fast access to balance the higher amount of data to push on screen.

Quote:

2. Writing to VRAM with back-to-back out (c),r in screen 5 with sprites enabled during VDP command execution. I was outputting sprite attributes like normal, they started to corrupt when I walked to a place where it was doing VDP commands. I’ve since added a single nop between the outs to fix it.

This is unexpected. From the vram timing analisys this should not happen: if a command is in progress and you out to vdp the command will be stalled. I think the problem should appear even without command in progress.....

By Grauw

Ascended (8615)

Grauw's picture

26-11-2019, 12:23

gdx wrote:

I have already made direct accesses to display texts and I have not noticed any problem even in R800 RAM mode which is the fastest.

Quite the contrary, in R800 mode a 54 cycle (7.5 µs) wait is enforced so there is no way to output to VRAM faster than that. On Z80 out (98h),a takes only 12 cycles (3.4 µs), and outi takes 18 (5.0 µs). So using the R800 is not a good way to test VDP timing limitations, it is actually slower than the Z80 for bulk VDP access. Always run in Z80 mode when you do these tests, and preferably not on a machine with an T9769 engine that inserts 1 or 2 wait cycles on VDP access even in Z80 mode.

By the way I looked at the openMSX timing documentation and I think I was incorrect in saying that TEXT2 was slower than on TMS9918. Even though that’s what I distinctly recall. Maybe it was slower than TMS9918 in TEXT1 40 columns mode.

Either way, minimum VRAM access time in TEXT2 is 5.4 µs, so outiis too fast.

PingPong wrote:
Grauw wrote:

2. Writing to VRAM with back-to-back out (c),r in screen 5 with sprites enabled during VDP command execution. I was outputting sprite attributes like normal, they started to corrupt when I walked to a place where it was doing VDP commands. I’ve since added a single nop between the outs to fix it.

This is unexpected. From the vram timing analysis this should not happen: if a command is in progress and you out to vdp the command will be stalled. I think the problem should appear even without command in progress.....

Quoting the openMSX documentation: "16 cycles in advance of an access slot the VDP checks whether there is either a pending CPU or command request."

So this extends the maximum wait time by 16 cycles when a VDP command is active.

By PingPong

Prophet (3495)

PingPong's picture

26-11-2019, 12:31

Grauw wrote:
gdx wrote:

I have already made direct accesses to display texts and I have not noticed any problem even in R800 RAM mode which is the fastest.

Quite the contrary, in R800 mode a 54 cycle (7.5 µs) wait is enforced so there is no way to output to VRAM faster than that. On Z80 out (98h),a takes only 12 cycles (3.4 µs), and outi takes 18 (5.0 µs). So using the R800 is not a good way to test VDP timing limitations, it is actually slower than the Z80 for bulk VDP access. Always run in Z80 mode when you do these tests, and preferably not on a machine with an T9769 engine that inserts 1 or 2 wait cycles on VDP access even in Z80 mode.

By the way I looked at the openMSX timing documentation and I think I was incorrect in saying that TEXT2 was slower than on TMS9918. Even though that’s what I distinctly recall. Maybe it was slower than TMS9918 in TEXT1 40 columns mode.

Either way, minimum VRAM access time in TEXT2 is 5.4 µs, so outiis too fast.

PingPong wrote:
Grauw wrote:

2. Writing to VRAM with back-to-back out (c),r in screen 5 with sprites enabled during VDP command execution. I was outputting sprite attributes like normal, they started to corrupt when I walked to a place where it was doing VDP commands. I’ve since added a single nop between the outs to fix it.

This is unexpected. From the vram timing analysis this should not happen: if a command is in progress and you out to vdp the command will be stalled. I think the problem should appear even without command in progress.....

Quoting the openMSX documentation: "16 cycles in advance of an access slot the VDP checks whether there is either a pending CPU or command request."

So this extends the maximum wait time by 16 cycles when a VDP command is active.

I hardly think that this extent is applyed only when a vdp command is in place.
To me it does mean that ALWAYS the "16 cycles in advance check" does apply always. If there is no command active (or when a command is active but it does not yet need a vram access) i think the 16 cycles delay for check always apply. From the point of view of VDP engineers is far more easier to always keep this check active instead of conditioning this to the vdp command CE flag.
So i think that even without a cmd engine active if the z80 is accessing too fast corruption occours, but this should be checked on real hw.

By gdx

Prophet (3163)

gdx's picture

26-11-2019, 13:43

I found an old test that works on real MSX1 (TMS9918), MSX2 and MSX Turbo R (Z80 and R800). It works also in text mode 80 columns.

CALSLT	equ	001ch
INITXT	equ	0006Ch
LINL40	equ	0F3AEh
EXPTBL	equ	0FCC1h

	org	100h

	ld	a,40		; 80 for 80 columns
	ld	(LINL40),a

	ld ix,INITXT
	ld iy,(EXPTBL-1)
	call CALSLT	; SCREEN0
	
	ld	hl,0
	ld	c,099h
	di
	out	(c),l
	ld	a,h
	and	03fh
	or	040h
	out	(c),a
	ei
	ld	b,END-TEXT
	dec	c
	ld	hl,TEXT
	otir
JP4EVER:
	jr	JP4EVER
TEXT:
	db	"abcdefghijklmnopqrstuvwxyz"
	db	"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	db	"0123456789"
	db	"abcdefghijklmnopqrstuvwxyz"
	db	"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	db	"0123456789"
	db	"abcdefghijklmnopqrstuvwxyz"
	db	"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	db	"0123456789"
END:

By Grauw

Ascended (8615)

Grauw's picture

26-11-2019, 15:54

PingPong wrote:

I hardly think that this extent is applyed only when a vdp command is in place.
To me it does mean that ALWAYS the "16 cycles in advance check" does apply always. If there is no command active (or when a command is active but it does not yet need a vram access) i think the 16 cycles delay for check always apply. From the point of view of VDP engineers is far more easier to always keep this check active instead of conditioning this to the vdp command CE flag.
So i think that even without a cmd engine active if the z80 is accessing too fast corruption occours, but this should be checked on real hw.

Well sprites were fine when no command was executing during VRAM access, and they glitched when it was. Adding nops between the sprite attribute table writes fixed it (and out (c),r is quite fast so I wasn’t very surprised).

My suspicion was, a slot that would otherwise go to the VRAM access was already claimed by the command engine. Normally VRAM access gets priority, but if the slot has already been given away, it can force the VRAM access to the next one when it’s right on the edge of permissible access speed.

gdx wrote:

I found an old test that works on real MSX1 (TMS9918), MSX2 and MSX Turbo R (Z80 and R800). It works also in text mode 80 columns.

otir was fine (23 cycles), only outi (18 cycles) is problematic...

Page 2/5
1 | | 3 | 4 | 5