VDP overrun

By PingPong

Prophet (3281)

PingPong's picture

28-04-2018, 23:25

Hi, all.
we all know that the z80 can easily overrun the msx 1 vdp when writing the data port in vram transfers.
on msx2 this happen less frequently
on turboR this can not happen on R800 because of wait states.

But, can the R800 overrun the v9990?

Login or register to post comments

By Grauw

Enlighted (8015)

Grauw's picture

29-04-2018, 00:10

I would not assume so… R800 I/O is much faster, but still limited by the MSX bus speed, an I/O instruction on R800 has waits inserted to take 10 R800 cycles at 7.16 MHz (so 5 Z80 cycles). Given how fast V9990 commands execute, there must be many and much tighter access slots, and the V9990 won’t be impressed by the R800 I/O speed.

In fact, I think the concept of access slots may not exist on the V9990 at all… The V9990 RAM is dual-ported, so this should allow the VDP to use the full memory bandwidth of a single port for display without inhibiting command or CPU VRAM access.

Finally, I did not find a clear number on maximum VRAM transfer speed (you may try to interpret section 13.3.5 if you wish Big smile), but the V9990 outputs a WAIT signal (I assume connected on Gfx9000), which becomes active when the VDP is accessed while it’s busy.

By sd_snatcher

Prophet (2997)

sd_snatcher's picture

29-04-2018, 00:30

@Grauw

Does the R800 I/O have 10 cycles inserted for any I/O port?

How did you measure the instruction timing without waits for the table in your website then?

By Grauw

Enlighted (8015)

Grauw's picture

29-04-2018, 01:05

I’m quite sure all I/O gets those waits, e.g. for sure the MSX-MUSIC, MSX-AUDIO and MoonSound do. So far I have not seen any evidence to the the contrary.

One thing I haven’t tested specifically is I/O to the ports built-in to the S1990 (e.g. the timer). However it would surprise me if those would get an exception, it seems like it would only complicate the logic.

The R800 timings without waits are straight from the documentation iirc, only the “+wait” column is measured since that is the result of wait states inserted by the S1990 (which is undocumented).

p.s. A few months back I made a nice new way to measure R800 timing cycle-accurately using visual patterns, I only used it to confirm muluw timing, but I should spend some more time on fleshing it out so I can test the few remaining things I haven’t been able to test (like ldir), and release it so you can easily test for yourself.

By hit9918

Prophet (2853)

hit9918's picture

29-04-2018, 01:05

the 9990 is much bigger than the R800, waiting for an ARM to make DOOM!
because one can guess that vram transfer again goes as fast as LMMV. which on the 9990 is hell a lot.

By Grauw

Enlighted (8015)

Grauw's picture

29-04-2018, 01:07

hit9990: Indeed, good point about LMMV.

By wouter_

Champion (409)

wouter_'s picture

29-04-2018, 10:29

Grauw wrote:

... an I/O instruction on R800 has waits inserted to take 10 R800 cycles at 7.16 MHz (so 5 Z80 cycles)...

I can give a slightly more detailed answer on the R800 I/O instruction timing. It takes either 9 or 10 R800 cycles:

There are 3 main parts in this instruction that take time:
- Fetch and decode the instruction.
- Extra overhead.
- The actual I/O operation.

An I/O instruction is 2 bytes long, so (in ideal circumstances) opcode fetching takes only 2 R800 cycles. The I/O operation itself is visible on the MSX bus (3.5MHz), and takes 3 cycles on that bus, so 6 cycles on the R800 bus. My measurements show that the total length of the instruction is either 9 or 10 R800 cycles. So there's 1 or 2 cycles extra overhead.

This variability in the overhead can be explained by the 'alignment' of the R800 bus (7MHz) and the standard MSX bus (3.5MHz). The I/O operation can only start when the slower MSX bus is at the start of a cycle. So sometimes both buses are aligned and the instruction takes only 9 cycles, and sometimes there's an extra R800 cycle needed and the full instruction takes 10 cycles.

I've documented my measurements in a bit more detail in this old text file, lines 642-674.

By hit9918

Prophet (2853)

hit9918's picture

29-04-2018, 17:10

wouter_ wrote:

The I/O operation itself is visible on the MSX bus (3.5MHz), and takes 3 cycles on that bus

aha so actualy the TR slot is incompatible because original Z80 IO goes in 4 cycles
and when things dont work, the problem often is somewhere else, like the clock pin or the OPL delay.