Could the Z80 do interference-free video as the 6502 could?

Question

Technically this isn't just about video since it applies to any regularly scheduled DMA¹ from a non-CPU subsystem, but video is the most common application of this technique so I'll use that as the example.

The 6502 needs access to memory only half the time, during the what is usually called the ϕ2 phase of the clock. The other half of the time, so long as you tri-state the CPU address pins,² the bus and memory are available to other systems. This is often used for video systems that have a frame buffer in RAM directly accessible to the CPU; the CPU updates the frame buffer during ϕ2 and the video system reads the buffer during ϕ1, and there is never contention for memory access between the two.³

The Z80 does not have such a well-defined, synchronous system of accessing RAM. Many cycles don't need RAM access, but many do, and which particular ones do and do not depend on the instruction mix. Thus, at least on many early systems, when the frame buffer was in memory shared by the CPU and video subsystem (and the memory was not dual-ported) there was the possibility that both would try to access the memory at the same time and one would have to be denied access. This could be done by pausing the CPU, thus slowing down program execution, or by denying access to the video system, which would cause effects such as snow on the screen because the data to be displayed could not be retrieved.

Given a subsystem such as a video display that needed a certain amount of guaranteed bandwidth and had its frame buffer in single-ported RAM directly accessible by the CPU (i.e., the CPU could execute code from that RAM), was it possible on the Z80 to set things up so that the subsystem would always get that bandwidth and yet the CPU would never be paused or slowed, as can be done on the 6502? What sort of compromises, if any, would be involved in doing this? (By "compromise" I'm thinking of differences in behaviour that you would not have had if you had used dual-ported RAM to share the memory.)

---

¹ Wikipedia gives a good definition: "Direct memory access (DMA) is a feature of computer systems that allows certain hardware subsystems to access main system memory (random-access memory) independently of the central processing unit (CPU). ¶ Without DMA, when the CPU is using programmed input/output, it is typically fully occupied for the entire duration of the read or write operation, and is thus unavailable to perform other work. With DMA, the CPU first initiates the transfer, then it does other operations while the transfer is in progress, and it finally receives an interrupt from the DMA controller (DMAC) when the operation is done."

² On some versions of the 6502, such as the Commodore 64's 6510, there is a signal to request that the CPU do this itself. On others, such as the Apple II's 6502, external tri-state buffers are needed.

³ There were some systems, such as the Commodore 64, where more than half the memory bandwidth was sometimes needed, and from time to time these would "steal" cycles from the CPU as well as using all the ϕ1 time. But many, such as the Apple II, were designed so that the video system never needed to do this.

Answer 1

Given a subsystem such as a video display that needed a certain amount of guaranteed bandwidth, was it possible on the Z80 to set things up so that the subsystem would always get that bandwidth and yet the CPU would never be paused or slowed, as can be done on the 6502?

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.

---

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.

This is where a Z80 usually puts out the RAM refresh address marked by /RFSH during these two cycles, but ignore any returned data. It would be possible to use this duration to execute video access. There are two main consideration when going this way:

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

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).

Instructions come in machine cycle combinations in likeliness of

1. M1 only (like NOP or MOV A,B)
2. M1 and up to 4 following M-cycles
3. Dual M1 and up to 4 following M-cycles (all prefixed instructions)

If it would be only M1 cycles, the situation would be almost exactly like with a 6502, but the second case (*2), instructions with additional machine cycles, complicates this because

• only the M1 cycle is 4 T-cycles, all other are 3 T-cycles.
• the number of T cycles between two consecutive M1 varies between 4 and 16 clocks

Any solution to go without slowing the CPU will have to cover both and have at least one 'read ahead' buffer to equalize phase shifts introduced by different M-cycle length. If 'empty' this register would read the next byte to be displayed with the next M1 cycle coming along.

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).

A variation with some impact could use such a one byte buffer and a lower clock rate by stopping the CPU only if the buffer runs empty right before the next byte is to be fetched. How much slow down this produces is quite up to each programs instruction mix, much related to estimations of cache hit strategies.

It's up to the reader to find case dependent estimations.

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.

---

Having said all of that, I would either

Go the way of adding wait states when the CPU is accessing video.

The performance decrease is minuscule, as it only extend the accessing M-cycle by maybe 0-4 T-cycles. So, even within an LDIR instruction, slow down due concurrent access will be less than 20%.

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

If the port is 'empty' writing will be immediate, if not, the CPU will be put on hold. This should be quite rare, as the port will usually be able to write to video RAM within 4 CPU T-cycles (*4), so way faster than the Z80 can issue a follow up write. Even LDIR needs 21 T-cycles between two consecutive write.

Reading will be slower and introduce a 0..4 T-cycle wait penalty to synchronize for access. Then again, reading happens way less often than writing, so it might not be of great concern.

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.

*3 - As usual depending on application type)

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

Answer 2

TL/DR; As you stated in the question:

"Many cycles don't need RAM access, but many do, and which particular ones do and do not depend on the instruction mix.

There is no "do nothing" solution to this constraint, and Z80-based systems that wanted consistent video output would have to solve this one way (hardware) or the other (software).

---

The best solution, and the one used when consistent video output was paramount, was to simply add a video subsystem. Here, a display processor with its own RAM ("VRAM") would provide a hardware controller for the CPU to access the non-shared memory. See, for example, Sega's Z-80 based Master System game console.

Eschewing such a hardware solution meant that a simpler synchronization mechanism would be implemented to block either the display or the CPU as needed, just as you describe in the question. So, through software, a consistent display would be created by the programmer carefully managing the CPU access to the shared display memory.

It seems that no "third way" is either necessary or possible.

Answer 3

If the memory works at the same speed as Z80 (DRAM cycle time is 1 CPU clock cycle), DMA can have the memory at the speed of least 2 cycles out of 3, presuming that every Z80 memory access gets exactly single DRAM cycle.

This idea was implemented in some russian ZX-Spectrum clones, among which the most known one is "Pentagon".

A similar idea is used in Amiga computers, where 68000 CPU is able to run off chip memory without wait cycles (provided there's not too many bitplanes and other DMAs are on).

upd: As @cjs has some doubts in my statements, here is an example diagram containing clock, Z80 cycles, some Z80 signals and how DRAM cycles could be scheduled. The pattern shown is valid for an instruction like LD IX,[addr].

upd2: In pentagon ZX clone, video fetch requires at least 2 bytes in every 4-clock video cycle (which maps to 8-pixel byte shown on the screen). It could be seen from a diagram, that video will always have that amount, with just wasting possible additional accesses.

Answer 4

To answer the specific question in a very literal way:

was it possible on the Z80 to set things up so that the subsystem would always get that bandwidth and yet the CPU would never be paused or slowed, as can be done on the 6502?

Yes. The Galaksija is a computer that does this. The display subsystem gets full bandwidth and the CPU is not technically slowed down.

What sort of compromises, if any, would be involved in doing this? (By "compromise" I'm thinking of differences in behaviour that you would not have had if you had used dual-ported RAM to share the memory.)

The compromise is limiting the opcodes that may be executed while the display is running.

The way this works is that the display generation hardware is set up to read the byte from the screen buffer directly off the databus during T3. At this time, the Z80 does a read from an address involving R, which is designed for DRAM refresh. The Galaksija hardware rigs this to get the character from the screen buffer (this byte is looked up in a character ROM, and the result is clocked out for the next eight pixels).

As you can imagine, variation in the timing of the instruction stream is going to be detrimental to the picture on the screen here. So the machine code running at this time needs to be very carefully timed. It only uses M1 cycles for the 32 cycles where the computer is generating the active part of the display (i.e., 31 single-byte opcodes followed by one more instruction).

Parts of this same machine code happens to also be useful data. There is the string BREAK, and the floating point constant 1.0. This same code also counts the scanlines, so it can set the hardware up to start displaying the next one. And of course, it keeps track of when it needs to break out of this loop.

Answer 5

The Amstrad CPC range of Z80 machines 'solved' this problem by interleaving RAM reads by the video gate array with Z80 read and writes.

As some Z80 M-states last 3 clock cycles, and some last 4 clock cycles, the video gate array uses the WAIT line to pause the Z80 every time it accesses video memory. This doesn't affect the 4 cycle states, but effectively stretches the 3 cycle states to 4. Because of this, the 4MHz Z80 appears to run at around 3.3MHz.

Answer 6

To add to the Spectrum answer: the transparent video access was used in Spectrum 128, not just the clones. Not that it matters. Indeed the method used required memory access time of 1 clock cycle. But there were only 32 characters per line.

Now suppose we want 64 bytes per line. Using 6 pixels per character we can even squeeze 80 characters for a CPM machine. Use 10 MHz clock for both the CPU and pixel clock. Static memory chips 128K x 8 bits with 55 ns access time are plentiful and cheap. No problem!