R register
I'm cross-posting this as a spin-off of a thread in "Hardware" category
I have been checking emulator support & correctness of the R register behaviour.
From Z80 Manual
From this, we know that:
1 - R register, bit 7 must not change without being explicitly changed by an instruction.
NOTE: Reset also sets R register to zero, hence also changes bit 7.
2 - R register is incremented just after any instruction fetch. Hence R register can be considered a simple counter (instruction counter). It makes sense to do sequential increments, since when refreshing memory we don't want to skip any addresses, in order to guarantee that all addresses are refreshed equally and in time.
NOTE: There is large margin on the refresh timing, so it doesn't matter if we hold it for some time.
3 - R register content is dumped on the address bus lower byte, just after fetch, i.e. just after being incremented.
Having said 3 points above, I find it strange, that at least 2 emulators (the 2 I tested on), increment twice for "LD A,R" instruction, and once for all other instructions that I tested.
NOTE: All Z80 repeat instructions, like LDIR, LDDR, CPIR, and CPDR are re-fetched for each iteration (while BC is not 0), hence each iteration implies an increment.
So is the double increment correct, due to some Z80 quirk ?
Or
Emulator authors, inherit most of this base emulation, and hence this bug propagated ?
Do any of you know any special reason for this behaviour ?
I have been checking emulator support & correctness of the R register behaviour.
From Z80 Manual
Memory Refresh (R) Register.
The Z80 CPU contains a memory refresh counter, enabling dynamic memories to be used with the same ease as static memories. Seven bits of this 8-bit register are automatically incremented after each instruction fetch. The eight bit remains as programmed, resulting from an LD R, A instruction.
The data in the refresh counter is sent out on the lower portion of the address bus along with a refresh control signal while the CPU is decoding and executing the fetched instruction.
From this, we know that:
1 - R register, bit 7 must not change without being explicitly changed by an instruction.
NOTE: Reset also sets R register to zero, hence also changes bit 7.
2 - R register is incremented just after any instruction fetch. Hence R register can be considered a simple counter (instruction counter). It makes sense to do sequential increments, since when refreshing memory we don't want to skip any addresses, in order to guarantee that all addresses are refreshed equally and in time.
NOTE: There is large margin on the refresh timing, so it doesn't matter if we hold it for some time.
3 - R register content is dumped on the address bus lower byte, just after fetch, i.e. just after being incremented.
Having said 3 points above, I find it strange, that at least 2 emulators (the 2 I tested on), increment twice for "LD A,R" instruction, and once for all other instructions that I tested.
NOTE: All Z80 repeat instructions, like LDIR, LDDR, CPIR, and CPDR are re-fetched for each iteration (while BC is not 0), hence each iteration implies an increment.
So is the double increment correct, due to some Z80 quirk ?
Or
Emulator authors, inherit most of this base emulation, and hence this bug propagated ?
Do any of you know any special reason for this behaviour ?
Comments
That would be my first guess.
So, went digging a little further, and found a chapter in "Z80 documented V0,91"
6.1 R register and memory refresh
So this clarifies the weird behaviour for instructions with prefixes.
Thank you for your feedback,