TMS VDP timing testing

Page 1/3
| 2 | 3

By Eugeny_Brychkov

Paragon (1065)

Eugeny_Brychkov's picture

07-09-2018, 22:05

In the course of developing video player for TMS VDPs, I am trying to minimize time output to the VRAM takes. Datasheet says that register write must be min 2 us (7.15 T-cycles), VRAM write must be min 8 us (28.63 us) for SCREEN 2 mode. I am talking about Z80 equivalent T-cycles here.

Thus generally I decided that to set up pointer for writing

xor	a
out	(099h),a
ld	a,040h
out	(099h),a

would be enough, not accounting for additional 0.15 T-cycles.

But with VRAM write I get the following picture:
OUTI + NOP -> 23 T-cycles -> buggy image
OUTI + INC DE -> 25 T-cycles -> buggy image
OUTI + LD A,(HL) -> 26 T-cycles -> good image in openMSX, but buggy image on real TMS9918 machine
OUTI + RES 0,A -> 28 T-cycles -> good image in both openMSX and on real TMS9918

Unfortunately I did not find instruction of 9 T-cycles to check, so that cumulative execution time would be 27 T-cycles. Thus the routine should look like 256 sets of OUTI + RES 0,A, with JP NZ at its end (counting number of 8-pixel blocks, in total 24 times).

Initially I had OUTI + JR NZ to this OUTI, it was consuming 31 T-cycles; then OUTI + JP NZ, it consumes 29, but with RES, while code takes more space, will execute one T-cycle less (in total 256 T-cycles less for one 8-pixel row, and 6144 T-cycles less for whole screen area).

Any better ideas?

Update: I figured out how to make 27 T-cycles, it is as simple as

ld	a,(hl)
inc	hl
out	(098h),a

Right now testing, seems picture on real TMS is stable with no bugs on the screen.
I must say that I disable sprites by setting the first one to line 208.

Login or register to post comments

By Manuel

Ascended (15287)

Manuel's picture

08-09-2018, 09:13

If you can give us the details of the test, for example by sharing the program and telling the details of the hardware you were running it on, we can check what should be adjusted in openMSX.
I do remember that we set somewhat conservative values in openMSX in order not to break working programs on real hardware. There could be some variation on real hardware in the access timing, for example.

By Eugeny_Brychkov

Paragon (1065)

Eugeny_Brychkov's picture

08-09-2018, 23:16

Sure, here it is. Here's another one, and another one. Hardware need to be TMS, ideally should be tested on each model of VDP to see what should be the safe timing to run.

Manuel wrote:

we can check what should be adjusted in openMSX.

I think it is too early to talk about changes to emulation. I do "stress test" of the machine which normal programs do not do; and while I see some picture discrepancies, they appear under these stress conditions, and actually must be out of specifications for the TMS chips.

By Manuel

Ascended (15287)

Manuel's picture

08-09-2018, 23:41

Which exact VDP and MSX model have you been testing on then?

By Eugeny_Brychkov

Paragon (1065)

Eugeny_Brychkov's picture

09-09-2018, 08:49

Panasonic CF2700, _NETSYSINFO says it is TMS9918/28 with 60 Hz. I need people to test on their (other model) machines, but it seems very few people having MSX1 these days? Or maybe my request on facebook is too complicated and lengthy...

By hit9918

Prophet (2844)

hit9918's picture

09-09-2018, 17:38

27 cycles is like a vram acess slot every 5th char. 40 pixels of 5.355mhz dotclock -> 26.66 cycles of 3.57Mhz.
I see no chance that VDPs differ on this

By Eugeny_Brychkov

Paragon (1065)

Eugeny_Brychkov's picture

09-09-2018, 18:13

hit9918 wrote:

40 pixels of 5.355mhz dotclock -> 26.66 cycles of 3.57Mhz.

So do you mathematically confirm the 27 T-cycles @ 3.579545 MHz Z80 equivalent for TMS VDPs (50 and 60 Hz) for SCREEN 2 mode with sprites disables by putting sprite zero coordinate to 208 - to be safe to use?

I see this value to perform well on my CF-2700, the goal of my request on Facebook (and here) is to ensure it works on another VDP TMS9929.

By PingPong

Prophet (3229)

PingPong's picture

09-09-2018, 20:46

Eugeny_Brychkov]
hit9918
wrote:

... for SCREEN 2 mode with sprites disables by putting sprite zero coordinate to 208 - [b wrote:

to be safe to use?.

I do not think that disabling sprites change anything on tms vdp. Perhaps TMS vdp does not have any disable sprite bit only the stupid trick of Y=208. I Think originally this stupid feature was introduced to allow to shorten the SAT and gain some of the tiny 128 bytes sprites storage for other purposes.
Speculation: Even if you put y=208 for sprite plane 0 i think the VDP will continue to parse the entire SAT. Only it does not load any of the 4 y buffers used to display the sprites.
Speculation n.2: Even when there are no sprites to be displayed on a specific scanline, i think TMS vdp perform dummy reads in the same slot timing positions that would be performed with a full load of 4 sprites / scanline

By hit9918

Prophet (2844)

hit9918's picture

11-09-2018, 17:12

one day I too measured 27 cycles.
https://www.msx.org/forum/development/msx-development/direct...
at the bottom of the page I talk of results. the talk above may be myths.

the sprites make no difference. to make a difference there would have to be a dynamic vram slot alloocation cpu versus sprites. the MSX1 VDP is too simple to have such thing.

By Eugeny_Brychkov

Paragon (1065)

Eugeny_Brychkov's picture

11-09-2018, 18:57

hit9918 wrote:

one day I too measured 27 cycles.
https://www.msx.org/forum/development/msx-development/direct...
at the bottom of the page I talk of results.

Thank you very much!

By TomH

Champion (322)

TomH's picture

11-09-2018, 20:23

I must be suffering a comprehension failure.

Following the TMS memory access window availability bible, if you were magically in-phase then the write windows on each line, from the Z80's point of view, start at cycles:

  • in a burst: -0.66, 0.66, 2, 3.33, 4.66; then
  • in a burst: 19.33, 20.66, 22, 23.33; then
  • 36.66, 58, 79.33, 100.66, 122, 143.33, 164.66, 186; then
  • in a burst: 206, 207.33.

The longest gaps are the periods of 21.33 cycles while pixels are being output — 16 memory windows, which is 32 dot clock pixels rather than 40.

How do the two things reconcile?

Page 1/3
| 2 | 3
My MSX profile