I don't know if this applies to 8-bit or 16-bit or both, but I see the same info regarding detecting CPUs here:

http://stanislavs.org/helppc/cpu.html

Edit: it appears the Z flag could reflect some bit of internal storage used in intermediate stages of calculation.
It is possible that after the specific multiply in the detection code the Z flag is always set to 0 on real 808x and always untouched on V20.

I've added the zero flag 'bug' in my latest 808x CPU core commit.

On x86 the flags are defined, and based on characteristics of the result. Z is set if the result is zero.

Strangely on all manuals I can find, they tell me that MUL only affects the carry and sign flags. All other flags are 'undefined'? What's up with those so-called 'undefined' flags? ZF doesn't seem to be entirely undefined (it seems to be half-working? Only clearing and not setting?)

To complicate matters more I think I've seen PCEm only updating the Zflag based on the lower 16bit register (AX). So for 16bit multiply where the result would be in DX:AX it only checks the AX to set the flag. I think fake8086 does that too. That expands to 32bit multiply where they only look at EAX.

Even on Pentium 4, SF, ZF, AF and PF are undefined after MUL/IMUL.
It's just undefined, meaning, it could be set, or unset, so you can't determine anything from it.
Because it is undefined, it is just as correct to always clear it, always set it, always preserve its value, set it randomly or actually set it correctly based on result but nobody would use the result.
It could depend on source values, or destination values.
And as you see, different CPUs work differently.

No, that's not true at all. They are very well defined, I'm just not allowed to tell you exactly how, but vladstamate is correct when he sees that only the lower half of the result is contributing to the effect.

So the bits are very well defined, but hidden from most programmers? Why would Intel hide information that a program might use during execution? Especially since it might affect execution flow (like this BIOS using it to detect 8088 processors vs V20 processors)? Like this actual 'accurate' emulators can't be made when information when such a basic result is hidden? Software depending on it might actually crash on any emulator actually following the processor specs itself, instead of observed information? Or it might assume something according to docs and emulators, but crash when ran on an actual processor? Is this why they actually documented as 'undefined'?

They are documented as "undefined" in order for the behaviours to be removed in the future, primarily to increase performance. The most interesting bits from Intel's point of view are the ones that are truly documented.
That's as much as I can say about it.

There's one thing I wonder now: Why do you (peterferrie) know about those flags(since you say that's about as much as you can(are allowed) to say about it)? Since it's officially undocumented and unusable on newer processors, why would you need to know about it (if it can't be used in normal software, it's practically useless to know since it can't be used on a modern CPU)? No software can actually use it if it's inconsistent with different CPUs, so it's useless in that aspect? Except for viruses etc.(saw some information about your job at antivirus companies>)?

I was working on a research project over a decade ago (intended to be a conference talk that wasn't accepted), which led to questions which required a pact with the devil (NDA) for the answers.

peterferrie wrote:

I was working on a research project over a decade ago (intended to be a conference talk that wasn't accepted), which led to questions which required a pact with the devil (NDA) for the answers.

Peter Ferrie, one of my favorite Internet people 😁