10

Is there a software method of disabling memory refresh on the Z80? Or would it be acceptable to create a hardware method of disabling the address bus during the refresh cycle? If I switch off the output-enable of the bus transceiver during refresh cycles, the memory and peripherals would never see this request, but I'd need to add some extra glue logic and I'm not sure if it's worth it. I really would like to disable the refresh. Is there a version of the Z80 that doesn't refresh?

12
  • 4
    What computer is this meant for and what do you want to accomplish?
    – Raffzahn
    Oct 29, 2019 at 18:18
  • 11
    Why do you want to disable the refresh cycle? Oct 29, 2019 at 20:06
  • 6
    Honestly, I didn't include the 'why' I want to do this because I didn't want to tempt people into giving answers about why I shouldn't. I just wanted to know if it is possible for educational reasons, to remove confusion when watching the address bus for debugging, and because my hardware just doesn't need it. Obviously the glue logic is simpler if I don't have to watch the refresh pin.
    – Jasmine
    Oct 30, 2019 at 3:48
  • 4
    Because the request is confusing without that information? Instead of 5 minutes, it cost me about an hour to write a somewhat usable answer. There is a next to endless ways to 'disable' refresh - and all depend on what should be archived - not just the selection. Also the requirement does change - especially when it's as broad as 'disable'. As there is simply no disable switch, the question is what effect of refresh is to be avoided - and that's what the a good answer should be about - at least any beyond a quite compact "No, not possible." Answer
    – Raffzahn
    Oct 30, 2019 at 17:43
  • 8
    I have to agree with Jasmine on this. I don't like it when I ask a question (hasn't happened to me here, but on other forums) and people will jump in with "don't do that, it's stupid". Let ME be the judge of that. Sometimes people need to figure things out for themselves, or they have an idea that might be criticized or take too long to explain. The worst, in my opinion, is when I go to the hardware store and ask for something generic, not a specific product, because I'm making something and the clerk will ask what it's for. Ugh! It doesn't matter what it's for!
    – Mike
    Oct 30, 2019 at 20:09

3 Answers 3

17

A Z80 will always do a refresh cycle during T3/T4 of an M1 cycle. Disabling is not possible.

During a refresh cycle the /RFSH signal will be active for both cycles, signaling a valid refresh address, while /MREQ is active during the second half of T3 and the first half of T4. Neither /RD nor /WR will be active during T3/T4. Thus a refresh cycle is never a valid data access cycle.

The question isn't clear to what purpose the refresh has to be disabled.

  • Normally no precaution is to be taken for refresh. At least if decoding includes /RD and /WR (*1), as neither is signalled during non-data-transfering cycles memory access.

  • If it is meant to avoid detecting refresh as memory cycle (due /MREQ being active) when decoding an address, integrating /RFSH to disable decoding is all that's needed.

  • If it's about to use that time for some hidden memory access, then buffers have to be added to seperate address bus as well as all other memory access signaling.


*1 - In general Z80 address decoding should always include /RD and /WR before doing anything substantial, as these are the lead signals to indicate a valid memory access. /MREQ only signals a valid address bus content.

2
  • 2
    Right, I took the guess that there's something in his address decoding that he doesn't want to trip — like maybe he's a Woz-esque fan of soft switches — but quite probably this discussion of signals (+1 from me, as usual) is more useful than merely pointing out that you can lock the refresh addresses into any aligned 128-byte range you like.
    – Tommy
    Oct 29, 2019 at 21:45
  • 1
    @Tommy Yes, I had the same impression. But the question doesn't offer enough information to give a good answer. That's why I added a request for clarification to the question first and waited a bit. Your idea of why he wants it seams logical, haven't thought along that line.
    – Raffzahn
    Oct 29, 2019 at 22:12
10

No, it cannot be disabled, although it can be ignored by the rest of the hardware. Just OR /MREQ with /RFSH negated. Decoding /MREQ along with /RD or /WR is also fine, and you won't need /RFSH. A 74HCT138 3 to 8 decoder can do the job.

No, there is no Z80 pin compatible, software compatible processor that allows the user to disable the refresh cycle, but the eZ80 microcontroller series have a Z80 compatible mode, in which machine code programs written for the original Z80 can still be executed, while using a fully pipelined execution mode (as opposed to the overlapping execution mode employed by the original Z80) for executing instructions, thus removing the refresh cycle (although the R register still exists).

8

I can't speak as to derivatives, but the plain Z80 does not permit you to disable refresh. One refresh cycle will be attached to every operation byte fetched from the instruction stream (with the exception of offsets in IX/IY+d mode).

That said, the value placed on the bus during refresh is I:R — the I register is used to populate the top 8 bits, and is guaranteed 0 at reset. So as long as you have something in the first 128 bytes that isn't troubled by the refreshes, such as a ROM, it shouldn't be problematic.

Even if your first 128 bytes are only transiently ROM, it might be acceptable to set I and the top bit of R appropriately during machine startup so that the refresh requests miss anything sensitive.


EDIT: there seems to be some controversy about this, for some reason. Secondary sources are more explicit, so:

Per this extract from the ZX Spectrum FAQ:

The R register is a counter that is updated every instruction, where DD, FD, ED and CB are to be regarded as separate instructions. So shifted instruction will increase R by two. There's an interesting exception: doubly-shifted opcodes, the DDCB and FDCB ones, increase R by two too.

So that says: if your instruction has two bytes, it'll increment R twice. Note that "doubly-shifted opcodes" are those with an offset, using IX/IY+d addressing, so they're three instruction bytes but only two of those increment R. So, if you buy that R is incremented only during a refresh cycle, that FAQ says exactly what I said.

See also this table of MSX instruction timings. What's interesting about the MSX is that it inserts one extra cycle into every M1. Check out the differences between the Z80 and Z80+M1 columns. The following is the first of the hundreds of entries where the difference is more than 1:

ADC A,(IX+o) 19 21 5 7 DD 8E o 3

So, from the two sources cited so far you can conclude:

  • R is incremented twice for ADC A,(IX+d); and
  • hardware that inserts a one-cycle WAIT every time it sees an M1 cycle will insert two cycles of wait total for ADC A,(IX+d).

Spoiler: it's because there are two M1 cycles and two refreshes in ADC A,(IX+d), on account of it contributing two bytes to the instruction stream other than its offset.

Alas the official Z80 User Manual is a little more oblique, but it defines M1 as:

M1. Machine Cycle One (output, active Low). M1, together with MREQ, indicates that the current machine cycle is the op code fetch cycle of an instruction execution. M1, when operating together with IORQ, indicates an interrupt acknowledge cycle.

That's an unfortunate use of 'the', but the sentiment to equate M1 cycles with op code fetches is basically correct, and correlates with the much lazier later in-place definitions:

Figure 5 depicts the timing during an M1 (op code fetch) cycle.

Total point? The definition given above is exactly correct. There is one refresh cycle per byte fetched from the instruction stream, with the exception of offsets in IX/IY+d instructions.

As tangential evidence I also offer my Z80 emulator, one of the cycle-perfect ones which just so happens to be used in emulations of the ZX80/81 (refresh cycle used for graphics fetch), the MSX (one cycle's delay on every M1 machine cycle) and the Amstrad CPC (WAIT strobed for three out of four cycles, which will properly stretch the instruction stream only if you're sampling WAIT properly). It gets 100% perfection on every timing test I've been able to source, including across all three of those platforms.

4
  • Refresh cycles are generated for every M1 cycle. Oct 29, 2019 at 20:06
  • 2
    @busybee yes, and an M1 cycle is formally defined to be: an opcode fetch. So you've said exactly what I said, using a synonym. And aggressive bolding.
    – Tommy
    Oct 29, 2019 at 21:39
  • 2
    Erm, little correction, it isn't "one refresh cycle per byte fetched from the instruction stream", but one refresh cycle (as part of M1) per opcode fetched - tehre is no refresh when parameter bytes of the instruction stream are fetched.
    – Raffzahn
    Oct 29, 2019 at 22:09
  • @Raffzahn you're right, and even my own links prove it. See e.g. ADD n in the MSX link.
    – Tommy
    Oct 29, 2019 at 22:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .