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