Return to Answer

While the 6502 is essentially double clocked, using memory only every other cycle, the Z80 has a less strict format and only one dedicated clock cycle in each instruction that can be used for transparent access if certain conditions are meet and that's during the third and fourth clock cycle (T3/T4) of the first machine cycle (M1) of each instruction.

While the second can be easy satisfied by crating a video address layout that spreads out the video memory in a way making sure every row gets accessed in time, the first point holds the real challenge, as instructions are of different length, mixed in random sequence (*1).

While the 6502 is essentially double clocked, using memory only every other cycle, the Z80 has a less strict format and only one dedicated clock cycle in each instruction that can be used for transparent access if certain conditions are met and that's during the third and fourth clock cycle (T3/T4) of the first machine cycle (M1) of each instruction.

While the second can be easily satisfied by crafting a video address layout that spreads out the video memory in a way making sure every row gets accessed in time, the first point holds the real challenge, as instructions are of different length, mixed in random sequence (*1).

No, at least not unless the Video runs way slower than the CPU. And even in that case it might need buffering and/or insert wait states in fringe cases.

• M1 cycles come in different intervals
• When using dynamic RAM, Refresh has to be provided by different means.

Lets do a quick back-of-the-envelop estimate for a 40x25 character display, equal to 320 pixel in B&W. On a 15 kHz screen this means reading 40 bytes per scan line within ~50 µs, or one byte every 1.25 µs. Since the maximum time between two M1 cycles on a Z80 is 20 clocks, such a display system would work fine with a CPU clock rate of 16 MHz.

So yes, a complete transparent display access can be done, but CPU clock speed requirements are rather harsh, even if it's just about a homecomputer like display (40x24 character or 320x240 in B&W).

And like with a bigger cache, one could use a FIFO of for example 2 or 4 byte wide buffers, increasing buffer hit situations quite a lot. I seems plausible that with a 4 byte FIFO such a display could run bound to a 4 MHz CPU with no or only very little impact - not only because it smoothes out instruction length quite good, but also increases access time as the FIFO will be filled during blanking, essentially building up a time buffer of 16 clocks.

Of course, all of this comes with increased chip count. It needs to be carefully checked when the effort needed for buffering gets higher then adding a conditional dual port access. One which may only slow down the CPU if accessing during a displayed line, a rather rare occurrence (*3)

Now, if this is about a computer design intended to be sold in high numbers, a controller with an on chip FIFO could tip the scale again. Here buffer size can be much larger, maybe a whole scan line, which should allow 80 char (640 px) on a 4 MHz Z80 without much delay. Kinda like the VIC, but without the slow down.

Or make all CPU access go thru an access port instead.

This is in also the way all TI9918 compatible VDP are interfaced and a reason why the 9918 was so widely used with Z80 machines. Of course it only works with dedicated video memory.

*1 - From the PoV of the video logic that is.

*2 - The third case can be ignored as it's appears as a combination of a type 1 followed by a type 2.

*4 - Assuming a timing liek a similar 6502 setup.

No, at least not unless the video runs way slower than the CPU. And even in that case it might need buffering and/or insert wait states in fringe cases.

• M1 cycles come in different intervals
• When using dynamic RAM, refresh has to be provided by different means.

Let’s do a quick back-of-the-envelop estimate for a 40x25 character display, equal to 320 pixel in B&W. On a 15 kHz screen this means reading 40 bytes per scan line within ~50 µs, or one byte every 1.25 µs. Since the maximum time between two M1 cycles on a Z80 is 20 clocks, such a display system would work fine with a CPU clock rate of 16 MHz.

So yes, a complete transparent display access can be done, but CPU clock speed requirements are rather harsh, even if it's just about a home computer-like display (40x24 character or 320x240 in black-and-white).

And like with a bigger cache, one could use a FIFO of for example 2 or 4 byte wide buffers, increasing buffer hit situations quite a lot. I seems plausible that with a 4 byte FIFO such a display could run bound to a 4 MHz CPU with no or only very little impact - not only because it smooths out the instruction length quite good, but it also increases access time as the FIFO will be filled during blanking, essentially building up a time buffer of 16 clocks.

Of course, all of this comes with increased chip count. It needs to be carefully checked when the effort needed for buffering gets higher than adding a conditional dual port access. One which may only slow down the CPU if accessing during a displayed line, a rather rare occurrence (*3).

Now, if this is about a computer design intended to be sold in high numbers, a controller with an on chip FIFO could tip the scale again. Here buffer size can be much larger, maybe a whole scan line, which should allow 80 char (640 px) on a 4 MHz Z80 without much delay. It is kind of like the VIC, but without the slowdown.

Or make all CPU access go through an access port instead.

This is in also the way all TI9918 compatible VDPs are interfaced and a reason why the 9918 was so widely used with Z80 machines. Of course it only works with dedicated video memory.

*1 - From the point of view of the video logic that is.

*2 - The third case can be ignored as it appears as a combination of a type 1 followed by a type 2.

*4 - Assuming a timing like a similar 6502 setup.

While the second can be easy satisfied by crating a video address layout that spreads out the video memory in a way making sure every row gets accessed in time, the second holds the real challenge, as instructions are of different length, mixed in random sequence (*1).

While the second can be easy satisfied by crating a video address layout that spreads out the video memory in a way making sure every row gets accessed in time, the first point holds the real challenge, as instructions are of different length, mixed in random sequence (*1).