TMS VDP timing testing

Page 2/3
1 | | 3

By hit9918

Prophet (2855)

hit9918's picture

11-09-2018, 21:40

this subtle difference is because... it is MSX2 Big smile
but, when you say the longest gap is 21.33 cycles - but the 18 cycles outi works on MSX2.
you're maybe off by factor 2. the cycles in wouters diagram (the big pic) are 21Mhz cycles, 4 times the dotclock of 256 pixel mode.

meanwhile the MSX1 has a TI manual with problematic explanations

By TomH

Champion (327)

TomH's picture

11-09-2018, 22:11

hit9918 wrote:

this subtle difference is because... it is MSX2 Big smile

Most of it is, but the timing diagram features the regular old TMS9918 at the bottom, showing refresh, text and character line costs, with 171 memory access windows occupying 342 cycles per line. You could very broadly describe it as eight blocks of 15-window VDP access with a single empty window between during pixels to collect all background and some sprite locations, plus the remainder of sprite locations and sprite graphics for the blessed four spread less-intensely throughout the border.

The diagram is here. Scroll to the bottom.

hit9918 wrote:

but, when you say the longest gap is 21.33 cycles - but the 18 cycles outi works on MSX2.
you're maybe off by factor 2. the cycles in wouters diagram (the big pic) are 21Mhz cycles, 4 times the dotclock of 256 pixel mode.

I didn't inspect the MSX2 section of the diagram.

By hit9918

Prophet (2855)

hit9918's picture

11-09-2018, 22:41

boy I forgot that this pic has MSX1 at the bottom Big smile

ok the slots are 16 boxes apart. 32 pixels, 21.33 cpu cycles.
I got no idea what makes it 27 cycles.

By Eugeny_Brychkov

Paragon (1079)

Eugeny_Brychkov's picture

12-09-2018, 20:59

I made a video playback engine basing on 27 T-cycles, seems to work well!

By TomH

Champion (327)

TomH's picture

21-09-2018, 16:25

hit9918 wrote:

ok the slots are 16 boxes apart. 32 pixels, 21.33 cpu cycles.
I got no idea what makes it 27 cycles.

As it turns out, the answer in the data sheet: it confirms a maximum 16 windows separation, but almost mentions a 2us setup time for making a transfer.

So I think the issue is:

  • if your attempt to initiate a transfer overlaps an available access window, the VDP won't use that window;
  • since you are not running exactly in phase with the available windows, you therefore need each write to be spaced so that there is enough time for (i) 2us; plus (ii) enough time to get from the end of the 2us to the end of the next access window.

So not 16 windows, but 2us + 16 windows.

By ARTRAG

Enlighted (6188)

ARTRAG's picture

10-04-2019, 09:15

Sorry to introduce a new question:
Why the following code executed during VBLANK fails on some msx2 and msx TR in z80 mode (and works JP on msx 1) ?

	ld	a,low  @1
	out (0x99),a
	ld	a,high @1
	out (0x99),a
;[3]	nop			; comment  if in vblank
	in a,(0x98)
	dec a
	jr 	nz,2f
	ld	a,low  @1
	out (0x99),a
	ld	a,0x40 + high @1
	out (0x99),a
; [2]	nop			; comment  if in vblank
	xor a
	out (0x98),a
; [2]	nop			; comment if in vblank
2:	; next

NB1: the issue appears on real HW
NB2: openmsx and bluemsx does not report issues
NB3: @1 is a constant (this is a segment of a macro)

By gdx

Prophet (2858)

gdx's picture

10-04-2019, 09:20

Maybe because of register 14?

By ARTRAG

Enlighted (6188)

ARTRAG's picture

10-04-2019, 09:23

To make things clearer: I see that the VRAM->ram transfer fails.
I was expecting that in VBLANK the VDP needs only 2us to set the VRAM address (2e-9*3.567e6 = about 8 cpu cycles) .
This means that 8 cpu cycles after the second out (99h) I should be able to read the VRAM on port 98h...
Is this correct ? Apparently not on msx2 and upper...

By Grauw

Ascended (8192)

Grauw's picture

10-04-2019, 11:08

What’s more, out takes 12 cycles already, so you shouldn’t even need the nops.

However, I think that’s enough for write but read needs more time. The 2 μs is the time it takes for the address set-up to be processed, but then it takes some additional time to actually read the value from memory and put it in the buffer. I think the additional set-up time for reads is documented, but I can’t look it up right now.

By ARTRAG

Enlighted (6188)

ARTRAG's picture

10-04-2019, 22:26

Grauw wrote:

What’s more, out takes 12 cycles already, so you shouldn’t even need the nops.

However, I think that’s enough for write but read needs more time. The 2 μs is the time it takes for the address set-up to be processed, but then it takes some additional time to actually read the value from memory and put it in the buffer. I think the additional set-up time for reads is documented, but I can’t look it up right now.

If you mean 12 cycles spent by in a,(98h), yes, they are sufficient for the TMS VDP.
The TMS manual states that 2us is the time needed in VBLANK to set the VRAM address and read the data and this is confirmed by tests on the real HW.
The code works without nops on a real NTSC msx1 from Japan.

What I do not see in manuals is the time needed in the Yamaha's V9938.
Apparently even in VBLANK, V9938 and V9958 need more time to fetch the data from VRAM.

Page 2/3
1 | | 3