Path: vanilla!asbach!noris.net!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-ulm.de!news.belwue.de!fu-berlin.de!cs.tu-berlin.de!informatik.uni-bremen.de!nordwest.pop.de!uniol!uni-erlangen.de!uni-regensburg.de!lrz-muenchen.de!informatik.tu-muenchen.de!Germany.EU.net!howland.reston.ans.net!swrinde!tank.news.pipex.net!pipex!dish.news.pipex.net!pipex!news.lsl.co.uk!lsl!timbe
From: timbe@lsl.co.uk
Newsgroups: comp.sys.sinclair
Subject: Re: Z80 F effects
Message-ID: <1996Feb20.142216.5635@lsl>
Date: 20 Feb 96 14:22:16 +0000
References: <4gal9p$lel@lyra.csx.cam.ac.uk>
Followup-To: comp.os.cpm
Organization: Laser-Scan Ltd., Cambridge, UK
Lines: 96

In article <4gal9p$lel@lyra.csx.cam.ac.uk>, mgr11@cus.cam.ac.uk (M.G. Rison) writes:
> [Note followups.]

Think I killed them...


> 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!

I believe that C = old H; I don't know why but... (and I might be mistaken)

> 
> 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..

1) I don't trust much documentation. Get a z80 and see what happens for any
particular instruction.

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.

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...

I am sure others will have lots to say on such subjects so I'll sign off.

Tim 



----

Xref: vanilla comp.os.cpm:3 comp.sys.sinclair:8622 comp.sys.amstrad.8bit:5
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!news.mathworks.com!zombie.ncsc.mil!nntp.coast.net!news00.sunet.se!sunic!news99.sunet.se!news.kth.se!xbyse.nada.kth.se!d88-bli
From: d88-bli@xbyse.nada.kth.se (Bo Lindbergh)
Newsgroups: comp.os.cpm,comp.sys.sinclair,comp.sys.amstrad.8bit
Subject: Re: Z80 F effects
Date: 21 Feb 1996 10:51:02 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 14
Message-ID: <4getem$4ef@news.kth.se>
References: <4gal9p$lel@lyra.csx.cam.ac.uk>
NNTP-Posting-Host: xbyse.nada.kth.se
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

In article <4gal9p$lel@lyra.csx.cam.ac.uk> rison@hep.phy.cam.ac.uk writes:
> [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


----

Xref: vanilla comp.os.cpm:4 comp.sys.sinclair:8634
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!peer-news.britain.eu.net!uknet!lyra.csx.cam.ac.uk!mgr11
From: mgr11@cus.cam.ac.uk (M.G. Rison)
Newsgroups: comp.os.cpm,comp.sys.sinclair
Subject: Re: Z80 F effects
Followup-To: comp.os.cpm
Date: 21 Feb 1996 12:47:49 GMT
Organization: University of Cambridge, England
Lines: 75
Message-ID: <4gf49l$nrn@lyra.csx.cam.ac.uk>
References: <4gal9p$lel@lyra.csx.cam.ac.uk> <1996Feb20.142216.5635@lsl>
Reply-To: rison@hep.phy.cam.ac.uk
NNTP-Posting-Host: ursa.cus.cam.ac.uk

En la artikolo <1996Feb20.142216.5635@lsl>,  <timbe@lsl.co.uk> skribis:

> In article <4gal9p$lel@lyra.csx.cam.ac.uk>, mgr11@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.

Mark

======================================================================
|   rison@hep.phy.cam.ac.uk       |  Esperanto - lingvo inter-nacia  |
|   rison@vxcern.cern.ch          |       * Mi estas riisto *        |
======================================================================


----

Xref: vanilla comp.os.cpm:6 comp.sys.sinclair:8843
Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!peer-news.britain.eu.net!uknet!bhamcs!news.ox.ac.uk!news
From: imc@ecs.ox.ac.uk (Ian Collier)
Newsgroups: comp.os.cpm,comp.sys.sinclair
Subject: Re: Z80 F effects
Date: 23 Feb 1996 19:01:26 GMT
Organization: Oxford University Computing Laboratory
Lines: 47
Message-ID: <7937.imc@comlab.ox.ac.uk>
References: <4gal9p$lel@lyra.csx.cam.ac.uk> <1996Feb20.142216.5635@lsl> <4gf49l$nrn@lyra.csx.cam.ac.uk>
NNTP-Posting-Host: booth3.ecs.ox.ac.uk
X-Local-Date: Friday, 23th February 1996 at 7:01pm GMT

In article <4gf49l$nrn@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote:
>En la artikolo <1996Feb20.142216.5635@lsl>,  <timbe@lsl.co.uk> skribis:
>> 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.

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 - imc@comlab.ox.ac.uk - WWW Home Page:
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html