bits 5 and 3 of F register on LDI/LDIR

[Fran123]

Hello 

I noticed the bits 5 and 3 of register F changes on LDI and LDIR instructions, but I couldn't find a pattern of behaviour.
The only I was read about  that bits is  "The values of bits 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."  

Does anybody know how they behave?

Thank you

[McArti0]

https://www.zilog.com/docs/z80/um0080.pdf

page 130 manual (144 pdf)

LDI

Condition Bits Affected
S is not affected.
Z is not affected.
H is reset.
P/V is set if BC – 1 ≠ 0; otherwise, it is reset.
N is reset.
C is not affected.

Table 21. Flag Register Bit Positions
Bit      7 6 5 4 3  2  1 0
Position S Z X H X P/V N C

X Not Used

[Fran123]

I ask about bits 3 and 5

[McArti0]

im testing now 

[McArti0]

Copilot from Microsoft Edge say: 

The Flag Register (also known as the F register) in the Z80 processor is an 8-bit register that stores information about the results of the last operation performed. Each bit in the flag register represents a specific flag. Here is a description of each bit:

• Bit 7 (S - Sign Flag): Set to 1 when the result of an operation is negative.
• Bit 6 (Z - Zero Flag): Set to 1 when the result of an operation is zero.
• Bit 5 (5 - Flag 5): A replica of the fifth bit of the accumulator (or result).
• Bit 4 (H - Half Carry Flag): Set to 1 when there is a half carry (or borrow) between bits 3 and 4 during addition or subtraction operations.
• Bit 3 (3 - Flag 3): A replica of the third bit of the accumulator (or result).
• Bit 2 (P/V - Parity/Overflow Flag): Set to 1 when the result of an operation has even parity (for logical operations) or when there is an overflow (for arithmetic operations).
• Bit 1 (N - Add/Subtract Flag): Set to 1 when the last operation was subtraction.
• Bit 0 (C - Carry Flag): Set to 1 when there is a carry (or borrow) from the most significant bit during addition or subtraction operations.

[MoteroV4]

Code Select Expand

bit   7  6  5  4  3  2  1  0
flag SF ZF YF HF XF PF NF CF

Bits 5 (YF) and 3 (XF) correspond to undocumented flags.

YF flag: A copy of bit 5 of the result.
XF flag: A copy of bit 3 of the result.

http://www.myquest.nl/z80undocumented/

It seems that in practice, on old NMOS Z80, they should follow this behavior pattern. But it is recommended not to base our programs on undocumented features because the current replacement 84C00 CMOS Z80 probably does not meet them.

[Prodatron]

Is there any reason why you should know about these undocumented bits in the F-register beside to develop a 100% correct Z80 emulator?
I never understood why this was necessary to know. Does it have any advantages for making code better/faster/shorter? Does anyone have an example for this? Or is this just for fun (which includes detecting, if a Z80 emu is cool or not).

[andycadley]

Is there any reason why you should know about these undocumented bits in the F-register beside to develop a 100% correct Z80 emulator?
I never understood why this was necessary to know. Does it have any advantages for making code better/faster/shorter? Does anyone have an example for this? Or is this just for fun (which includes detecting, if a Z80 emu is cool or not).

On the Spectrum, at least, the werewolf goes in the wrong direction if you don't emulate them correctly. Apparently a programmer accidentally took advantage of them.

[andycadley]

Is there any reason why you should know about these undocumented bits in the F-register beside to develop a 100% correct Z80 emulator?
I never understood why this was necessary to know. Does it have any advantages for making code better/faster/shorter? Does anyone have an example for this? Or is this just for fun (which includes detecting, if a Z80 emu is cool or not).

On the Spectrum, at least, the werewolf goes in the wrong direction if you don't emulate them correctly. Apparently a programmer accidentally took advantage of them.

Ok, so it's the Rhino in Sabre Wulf, as well as issues with Ghost and Goblins and speed lock games, but the principle is the same: emulating this stuff actually makes a difference some times.

http://z80.info/z80info.htm

[Fran123]

Is there any reason why you should know about these undocumented bits in the F-register beside to develop a 100% correct Z80 emulator?
I never understood why this was necessary to know. Does it have any advantages for making code better/faster/shorter? Does anyone have an example for this? Or is this just for fun (which includes detecting, if a Z80 emu is cool or not).

I trying to emulate the z80, I'm not planning to make another RVM either

[roudoudou]

iterating or not with LDI or LDIR, you keep S, Z and C
then you set P when BC will be zeroed
about the non documented behaviour, it's something like this

(((databusValue+A) & 2)<<4) | ((databusValue+A) & FLAG_3_BIT);

[GUNHED]

After the instruction BIT n,(HL) execution, bits 3 and 5 of the flag register become containing values that are not documented in the official documentation at all.
Actually these bits are copied from the bits 11 and 13 of the internal register pair of Z80 CPU, which is used for 16-bit operations, and in most cases to handle addresses.

[m_dr_m]

Code Select Expand

transfer_notes
; After ldi/ldd/ldir/lddr:
  ; P/V reset if BC reached 0, set otherwise.
  ; Let n := A + (last) copied byte.
     ;  - 5 is a copy of n.1
     ;  - 3 is a copy of n.3 
From https://64nops.wordpress.com/2021/01/13/perfectly-accurate-z80-flags-and-cpc-timing/. Edit: oh! So, what Roudoudou said.

There is also Z80TEST.O which checks a lot of those behaviors.

[m_dr_m]

@Prodatron  Some smart coders whose nicknames start by 'T' have used the OUTI undocumented flag behaviour to great effect!
And in that case it's pretty useful to know that Carry is affected, because the original doc is wrong.

Regarding LDI: fun indeed, protection and maybe one optimisation use case in 20 years.

[Benedikt]

Prodatron  Some smart coders whose nicknames start by 'T' have used the OUTI undocumented flag behaviour to great effect!
And in that case it's pretty useful to know that Carry is affected, because the original doc is wrong.

Explain that to the UA880D currently driving my CPC.

By the way: Has this document already been mentioned?