Z80 F effects
M.G. Rison
A while ago I posted (to comp.os.cpm) a summary of my understanding of
the undocumented Z80 DD/FD (index) instructions. This was met with
deafening silence, but I've been assured that's because it was truly
perfect.
I've now been encouraged to post a summary of my understanding of
effects of all the instructions on the F register. This has holes in
it, which I'd be more than happy to see filled. I'd also very much like
to know whether the bits which I think I understand are in fact not
correct. My Zilog reference is a datasheet from 1982.
The 8 bits in the Z80's flag register F are, from b7 to b0:
S (sign)
Set if the result is negative (most significant bit set)
Z (zero)
Set if the result is zero
F5
Undefined
H (half carry)
Set if there is a carry/borrow between the low and high nybbles
F3
Undefined
PV (parity/overflow)
Set if the result has even parity (logical operations)
Set if signed overflow has occurred (arithmetic operations)
N (add/subtract)
Set if the operation is a subtraction
C (carry)
Set if there is a carry/borrow out
The table below shows the effect of all instructions on F.
? indicates the effect is not known
* 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,H,V,P,N and C indicate the effect is as described above
r refers to any 8-bit quantity appropriate for that instruction
s refers to any 16-bit quantity appropriate for that instruction.
Instruction Flags Notes
=========== ===== =====
ADD/ADC/SUB/SBC/CP r SZ?H?VNC CP is just SUB with the result thrown away
INC/DEC r SZ?H?VN-
ADD s --?*?-0C H from MSB
ADC/SBC s SZ?*?VNC H from MSB
INC/DEC s --?-?---
AND r SZ?1?P00
OR/XOR r SZ?0?P00
RLCA/RLA/RRCA/RRA --?0?-0C
RLC/RL/RRC/RR r SZ?0?P0C
SLA/SLL/SRA/SRL r SZ?0?P0C SLL is like SLA except b0 gets set
RRD/RLD SZ?0?P0- Flags set on result in A
BIT n,r *Z?1?*0- PV as Z, S set only if n=7 and b7 of r set
CCF --?*?-0C H as old C
SCF --?0?-01
CPL --?1?-1-
NEG SZ?H?V1C A=0-A (Zaks gets C wrong)
DAA SZ???P-? Aaaargh!
LD A,R/LD A,I SZ?0?*0- PV as IFF2 [yaze doesn't affect F?]
LDI/LDIR/LDD/LDIR --?0?*0- PV set if BC<>0 [Zilog summ says S,Z mod?]
CPI/CPIR/CPD/CPDR SZ?H?*1- PV set if BC<>0, other flags from last CP
IN r,(C) SZ?0?P0- [Zilog detail says OUT (C),r/(n),A affect F?]
INI/INIR/IND/INDR ?*?????? Z set if B=0, port is post-decremented
OUTI/OTIR/OUTD/OTDR ?*?????? Z set if B=0, port is pre-decremented
All others --?-?--- Except for POP AF and EX AF,AF', of course...
Mark
======================================================================
| ri...@hep.phy.cam.ac.uk | Esperanto - lingvo inter-nacia |
| ri...@vxcern.cern.ch | * Mi estas riisto * |
======================================================================
Brett K. Heath
> [Note followups.]
> A while ago I posted (to comp.os.cpm) a summary of my understanding of
> the undocumented Z80 DD/FD (index) instructions. This was met with
> deafening silence, but I've been assured that's because it was truly
> perfect.
[CHOP]
I missed that completely, and wish I hadn't. Would some kind soul email me
a copy of this summary?
Brett K. Heath
Bo Lindbergh
> [Note followups.]
Note: Followup-To field judged to be irrelevant and ignored. :-)
> DAA SZ???P-? Aaaargh!
The C flag is set to the right value to use in the ADC/SBC of the next
(more significant) pair of BCD digits.
The H flag is set from the addition/subtraction of the correction term.
The unused flags are set from the result along with the S flag.
/Bo Lindbergh
M.G. Rison
> In article <4gal9p$l...@lyra.csx.cam.ac.uk>, mg...@cus.cam.ac.uk (M.G. Rison) writes:
> > [Note followups.]
> Think I killed them...
Aaaargh! The whole point was to force the discussion into comp.os.cpm
(only), so that it didn't break up into lots of little non-communicating
discussions. If someone requests followups to a specific group, please
honour this request, except if there's a good reason not to do so!
This message is copied to comp.os.cpm and comp.sys.sinclair; followups
are requested to comp.os.cpm only.
> > The 8 bits in the Z80's flag register F are, from b7 to b0:
> > [...]
> > DAA SZ???P-? Aaaargh!
> I believe that C = old H; I don't know why but... (and I might be mistaken)
I don't think that's the case. I don't want to be rude, but guesses
are of little use here; please only contribute if you can do so fairly
authoritatively.
> > [...]
> > IN r,(C) SZ?0?P0- [Zilog detail says OUT (C),r/(n),A affect F?]
Just checking: is H indeed reset?
> > [...]
> > INI/INIR/IND/INDR ?*?????? Z set if B=0, port is post-decremented
> > OUTI/OTIR/OUTD/OTDR ?*?????? Z set if B=0, port is pre-decremented
Dave Baldwin has pointed out that N is always set by these instructions.
He's also said C is unaffected (and that's what all my documentation
says), but Bill Haygood seemed to have evidence to the contrary -- any
news? Frank Cringle has suggested the other flags (except for PV,
perhaps) are set as for DEC B -- any news?
[BTW, by `port is pre/post-decremented' I am talking about whether the
high part of the port address is the value of B before or after B
has been decremented. Dave Baldwin disagrees with my claim that
B is pre-decremented for OUT -- anybody like to give evidence in
support of one of the claims?]
> 1) I don't trust much documentation. Get a z80 and see what happens for any
> particular instruction.
That's what I tried to do whenever I had any doubts.
> 2) It is possible to find the two undefined flags - they are usually the same
> bits of the 'result' (high byte of a 16 bit result I believe), but some
> instructions implement this, others do not. One thing about this is that you
> should not rely upon such 'side-effects' if you are not sure which processor
> you're program will run on - I looked at a z80B in a 48K spectrum and another
> in a +128K spectrum.
Right, so all we need to firm up now is the `usually'...
> 3) the out (c), f instruction actually outputs a zero (as far as I can tell)
> and I am not sure what happens with the in f,(c) instruction. Both are missing
> in the usual op-code listing...
[This is an issue regarding undocumented Z80 ops, not the flags.]
The IN F,(C) instruction is sometimes documented; its effect is to do a
normal IN, setting the flags, but throwing away the value read in.
The OUT (C),F instruction indeed seems to effectively output zero.
M.G. Rison
Brett K. Heath <hcmt...@csun.edu> skribis:
Try http://arachnid.cs.cf.ac.uk/User/K.E.W.Thacker/Amstrad/CPC_Guide
/Hardware_Programming/Chips/z80/dd_prefix.html .
There's also http://arachnid.cs.cf.ac.uk/User/K.E.W.Thacker/Amstrad
/CPC_Guide/Hardware_Programming/Chips/z80/flags_info.html .
I'll make improved versions of both these documents available as soon
as I get back to physical proximity with the computer which holds the
originals (no, it isn't connected to the net). In particular,
the first document has been extended to cover all undocumented Z80
operations.
Comments and corrections are extremely welcome.
Simon Cooke
: > 3) the out (c), f instruction actually outputs a zero (as far as I can tell)
: > and I am not sure what happens with the in f,(c) instruction. Both are missing
: > in the usual op-code listing...
: [This is an issue regarding undocumented Z80 ops, not the flags.]
: The IN F,(C) instruction is sometimes documented; its effect is to do a
: normal IN, setting the flags, but throwing away the value read in.
: The OUT (C),F instruction indeed seems to effectively output zero.
I can help out here I think... you see, it's not actually an IN or OUT
concerning the flags; that's just a twee way of saying "only the flags
are affected by these instructions"... What you've actually got is IN
(HL),(C) and OUT (C),(HL). Now, because when an IO occurs, the bus is
taken up for IO addressing, the logic to read or write to the (HL)
address clashes with that of the IO, and in this case, the IO logic wins
out. So in the case IN (HL),(C) the flags are affected as if you'd done a
normal IN A,(C) or whatever, but the value is thrown away. For OUT
(C),(HL) the bus clash causes whatever the internal floating level of the
Z80 is to be output on the bus... which means that on an NMOS Z80 you get
OUT (C),0 and on a CMOS Z80 you get OUT (C),255 *
On the Z380, the OUT instruction is altered to become OUT (C),n
(ED,71,nn) which will output a specific number to the port in BC. So if
you want stuff to be valid across the board, as always, don't use
undocumented codes... though those that work with IX/IY lower or upper
halves will work quite happily on the Z180,Z280 ** and Z380.
* Yep, we've tried it. I'm working on an accelerator system for a SAM
Coupe at the moment hoping to get it boosted from an effective (due to
contention) 3.9Mhz to 20MHz using a combination of shadow memory and
clever logic... we discovered that the OUT instruction would produce a
white border on the new CMOS Z80, and a black border on the old NMOS one
- which led us to our conclusions (white being all bits set in the
colour look-up table, black being all bits reset)
** not sure about the Z280, but it /should/ be compatible with the
others, so I think it'll hold.
Si Cooke
--
+- Email:Simon...@umist.ac.uk ---- Fidonet: 2:250/124.2 (Simon Cooke) -+
| Soon to be moving! New address & telephone number will appear here asap |
| Pager number: (In case of emergency) 01426 208084 ... email's best tho' |
+- WWW: http://jumper.mcc.ac.uk/~simonc ----------------------------------+
Ian Collier
>En la artikolo <1996Feb20.142216.5635@lsl>, <ti...@lsl.co.uk> skribis:
>Aaaargh! The whole point was to force the discussion into comp.os.cpm
>(only), so that it didn't break up into lots of little non-communicating
>discussions.
But he probably doesn't read comp.os.cpm. I certainly don't. Forcing
replies into that group is therefore depriving us of the rest of this
discussion. It's relevant to comp.sys.sinclair, therefore I'm keeping
the crossposting.
>> > INI/INIR/IND/INDR ?*?????? Z set if B=0, port is post-decremented
>> > OUTI/OTIR/OUTD/OTDR ?*?????? Z set if B=0, port is pre-decremented
>
>Dave Baldwin has pointed out that N is always set by these instructions.
>He's also said C is unaffected (and that's what all my documentation
>says), but Bill Haygood seemed to have evidence to the contrary -- any
>news? Frank Cringle has suggested the other flags (except for PV,
>perhaps) are set as for DEC B -- any news?
When I wrote xz80 I tested lots of instructions on a real +3 to try and
determine the flags affected. All instructions in xz80 give accurate
results to the best of my ability, including the undocumented flags. I
don't guarantee that they are right, but if you want to confirm something
then that's a good place to look. However, note that the flag results of
the block OUT instructions completely confounded me so I instead did what
the doc said.
For block IN instructions I have that flags are set to: b*b0b?10 where *
is the above, ? is a weird answer and b is the corresponding bit in the
final result of the B register. I hope that doesn't mean I forgot about
the H and C flags...
>[BTW, by `port is pre/post-decremented' I am talking about whether the
>high part of the port address is the value of B before or after B
>has been decremented. Dave Baldwin disagrees with my claim that
>B is pre-decremented for OUT -- anybody like to give evidence in
>support of one of the claims?]
As Allan Skillman will tell you :-) this is one bug in xz80. You are
correct to say that the decrement of B happens before an OUT but after
an IN.
Ian Collier - i...@comlab.ox.ac.uk - WWW Home Page:
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html
PEDRO BASTOS FONSECA
: A while ago I posted (to comp.os.cpm) a summary of my understanding of
: the undocumented Z80 DD/FD (index) instructions. This was met with
: deafening silence, but I've been assured that's because it was truly
: perfect.
Can you please email that undocumented opcode reference to me ?
Thanx.
CU@IRC (ZyBex)
Pedro Fonseca
K E W Thacker
Kev
Unofficial Amstrad WWW Resource:
http://www.cs.cf.ac.uk/User/K.E.W.Thacker/Amstrad/index.html
Author of A-CPC (Amstrad emulator for Amiga):
ftp: Aminet: /pub/misc/emu/acpc_dem.lha
--