The Z80 processor is quite straightforward, and contains to my knowledge no interesting bugs or quirks. However, it has some undocumented features. Some of these are quite useful, and some are not, but since many programs use the useful ones, and a few programs use the weird ones, I tried to figure them out and emulate them as best as I could. There is a Z80 emulator around, intended as a CP/M emulator, which halts the program if an undocumented opcode is encountered. I don't think this makes sense. ZiLOG doesn't dictate the law, the programs which use the processor's features do!
Most Z80 opcodes are one byte long, not counting a possible byte or word operand. The four opcodes CB, DD, ED and FD are shift opcodes: they change the meaning of the opcode following them.
There are 248 different CB opcodes. The block CB 30 to CB 37 is missing from the official list. These instructions, usually denoted by the mnemonic SLL, Shift Left Logical, shift left the operand and make bit 0 always one. Bounder and Enduro Racer use them. The SamRam monitor can disassemble these and uses the mnemonic SLL. These instructions are quite commonly used.
The DD and FD opcodes precede instructions using the IX and IY
registers. If you look at the instructions carefully, you see how they
work:
| 2A nn | LD HL,(nn) |
| DD 2A nn | LD IX,(nn) |
| 7E | LD A,(HL) |
| DD 7E d | LD A,(IX+d) |
A DD opcode simply changes the meaning of HL in the next instruction.
If a memory byte is addressed indirectly via HL, as in the second
example, a displacement byte is added. Otherwise the instruction simply
acts on IX instead of HL. (A notational awkwardness, that will only
bother assembler and disassembler writers: JP (HL) is not indirect; it
should have been denoted by JP HL) If a DD opcode precedes an
instruction that doesn't use the HL register pair at all, the
instruction is executed as usual. However, if the instruction uses the
H or L register, it will now use the high or low halves of the IX
register! Example:
| 44 | LD B,H |
| FD 44 | LD B,IYh |
These types of inofficial instructions are used by very many programs. By the way, many DD or FD opcodes after each other will effectively be NOPs, doing nothing except repeatedly setting the flag `treat HL as IX' (or IY) and taking up 4 T states. (But try to let MONS disassemble such a block.)
I've never seen a program using inofficial ED instructions, and except for ED 6B nn, a long version of 2A nn, LD HL,(nn) I don't know any. I am pretty sure however that they exist, but I never took the trouble to test them all.
About the R register. This is not really an undocumented feature, although I have never seen any thorough description of it anywhere. 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. LDI increases R by two, LDIR increases it by 2 times BC, as does LDDR etcetera. The sequence LD R,A / LD A,R increases A by two, except for the highest bit: this bit of the R register is never changed. This is because in the old days everyone used 16 Kbit chips. Inside the chip the bits where grouped in a 128x128 matrix, needing a 7 bit refresh cycle. Therefore ZiLOG decided to count only the lowest 7 bits. Anyway, if the R register emulation is switched on the R register will behave as is does on a real Spectrum; if it is off it will (except for the upper bit) act as a random generator.
You can easily check that the R register is really crucial to memory
refresh. Assemble this program:
| ORG 32768 | |
| DI | |
| LD B,0 | |
| L1 | XOR A |
| LD R,A | |
| DEC HL | |
| LD A,H | |
| OR L | |
| JR NZ,L1 | |
| DJNZ L1 | |
| EI | |
| RET |
It will take about three minutes to run. Look at the upper 32K of memory, for instance the UDG graphics. It will have faded. Only the first few bytes of each 256 byte block will still contain zeros, because they were refreshed during the execution of the loop. The ULA took care of the refreshing of the lower 16K. (This example won't work on the emulator of course!)
Then there's one other dark corner of the Z80 which has its effect on programs like Sabre Wulf, Ghosts'n Goblins and Speedlock. The Mystery of the Undocumented Flags!
Bit 3 and 5 of the F register are not used. They can contain
information, as you can readily figure out by using PUSH AF and POP AF.
Furthermore, sometimes their values change. I found the following
empirical rule:
| The values of bit 7, 5 and 3 follow the values of the corresponding bits of the last 8 bit result of an instruction that changed the usual flags. |
For instance, after an ADD A,B those bits will be identical to the bits of the A register. (Bit 7 of F is the sign flag, and fits the rule exactly). An exception is the CP x instruction (x=register, (HL) or direct argument). In that case the bits are copied from the argument.
If the instruction is one that operates on a 16 bit word, the 8 bits of the rule are the highest 8 bits of the 16 bit result - that was to be expected since the S flag is extracted from bit 15.
Ghosts'n Goblins use the undocumented flag due to a programming error.
The rhino in Sabre Wulf walks backward or keeps running in little
circles in a corner, if the (in this case undocumented) behaviour of the
sign flag in the BIT instruction isn't right. I quote:
| AD86 DD CB 06 7E | BIT 7,(IX+6) |
| AD89 F2 8F AD | JP P,#AD8F |
An amazing piece of code! Speedlock does so many weird things that all must be exactly right for it to run. Finally, the '128 rom uses the AF register to hold the return address of a subroutine for a while. To keep all programs happy and still have a fast emulator, I had to make a compromise. The undocumented flags are not always emulated right, but they are most of the time.
Finally, a remark about the interrupt flip flops IFF1 and IFF2. There seems to be a little confusion about these. These flip flops are simultaneously set or reset by the EI and DI instructions. IFF1 determines whether interrupts are allowed, but its value cannot be read. The value of IFF2 is copied to the P/V flag by LD A,I and LD A,R. When an NMI occurs, IFF1 is reset, thereby disallowing further (maskable) interrupts, but IFF2 is left unchanged. This enables the NMI service routine to check whether the interrupted program had enabled or disabled maskable interrupts. So, Spectrum snapshot software can only read IFF2, but most emulators will emulate both, and then the one that matters most is IFF1.
Now for the emulated Z80. I have added eight instructions, to speed up
the RS232 input and output of the Interface I and several things of the
SamRam. These opcodes, ED F8 to ED FE are of little use to any other
program. ED FF is a nice one: it returns you to DOS immediately. I
used it for debugging purposes.