TMS VDP timing testing

Page 3/3
1 | 2 |

By PingPong

Prophet (3193)

PingPong's picture

10-04-2019, 23:17

From TMS manual:
"
The VDP needs 2 microseconds to read or write a byte to its RAM. In addition, it can only communicate with the CPU at precise moments, when it is not too busy with building the screen. Such moments are known as CPU access windows and may arise at various intervals depending on the video mode. In standard or bitmap mode, a window occurs every 16 memory cycles, each cycle being 372 ns long. This means the VDP may have to wait upto 5.95 us before a CPU access window occurs. Adding the 2 us needed for RAM access gives us a maximum delay time of 8 us. Of course, it can be as fast as 2 us if a window just happens to open (even less for reading operations, thanks to the read-ahead buffer). In text mode, a window opens every three memory cycles, i.e. at intervals of 1.1 us. In multicolor mode, a window opens every four memory cycles, i.e. at 1.5 us intervals."

By ARTRAG

Enlighted (6113)

ARTRAG's picture

10-04-2019, 23:25

PingPong wrote:

From TMS manual:
"
The VDP needs 2 microseconds to read or write a byte to its RAM. In addition, it can only communicate with the CPU at precise moments, when it is not too busy with building the screen. Such moments are known as CPU access windows and may arise at various intervals depending on the video mode. In standard or bitmap mode, a window occurs every 16 memory cycles, each cycle being 372 ns long. This means the VDP may have to wait upto 5.95 us before a CPU access window occurs. Adding the 2 us needed for RAM access gives us a maximum delay time of 8 us. Of course, it can be as fast as 2 us if a window just happens to open (even less for reading operations, thanks to the read-ahead buffer). In text mode, a window opens every three memory cycles, i.e. at intervals of 1.1 us. In multicolor mode, a window opens every four memory cycles, i.e. at 1.5 us intervals."

yes, and it follows:

"There are two exceptions to these rules, however:

When the screen is blank (because bit 1 in register 1 is set as 0) the VDP does not handle the screen and a CPU access window is permanently open. Consequently, there is no wait time.
When the VDP is done with drawing a frame and enters vertical refresh mode it issues an interrupt (if enabled) and opens a 4.3 milliseconds (4300 us) window for CPU access."

My code is working in VBLANK, and works perfectly on TMS vdps.
It fails on msx2 and up.

By gdx

Prophet (2612)

gdx's picture

11-04-2019, 02:32

Have you checked if register 14 is not changed between two interrupts? I do not think the v99x8 needs more time than the TMS.

By ARTRAG

Enlighted (6113)

ARTRAG's picture

11-04-2019, 09:05

Nothing is changing r14, there is only my custom isr code where I read and write the vram and, on the main loop, normal vram writes

By PingPong

Prophet (3193)

PingPong's picture

11-04-2019, 10:52

the msx2 VDP is by far fastest than TMS vdp, in worst case takes 4us or so to perform the I/O operation. So it is unlike that the failure is due to vdp timing. if we check the V9938 VRAM timings in vblank there is an access slot every 8 clock cycles that means 8/21 ^ 10E6 us. So the issue must be related to address setup timing, that is the delay the vdp take to accept the request. I suspect that this setup is implemented in a different way but unfortunately we do not have a *REAL* diagram that shows the time elapsed between the CS* vdp signal (from cpu) and the CASx signals.

There is a timing diagram for the v9958 however from yamaha that relate those two signals (CSw / CSr and CASx) when explaining about the timing of the WAIT signal. i've not checked by maybe can help to understand the problem.

there are two diagrams: one for read cycle and one for write.

By Manuel

Ascended (15187)

Manuel's picture

15-04-2019, 21:43

How does this relate to the VDP VRAM timing measurements? As shown in http://openmsx.org/vdp-vram-timing/vdp-timing-2.html

By PingPong

Prophet (3193)

PingPong's picture

16-04-2019, 10:03

Manuel wrote:

How does this relate to the VDP VRAM timing measurements? As shown in http://openmsx.org/vdp-vram-timing/vdp-timing-2.html

i suspect that the difference is the delay elapsed after the last cpu out on port (99) (CSx strobe signals to VDP) and the CASx VDP signals that performs the I/O. That's because the v9938 is much faster than TMS when performing cpu I/O. So the difference must be in the initial delay of 2us.
Unfortunately we can not verify this because the diagrams does not show CSx signals related to CASx, only CASx signals :-(

what is the minimum delay needed to get a reliable vram reading after address setup on v99x8?

By ARTRAG

Enlighted (6113)

ARTRAG's picture

16-04-2019, 20:22

Testing my code on real msx2 and TR (in z80 mode), we have found that the minimum delay between the last out 99h and the in 98h has to be not less than two nops. It means 10 CPU cycles to be added to the 12 cycles for in a,(98h).

Page 3/3
1 | 2 |
My MSX profile