MiSTer FPGA Forum

MicroCoreLabs wrote:

The core is actually very faithful to the original machine, however, the CPU instructions have some small bugs. On the recommendation of a user (Rafa, from the Telegram development group that has the core in Spanish), he has observed the following bugs with the LandMark PCXT diagnostic software:

The same software has fewer bugs in the 86Box emulator, although common in the type of instructions:

The common part in both systems, although with different results, would be the following:

Although, as can be seen, there is better cycle accuracy in the core, close to the 4.77Mhz of the original.

The 3 CPU additional bugs of core are as follows:
I have done some research on one of them, corresponding to opcode 0x9F (LAHF), whose function is to store the state of the flags in AH. Reviewing the detail of the instruction:

https://c9x.me/x86/html/file_module_x86_id_148.html

We have that, the MCL86 module is not taking into account the fixed value of the reserved flags... bits, 1, 3 and 5.

kitune-san wrote:

Finally, the software also tests the timer, among other ICs:

In particular, the timer has random failures, if the test is repeated, sometimes it fails and sometimes it is fine. This behaviour also occurs in 86Box and in a real PCXT (Real Micro8088 PCXT at 4.77MHz), so I wouldn't read too much into it either, but I don't know if something can be improved.

Interesting tests.. Thanks for running them!

The first group which both the MCL86 and 86Box fail are MUL/DIV opcodes which have undefined flags so there is practically no way for us to emulate this behavior. The 0xF7, 0xEB is also an IMUL, so it is probably just random luck that 86Box got it correct.

The 0x9F is LAHF and the MCL86 does not copy a '1' for bit[1] which is easy to adjust in microcode.

And 0xD3, 0xE8 is SHR AX,cl which also has undefined AUX flag behavior so the MCL86 is correct here too.

I am guessing that the author probably checked all flags for all opcodes even if they are undefined. This is ok for checking to see if it is a real 8086, however it is probably too strenuous to be checking for non-Intel silicon. The manual does say also that a NEC V20 will fail...

That said, none of these differences should affect the operation of any application.

Quite often, the undocumented flags are used by mistake. For example, Ghosts'n'Goblins for the Speccy won't work if an undocumented flag is not properly emulated, due to a program bug. And some protection schemes depend on the behaviour of undocumented flags as well, in an attempt to fool those who attempt to debug them (and won't work if they aren't properly emulated). https://worldofspectrum.org/faq/referen ... documented

MicroCoreLabs wrote: ↑Mon Nov 28, 2022 6:38 pm I am guessing that the author probably checked all flags for all opcodes even if they are undefined. This is ok for checking to see if it is a real 8086, however it is probably too strenuous to be checking for non-Intel silicon. The manual does say also that a NEC V20 will fail...

That said, none of these differences should affect the operation of any application.

I also happen to have an NEC v20 , and in that case I can't even run the application: