Undocumented features of the Zilog Z80 CPU
What is meant by "undocumented features"? In this context the phrase is normally used to refer to those aspects of the behaviour of the Z80 that are either not specified in, or are in direct contravention to the official documentation from Zilog. These broadly fall into two categories: Instructions and Flag Behaviour. 
This webpage is not intended as an offical guide to these exceptions. It contains information collected from various sources, including personal experience and study, relating to the peculiarities of the Z80. The trouble with "undocumented" information is that it is not, err, documented.. :-) Obviously. Therefore these things tend to be collections observations from many people. Other sources of this same unofficial information may differ in the details described as each source makes assumptions or even mistakes in their interpretations of the data. This page describes the information in a form which *I* believe to be correct, and which ASp behaviour is based on. I make no warranties as to its accuracy. 
Undocumented Instructions: 
There are approximately 1800 possible opcode combinations available to the Z80. Less than half of these are defined as being "official" instructions. The question is, what will a Z80 do if it encounters one which is undefined? 
Most modern processors will reject any unofficial (undocumented) opcodes and fall back to an error routine in an effort to minimise damage caused by the processor (presuambly) trying to run code it shouldn't be. As with many older CPUs the Z80 has no such failsafes and will continue to try to run the code. In many cases the illegal opcode will simply "do nothing", but in other cases the cpu may perform actions which would take more effort to achieve by "official" means. Programmers have tried to squeeze performance out of a CPU by taking as many shortcuts as possible, including the use of such hidden features as undocumented instructions. When creating an emulator therefore, it is important to understand and correctly emulate these features to ensure all programs will work. 
The Z80 instruction set has "basic" 1-byte opcodes and "shifted" 2 or more byte opcodes. In addition, data bytes can be embedded into the instruction stream. The "shifted" opcodes are prefixed with a byte of value CB, DD, ED, or FD (hex). Double-shifted opcodes are prefixed DD CB or FD CB. 
All "basic" single byte opcodes are defined and documented. 
All CB-shifted opcodes are defined, except the range CB 30 to CB 37. This first group of undocumented codes are usually referred to as "Shift Left Logical". The byte referenced is shifted one bit to the left just like the documented SLA instruction. Unlike that instruction however, SLL causes the Least Significant Bit to be set to a "1". 
The ED-shifted opcodes are mostly defined between ED 40 to ED 7F. In addition there are the block transfer instructions. Those opcodes outside that range will do nothing at all, except take time to fetch (8 cycles total). Those within the range 40 to 7F which are undocumented do have an effect. The following table of opcodes details the effective instructions for this range. It is available from a number of public sources, this version is taken from the documentation for the "Z80" Spectrum emulator for PC's by Gerton Lunter. Those instrunctions marked with a "*" are undocumented, those marked with "#" are documented in some manuals, but have shorter, single-byte equivalents. 
ED40	IN B,(C) 	ED60	IN H,(C)	
ED41	OUT (C),B 	ED61	OUT (C),H	
ED42	SBC HL,BC 	ED62	SBC HL,HL	
ED43	LD (nn),BC 	ED63	#LD (nn),HL	
ED44	NEG 	ED64	*NEG	
ED45	RETN 	ED65	*RET	
ED46	IM 0 	ED66	*IM 0	
ED47	LD I,A 	ED67	RRD	
ED48	IN C,(C) 	ED68	IN L,(C)	
ED49	OUT (C),C 	ED69	OUT (C),L	
ED4A	ADC HL,BC 	ED6A	ADC HL,HL	
ED4B	LD BC,(nn) 	ED6B	#LD HL,(nn)	
ED4C	*NEG 	ED6C	*NEG	
ED4D	RETI 	ED6D	*RET	
ED4E	*IM 0 	ED6E	*IM 0	
ED4F	LD R,A 	ED6F	RLD	
ED50	IN D,(C) 	ED70	#IN (C)	
ED51	OUT (C),D 	ED71	*OUT (C),0	
ED52	SBC HL,DE 	ED72	SBC HL,SP	
ED53	LD (nn),DE 	ED73	LD (nn),SP	
ED54	*NEG 	ED74	*NEG	
ED55	*RET 	ED75	*RET	
ED56	IM 1 	ED76	*IM 1	
ED57	LD A,I 	ED77	*NOP	
ED58	IN E,(C) 	ED78	IN A,(C)	
ED59	OUT (C),E 	ED79	OUT (C),A	
ED5A	ADC HL,DE 	ED7A	ADC HL,SP	
ED5B	LD DE,(nn) 	ED7B	LD SP,(nn)	
ED5C	*NEG 	ED7C	*NEG	
ED5D	*RET 	ED7D	*RET	
ED5E	IM 2 	ED7E	*IM 2	
ED5F	LD A,R 	ED7F	*NOP	
The DD and FD shifted opcodes are offically defined for only a few combinations. The way they appear to work is to translate a reference to the HL register pair into a reference to the IX or IY register pairs. If the reference was to (HL) indirect memory access, then the IX or IY pairs are used as index registers to an offset added to the end of the opcode. All this is documented. In instances where the DD or FD prefix is placed in front of an opcode which makes no reference to HL the instruction is performed as if the DD or FD was not there. However, if the instruction made reference to the H or L registers separately, then the instruction will now be performed on the high or low byte (as appropriate) of the IX or IY index register. Not all references to HL can be addressed in this way. For example, "EX DE,HL" (exchange DE and HL register pairs) will NOT change to "EX DE,IX" if prefixed with DD. 
The double-shifted opcodes are more complex. Only 62 of the 512 possible combinations are defined (64 if you allow for the above-mentioned SLL instruction). They cause CB-shifted instructions to work on (IX+d) or (IY+d) indexed values. The undocumented instructions ALL have an effect. The index offset byte is encoded directly after the CB regardless, for eg, DD CB 04 46 is "BIT 0,(IX+4)". Therefore it is the second byte after the CB which defines the operation, the index offset is always fetched. What happens is this: If the opcode would normally refer to the (HL) indirect mode, then the instruction works normally. If the opcode does NOT refer to (HL) then the operation is performed on the indexed data anyway but the answer is written both to the indexed value AND to the register which would be referenced by a single-shifted CB opcode. ie: The data gets written to TWO locations. In the event of an instruction which does not modify anything, eg. the BIT instruction, there is no result to write and therefore no modification is performed to either "destination". So, if CB C7 is "SET 0,A" then DD CB 04 C7 is "SET 0,(IX+4)" (unofficially) but the result will ALSO get written to register A. Note, the operation is not performed on the two destinations, but the answer to the one is duplicated into the other. 
That covers all of the 1792 possible opcode combinations. 
Undocumented Flag Behaviour 
For each instruction the Flag Register (F) may be defined as having bits set or reset to reflect some aspect of the result of an operation. The behaviour of some or all of the bits of this register after certain instructions is not completely defined in official documentation. 
There are two bits of the F-register which are "unimplemented" - bits 3 and 5. Rather than remaining as "0" or some other inert bahaviour, these bits are also affected by instructions. Under most circumstances they are set the same as bits 3 and 5 of the answer to the operation. For eg, "ADD B" will add B to A, the result being written to A. Various bits in the F register will be set or reset to indicate the result of this operation. In addition, the "unimplemented" bits will be set with copies from the A register. 
It is very difficult to correctly determine all flag behaviour under all conditions. Here are some of the more popularly accepted undocumented behaviours that I have verified using a real Z80. 
BIT n,r: The P/V bit is set to the same value as the Z bit. In addition, normally the S-bit is set to zero, but if the instruction is BIT 7,r then the S bit is a copy of the MSB of the tested byte. 
CCF: The H-bit is set to what the C-bit was before the instruction was executed. 
AND r: The H-bit is set to 1 for the "AND" instruction, whereas all other logic ops set it to zero. 
CP x: The unimplemented bits are set according to the source argument (x), not the result. The other flags are set according to the result. 
There are some sources of information which suggest extremely complex behaviour of the F register. Mostly I have found this information to be incorrect. Because these are UNDOCUMENTED features, the manufacturer is at liberty to change the behaviour of these things and so those results may be from a different revision of chip. Specifically, I have found that references to the following to be incorrect when I tried this with a real Spectrum: 
BIT n,(HL)/(IX/IY+d): Suggestions that the unimplemented flag bits are set to values dependent on the immediately preceding instruction. I found that they are set to bits 3 and 5 of the argument as is a normal BIT instruction applied to a register. 
Block transfer and compare instructions: Suggestions that the unimplemented bits are set to values mathematically related to the A register and the indexing HL register pair, as well as the memory contents referenced. I find that they are either unaffected or are set according to a normal (non-block) operation. 
