Why do only the low 7-bits of the R register increment?

Question

On the Z80 the R register is 8 bits wide, as evidenced by LD A,R and LD R,A And every M1 cycle, R increments by 1. But the uppermost bit does not participate in this increment. R will not go from 0x7F to 0x80 or from 0xFF to 0x00. Apparently that behaviour is useful for DRAM refresh.

But how was that implemented?

• The Z80 has a 4-bit ALU which is used for all 8-bit and 16-bit operations, but apparently not this one. That means there must be a separate incrementer on the die?

• I'm sure the Z80 designers were not imagining a programmer wanting to use R as an 8 bit counter, so they could have saved one bit of memory by having R only 7 bits wide.

Answer 1

The R register is solely used to put out consecutive increased row addresses for RAM refresh. The fact that it is readable and setable by programs (*1) is rather a quirk than a feature (*2).

I and R is a register pair right beside PC; a clever trick to save circuitry:

• Firstly, I needs to be placed on the upper address bus, like PCH, so putting it alongside PCH means the same buffers and signal lines can be used when the upper half of the interrupt service address is to be put out.

• Secondly, for a refresh address it doesn't really matter if it's on the upper or lower address bus half, so the 'hole' beside I can be easy be used for another register holding the refresh (row) address, and again the same buffers/lines can be used to deliver it.

• And lastly, putting R here allows the usage of the the same incrementer/decrementer circuits as used to handle the PC.

From this it's easy to see that

• R doesn't have a specialized 7-bit incrementer; it uses the full 16-bit incrementer as for PC, but during operation on (I)R, carry over is disabled between bit 7 and 8, so making it work as 7-bit incrementer.

• Since the register block is a symmetric structure of 12 register pairs, leaving out one bit somewhere in the middle wouldn't have saved anything.

So, why just 7 Bits?

When Faggin et. al. designed the Z80 in 1974/75, the only available DRAM with multiplexed addresses (and row refresh) was Mostek's 4 KiBit Chip MK4096, released in 1973. It was an instant success - a good reason for Zilog to include support for the new RAM interface design. The MK4096 needed a 6-bit row address for refresh. At that time 16 KiBit DRAM's were talked about, but no-one had one until Mostek started selling its MK4114 in 1976 - after the Z80 was released. So for this time-frame, the decision of utilizing 7 bits was already looking forward.

Anything bigger was hard to imagine at that time. After all, it took 4 more years, until 1980, to make 64 KiBit DRAM available (which now would require 8-bit refresh counters).

• From a technological and marketing standpoint offering 7 bit (instead of 6) was a sensible, forward-looking decision.

• Why it only used 7 bit for the increment can only be guessed, as all the other hardware would have supported a full 8-bit refresh counter.

---

*1 - Of course it needs to be read- and writeable on the hardware side, otherwise it can't do it's job:)

*2 - Well, there have been uses found, like RNG seeds and the like, as well as using the 8th bit as a 'secret' flag.

Answer 2

The 'R' register increment happens simultaneously with other operations, as it happens for every instruction, but must occur after the refresh cycle in each instruction (which happens at the end of instruction fetch, thus pushing the only time the increment can actually happen into the time when the fetched instruction is executing), so it cannot use the standard ALU. Therefore, the Z80 has a separate 7-bit wide incrementer for the R register. It is implemented as part of the circuitry for the instruction counter incrementer (instruction counter increment can happen immediately after instruction fetch, i.e. while the refresh cycle is being generated, so doesn't conflict with ordinary instruction execution, but the ALU incrementer is only 8 bits I believe, while the instruction counter needs a full 16 bit incrementer).

7 bits would have been chosen because 128 was the number of refresh cycles required for the most common DRAM chip type at the time the Z80 was designed, the 4116.

Ken Shirriff has die photos and a more detailed explanation on his blog, and a detailed article about the implementation of the incrementer. It's also worth noting that other register increments are also apparently implemented not using the ALU but by a dedicated increment/decrement circuit. Presumably, because this doesn't need full carry prediction, but a much simpler circuit to detect the case of all ones (or zeroes for decrement) to the right of each bit, this could be done in a single cycle rather than requiring two to feed the operation through the ALU, without wasting too much die space.

Answer 3

@Jules's link to the incrementer details offers an unsatisfying explanation:

When the Z-80 was introduced, 16K memory chips were popular. Since they held 2^14 bits, they had 7 row address bits and 7 column address bits. Thus, a 7 bit refresh value matched their need. Unfortunately, this rapidly became obsolete with the introduction of 64K memory chips that required 8 refresh bits.

That explanation suggests no reason why the designers couldn't have chosen 8 bits, with an eye to future memory devices.

I think the real reason lies elsewhere in that description.

Firstly:

Bits 7 through 11 are computed using the carry lookahead value, allowing them to be computed without waiting on the low-order bits. In parallel, the carry/borrow out of these bits is computed by the large NOR gate in the middle, and used to compute bits 12 through 14. The last carry lookahead value is computed at the left and used to compute bit 15. Note that the number of carry blocks decreases as the number of carry lookahead gates increases. For example, output 6 depends on three inc/dec blocks and no carry lookahead gates, while output 14 depends on one inc/dec block and two carry lookahead gates. If the inc/dec blocks and carry lookahead gates require approximately the same time, then the output bits will be ready at approximately the same time.

i.e. The splits in the circuit structure were designed to meet overall timing constraints on the 16-bit incrementer, without regard for any secondary function it may be used for. As it turned out, one of those splits was between bits 6 and 7.

Next:

One unexpected feature of the Z-80's incrementer is that it can pass the value through unchanged. If the carry-in to the incrementer/decrementer is set to 0, no action will take place. This seems pointless, but it actually useful since it allows a 16-bit value to be latched and then read back unchanged.

Furthermore, if the carry-in to bit 7 of the incrementer is set to 0 - via the 'refresh' input to the NOR gate - then the upper 9 bits of the incrementer will not increment, but will preserve their input values.

And finally:

The program counter and refresh register are separated from the rest of the registers and coupled closely to the incrementer. This allows the incrementer to be used in parallel with the rest of the Z-80. In particular, for each instruction fetch, the program counter (PC) is written to the address bus and incremented. Then the refresh address is written to the address bus for the refresh cycle, and the R register is incremented. (Note that the interrupt vector register I is in the same register pair as the R register. This explains why the I value is also written to the address bus during refresh.)

i.e. The I and R registers are updated through the incrementer as a 16-bit pair, just like the PC - but in this case the upper 9 bits are not incremented, and so I and bit 7 of R are actually reloaded with the same value. There's no separate load control for the two halves of the pair, at least as far as the incrementer is concerned.

(EDITED TO ADD: That's actually quite an assumption on my part, especially considering the separate I & R load capability I mention below. But I think that even if R can be loaded from the incrementer independently of I, the argument still applies to bit 7 of R.)

(Note that I and R can be individually transferred to and from A, but this is a distinct function from the refresh-cycle increment.)

So: While it would seem natural for the refresh counter to use 8 bits, the internal structure of the 16-bit incrementer (adopted to meet its timing requirements) was such that a 7-bit counter function is what was available - and this was sufficient for the prevailing memory technology of the time.