VOGONS


Reply 100 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

There's one thing I don't quite get, though: why are the timings, even after substracting memory access timings from the EU timings still resulting in some very non-1.00 scores when running MIPS? I see two stats(General and/or Integer math and the final count) nearing 1.00 score in MIPS on both 8088 and Compaq 80386(Mem-Mem and Reg->Mem) columns, but the other scores range from 0.5 to 1.5, even though timings are based(and BIU timings substracted) on the timings given in the manuals? Why aren't all timings properly approaching 1.00 score?

Edit: Just tried the AT BIOS on my current AT emulation, which crashes with a System Board Error(Diagnostics code 2B). So there's a problem with the PIT(doubt it) or PIQ(changed to fix Windows 3.0 setup input, handling of disabled IR rising interrupts being changed slightly).

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

Reply 101 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just fixed a bug in the 80386 core, where the 32-bit offsets were truncated to become zeroed, as the required memory mask was never set(being 0x00000000), thus clearing all memory offsets when addressed as 32-bit. Now some 32-bit software(like the PLOP boot manager) runs better without crashing(although the Compaq BIOS still has problems configuring the DMA controller mode control register??? It's being setup for test mode instead of read mode when reading data from the floppy drive?).

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

Reply 102 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried running the Jazz Jackrabbit for MS-DOS install.exe again, which now properly continues to the main installation screen and displays a message, but oddly enough when I press enter, I see it reading the press/release codes(XT keyboard format, due to keyboard translation being enabled) 0x1C, 0x9C from the 8042(which is correct), then two more reads follow(both returning 0 because there's nothing in the input buffer?). Anyone knows what might be the cause of this? The installation wizard doesn't continue to the next step?

Edit: It does seem to respond to the Numpad Enter key, but not the normal carriage return key? This happens during all installation menus. It also doesn't repond well to the Escape key(seems to have barely any effect, besides light processing within the interrupt handler)?

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

Reply 103 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried to run a simple linux distro (Linux Mini distro), it eventually crashes at segment 8B00:0000(which is filled with zeroed memory). I see it's reading a lot from the hard disk(from segment 8A00, which uses interrupt 13h to do it's work)?

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

Reply 104 of 142, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

Does the Linux Mini distro support 386? And also how much memory are you giving it, and will it be ok with that little?

On my real 386 I used an old version of Slackware, I think 4? That worked, albeit a bit slow, with a DX@40Mhz and 32Mb RAM.

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 105 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

I'm trying to use the various distros from Bochs:
http://bochs.sourceforge.net/guestos/linux-img.tar.gz

It's the disk image from http://bochs.sourceforge.net/diskimages.html , the "4-meg hard disk image which boots into Linux.", the link named Linux. The same issues seems to occur with those other distros on that page.

I saw it starting printing "LI", then a repeating number in intervals(nothing now, after the lastest bugfixes in the CPU core and PIC fixes).

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

Reply 106 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Are there any good ways to go about finding bugs in my x86 emulation? I'm now running Microsoft Flight Simulator 4.0 as a test(in 8086 mode) on my 80386 Compaq Deskpro 386 emulation. It seems to run fine without problems(in demo mode). It's already flown past several places without crashing, so the algorithmic instructions work without problems?

When trying to run it in 80386 mode, it crashes after the configuration screens(entering '1' at the first option to go through setup), when the game is starting(still a black screen). It somehow starts executing invalid code(0xFFFF instruction bytes fetched from memory, which is an #UD).

Stuff like Wolfenstein 3D that was originally working on the 80286 emulation doesn't run at all anymore on the 80286+ CPU emulation? It crashes as well when starting.

Edit: Something odd's happening to the numbers on the circular displays, though: the turning arrow for the different compasses seems to erase the numbers on the display below it?

Filename
Microsoft Flight Simulator 4.0 MS-DOS UniPCemu 80386 in 8086 mode.zip
File size
336 KiB
Downloads
37 downloads
File comment
Microsoft Flight Simulator 4 running on UniPCemu's 80836 in 8086 mode(real mode).
File license
Fair use/fair dealing exception

Since the plane doesn't crash, that means that at least the algorithmic instructions work without problems? Although, eventually it crashes navigating the menus as the demo is running?

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

Reply 107 of 142, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:
I'm trying to use the various distros from Bochs: http://bochs.sourceforge.net/guestos/linux-img.tar.gz […]
Show full quote

I'm trying to use the various distros from Bochs:
http://bochs.sourceforge.net/guestos/linux-img.tar.gz

It's the disk image from http://bochs.sourceforge.net/diskimages.html , the "4-meg hard disk image which boots into Linux.", the link named Linux. The same issues seems to occur with those other distros on that page.

I saw it starting printing "LI", then a repeating number in intervals(nothing now, after the lastest bugfixes in the CPU core and PIC fixes).

That is too complicated. Just Google around for Slackware boot image disk, for anything less than Slackware 4.0. There are plenty of FTP sites that have that. It will be a floppy image, 1.4Mb, so you will remove all the CD/HDD and all that complexity. And boot that. It should support 386 CPU. There are .img boot disk for low memory machines as well.

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 108 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

There's still a problem with floppy disks: the FDC on the Compaq Deskpro 386 doesn't seem to work(it programs the DMA controller mode for test mode instead of write mode(to read FDC sectors into memory)). Thus atm(for some unknown reason), on the Compaq Deskpro 386, floppy booting won't work: it'll fail reading sectors from the disk(since DMA doesn't transfer due to test mode).

Is there any tool that can be used to find the bug in the x86 CPU that causes it to fail booting? I have a disassembly of the Compaq Deskpro 386 BIOS, but I don't know what causes the FDC to be incorrectly programmed. It seems to load the value from a table, but either the table location or it's index is incorrectly calculated? And the cause might be further up the call tree?

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

Reply 109 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found some bugs in the conversion from 16-bit to 32-bit instructions of the 80(1/2)86 instructions to 80386 instruction extensions. The opcodes 25(ANDD)/2D(SUBD)/35(XORD)/3D(CMPD)/C7(MOVD)/F7(/0 TEST only) were using 16-bits immediate parameters instead of 32-bit(backend side only, the reading from the prefetch buffer acted as supposed to, just operating on the parameters stored in the last instruction using those 16-bit immediates). The CMPSD instruction was even executing on 16-bit data completely(although using the 32-bit handling to execute it, just taking 16-bit old immediate in a 16-bit variable instead of 32-bit immediate into 32-bit variable). These problems have now been fixed.

Edit: Debugging himem.sys's testing extended memory, I now see it entering protected mode! 😁

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

Reply 110 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

It seems to do something odd: it enters protected mode, loads ES/DS descriptors with a 4GB descriptor(whose data checks out for the purposes of HIMEM.SYS' method of copying memory high), returns to real mode immediately after that. So far so good. But then, before returning to the REP MOVS instruction, it loads DS and ES with segment value 0, causing the entire 32-bit descriptor to be reloaded with real-mode values? That wouldn't work for unreal mode, as it needs those 32-bit descriptors to even work?

So, does the high rights byte get reloaded when loading a NULL selector in real mode? I mean the byte containing the granularity, D/B and high limit? HIMEM.SYS loads the segment in real mode before returning from the fault handler that loads the descriptor to clear them to zero?

Edit: Looking at http://www.os2museum.com/wp/will-the-real-rea … lease-stand-up/ shows something:
- The base is updated when loading segments in real mode.
- The selector is updated when loading segments in real mode.

Furthermore, it's known that loading a segment in real mode updates the access rights to 0x93 for real-mode compatibility.

So that means that all other fields(limit low word and limit high/G/D_B byte) aren't updated in real mode? They keep their old values as specified?

Edit: Modifying the x86 emulation to not reload the flags/limit byte (cleared only when loading segments using the Virtual 8086 mode), I see it accessing high memory using REP MOVSD. But eventually, it still errors out the memory test at address 00100000h?

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

Reply 111 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've made a little log of the HIMEM.SYS driver testing extended memory(which SHOULD be working, according to what I can see from the BIU I/O), but it still fails the memory test for some unknown reason?

Filename
debugger_HIMEM_highmemorytest.zip
File size
3.75 MiB
Downloads
44 downloads
File comment
HIMEM.SYS(MS-DOS 6.22) high memory test running.
File license
Fair use/fair dealing exception

The high memory access seems to succeed, but something is making it fail the memory instead? Can anyone see what's going wrong?

Edit: This is the way all memory and hardware accesses are mapped:
https://bitbucket.org/superfury/unipcemu/src/ … ler.c?at=master

A normal path would be:
EU -> BIU -> MMU_IO_read/writehandler -> hardware(by handler itself) or <- memory(MMU_IO_read/writehandler returning 1) -> MMU_internal_directr/wb -> applymemoryholes(memory remapping and memory hole functionality). When fully allowed(no hole/hardware/remap or remapped to memory), MMU_internal_directr/wb writes to or reads from memory and the chain is returned through(with the value read during reads) to the BIU itself(or handler itself for protection structures(descriptor table reading etc.).

Is that behaviour correct(mainly the MMU_internal_directr/wb and applyMemoryHoles function)?

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

Reply 112 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just managed to find some little bugs in the 80386 core(both with disassembly and actual instruction execution):

- Fixed some 32-bit instruction disassembly.
- Fixed RET(F) using 16-bit immediate always, not depending on operand size.
- POPD using 32-bit disassembly.
- Fixed CALL Mp segment displacement.
- Improved 32-bit IMULD comments.
- Improved 32-bit LSL protection.
- Fixed 32-bit BT(S/R/C) disassembly.
- Fixed 32-bit BS[F/R]D disassembly.
- Fixed 32-bit JMP Mp using the 32-bit data read instead of previous instruction 16-bit stored data.

Some were truncating data, other instructions were using old 16-bit leftover data from another instruction and others (RETD/RETFD) were actually using a 32-bit immediate instead of the required 16-bit immediate.

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

Reply 113 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the cycle-accuracy a bit, implementing the 80386 BIU versions of the PUSH/POP FS, PUSH/POP GS, MOVSX and MOVZX and IMUL instructions.

Now the only 80386 instructions not using the BIU yet are the SHLD and SHRD instructions and the bit test instructions(BT, BTS, BTR, BTC, BSF, BSR). Then the only thing not working using the BIU is the 80486-specific instruction and the protected mode functionality itself(the descriptor fetching and paging lookups), both which are pretty hard to implement due to their sheer complexity(Memory accesses waiting for Paging accesses waiting for BIU, as well as the complex EU modes(task switching with protection etc. through the BIU, interrupts in protected mode through the BIU)).

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

Reply 114 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Another small improvement, now implementing all instruction, only the bit test instructions being left to convert.

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

Reply 115 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just converted the bit test instructions and bit scan instructions. Now the all 80386+ instructions are handled through the BIU, with small improvements in cycle accuracy(due to cycles being moved from the end to the actual processing phase, before writeback).

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

Reply 116 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Still strange, though: even though the 80386 core is fully converted to use the BIU for memory accesses, it still has about 50%-80% of the speed of a real 80386SX? Even though it's a 80386DX being emulated?

455-80386 core converted to cycle core..jpg
Filename
455-80386 core converted to cycle core..jpg
File size
101.99 KiB
Views
687 views
File comment
MIPS running on the completed 80386 cycle-based BIU/EU instruction core.
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

Reply 117 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

Is there any reasonable way to find the bugs in my x86 eulation? 8086 code seems to be running without problems, but 80386 and 286 programs(except Megarace partly) seems to go into undefined execution(#UD) territory(unread data or unprocessed or invalid jumping), even though the 386 code(except new opcodes) is a simple 32-bit operand extension of the 16-bit variants(except some unconditional jumps like opcodes 0x70-0x7F). Also, the 286 emulation is failing as well, despite adding only 186 and a handful of new 286+ opcodes? Even something simple like HIMEM.SYS, Windows 3.0(Protected mode) and Wolfenstein 3D goes wrong for unknown reasons(all crashing when starting and HIMEM reporting invalid memory at the 1MB barrier with A20 being enabled properly). The low 4GB descriptor limit is loaded with 0xFFFF as well as access rights with real-mode compatible values besides a base of 0(due to loading segment 0 into DS/ES after entering unreal mode before returning to the interrupted REP instruction in HIMEM.SYS, so that shouldn't be causing any problems. Then why does it report faulty high memory at address 0x100000?

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

Reply 118 of 142, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

Now you're in the realm of requiring an actual debugger or huge trace-logs, and performing side-by-side execution to see where the code paths deviate.
Once you see where the paths separate, the problem might be obvious. If not, then we can certainly help to identify it.

Reply 119 of 142, by superfury

User metadata
Rank l33t++
Rank
l33t++

That's exactly the difficult part: the method of execution is a cycle-based one, whereas most emulators(except mine and vladstamate's afaik) run on an instruction level at most(like Dosbox).

So that would mean I need to rebuild some of the instruction-level hardware synchronization instead of cycle-level to compare with those emulators? I think that would be easier than I originally thought: simply implement it at the same level as the debugger, which also runs at an instruction level(using CPU[0].executed to time 0ns or 1/1000th cycle timing(instruction constant specified) to provide semi-Dosbox compatibility without changing the CPU's EU/BIU emulation)?

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