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