-
Notifications
You must be signed in to change notification settings - Fork 3
Open
Description
Some of the flags behavior tested by Z80_XCF_Flavor is incorrect, incomplete, or redundant. It is quite possible that the reported results are bogus.
More specifically:
- The behavior as it documented for NEC NMOS and ST CMOS seems to be incorrect. I get a different behavior:
- NEC NMOS - very similar to Zilog, although, in certain conditions that are not thoroughly tested by your utility, it produces a non-deterministic result when setting XF in the case where A = 0 and XF = 1 prior to executing SCF/CCF. It is possible that other bits, static charges, silicon manufacturing process, the phase of the moon, etc. affect the result in this case
- ST CMOS - sets YF = 0 and XF = 1 in Q0_F0_A1 test case. As a matter of the fact, most CMOS CPUs do that, with only exception being NEC CMOS CPUs, that have some randomness in setting the XF here
- It doesn't make sense to include tests with the same deterministic results, that are the same on all CPUs. That is all tests where SCF or CCF instruction is executed after executing an ALU instruction
- Q0_F0_A0 - always sets YF = 0 and XF = 0
- Q1_F1_A0 - always sets YF = 0 and XF = 0
- Q0_F1_A1 - always sets YF = 1 and XF = 1 - although in this case SCF/CCF follow a NOP instruction, the fact that all of the relevant bits - FLAGS.5, FLAGS.3, A.5, and A.3 are set to 1 always seem to result in YF = 1 and XF = 1
- Q1_F1_A1 - always sets YF = 1 and XF = 1
- This leaves only two interesting test cases Q0_F1_A0 and Q0_F0_A1.
- These tests actually seem to ignore the "Q" part of the equation, and the final result is CPU dependent
- Moreover, not all CPUs produce a reliable result in this (or similar) cases, where an SCF or CCF instruction follows an instruction that doesn't set FLAGS.
I tried to document my findings here. These findings are based on my testing of about 20 real CPUs of different types
Metadata
Metadata
Assignees
Labels
No labels