		Z80 Undocumented Features (in software behaviour)
		=================================================

			By Sean Young (sean@msxnet.org)
			  Version 0.3 October 1998


This document describes all I know about undocumented features of the Z80.
Almost everything is taken from other people's pages, so don't think this
all my own stuff. However, I think there is some new stuff here too; about 
interrupts and flag affection and some other stuff. 

All information has a references to where I got it from. It's marked with
[number], which refers to the references at the end of this document (5.3).
For example, [5] indicates I've figured it out myself by experimenting.

As you've probably noticed, I'm no (true) native English speaker. Any 
comments, additions, about technical stuff or language is very welcome.

You can always find the latest version of this document at:

	http://www.msxnet.org/tech/


1) Undocumented Opcodes
 1.1) Prefixes in general
 1.2) CB Prefix
 1.3) DD Prefix
 1.4) FD Prefix
 1.5) ED Prefix
 1.6) DDCB Prefix
 1.7) FDCB Prefix
 1.8) Combinations of prefixes

2) Undocumented Flag affection & operation
 2.1) Flag register bits
 2.2) All instructions that affect the flags
  2.2.1) 8 Bit arthmetic and logical
  2.2.2) 16 Bit arithmetic
  2.2.3) BIT instruction
  2.2.4) Other non-block instructions
  2.2.5) Memory block instructions
  2.2.6) I/O block instructions
 2.3) Undocumented operation
  2.3.1) DAA
  2.3.2) I/O Instructions
  2.3.3) Block instructions

3) Interrupts and I register
 3.1) Non-maskable Interrupts (NMI)
 3.2) Maskable Interrupts (INT)
 3.4) Things affecting the IFFs
 3.5) HALT instruction
 3.6) Where can interrupts occur?

4) Timing and R register
 4.1) R register and memory refresh
 4.2) Instruction timings
 
5) Other information
 5.1) Power on defaults
 5.2) Errors in official documentation
 5.3) References and other resources


1) Undocumented Opcodes [1]
---------------------------

There are quite a few undocumented opcodes/instructions to the Z80. This
section should describe every possible opcode (so you know what
instruction will be executed, whatever the combination of values is).

Check out my Z80 Opcodes list for a complete list of all instructions.

	http://www.msxnet.org/tech/Z80/z80opcod.txt


1.1) Prefixes in General [1]

There are the following prefixes: CBh, EDh. DDh. FDh. DDCBh and FDCBh. 
Prefixes change the way the following opcodes are interpreted. 

All instructions without a prefix (without anything like the above before
it) are documented in the official documentation.


1.2) CB Prefix [1]

An opcode with a CBh prefix is a rotate, shift or bit test/set/reset 
instruction. There are a few instructions missing from the official list, 
which are usually denoted with SLL (Shift Logical Left). It works like 
SLA, for one exception: it sets bit 0 (SLA resets it).

	CB30	SLL B
	CB31	SLL C
	CB32	SLL D
	CB33	SLL E
	CB34	SLL H
	CB35	SLL L
	CB36	SLL (HL)
	CB37	SLL A


1.3) DD Prefix [1]

In general, after a DD prefix the instruction is executed as if the DD
weren't there. There are some exceptions:

* Any access to HL is treated as an access to IX (except EX DE,HL and EXX
  and the ED prefixed instructions that use HL).
* Any access to (HL) is changed to (IX+d), where d is a signed displacement
  byte placed after the main opcode (except JP (HL), which isn't indirect
  anyways.
* Any access to H is treated as an access to IXh (the high byte of IX)
  Except if (IX+d) is accessed.
* Any access to L is treated as an access to IXl (the low byte of IX)
  Except if (IX+d) is accessed.
* A DD prefix before a CB selects a completely different instruction 
  set (see 1.5).

So for some examples:

Without DD prefix	With DD prefix
LD H,(HL)		LD H,(IX+d)
LD H,A			LD IXh,A
LD L,H			LD IXl,IXh
JP (HL)			JP (IX)
LD DE,0			LD DE,0
LD HL,0			LD IX,0

Note LD IXl,IYh is not possible: only IX or IY is accessed in one instruction.


1.3) FD Prefix [1]

This prefix has the same effect as the DD prefix, though IY is used in
stead of IX.


1.4) ED Prefix [1]

There are a number of undocumented EDxx instructions, of which most are
duplicates of documented instructions. Any instruction not listed has
no effect (just like 2 NOP instructions).

The complete list except for the block instructions: (* = undocumented)

        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 * RETN
        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 * RETN
        ED4E * IM 0                     ED6E * IM 0
        ED4F   LD R,A                   ED6F   RLD

        ED50   IN D,(C)                 ED70 * IN (C) / IN F,(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 * RETN                     ED75 * RETN
        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 * RETN                     ED7D * RETN
        ED5E   IM 2                     ED7E * IM 2
        ED5F   LD A,R                   ED7F * NOP

The ED70 instruction reads from I/O port C, but does not store the result. 
It just affects the flags like the other IN x,(C) instruction. ED71 simply
outs the value 0 to I/O port C.

The ED63 is a duplicate of the 22 instruction (LD (nn),HL) just like the
ED6B is a duplicate of the 2A instruction. Of course the timings are
different. These instructions are listed in the official documentation.

According to Gerton Lunter (gerton@math.rug.nl):
    The instructions ED 4E and ED 6E are IM 0 equivalents: when FF was put
    on the bus (physically) at interrupt time, the Spectrum continued to
    execute normally, whereas when an EF (RST #28) was put on the bus it
    crashed, just as it does in that case when the Z80 is in the official
    interrupt mode 0.  In IM 1 the Z80 just executes a RST #38 (opcode FF)
    no matter what is on the bus.

[5] All the RETI/RETN instructions are the same, all like the RETN 
instruction. So they all, including RETI, copy IFF2 to IFF1. More information
on RETI and RETN and IM x is in the part about Interrupts and I register (3).


1.5) DDCB Prefixes [1][5]

The undocumented DDCB instructions store the result (if any) of the 
operation in one of the seven all-purpose registers, which one depends on
the lower 3 bits of the last byte of the opcode (not operand, so not
the offset).

        000     B
        001     C
        010     D
        011     E
        100     H
        101     L
        110     (none: documented opcode)
        111     A

The documented DDCB0106 is RLC (IX+01h). So, clear the lower three bits 
(DDCB0100) and something is done to register B. The result of the RLC
(which is stored in (IX+01h)) is now also stored in register B. Effectively,
it does the following:

	LD B,(IX+01h)
	RLC B
	LD (IX+01h),B

So you get double value for money. The result is stored in B and (IX+01h). The
most common notation is: RLC (IX+01h),B

I've once seen this notation:

	RLC (IX+01h)
	LD B,(IX+01h)

That's not correct: B contains the rotated value, even if (IX+01h) points to 
ROM memory.

The DDCB SET and RES instructions do the same thing as the shift/rotate
instructions:

DDCB10C0	SET 0,(IX+10h),B
DDCB10C1	SET 0,(IX+10h),C
DDCB10C2	SET 0,(IX+10h),D
DDCB10C3	SET 0,(IX+10h),E
DDCB10C4	SET 0,(IX+10h),H
DDCB10C5	SET 0,(IX+10h),L
DDCB10C6	SET 0,(IX+10h)
DDCB10C7	SET 0,(IX+10h),A

So the value of (IX+10h) with bit 0 set, is also stored in register A.

The DDCB BIT instructions do not store any value; the merely test a bit.
That's why the undocumented DDCB BIT instructions are no different from
the official ones:

DDCB d 78       BIT 7,(IX+d)
DDCB d 79       BIT 7,(IX+d)
DDCB d 7A       BIT 7,(IX+d)
DDCB d 7B       BIT 7,(IX+d)
DDCB d 7C       BIT 7,(IX+d)
DDCB d 7D       BIT 7,(IX+d)
DDCB d 7E       BIT 7,(IX+d) - official one
DDCB d 7F       BIT 7,(IX+d)


1.6) FDCB Prefixes [1]

Same as for the DDCB prefix, though IY is used in stead of IX.


1.7) Combinations of Prefixes [5]

This part may be of some interest to emulator coders. Here we define
what happens if strange sequences of prefixes appear in the instruction
cycle of the Z80.

In general, DD and FD can change the following instruction a bit, (use IX or
IY in stead of HL), and ED and CB select a completely different set of 
instructions.

EDxx: Any DD or FD prefix before it is ignored, no matter how many. A CBh
prefix can't appear before it because CBED is interpreted as SET 5,L; 
a separate instruction. If the second byte of an EDxx opcode is CB, DD, FD
or ED, it has no effect on following instructions:

	EDFD210000	NOP; LD HL,0

FDxx/DDxx: Any DD or FD before the FDxx/DDxx is ignored; in a sequence of DDs 
and FDs, it is only the last one that counts. The ones before just act like 
NOPs. CB before an DD or FD is not possible (as a prefix) because CBDD and
CBFD are instructions in themselves, so is EDFD and EDDD. 

CBxx: DD and FD prefixes are possible, with the effect as stated above. ED
isn't possible; EDCB is an instruction in itself (which doesn't do anything).


2) Undocumented flag affection & operation [5][3]
-------------------------------------------------

2.1) Flag register bits [5][3]

The F (flag) register has the following bits:

F	7  |  6  |   5  |  4  |  3  |  2  |  1  |  0
-----------+-----+------+-----+-----+-----+-----+-----
flag	S  |  Z  |   5  |  H  |  3  | P/V |  N  |  C

S flag: 
  set if the 2-complement value is negative. It's simply a copy of the most 
  significant bit.

Z flag:
  Set if the value is zero.

5 flag:
  A copy of bit 5 of the result.

H flag:
  The half-carry of an addition/subtraction (from bit 3 to 4). Needed for
  DAA correction.

3 flag:
  A copy of bit 3 of the result.

P/V flag:
  This flag can either be the parity of the result, or the 2-compliment
  signed overflow (2-compliment value doesn't fit in the register).

N flag:
  Shows whether the last operation was an addition (0) or an subtraction (1).
  This information is needed for DAA.

C flag:
  The carry flag, set if there was a carry after the most significant bit.

In this part, the following notation is used for flag affection:

* indicates the effect is non-standard (see the notes).
0 indicates the flag is reset.
1 indicates the flag is set.
- indicates the flag is not affected.
S,Z,5,H,3,P,V,N,C indicate the flag is set as above.

Notice there's no ``unknown'' or ``undefined'' here. :)


2.2) All instructions that affect the flags [1][2][3]

This section lists all the instructions that affect the flags, and how they
do that. 


2.2.1) 8 Bit arithmetic and logical

The 8 bit arithmetic group is straightforward:

ADD/ADC/SUB/SBC       SZ5H3VNC  

All standard flags ..

CP r                  SZ*H*VNC

A CP is simply a SUB with the result thrown away. Flag 5 and 3 are copied 
from the operand, not the result (which is thrown away anyways).

INC/DEC r             SZ5H3VN-

AND r                 SZ513P00
OR/XOR r              SZ503P00

RLCA/RLA/RRCA/RRA     --503-0C
RLC/RL/RRC/RR r       SZ503P0C
SLA/SLL/SRA/SRL r     SZ503P0C  SLL is like SLA except bit 0 gets set
RRD/RLD               SZ503P0-  Flags set on result in A


2.2.2) 16 Bit arithmetic

The 16 bit additions are a bit more complicated. 16 bit additions are done in 
two stages: first the lower bytes are added, then the two higher bytes. The 
S,5,H,3 flags are affected as by the second 8 bit addition. Z is set if the 
whole 16 bit result is 0.

ADD s                 --***-0C
ADC/SBC s             SZ***VNC


2.2.3) BIT instruction [5] [6]

BIT n,r               *Z513*0-	r is one of the 8 bit registers.

BIT behaves much AND r,2^n with the result throw away and the C flag is 
unaffected. So in effect: 
Z = set if the tested bit is reset. 
S = set if n=7 and tested bit is set.
5 = set if n=5 and tested bit is set.
3 = set if n=3 and tested bit is set.
P/V = set like Z.

BIT n,(IX/IY+d)	      *Z*1**0-

Again, P/V is set like Z and S is if set n=7 and the tested bit is set. But
the 5 and 3 flags are different: they are a copy of bit 5 and 3 of the high
byte of IX/IY+d (the value after the addition of d to IX or IY).

BIT n,(HL)            *Z*1**0-

P/V, Z, S set as the other BIT instructions, but the 5 and 3 flags are
different. Okay, brace yourself. They are a copy of an internal register of
the Z80, which is set as follows:

ADD HL,xx      (use high byte of HL, i.e. H, before the addition)
LD r,(IX/IY+d) (use high byte of the resulting address IX/IY+d)
JR d           (use high byte target address of the jump)
LD r,r'	       (not affected)
others         not tested -- any additions welcome!


2.2.4) Other non-block instructions [2] [5]

CCF                   --***-0*

C=1-C, H as old C. 5, 3 from A register

SCF                   --*0*-01
CPL                   --*1*-1-

5, 3 from A register.

NEG                   SZ5H3V1C

DAA                   SZ5*3P-*

See below (2.3) for more information.

LD A,R/LD A,I         SZ503*0-

P/V contains a copy of IFF2.

IN r,(C)              SZ503P0-

Also true for IN F,(C) / IN (C). 


2.2.5) Memory block instructions [2] [5]

LDI/LDIR/LDD/LDDR     --*0**0-  P/V set if BC not 0
                                5 is bit 1 of (transferred byte + A)
                                3 is bit 3 of (transferred byte + A)

So add A to the (last) transferred byte (from (HL)), and bit 1 of that
8 bit value is flag 5, and bit 3 is flag 3.

CPI/CPIR/CPD/CPDR     SZ*H**1-  P/V set if BC not 0
                                S,Z,H from (A - (HL) ) as in CP (HL)
                                3 is bit 3 of (A - (HL) - H)
                                5 is bit 1 of (A - (HL) - H)

CPI instructions are weird too. The test is simply like a CP (HL). Flag 3 and
5 are set like this: Take A, subtract the last (HL), and then decrease it
with 1 if the H flag was set (/after/ the CP). Bit 1 of this value is flag
5, bit 3 is flag 3.


2.2.6) I/O Block instructions [5] [6]

INI/INIR/IND/INDR     SZ5*3***  Flags affected as in DEC B
OUTI/OTIR/OUTD/OTDR   SZ5*3***  Flags affected as in DEC B

Another weird one. S,Z,5,3 are affected by the decrease of B, like in DEC B.
The N flag is a copy of bit 7 of the last value read from/written too the
I/O port. The C and H flag is set as follows: Take register C, add one to it
if the instruction increases HL otherwise decrease it by one. Now, add the
the value of the I/O port (read or written) to it, and the carry of this
last addition is copied to the C and H flag (so C and H flag are the same). 
Beats me, but tests show it to be true. 

Pedro Gimeno (pgimeno@geocities.com) has figured out how the P/V flag is
affected. The result depends on the B register, the lower 3 bits of the C
register and the lower 3 bits of the value from the I/O port. This next part 
is written by him. Whatever he says about INI/INIR is true for OUTI/OTIR,
and what he says about IND/INDR is true for OUTD/OTDR.

I use the notation C.2 to mean bit 2 of C. "inp" is the byte being
input.

First, look at bits 1 and 0 of both C and inp and look up this table to
obtain a temporary result:

C.1   C.0  inp.1 inp.0   Temp1
 0     0     0     0       0
 0     0     0     1       0
 0     0     1     0       1
 0     0     1     1       0
 0     1     0     0       0
 0     1     0     1       1
 0     1     1     0       0
 0     1     1     1       1
 1     0     0     0       1
 1     0     0     1       0
 1     0     1     0       1
 1     0     1     1       1
 1     1     0     0       0
 1     1     0     1       1
 1     1     1     0       1
 1     1     1     1       0

You'll need also an additional temporary result which depends on B (all
of its bits), according to the following pseudocode:

If B.3 = B.2 = B.1 = B.0 = 0 then [i.e. if B and 0Fh = 0 then]
  let Temp2 = Parity(B) xor (B.4 or (B.6 and not B.5))
else
  let Temp2 = Parity(B) xor (B.0 or (B.2 and not B.1))

where Parity(B) is defined as not (B.0 xor B.1 xor B.2 xor B.3 xor B.4
xor B.5 xor B.6 xor B.7), i.e. 1 if B has an even number of bits = 1,
and 0 otherwise (the usual parity function).

Note that I obtained the operation (B.0 or (B.2 and not B.1)) from the
next table using Karnaugh maps:

B.2 through B.0  000 001 010 011 100 101 110 111
Value             0   1   0   1   1   1   0   1

For completeness here's the full table of values of Temp2 according to
B:

    0123456789ABCDEF <- (low nibble)
00  0011010011001011
10  0100101100110100
20  1100101100110100
30  1011010011001011
40  0100101100110100
50  1011010011001011
60  0011010011001011
70  0100101100110100
80  1100101100110100
90  1011010011001011
A0  0011010011001011
B0  0100101100110100
C0  1011010011001011
D0  0100101100110100
E0  1100101100110100
F0  1011010011001011
^
(high nibble)

And finally, the value of the P/V flag is:

P/V = Temp1 xor Temp2 xor C.2 xor inp.2
IND / INDR:

The operations to obtain the P/V flag are the same as for INI/INIR but
the table used to lookup Temp1 is different:

C.1   C.0  inp.1 inp.0   Temp1
 0     0     0     0       0
 0     0     0     1       1
 0     0     1     0       0
 0     0     1     1       0
 0     1     0     0       1
 0     1     0     1       0
 0     1     1     0       0
 0     1     1     1       1
 1     0     0     0       0
 1     0     0     1       0
 1     0     1     0       1
 1     0     1     1       0
 1     1     0     0       0
 1     1     0     1       1
 1     1     1     0       0
 1     1     1     1       1


2.3) Undocumented operation [1][5]


2.3.1) DAA [4] [5]

This instruction is useful when you're using BCD values. After an addition
or subtraction, DAA makes the correction so the value is the correct BCD
value again.

The correction done is as in the following table [4]:

N | C | high   | H | low    | # added | C after
  |   | nibble |   | nibble | to A    | execution
--+---+--------+---+--------+---------+-----------
add, adc, inc operands:
0   0   0-9      0   0-9      00        0
    0   0-8      0   a-f      06        0
    0   0-9      1   0-3      06        0
    0   a-f      0   0-9      60        1
    0   9-f      0   a-f      66        1
    0   a-f      1   0-3      66        1
    1   0-2      0   0-9      60        1
    1   0-2      0   a-f      66        1
    1   0-3      1   0-3      66        1
-------------------------------------------------
sub, sbc, dec, neg operands:
1   0   0-9      0   0-9      00        0
    0   0-8      1   6-f      fa        0
    1   7-f      0   0-9      a0        1
    1   6-f      1   6-f      9a        1

This table is all I know about DAA operation. 

Emulator builders: this instruction is hard to emulate. The Intel 80x86
equivalents are more or less the same, but differ for some input values
(not in the table?). If you're not using assembly, the best way IMHO is
to put all possible output values (for A and F registers) in a table. The
output depends on the following inputs: A register and H,N,C flags. That's
11 bits in total, so the table will have size: 2^11*2 = 4096 bytes, which
isn't too bad.


2.3.2) I/O Instructions

The I/O instructions use the whole of the address bus, not just the lower
8 bits. So in fact, you can have 65536 I/O ports in a Z80 system (the Spectrum
uses this). IN r,(C), OUT (C),r and all the I/O block instructions put the
whole of BC on the address bus. IN A,(n) and OUT (n),A put A*256+n on the 
address bus. 


2.3.3) Block instructions

The repeated block instructions simply decrease the PC by two so the 
instruction is simply re-executed. So interrupts can occur during block 
instructions. So, LDIR is simply LDI + if BC is not 0, decrease PC by 2.


3) Interrupts and I register [4]
--------------------------------

For the interrupts, the following things are important: Interrupt Mode
(set with the IM instructions), the interrupt flip-flops (IFF1 and IFF2),
and the I register.

There are two types of interrupts, maskable and non-maskable. The maskable
type is ignored if IFF1 is reset. Non-maskable interrupts (NMI) will
always occur, and they have a higher priority, so if the two are requested 
at the same time the NMI will occur.


3.1) Non-maskable interrupts (NMI) [4]

When a NMI is accepted, IFF1 is reset. At the end of the routine, IFF1 must
be restored (so the running program is not affected). That's why IFF2 is
there; to keep a copy of IFF1.

An NMI is accepted when the NMI pin on the Z80 is made low. The Z80 responds 
to the /change/ of the line from +5 to 0. When this happens, a call is done 
to address 0066h and IFF1 is reset so the routine isn't bothered by maskable 
interrupts. The routine should end with an RETN (RETurn from Nmi) which is 
just a usual RET, but also copies IFF2 to IFF1, so the IFFs are the same as 
before the interrupt.

You can check whether interrupts were disabled or not during an NMI by using 
the LD A,I or LD A,R instruction. These instructions copy IFF2 to the P/V 
flag.


3.2) Maskable interrupts (INT) [4]

If the INT line is 0 volt and IFF1 is set, a maskable interrupt is accepted - 
whether or not the the last INT routine has finished. That's why you should 
never enable interrupts during such a routine, and make sure that the device 
that generated it has put the INT line up to +5 volt again before ending the 
routine.

When an INT is accepted, both IFFs are cleared, preventing another interrupt 
from occurring which would end up as an infinite loop. What happens next 
depends on the Interrupt Mode.

IM 0:
  The instruction on the bus is executed (usually an RST instruction, but
  it can be anything else -- even instructions larger than one byte). 
  The I register is ignored.

IM 1:
  An RST 38h is executed, no matter what value is put on the
  bus or what value the I register has.

IM 2:
  A call is made to the address read from memory. What address is
  read from is calculated as follows: (I register) * 256 + (value on bus). 
  Of course a word (two bytes) are read, comprising an address where the
  call is made to. In this way, you can have a vector table for interrupts.

At the end of a maskable interrupt, the interrupts should be enabled again. 
You can assume that was the state of the IFFs because otherwise the interrupt 
wasn't accepted. (snappy huh). So, an INT routine always ends with an EI and 
a RET (RETI according to the official documentation,
more about that later):

INT:	.
	.
	.
	EI
	RETI (or RET)

Note a fact about EI: a maskable interrupt isn't accepted directly after it,
so the next opportunity for an INT is after the RETI. This is very useful;
if the INT is still low, an INT is generated again. If this happens a lot and
the interrupt is generated before the RETI, the stack could overflow (since
the routine is called again and again). But this property of EI prevents this.

DI is not necessary at the start of the interrupt routine: the Z80 disables 
them when accepting the interrupt.

You can use RET in stead of RETI too, it depends on hardware setup. RETI
is only useful if you have something like a Z80 PIO to support daisy-chaining:
queueing interrupts. The PIO can detect that the routine has ended by the
opcode of RETI, and let another device generate an interrupt. That is why
I called all the undocumented EDxx RET instructions RETN: All of them 
operate like RETN, the only difference to RETI is its specific opcode. 
(Which the Z80 PIO recognises.)


3.3) Things affecting the IFFs [4]

All the IFF related things are:

		IFF1	IFF2
/CPU reset	0	0
DI		0	0
EI		1	1
Accept INT	0	0
Accept NMI	0	-
RETI/N		IFF2	-	All the EDxx RETI/N instructions
LD A,I/LD A,R	-	-	Copies IFF2 into P/V flag

Note the fact about RETI/N: all the EDxx RET instructions copy IFF2 into
IFF1, even RETI! The other one-byte RET commands (RET, RET NZ etc.)
don't do this.

Since every INT routine must end with this sequence:

	EI
	RETI (or RET, but RETI officially)

It does not matter that RETI copies IFF2 into IFF1; both are set anyways.

[5] There seems to be some dispute about whether or not when an NMI is 
accepted, IFF1 is copied into IFF2 before clearing IFF1. Some official docs 
even states this, but I've been experimenting with nested NMIs (if it were
correct, the IFF states would be lost after a nested NMI) and I've found
it to be wrong. Only IFF1 is reset, that's all.

If you're working with a Z80 system without NMIs (like the MSX), you can 
forget all about the two separate IFFs; since a NMI isn't ever generated, 
the two will always be the same. 


3.5) HALT instruction [4]

The HALT instruction halts the Z80; it starts executing NOPs, until a maskable 
or non-maskable interrupt is accepted. Only then does the Z80 increase the PC 
and continues with the next instruction. During the HALT state, the HALT line 
is set. The PC is increased before the interrupt routine is called.


3.6) Where can interrupts occur? [5]

During execution of instructions, interrupts won't be accepted. Only /between/ 
instructions. This is also true for prefixed instructions.

Directly after an EI or DI instruction, interrupts aren't accepted. They're
accepted again after the instruction after the EI (RET in this example). So for 
example, look at this MSX2 routine that reads a scanline from the keyboard:

	LD	C,A
	DI
	IN	A,(0AAh)
	AND 	0F0h
	ADD	A,C
	OUT	(0AAh),A
	EI
	IN	A,(0A9h)
	RET

You can assume that there never is an interrupt after the EI, before the
IN A,(0A9h) -- which would be a problem because the MSX interrupt routine
reads the keyboard too.

Using this feature of EI, it is possible to check whether it is true that
interrupts are never issued during instructions:

	DI
	<make sure INT is active>
	EI
	<insert instruction to test>

INT:
	<store PC where INT was issued>
	RET

And yes, for all instructions, including the prefixed ones, interrupts are
never issued during an instruction. Only after the tested instruction. 
Remember that block instructions simply re-execute themselves (by decreasing
the PC with 2) so an interrupt is accepted after each iteration.

Another predictable test is this: at the <insert instruction to test> insert
a large sequence of EI instructions. Of course, during execution of the EI
instructions, no interrupts are accepted. 

But now for the interesting stuff. EDED or CBCB are just instructions in
themselves, so interrupts are issued after them. But DD and FD are just
prefixes, which only slightly affects the next opcode. If you test a large
sequence of DDs or FDs, the same happens as with the EI instruction: no
interrupts are accepted during the execution of these sequences.

This makes sense, if you think of DD and FD as a prefix which set the
"use IX instead of HL" or "use IY instead of HL" flag. If an interrupt was
issued after DD or FD, this flag information would be lost, and:

	DD 21 00 00 	LD IX,0

could be interpreted as a simple LD HL,0, if the interrupt was after the last
DD. Which never happens, so the implementation is correct.

Because of this,

	DD DD 21 00 00

is also always executed as LD IX,0 and never as LD HL,0.

For the same reason, NMIs aren't accepted after a DD or FD too (I haven't
tested this but I can't imagine otherwise). The Z80 docs say that no 
interrupts are accepted after EI or DI, which also includes NMIs (also not
tested).


4) Timing and R register [1]
----------------------------

4.1) R register and memory refresh [1][4]

During every first machine cycle (beginning of an instruction or part
of it -- prefixes have their own M1 two), the memory refresh cycle is
issued. The whole of IR is put on the address bus, and the _RFSH is lowered.
It unclear whether the Z80 increases the R register before or after putting
IR on the bus. 

The R register is increased at every first machine cycle (M1). Bit 7 of
the register is never changed by this; only the lower 7 bits are included
in the addition. So bit 7 stays the same, but it can be changed using the
LD R,A instruction.

Instructions without a prefix increase R by one. Instructions with an ED, CB,
DD, FD prefix, increase R by two, and so do the DDCBxxxx and FDCBxxxx 
instructions (weird enough). Just a stray DD or FD increases the R by
one. LD A,R and LD R,A access the R register after it is increased (by 
the instruction itself). 

Remember that the block instructions simply decrease the PC with two, so
the instructions are re-executed. So LDIR increased R by BC times 2 (note that
in the case of BC = 0, R is increased by 10000h times 2, effectively 0).

Accepting an maskable or non-maskable interrupt increases the R by one.

After a hardware reset, or after power on, the R register is reset to 0.

That should cover all there is to say about the R register. It is often
used in programs for a random value, which is good but of course not
truly random.


4.2) Instruction timings [1][4]

Not much stuff here, as I'm no cycle expert. The opcode list does show
the timings of all instructions though:

	http://www.msxnet.org/tech/Z80/z80opcod.txt

Undocumented timings:

* Stray DD or FD: same as a NOP (increases R by one).

* EDxx (not one of the list above or block instruction): 
  Same as two NOPs. Increases R by 2.

* Accepting interrupts (all one M1 and thus increase R by one): (T states)

  IM 0: 13 (assuming the instruction is a RST)
  IM 1: 13
  IM 2: 19
  NMI : 11


5) Other Information
--------------------

5.1) Power on defaults [4]

After a reset (a hard reset of course) or power on, all registers are set
to 0, the IFFs are reset and the interrupt mode is 0. So, since the PC is
0, the Z80 starts executing code at address 0.


5.2) Errors in official documentation [5]

In different official (?) documentation, I've seen some errors. Some don't
have all of these mistakes, so your documentation may not be flawed but 
these are just things to look out for.

* The Flag affection summary table shows that LDI/LDIR/LDD/LDDR instructions 
  leave the S and Z in an undefined state. This is not correct; the S and Z
  flags are unaffected (like the same documentation says).

* Similary, the same table shows that CPI/CPIR/CPD/CPDR leave the S and H
  flags in an undefined state. Not true, they are affected as defined 
  elsewhere in the documentation.

* Also, the table says about INI/OUTD/etc "Z=0 if B <> 0 otherwise Z=0";
  of course the latter should be Z=1.

* The INI/INIR/IND/INDR/OUTI/OUTD/OTIR/OTDR instructions do affect the C
  flag (some official documentation says they leave it unaffected, 
  important!) and the N flag isn't always set but may also be reset (see 
  above for exact operation).

* When an NMI is accepted, the IFF1 isn't copied to IFF2. Only IFF1
  is reset.

* In the 8-bit Load Group, the last two bits of the second byte of
  the LD r,(IX + d) opcode should be 10 and not 01.

* In the 16-bit Arithmetic Group, bit 6 of the second byte of the
  ADD IX, pp opcode should be 0, not 1.

* IN x,(C) resets the H flag, it never sets it. Some documentation states
  it is set according to the result of the operation; bullocks, no
  arithmetic is done in this instruction.


5.3) References and other resources

Here are a few locations on the web, with information about the Z80. 

The references in this document are marked here two. They are in no particular
order, and maybe I made a mistake somewhere too.. So include the Standard
Disclaimer.

http://www.acorn.co.uk/~mrison/en/cpc/tech.html [3]
	Mark Rison Z80 page for !CPC.

ftp://ftp.ping.de/pub/misc/emulators/yaze-1.10.tar.gz [2]
	YAZE (Yet Another Z80 Emulator). This is a CPM emulator by Frank 
	Cringle. It emulates almost every undocumented flag, very good
	emulator. Also includes a very good instruction exerciser.

http://www.geocities.com/SiliconValley/Peaks/3938/z80_home.htm
	Z80 Family Official Support Page by Thomas Scherrer. Very good, a lot
	information there.

http://www.kendalls.demon.co.uk/cssfaq/tech_z80.html
	Spectrum FAQ technical information.

ftp://ftp.void.jump.org/pub/sinclair/emulators/pc/dos/z80-400.zip [1]
	Gerton Lunter's Spectrum emulator (Z80). In the package there is
	a file TECHINFO.DOC, which contains a lot of interesting 
	information.

http://users.aol.com/autismuk/emu.html
	A TRS80 (Z80 based) emulator in assembly.

http://www.zilog.com/ 
	Guess what, the makers of the little bastard. Not much information
	here (you can order technical books though).

http://www.msxnet.org/tech/ [5]
	My own (Sean Young) Z80 page. You can find this document there
	and some other stuff.

Mostek Z80 Programming Manual [4]
	A /very/ good reference book to the Z80.

Pedro Gimeno (pgimeno@geocities.com) [6]


