Is there any software that can be used(easily) for determining bugs in x86 protected mode emulation? E.g. missing or too many faults etc, paging emulation, general protection fault tests, stack fault tests, not present fault tests etc.?
EMM386 works without noticable problems, as do Megarace and Microsoft Flight Simulator 4(version 5.1 runs, but doesn't display the upper part(the part containing the output of the view mode. It just displays gray color?).
Hottobar's test386.asm testsuite already checks out 100%.
Linux won't boot, so xoreaxeaxeax can't be run as well.
Well, CheckIt! and NSSI can test 16/32-Bit protected mode..
Though perhaps not as thoroughly as you may need, since these are general purpose diagnostic programs.
As a stress test, Linux/Minix or OS/2 aren't bad either, I think. Anyway, these depths of x86 aren't my league. I'm just an user.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
Running the MS-DOS boot.com on the minix.mnx image results(tutorial from https://virtuallyfun.com/wordpress/2009/10/09 … dos-minix-2-04/) in the following(running from MS-DOS 5.0 in UniPCemu instead of Dosbox):
1. I'm greeted with a message telling me to choose something. I press enter.
2. It starts the kernel, then proceeds to mount four partitions?
3. It then reboots(triple fault?) after seeing a flash on the screen about some little text with a turning thing again(on the third row I believe):
First steps of the booting process:
Last edited by superfury on 2018-05-16, 12:24. Edited 1 time in total.
Looking at the CPU state itself, it seems to triple fault. The previous instruction was running at CS base address E400. So it's somewhere in the kernel?
The base of CS is still E400, with a 4GB limit. All other segments have a base of 1A400 with a limit of 4GB. CPL is zero, so it's still in the kernel.
It seems to have encountered an #UD exception(for executing a FFFFh instruction), at logical address 05c70009h(the value of EIP when the instruction starts)? Paging is disabled(so it's trying to execute non-existant physical memory). Anyone knows anything about this? Previous opcode was C3h(A RET instruction).
Edit: OK, it's already running in protected mode during the loading stage. So somewhere after that, after loading init, it ends up at an unknown 0xFFFF opcode?
Edit: Here's a common emulator log of the kernel loading (starting somewhere within the kernel image loading) and crashing(look for #UD in the log):
Edit: Another code bug revealed with the POP ES instruction: it wasn't using the operand size to perform the 16-bit POP. So it was always increasing/decreasing (E)SP with 2 instead of the proper 4.
Although some command cannot be found within it's filesystem?
Edit: Yay! A prompt from Minix is now showing up(after entering root as username and waiting for a while!) 😁
#
Edit: Prompt seems to be slow, but working! 😁
Edit: Compiling itself seems to fail due to not being able to write to the /tmp directory or a subdirectory within it(some compiler code about write error writing some temporary file).
"part" seems to run fine.
Running "shutdown" properly returns to the loader. Then running set gives the correct information. Finally running exit returns to the MS-DOS prompt:D And of course the MS-DOS prompt is running fine.
I'm just thinking: since minix (mostly) runs without problems(except some strange various commands(like rm(which exists when running from the command line within Minix)) not being found when starting the daemons and services on bootup of the Minix OS(rm,sysenv,sleep,elvprsv,cleantmp,mkdir to be exact, see the above screen capture)), would it be somehow possible to run xoreaxeaxeax from within it?
Hottobar's test386.asm testsuite already checks out 100%.
superfury wrote:
Edit: Another code bug revealed with the POP ES instruction: it wasn't using the operand size to perform the 16-bit POP. So it was always increasing/decreasing (E)SP with 2 instead of the proper 4.
I know test386.asm does not test all the protected mode operations (my emu doesn't work and still it passes the test), but something basic like this should be tested and detected.
Thanks for the heads up, I'll add a issue on the tracker.
What other bugs have you fixed that can be easily tested for?
You could also try to run some demanding protected mode DOS game, like Pinball Illusions.
Look at what that game throws at me when I try to run it with my emu: https://github.com/barotto/IBMulator/issues/32
Debugger log without registers and memory transactions.
File license
Fair use/fair dealing exception
It even looks like it's throwing multiple stack faults after each other(fault handling throwing stack fault?)
Edit: Looking further up the log, there's a #GP fault(#GP(0)) which eventually throws a stack fault. Said #GP fault is a address-size overridden XLAT using the CS segment(instruction bytes 2E 67 D7)?
So it's executing a XLAT CS:[EBX+AL], where EBX=0x2AC7, AL=0x69. So it's reading a byte at CS:2B30?
Looking at the interrupt cause(internal emulator flag for verifying the kind of fault that's the cause of the exception when accessing memory parameters), it says the cause is cause 3, which is a system segment access rights breach(Code, execute-only(w/(w/o)conforming) being read by the instruction as data. CS has access rights 0x9B, which means code, nonconforming, executable and readable, not accessed and valid.
So there's definitely a problem with my emulator's protection handling there. It shouldn't do that on reads, since it's executable and readable?
Edit: It seems the protection module itself works fine. It's the XLAT instructions(both 16-bit and 32-bit versions) that were faulty: it was checking memory against a write(for the memory operand) instead of a proper read.
Edit: Now I see it continuing until loading offset 0x48B4E(Which according to the screen is the value of EDI)? I see it's faulting on a MOV instruction. Odd...
Edit: It seems to be using FS:EDI to address the MOV to write. It's an 8-bit MOV. The instruction that's decoded is 0x64 67 88 07. According to onlinedisassembler.com, it's an MOV BYTE PTR FS:[EDI],AL instruction. The cause of the fault is a limit violation(cause #6). The FS descriptor contains 0004933b74a08b4b(little endian format of the 64-bit descriptor that's loaded). So the limit is 0x48B4B. The EDI registers contains 0x48b4e, so a clear limit violation. Now the question: why is EDI 3 higher than the limit? Some substraction going wrong? Or too much added somewhere?
It's the XLAT instructions(both 16-bit and 32-bit versions) that were faulty: it was checking memory against a write(for the memory operand) instead of a proper read.
Adding this as well to the test386.asm issue tracker.
What does the last UniPCemu bug(XLAT checking for writes instead of reads) have to do with test386.asm? Checking for PUSH/POP *S correctly modifying the stack would be correct to test there, but the bug within UniPCemu's XLAT checking against writes instead of reads doesn't have a specific bug on that instruction on a real CPU, unless you want to test read/write faults on EVERY single opcode?
Edit: P.S. the fault I'm dealing with currently seems to either take place BEFORE your faulting problem, or your piece of code(indicated by the image in your issue tracker) doesn't get triggered in UniPCemu.
I can tell you it displays some information(base and extended memory detected(~400K and 3M)), executes three drive reads with large delays in between, after the third hard disk access, another delay, after which the invalid EDI register memory operand crashes the app into it's fault handler.
What do you see happening in your case? (In common log format, I end up with a huge 14GB text file which takes about 3 hours basically hanging my PC with only 8GB physical RAM(Pagefile about 40GB large, Windows 10 swapping like crazy to become pretty much unresponsive until finished(+poweron every 30 minutes due to power saving sleep mode timer)).
unless you want to test read/write faults on EVERY single opcode?
No that would be unfeasable. At this point it's more like a reminder to add a test for XLAT, which is missing. But you're right it won't probably detect your particular bug.
The goal is to test as much as possible for the correct execution of the various opcodes, so that you can narrow your search. Right now many instructions are not tested at all.
superfury wrote:
What do you see happening in your case?
It happens well into the introduction, just before this scene:
Doesn't reach there in my case. at the 14 second mark, UniPCemu #GP faults because of the invalid [EDI] during a MOV. So at about the point the sound driver seach pops up(which it doesn't in UniPCemu, crashing instead).
Edit: Odd, just tried to run the 360K Compaq Deskpro 386 setup disk 1. It will eventually run a loop calling interrupt 21h, but interrupt 21h vectors to F000:1BD0, which is somewhere inside the BIOS ROM instead of MS-DOS?
Edit: Something's clearly going wrong there.
One other odd little thing I notice with MS-DOS games, Maniac Mansion 2: Day of the Tentacle(just gotten that one last friday on the PS Vita:D ) doesn't seem to repond well(at all) to command line parameters? It will always display the help for the parameters followed by an NULL segment fault?