I do notice some strange behaviour executing EMM386.EXE on a 8086 processor. For some reason, instead of detecting it as being a 8086 and not running the 80836+ code, it doesn't even begin to detect it's trying to do something illegal on a 8086, it just eventually jumps into bogus space(214F:00000250) using a RETF, right after executing a pop CS, which shouldn't be in normal production code?

Excerpt from the log(where it's going wrong):

10311:00000fbf 06 push es
20311:00000fc0 FC cld
30311:00000fc1 2E C5 1E A8 0F lds bx,word cs:[0fa8]
40311:00000fc6 8A 47 02 mov al,byte ds:[bx+02]
50311:00000fc9 3C 0D cmp al,0d
60311:00000fcb 73 1F jnc 00000fec
70311:00000fcd 98 cbw
80311:00000fce D1 E0 shl ax,1
90311:00000fd0 BE 8E 0F mov si,0f8e
100311:00000fd3 03 F0 add si,ax
110311:00000fd5 2E FF 14 call word cs:[si]
120311:00000ff7 2E 80 3E AC 0F 00 cmp byte cs:[0fac],00
130311:00000ffd 0F pop cs
140fd8:00000ffe 66 81 jb 00000f81
150fd8:00000f81 00 02 add byte ss:[bp+si],al
160fd8:00000f83 00 00 add byte ds:[bx+si],al
170fd8:00000f85 0F pop cs
189087:00000f86 C8 01 2E retf 2e01
19214f:00000250 00 00 add byte ds:[bx+si],al
20214f:00000252 00 00 add byte ds:[bx+si],al
21214f:00000254 00 00 add byte ds:[bx+si],al
22214f:00000256 00 00 add byte ds:[bx+si],al
23214f:00000258 00 00 add byte ds:[bx+si],al
24214f:0000025a 00 00 add byte ds:[bx+si],al
25214f:0000025c 00 00 add byte ds:[bx+si],al
26214f:0000025e 00 00 add byte ds:[bx+si],al
27...

Oddly enough, fake86 doesn't crash on it(as far as I've read and seen on video and screen captures), instead just producing an error message and continuing on to the autoexec.bat. UniPCemu hangs up completely(the CPU itself to be exact, since it's running 0000h instructions forever).

Hmmm.... Something odd happens with the UART from the CPU's perspective: programs like miniterm(from the Arachne web browser) seem to read the UART data port when it's cleared regularly(thus reading 0x00 bytes that are inserted into it's output on the screen showing the init string etc.).

Eventually I manage to get it into the UniPCemu server(a server build that allows a simple login and then provides serial internet using the TCP/IP protocol using WinPCap(see older thread)). The server runs fine(Dosbox handles it without any problems on Windows 95 and Arachne under MS-DOS). But UniPCemu, after logging in, when halfway through receiving the IP address(after all is confirmed by the server), it simply stops receiving the data(what remains is the final half of the IP address, line break, CONNECTED text and another line break, after which the server starts sending/receiving SLIP TCP/IP packets, which is somehow discarded by the miniterm application).

So it runs partially, but eventually craps out, becoming unstable on the emulated CPU(it's only communicating using 8-bit I/O to the UART). The UART does it's job correctly, but the CPU itself, together with the miniterm application seems to receive data but parse it incorrectly(also receiving data when the buffer is actually empty!!! ). Maybe a TEST instruction going wrong somehow(which aren't tested using any testsuite yet)?