Some 8088 instruction bugs

[spark2k06]

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:

XTSERV_CPU_PCXT.png (108.83 KiB) Viewed 1552 times

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

XTSERV_CPU_86Box.png (5.59 KiB) Viewed 1552 times

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

MiSTer vs 86Box.png (44.8 KiB) Viewed 1552 times

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:

Code: Select all

CPU failed test:  6 errors
Instruction sequence was:
 F7
 EB
Register flags contains 0000H but should contain 0044H
Register value before instruction was 0801H
Test number 49
CPU failed test:  7 errors
Instruction sequence was:
 9F
Register ah contains 44H but should contain 46H
Register value before instruction was 02H
Test number 50
CPU failed test:  8 errors
Instruction sequence was:
 D3
 E8
Register flags contains 0410H but should contain 0400H
Register value before instruction was 0410H
Test number 149

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.

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

XTSERV_SYSTEM_PCXT.png (110.57 KiB) Viewed 1552 times

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.

[MicroCoreLabs]

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.

[pgimeno]

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

[spark2k06]

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:

NEC_V20.png (184.53 KiB) Viewed 1143 times