Forums

Probably done to death but I keep seeing code that violates VDP timing so I thought I'd ask.

The official sega reference manual (for mark iii) states that the VDP cannot process data/reg access faster than 16T / 29T (active video). However everyone seems to be violating this, including the wiki : http://www.smspower.org/Development/VDPProgrammingTechniques

When is the VDP timing ok to violate and when isn't it?

ld a,l
out ($bf),a
ld a,h
out ($bf),a

Sets the internal VRAM address pointer. Time between OUTs is 15T.

loop:
outi
jr nz, loop

Writing data to VRAM. Time between OUTs is 28T.

loop:

ld a,l
out ($bf),a
ld a,h
out ($bf),a ;; 15T (as earlier example)

in a,($be) ;; 11T
ex af,af'

ld a,e
out ($bf),a ;; 19T
ld a,d
or $40
out ($bf),a ;; 22T

ex af,af'
out ($be),a ;; 15T

inc de

cpi
jp pe, loop

VRAM to VRAM transfer. Time between OUTs listed above. (Ok I wrote this one so seeking comments given the rest of the examples here).

Here's one advocated by the wiki:

.rept 3
.rept 4
.rept 4
.rept 4
out (c), d
out (c), h
.endr
.rept 4
out (c), e
out (c), l
.endr
.endr
.endr
.rept 4
.rept 4
.rept 4
out (c), e
out (c), l
.endr
.rept 4
out (c), d
out (c), h
.endr
.endr
.endr
.endr

TIme between OUTs is 11T.

See here:

http://www.smspower.org/forums/14599-HowManyBytesCanIWriteToVRAMPerFrame

The VDP is reading its RAM and we can write to it (or read) safely so long as we don't write faster then the rate at which it is leaving "slots" in its reads for our writes to complete. The Z80 clock is not at the same rate as the pixel clock, so it gets confusing. But basically, you can write a byte every 22.8 CPU cycles during the acrive display (so practically every 23) and every 2.68 CPU cycles during the inactive display (aka VBlank although it includes the border area). You have no chance to get near one byte every 3 cycles on the Z80 so just go as fast as you can, outi blocks are the fastest general purpose way but if you have data that fits in the registers then you can do better.

Other stuff, like changing VDP registers and the address value and state seem to be unlimited at any time because they don't contend with the active display rendering.

Maxim wrote

But basically, you can write a byte every 22.8 CPU cycles during the active display (so practically every 23) ...

When we were testing this in 2014 we found out that anything faster than 26 cycles would anyway lead to corruption. This applies to writing to VRAM/CRAM, no problems when writing to address registers.

OK, but the VBlank rate is still only CPU constrained. (I made a similar test many years ago but I forget what result I got then. The corruption was sometimes hard to notice...)

Yes, sure! Well, at least until we found a way to force the Z80 to OUT one byte for each clock cycle ;)

Author	Message
Alcoholics Anonymous Joined: 17 Nov 2015 Posts: 97 Location: Canada	VDP Timing Constraints Posted: Fri Sep 09, 2016 7:02 pm
	Probably done to death but I keep seeing code that violates VDP timing so I thought I'd ask. The official sega reference manual (for mark iii) states that the VDP cannot process data/reg access faster than 16T / 29T (active video). However everyone seems to be violating this, including the wiki : http://www.smspower.org/Development/VDPProgrammingTechniques When is the VDP timing ok to violate and when isn't it? ld a,l out ($bf),a ld a,h out ($bf),a Sets the internal VRAM address pointer. Time between OUTs is 15T. loop: outi jr nz, loop Writing data to VRAM. Time between OUTs is 28T. loop: ld a,l out ($bf),a ld a,h out ($bf),a ;; 15T (as earlier example) in a,($be) ;; 11T ex af,af' ld a,e out ($bf),a ;; 19T ld a,d or $40 out ($bf),a ;; 22T ex af,af' out ($be),a ;; 15T inc de cpi jp pe, loop VRAM to VRAM transfer. Time between OUTs listed above. (Ok I wrote this one so seeking comments given the rest of the examples here). Here's one advocated by the wiki: .rept 3 .rept 4 .rept 4 .rept 4 out (c), d out (c), h .endr .rept 4 out (c), e out (c), l .endr .endr .endr .rept 4 .rept 4 .rept 4 out (c), e out (c), l .endr .rept 4 out (c), d out (c), h .endr .endr .endr .endr TIme between OUTs is 11T.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Fri Sep 09, 2016 8:34 pm
	See here: http://www.smspower.org/forums/14599-HowManyBytesCanIWriteToVRAMPerFrame The VDP is reading its RAM and we can write to it (or read) safely so long as we don't write faster then the rate at which it is leaving "slots" in its reads for our writes to complete. The Z80 clock is not at the same rate as the pixel clock, so it gets confusing. But basically, you can write a byte every 22.8 CPU cycles during the acrive display (so practically every 23) and every 2.68 CPU cycles during the inactive display (aka VBlank although it includes the border area). You have no chance to get near one byte every 3 cycles on the Z80 so just go as fast as you can, outi blocks are the fastest general purpose way but if you have data that fits in the registers then you can do better. Other stuff, like changing VDP registers and the address value and state seem to be unlimited at any time because they don't contend with the active display rendering.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sun Sep 11, 2016 9:02 am
	Maxim wrote But basically, you can write a byte every 22.8 CPU cycles during the active display (so practically every 23) ... When we were testing this in 2014 we found out that anything faster than 26 cycles would anyway lead to corruption. This applies to writing to VRAM/CRAM, no problems when writing to address registers.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Sep 11, 2016 11:03 am
	OK, but the VBlank rate is still only CPU constrained. (I made a similar test many years ago but I forget what result I got then. The corruption was sometimes hard to notice...)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Sep 12, 2016 9:01 am
	Yes, sure! Well, at least until we found a way to force the Z80 to OUT one byte for each clock cycle ;)

Forums

View topic - VDP Timing Constraints