OpenMSX too_fast_vram_access in MSX1 Japanese (60hz) systems

By Wlcracks

Champion (315)

Wlcracks's picture

02-02-2019, 18:38

I am testing my low tec vdp vram dumps.
Working fine in openmsx, no too_fast_vram_access warnings. On real hardware working fine too.
Also when i use the border color for timings, seems ok too.
But when i change the system to 60hz the color bar goes half way. This could be the problem of my asm code, but the question is;
Why dont i get the too_fast_vram_access warning?
Is openmsx as accurate in 60hz systems as in 50hz on msx1? I dont have a 60hz real system for reference. 50hz openmsx compared to real system the seems fine. Just wondering.

Login or register to post comments

By Manuel

Ascended (15452)

Manuel's picture

02-02-2019, 21:43

You don't get it because too fast VRAM access is not the reason the color bar goes half way...

By Grauw

Enlighted (8078)

Grauw's picture

02-02-2019, 22:12

A 60 Hz frame consists of 262 lines of 228 Z80 cycles each (16.7 ms). After the end of active display (vertical blanking interrupt) it draws 70 lines of borders and such before active display restarts.

A 50 Hz frame consists of 313 lines of 228 Z80 cycles each (20 ms). After the end of active display (vertical blanking interrupt) it draws 121 lines of borders and such before active display restarts.

If you’re changing the background colour on the vertical blanking interrupt, then do stuff for 45600 cycles (200 lines worth), and change it back after, the coloured area will extend to active display line 130 @ 60 Hz, and line 79 @ 50 Hz. Perhaps this is what you’re seeing?

By Wlcracks

Champion (315)

Wlcracks's picture

03-02-2019, 07:42

Ok cool, thanks for the answers.
From what i understand
From the timing datasheets from TI.
TMS9128 = NTSC etc = 60Hz = 262 Lines
TMS9129 = PAL etc = 50 Hz = 313 Lines
So that i understand.
1/60 = 16.7ms.
1/50 = 20 ms.
Ok
262 / 16.7 ms = 15.72 kHz
313 / 20 ms = 15.65 kHz
So i guess the 228 Z80 cycles you mention =
3.58 Mhz / 15.72 kHz = 227,73
3.58 Mhz / 15.65 kHz = 228,75
Not sure that applies, because drift in the clocks and out of synch, double msx stupid half M1 cycles bla bla. But wutever its just an number 228. To confirm that i would use a logic analyzer, but how that's an other discussion.
I guess the VBLANK periode =
60hz 262 - 192 = 70 lines
50hz 313 - 192 = 121 lines

From what i read in some text file starting with "TMS 99xx TIMING The way the VDP works is a sort of a "best effort" approach....." you can write fast as possible when the TMS isnt using the VRAM for displaying on screen. So I guess after the VDP interrupt you can write fast as long as the first displayed line will show at lets say pset(0,0).
So i am writing with otir 3 blocks to VRAM after some household keeping on HTIMI.
Changing only the border color on the HTIMI is losing about half a line, but say just 1 line for housekeeping.
So when writing 2 otir's of each 0xff bytes long, one otir with 0x80 bytes long and of course setting VRAM address 2 times, the color bar method indicates its fine. Hardware and on openMSX, no "too fast errors".
Lets say my current VRAM writing is 121/2 = 60 lines, because it doesn't show up at the top at 50hz. This would be way to slow for 60 Hz TMS??
So if i had a 60hz MSX1, i would write into the area the TMS uses the VRAM. I would expect an "too fast" openmsx error.
So, call me dumb, but what do i miss here? Later I will pull out the logic analyzer on the printerport to time the lenght of the "fast" VRAM access but, not sure why i don't understand whats going on.

By Wlcracks

Champion (315)

Wlcracks's picture

03-02-2019, 08:00

No worries forget it, i was not looking right. The color bar was wrong its spot on. The "too fast" error works fine on 60hz TMS.
Thanks for the help.

By Grauw

Enlighted (8078)

Grauw's picture

03-02-2019, 11:47

Wlcracks wrote:

From what i understand
From the timing datasheets from TI.
TMS9128 = NTSC etc = 60Hz = 262 Lines
TMS9129 = PAL etc = 50 Hz = 313 Lines
So that i understand.
1/60 = 16.7ms.
1/50 = 20 ms.
Ok
262 / 16.7 ms = 15.72 kHz
313 / 20 ms = 15.65 kHz
So i guess the 228 Z80 cycles you mention =
3.58 Mhz / 15.72 kHz = 227,73
3.58 Mhz / 15.65 kHz = 228,75
Not sure that applies, because drift in the clocks and out of synch, double msx stupid half M1 cycles bla bla. But wutever its just an number 228. To confirm that i would use a logic analyzer, but how that's an other discussion.

It’s actually exactly 228 cycles*. The difference you see here is due to rounding. A line takes equally long at 50 or 60 Hz, just the number of lines drawn differs.

The TMS9xxx master clock is 10738636(.3636…) Hz, that’s 3x 3579545(.4545…) Hz. The pixel clock is half the master clock (5369318(.1818…) Hz), and a horizontal line consists of 342 pixels, 256 pixels of active display and the rest is border, erase and sync.

So converting this to CPU cycles: 342 * 2 / 3 = 228 cycles per line (1.5 pixel per CPU cycle). This means the horizontal scanning frequency is 15699.76 Hz (63.70 µs).

From this we can also derive that the vertical scanning frequency is either 15699.76 / 262 = 59.92 Hz (16.69 ms) or 15699.76 / 313 = 50,16 Hz (19.94 ms).

* Actually it’s only 228 cycles if the Z80 is fed from the same clock as the VDP. The VDP takes the 10.7 MHz clock and outputs a 3.58 MHz clock, which many MSX computers feed into the CPU, but others have a separate 3579545 crystal for the CPU, so there can be drift and deviation in either direction.

By Wlcracks

Champion (315)

Wlcracks's picture

03-02-2019, 12:26

Not sure but when CPU and VDP have seperate Xtal. I think that's not always true, different XTAL and no shared clock could indicate on asynchronous running. They will go out of phase.
This is the case in MSX1 setups without engine. Could be an MSX engine has clock dividers, i didn't check that.
Well drift in components, xtal tolerances, aging, capacitors and due to fact clocks trigger mostly on negative flank, it easily can skip cycles when clocks don't synch up. Even my cpu cycles after interrupt are same timing i still see a lot of variation.
I would not put my hand into fire, but i never measured this stuff. Maybe it is, but i think your calculations only work when you have a shared clock with clock dividers.
** oh sorry didnt see your addition. Smile

By Grauw

Enlighted (8078)

Grauw's picture

03-02-2019, 13:03

The TMS9918A VDP outputs 3.58 MHz on the CPUCLK pin, and the V9938/58 as well. But the TMS9928A and TMS9929A don’t.

Either way, due to the Z80 sometimes taking the same clock as the VDP, sometimes not, this can’t be relied upon to be exact (for demo effects or something), however for cycle maths purposes, determining how long something takes based on number of lines, or how much the CPU can do during one line in a screensplit, it’s useful to know 1 line takes 228 cycles, and whether due to crystal drift this is actually 228.01 or 227.99 doesn’t really matter that much.

By Wlcracks

Champion (315)

Wlcracks's picture

03-02-2019, 13:53

ok cool thanks again