VOGONS


test386.asm CPU tester

Topic actions

Reply 140 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just fixed two more bugs: opcodes 0x84-0x87 had their parameters(modr/m and reg) reversed and opcode 0F0D(Deliberate #UD on 80286+) had parameters it shouldn't have(modr/m and immediate entries).

Having fixed those, Wolfenstein 3D ends up with a hanging, corrupted main screen(showing logos and memory empty, while it says it's loading text at the bottom, hanging)?

I've checked all x86 opcodes up to the 80286 opcodes(TODO: 80386 (32-bit) extensions and 80386/80486 new (0F) opcodes), but no other errors show up. So 80286 software should work properly. Then why is Wolfenstein 3D crashing?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 141 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Now the 80386+ and 80486+ instructions are also modified to use the lookup table. The instruction tables(which details instruction rights(like LOCKable, valid modr/m reg values for immediate bytes or not etc.) and the parsing of the modr/m parameters and immediate parameters) also seems fine now. Fixed a few little bugs in them(reversed parameters in some cases, although unused for some of those instructions). Then eventually ran the testsuit again(originally finding a bug in the MOV CRn/DRn/TRn instructions being reversed and not working correctly. That have been fixed.). So now the entire CPU up to the 80486(also verified the new 80486 opcodes against the 80486 user reference manual's appendix A) should be at least parsing the opcodes correctly. Any remaining bugs should be misc. type bugs, if any(like protection errors, handling of faults, task switches, interrupts etc.).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 142 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

I just found out that Barotto has updated the testsuite(my testsuite version is still that of 02 June 2018, while he has updated it with some much needed flags tests(pushf(d)/popf(d)), real mode segment register tests, real-mode exception tests, protected mode segment register tests, improved STOSx,CMPSx,SCASx,MOVSx tests, various missing arithmetical instruction(adc/add/and/cmp/or/sbb/sub/xor/inc/dec) tests, LODSx tests, TEST tests and Double Percision(SHLD/SHRD) tests.

That also means we finallly have some testsuite that tests for some protected mode functionality! 😁

Time to compile and run that testsuite when I have the time...

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 143 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Yay for the new testsuite version! Immediately a bug found in POST B!

It seems to be the check that trying to load selector FFF8(Defined NULL in the code) gives has FFF8 pushed on the stack, but UniPCemu pushes FFF9 on the stack? So bit 1(EXT) is set, while it shouldn't? When should EXT be set?

With the protected mode core modified to set the EXT bit to 0 instead of 1 when not loading through an task switch(which should push EXT=1 within the error code), it now pushes the correct error code(I see the code continuing on until the end).

I see it once again continuing until the end. Comparing the log that's generated during the POST EE tests with the given reference log, it matches 100%! So no errors there afaik(in the algorithm department).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 144 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... The EXT bit should be set if the cause is external to the program.

https://css.csail.mit.edu/6.858/2010/readings … i386/s09_08.htm

What exactly falls under this definition of 'external'? All I can think of is a hardware interrupt or NMI? No other external sources exist on a 80386 afaik?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 146 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Currently UniPCemu sets the EXT bit in one case now: when exceptions fail(or hardware interrupts fail). Anyone knows in what case(s) it's actually set to 1?

Edit: Yay, some more useful information: http://beefchunk.com/documentation/hardware/m … 86/Figs/Fig.9.h

So with external it means stuff like single step, external interrupt(IRQ), coprocessor faulting, NMI and related interrupt handling triggering an exception! Interesting!

Edit: Just modified my code to apply the bit to said interrupts faulting and onwards(so nested faults as well). All causes by the instructions have the EXT bit cleared.
Edit: What I meant with that is that apparently, 'external' are all non-CS:IP instruction causes. So any of the above and more.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 147 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found some more bugs in the 80386+ core:
- Improved theoretical support for loading segment registers on the 80386+ functions(unused feature afaik, since it doesn't load segment registers).
- CALL Mp and JMP Mp(opcode FF GRP5 instructions) had their memory checking for the wrong start position. It actually skipped all memory checks for the data read from the ModR/M data in memory(both segmentation and paging checks and of course paging exceptions with it).

Those bugs(or at least the bug in the opcodes 0F /3(CALL Mp) and 0F /5 (JMP Mp)) have now been fixed.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 148 of 178, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie
awgamer wrote:

Has this cpu tester been tried on dosbox?

Out of the box would not work as the CPU tester requires it to be run as a BIOS ROM. I do not know of a way to do that in DosBOX.

That being said, I need to run this new version on CAPE.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 150 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just tried for fun to try to boot some little OS on a floppy(Haribote), which I've found at https://github.com/shift-crops/x86emu (the haribote_21h.img 1.44MB floppy disk image).

It seems to run until it's very first protected-mode task switch, which errors out until it reaches a triple fault(which in turn hangs the current IPS-mode emulation for some unknown reason).

Edit: Bug found in RPL retrieval during task switching (due to a simple "TSSSize?CSselector:CSSselector&3" RPL retrieval 😖 ). That was a problem in the "#define getRPL(value) (value&3)" macro combined with task switching. Thus loading CS(which is 😎 and changing CPL to 8 during a task switch(which triple faults the system:S ).

Also, for some odd reason, triple faulting in IPS mode that way seems to incorrectly return the TSS and stop execution permanently in IPS-mode(since executed is cleared and never set again after returning from the task switching routine, which indicates it isn't done yet 😖).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 151 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

That triple fault hanging the CPU is because the CS segment in the loaded TSS(value 0008) of a JMP causing a task switch is actually a data segment(accessrights=0x93), which causes a #TS fault, which doesn't exist, thus #GP faulting and double faulting, which both aren't present, thus triple faulting thd CPU.

The Task Switch routine returns a ongoing status(1 on busy with I/O, 0 on finished). Since it was returning 1 for faults, the executed flag got reset. Since it's reset, the whole operation takes 0 cycles in IPS-mode on the emulator end. Thus explaining the CPU hanging due to infinite cycles being taken waiting for the finishing of the instruction, eventually aborting the core loop each time it's called. The CPU execution state becomes undefined due to the triple fault, waiting for the finishing of execution to start resetting the CPU. But execution never finishes(executed==0), since the task switching state makes the CPU state invalid.
Luckily the fix is simple: return 0 even for faults. 1 is reserved for I/O through the BIU during task switching(TODO).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 152 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmmm... According to the OS's source code, the very first task switch should be the idle task with CS=0010 and all data segments 0008? But 0008 is loaded into CS instead???

https://github.com/tyfkda/haribote/blob/maste … /kernel/mtask.c

Better check if the rest of the TSS is loaded correctly(should be verified using the task's EFLAGS, which should be 0x202 according to the source code, and the other segment registers etc.)...

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 153 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just finished checking and fixed loading and saving of 32-bit TSS(it was having problems loading and storing the segment registers because the pointers to their consecutive segment selectors was updated incorrectly). Having fixed that, task switching seems to work without problems now! The mouse on that OS isn't working, though(probably because it's a serial mouse?).

Edit: Now it double faults due to the #GP fault handler for the debugger fault(because the T-bit of a task is set, which causes a non-existant debug trap, thus causing a general protection fault which has an invalid (also 0x0010) CS segment to use?). Odd.

Edit: Huh? The CR0's paging bit is cleared with the CR3 still containing a paging value? Is paging disabled during the fault oddly?

Edit: Just tried again. Now the fault doesn't seem to happen(the first time)?

Edit: Now the fault seems to be due to opcode 6A(the last executed instruction)?

Edit: Hmmmm... It the #GP fault handler that handles the debug trap fault handler tries to execute INT 0x20. But when loading CS with the value 0x0010, the loading fails for some odd reason?
Edit: The memory at 0x270010 which contained the general protection fault's CS segment descriptor is cleared to zeroes at this point(the INT 0x20)? So it will triple fault because of that reason?
Edit: Both interrupts should have been set at boot time, so something is clearing the IDT entry during the #GP fault handler?
Edit: While enabling the debugger during that error phase(just before until just after the triple fault), I notice it dumping some text into the main window(something about the GP fault, then EIP is written(behind the other window)). Then the INT 20h occurs, leading to the triple fault.

Filename
debugger_TripleFaultingOnINT20h.7z
File size
1.5 MiB
Downloads
65 downloads
File comment
INT20h triple faulting during task1.
File license
Fair use/fair dealing exception

So still some troubles, but progress! 😁

Edit: Hmmmm.... From row 2940096 onwards it seems to process something, writing zeroes into the GDT+0x10h selector?
Edit: Hmmmm... It has something to do with EBP+14 and onwards being zero instead of valid data for a descriptor to be filled?
Edit: Said clearing seems to be done by the code at line 3179983 and onwards (push 00)?
Edit: Hmmmm... Could that be row 33/34 of desctbl.c(it's initializing the GDT with zeroed entries). But after that, it's supposed to set GDT+0x0008 to a linear 4G descriptor, while setting GDT+0010 to ADR_LIMITBOTPAK and ADR_BOTPAK as a code descriptor, which obviously doesn't happen for some odd reason?
Edit: Looks like I'm right: row 3180755 is the end of the set_segmdesc function. After that it returns to the init_gdtidt function at 0010:0000131e, where the next two instruction after that is the for statement it seems(jns 0000130f is the loop executing). So 0010:00001324 should be the end of the for loop, where it calls the function to setup the gdt code segment.

But before it reaches that, the interrupt/fault already happens. I see it reaching "EBX: 00001f00", looking further down, but "EBX: 00001e00" isn't reached?
Edit: The last point it reaches in the loop is line 3292446, where it reaches count 00001eec(of clearing the GDT). So something interrupts said operation, while it shouldn't.
The interrupt flag is set, so there's a problem(interrupts can cause it to break in the middle of setting up the GDT).

Edit: Yup, during the second push, it actually still has the interrupt flag enabled, and the interrupt(which seems to be 20h) tries to use the a valid IDT entry to load CS, which faults because it's still cleared and not setup yet. Then it's the fault of some CLI not being executed before the main changing loop?

Edit: Hmmmm.... Said function that initializes the GDT/IDT doesn't affect the flags in any way(it's a problem with hardware timer(IRQ0) interrupts at this point). The cause of it seems to be within the first function of HariMain(bootpack.c), which is enabling interrupts after said initialization. But interrupts were already enabled before calling said function.... Hmmmm....
Edit: So line 3179898 is the start of the call to the HariMain function. At that point, interrupts are already enabled, which they shouldn't according to the source code?
Edit: Hmmmm.... The IRET at line 2940082 sets the Interrupt Flag on by popping it off the stack at stack address 0030FA3C.
Edit: Looking upwards, I still see it set at line 2939503, where the interrupt was started.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 154 of 178, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Mind if I use your test386.asm against DOSBox-X?

Though I don't have the free time now, I've been slowly developing programs to test parts of DOSBox-X.

So far, the only component written is one that ensures the Hercules/MDA/CGA/PCjr/Tandy/EGA/VGA basic video modes work correctly.

The test programs are in a sister project to DOSBox-X called DOSLIB.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 155 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found a bug in the TSS handling when starting a new task. The T(race)-bit wasn't actually set: the emulator was checking if bit 0 of the Backlink field in the 32-bit TSS was set(TSS offset 0 bit 1) instead of bit 0 of word 0x64(the T-bit in 80386 documentation). Oddly enough, the article on osdev.org (https://wiki.osdev.org/Task_State_Segment) doesn't mention that bit exists, just labeling it as "reserved"?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 156 of 178, by canthearu

User metadata
Rank Oldbie
Rank
Oldbie

Just a silly question.

I have written a little 8086 cpu emulation just for my own amusement. I have run against the same issues as the OP ... last time I spent several hours debugging what the CPU emulator was doing, and worked out that I screwed up my string instruction implementation.

Currently, I am having problems with MSDOS syscalls not working right (can't find files to open), but it is extremely difficult to track down emulation bugs in the huge debug outputs. I can't imagine how much more difficult it would be for a 386 cpu emulator.

My question is if the test386.asm can test the 16-bit real mode subset of the 386 instruction set so I can run it against my emulator?

Reply 157 of 178, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

Not really as it will require 32bit registers and addressing very fast.

What you really want is the 80186 test suite, that is entirely 16 bit. I forgot where I got mine from, Superfury might remember. If you cannot find it I can send it to you.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 158 of 178, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

I found this tester, same one?
https://forum.osdev.org/viewtopic.php?f=13&t=23739&start=15

Attachments

  • Filename
    80186_tests.zip
    File size
    23.94 KiB
    Downloads
    64 downloads
    File license
    Fair use/fair dealing exception

Reply 159 of 178, by superfury

User metadata
Rank l33t++
Rank
l33t++

Indeed, that one's it.

I also have a little mirror at my UniPCemu documentation repo (80186_tests.zip is the same file).

One small addition to it can be found within UniPCemu's documentation. 80186_tests_UniPCemu.zip contains the same files, but split source code and binary files(where the binary files are sorted by functionality using a prefix)).

The archive mentioned above also adds the missing result file in the original archive of the jmpmov test added by me(res_016.jmpmov.bin)). The archive you've posted was missing said file.

Filename
res_jmpmov.zip
File size
128 Bytes
Downloads
71 downloads
File comment
The missing result file of the jmpmov test.
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io