Z80 WAIT line questions - What does it do inside the CPU ?

[Banned 05.11.2017]

Hi there,

I have a question about the Z80 WAIT line. The question is about what does it exactly do inside the CPU in terms of the CPU internal state machine and control lines and clock.

For example, once the WAIT line is activated, does the CPU immediately stop its internal state machine operation or clock?

The WAIT line is used for slow IO devices and such, so once it goes active, the CPU waits for the IO device to finish its work. What I need to know is the internal process that makes this happen. It doesnt need to be in detail. I only need to know if the CPU stops its internal clock and control lines, until WAIT goes inactive.

This seems to make sense to me, because by stopping its internal clock, the CPU freezes in place for the IO to finish.

THis might not be the case though. The clock could still run but the internal state machine and its control lines orchestrating the CPU in general could halt.

Does anybody know what it actually does?

Thanks a lot.

[Andy Watson]

Zilog's literature indicates that the Wait line is "sampled" during the T2 state. To me, this suggests that the clock continues to operate but the state-machine is held in its T2 state until the wait line is sampled as high. Also, IO requests automatically incur at least one wait state - if this was achieved by stopping the clock the processor would become stuck in T2.

Zilog's description of the wait line: "The CPU continues to enter wait states for as long as this signal is active." suggests that the processor is actively doing nothing by repeating the T2 state. As for the control lines, I would expect them to maintain whatever state they were in when the wait became active - this is essentially the purpose for the wait signal - to prolong memory and IO accesses.

[Banned 05.11.2017]

Hmmm interesting. So we keep the states as long as wait is active.... very good Andy... Very good.

So whatever state the CPU is in at the moment WAIT goes active gets repeated for another clock cycle for as long as WAIT is active..

This seems a much better solution than just stopping the clock altogether.

The reason is that I am building a CPU and I need a WAIT line in it, but I wasn't sure the best way to actually do this...

Thanks a lot Andy, you saved the day!

[rstofer]

With the CPU held in T2, memory refresh doesn't happen.  There is a limit to how long the WAIT state can be maintained.  Same store with BUSREQ:  If the bus is used for a very long DMA transfer, the external controller needs to handle refresh.

Pages 13..15 here:
http://home.mit.bme.hu/~benes/oktatas/dig-jegyz_052/Z80-kivonat.pdf

[georges80]

Of course refresh is not an issue if you use static rams. Way back when, 32/64k byte static rams were unicorns so dram was necessary, these days for a retro machine it would be so easy to just use a couple of cheap 32k byte srams and be done. No refresh to worry about and a heck less wiring/routing.

Extended WAIT/BUSRQ will of course not only impact refresh (if you are using drams) but also keep the processor from executing/servicing interrupts, executing time sensitive code, etc.

cheers,
george.

[Banned 05.11.2017]

Is the WAIT line used for anything else other than for slow IO ?

Does it work if MemReq or IOReq are not active?

In other words, is the WAIT line a general WAIT line or does it only work if the CPU is doing IO operations?

[Banned 05.11.2017]

I am thinking of implementing the WAIT function as follows:

If WAIT is high at any moment, then at the next rising edge of the clock, the CPU goes to the same state it is right now AND no registers are written to. That is, I will AND the master clock with NOT WAIT, so that the clock will not rise is WAIT is high. This way the internal registers do not change until WAIT goes low again. This prevents double clocking registers inside the CPU and changing its state when WAIT is high.

Does it sound like a good idea?

[grumpydoc]

WAIT is sampled at certain defined times in the opcode fetch, memory read/write and I/O read/write cycles, it is not a general "stop the CPU for a while" line.

[Banned 05.11.2017]

However you said it is also sampled during the fetch cycle, so this means it is sampled in between instructions.. doesn't that make it a general waiting line ?

[grumpydoc]

However you said it is also sampled during the fetch cycle, so this means it is sampled in between instructions.. doesn't that make it a general waiting line ?

You could (ab)use it a bit to slow the CPU generally but if you miss the specific point that it is sampled (rising edge of T2 if memory serves but I don't have a datasheet handy) you have to wait (sorry) until the next memory or I/O cycle.

Once it is active, of course, it is sampled every clock.

[georges80]

However you said it is also sampled during the fetch cycle, so this means it is sampled in between instructions.. doesn't that make it a general waiting line ?

WAIT is sampled during an external bus cycle - it's intent is to allow for extra time for a device to respond to the address/chip decode going valid. Way back when, memory/IO etc was slow, e.g. it could take 500ns (or more) from valid address/chip select to having valid read data from the memory chip - so adding a WAIT state (or 2 or ...) would give one extra clock (or more) for the data to be valid. Ditto for write setup time.

So, WAIT is sampled during an external bus cycle. Every instruction goes to external memory - there is no cache etc inside a Z80.

The BIG question to you: What are you trying to achieve with the WAIT signal? Explain your need to activate it and why you want to stall the instruction? Is this to single step the program execution?

cheers,
george.

[Banned 05.11.2017]

It's for a homemade composite tv video card that I am building for the homebrew computer. I'm thinking of halting the CPU for a moment while the video card writes to its video ram. CPU asks video card to write a byte to VRAM, video card halts CPU while it does that, then back to business.

[edavid]

Hmmm interesting. So we keep the states as long as wait is active.... very good Andy... Very good.

So whatever state the CPU is in at the moment WAIT goes active gets repeated for another clock cycle for as long as WAIT is active..

This seems a much better solution than just stopping the clock altogether.

They did it that way not because it was better, but because the CPU used dynamic logic internally, so the clock had to keep running.

Your homemade CPU is presumably static logic, in which case it would be much simpler to stop the clock.

[rstofer]

I am thinking of implementing the WAIT function as follows:

If WAIT is high at any moment, then at the next rising edge of the clock, the CPU goes to the same state it is right now AND no registers are written to. That is, I will AND the master clock with NOT WAIT, so that the clock will not rise is WAIT is high. This way the internal registers do not change until WAIT goes low again. This prevents double clocking registers inside the CPU and changing its state when WAIT is high.

Does it sound like a good idea?

No...

Look at Figure 5 (and 6, 7) in the User Manual I linked above and notice what is happening at T2 time.  All of the bus signals required to read or write are active so your peripheral doesn't have access to the memory.  If you want access to the bus, you need to look at BUSREQn on page 15 et seq.  Figure 8 shows where the bus signals are floated when BUSACKn is active.

WAIT is used only for extending a read/write cycle while a read/write cycle is actually happening.  BUSREQ is used to cause the CPU to release the bus for some external access.

[grumpydoc]

It's for a homemade composite tv video card that I am building for the homebrew computer. I'm thinking of halting the CPU for a moment while the video card writes to its video ram. CPU asks video card to write a byte to VRAM, video card halts CPU while it does that, then back to business.

This might be a post your design moment.

OK, it is not an unreasonable thought to use WAIT - if the video card is accessing the memory when the Z80 access starts you could, indeed, use WAIT to allow the video card access to complete.

But that is not the whole solution - if the Z80 access is ongoing and the video card wants access you cannot just assert WAIT and expect the Z80 to always stop - you need some sort of exclusion mechanism which allows whoever gets there first to complete their access.

Or you could use dual port RAM or derive the Z80 clock from the video clock so that you can interleave access.

Oh, I was nearly correct - WAIT is sampled on the falling edge of T2.

[Banned 05.11.2017]

Yes I am using static ram only. So it's best to just stop the clock eh? That was my original idea, and today I ended up deciding to do just that because it would have the same effect anyhow. Thanks for your input.

[Banned 05.11.2017]

But my WAIT function is also used only for that, to extend reads and writes, and not to tristate the buses etc. What I want is a method to give a little more time for devices to work, rather than letting go of the bus in a DMA fashion...

But it seems better and simpler to just stop the clock altogether for this, this will freeze the CPU in place as long as needed for IO...

[edavid]

Yes I am using static ram only.

That is not really what I was talking about, see: https://en.wikipedia.org/wiki/Dynamic_logic_(digital_electronics)

I didn't think it was too likely that you were using dynamic logic, but that's the reason the Z80 and other CPUs of that vintage work that way.

[Banned 05.11.2017]

I don't have the schematics for my video card unfortunately. But I do have the schematics for my CPU

I am not using a Z80. I am using a homebrew CPU that I am building... This is why I am wanting to add a WAIT signal to my CPU, and not use Z80's... I just wanted to know how the z80 mechanism works..

I don't quite see the problem you mention. The video card will be working as normal, and then if the CPU wants to write to VRAM, it just raises WR, and the video card intercepts it, stops the CPU, writes the data, and then back to normal. There is no point at which the cpu is accessing the VRAM and conflicting with the video card because the video card controls the flow of data