Hmmmm... Something is going strange when testing paging on the Pentium emulation, running debian 3.0r0(from https://sourceforge.net/projects/bochs/files/ … Debian%20Linux/)? Trying to run it on the Pentium emulation makes the emulator somehow lock up, because the Paging TAG generation(which is used for looking up the entry and storing it) WILL set bit 0 to 1(the present bit) when saving the TLB entry. But when reading the TLB entry from the paging TLB, somehow all bits are correctly set in the tag to look it up, but bit 0 is reset? Even though the basic expression used is:

1//W=Writable, U=User, D=Dirty
2OPTINLINE uint_32 Paging_generateTAG(uint_32 logicaladdress, byte W, byte U, byte D, byte S)
3{
4	return (((((((((S<<1)|D)<<1)|W)<<1)|U)<<1)|1)|(logicaladdress & 0xFFFFF000)); //The used TAG(using a 4KB page, but the lower 10 bits are unused in 4MB pages)!
5}

Why is it clearing bit 0? All other bits are correctly set, but bit 0 is reset?

The only thing following it is:

1		TAG &= (curentry->entry->addrmask|0xFFF); //The full search mask, with the address width(KB vs MB) applied!

Where curentry->entry->addrmask is 0xFFC00000 due to it being in a 4MB TLB entry? But that still has bit 0 set, but it's still cleared after these two lines(Paging_generateTAG and the TAG &= (curentry->entry->addrmask|0xFFF); ? Why is this happening?

Edit: Managed to fix it. It seems a problem with the mask to be applied(for searching tags and masking off bits that are to be ignored(e.g. writable and dirty bits in some cases for memory read accesses) was causing issues. Since the mask and the tag that's pre-masked for quick search weren't matching properly with 4MB entries, it was failing to properly recognise them when the upper bits were non-zero(upper 10 bits of the address(bit 12 to 21) that were added in the case of the 4MB pages).

For the software mentioned in: Good MS-DOS software for validating x86 protection emulation?

Just tried the Into The Shadows demo. It seems to run fine, but very slow(of course, since it's running at 20% realtime speed).

Still need to test the other two.

Edit: ATP(Airline SImulator as peterferrie called it, if I'm not mistaken) seems to run fine. Just ran a little testflight. Everything seems to be working fine as far as I can see.

Edit: Hmmmm.... Greedy doesn't seem to respond to input? It gets to the main menu without issues, but unresponsive otherwise?

Hmmm.... After debugging some more on Basic Linux on the Pentium emulation, I see a 0x18 value being loaded into DS, which faults out due to a 0x00 being in the Access Rights byte?

Edit: Hmmm... Debugging some more I see the GDTR origianlly being at 906b4(Linear Address) with Access Rights 0x93(normal). Then 0x92 at C01BDFC0. Then 0x00 at the same base address?

Just retried OS/2(the same one as earlier). It says Loading on the second disk, then complains it cannot find "A:\COUNTRY.SYS" (without quotes)?

Anyone knows what the cause might be? I do see it using call gates, but they seem to work fine?

Hmmmm... Something weird happened to the Day of The Tentacle (Maniac Mansion 2) for MS-DOS. When starting the game, it seems to somehow hang at a black screen?

Is this perhaps related to the fix of the loading of SS:ESP when bopping down to user mode from kernel mode?

Yay! Having fixed the x86 protected mode breakpoints, NT 3.1 now continues past it's hard diskmcheck(chkdsk reports they're clean)! 😁

Edit: Yay! It properly starts the GUI part of the setup! Mouse cursor confirmed!

Edit: Mouse works! It gives a message box(using ET4000, perhaps VGA during the first part of setup): "The system isn't properly configured. Please run setup again".

Tried installing Rayman (The first) for MS-DOS(Although had to download a cue/bin due to the disk imaging software refusing to properly read in my CD-ROM(probably because one or more of the sectors before the volume boot record is damaged) and keeps throwing read errors, refusing to continue even though pressing retry again and again).

The installer seemed to run without errors. Then, when selecting the play option from the menu, I see a quick loading in a bit of Doom-styled header for a flash, then it dumps me back to the MS-DOS prompt saying "MSCDEX is corrupted"? What's up with that? I'm using a combination of Windows 95 OAKCDROM.SYS(instead of VIDE-CDD.SYS due to CD-ROM error reporting issues with VIDE-CDD) and MS-DOS 6.22's MSCDEX.EXE? Or should I use Windows 95's MSCDEX? Why is it complaining about MSCDEX?

Tried booting the current(?) i386 debian kernel on UniPCemu from a converted disk image(version 2 qemu disk image). UniPCemu is configured for 12MB RAM.

I see it triple faulting during a BOUND instruction(lower limit 0x8xxxxxxx and upper limit 0x100 is weird)? I see a quick out of memory message during that, before triple faulting and rebooting?

The bound instruction SHOULD be fine, but why the triple fault(invalid/unset #gp/#df interrupts)?

Anyone?

Hmmm... Tried running MS-DOS 6.22 setup in a variety of settings/architectures: XT/8088, Compaq Deskpro 386 w/ 80386 and Pentium. All seem to hang during the checking the hardware step it starts with?

I also tried it with the currently improved MDA/CGA emulation(line drawing and 9-pixel wide fonts now properly working on MDA). But I notice there's no line drawing boxes etc. on MDA? Or is that a problem with Dosbox's 14-row character font? It seems like it's in the tables through?
Edit: Nope. It was a precalculation problem.

Just tried running MS-DOS 6.22 setup disk 1 of 3 on the 8088 XT emulation with MDA... It 'rebooted' into the BIOS, making the Turbo XT BIOS display an error message saying something like "error code nn"? Does that mean 6.22 can't run fully on a 8088, or that the 8088 is having a bug?

Just tried running PCCheck 6.0. It loaded partly, then notifying me that the FAT was bad (perhaps during a hard disk check)?

Tried running NT 3.1 again. Now, it once again crashes with the logical memory location 28h invalid address?

Tried the Bochs' legacy BIOS ROM with UniPCemu... It seems to hang or crash on the keyboard initialization call somehow? I never see it returning from the function?

Now trying NT 3.1 workstation setup again. It seems to recognise the ATAPI CD-ROM drive correctly with the build 511+ from https://www.betaarchive.com/forum/viewtopic.php?f=61&t=36255 (using NT 3.10.511.1, thus the driver from 511+), but when it reaches the checks for attached harddrives etc. it gives me an error saying "An error occurred reading from or determining the configuration of a hard disk drive attached to your computer. This may indicate a hardware or configuration problem with a disk drive, disk controller, or SCSI adapter." etc.

So checking against a CD-ROM based setup isn't possible either.

Since Windows 95 C runs without much issues on Dosbox SVN Daum(Installed from CD-ROM on UniPCemu, first boot on Dosbox SVN Daum), the first setup part must be OK(except primary ATA and FDC reporting init failures in bootlog.txt and device manager).

Now the question, what and why is some driver crashing during boot at 137:6522? It's probably a 16-bit driver, as it's EIP is below 0xFFFF?
Anyone knows how to figure out what or why it's crashing during that segment load? It's a near RET instruction that seems to be trying to return to kernel space(above 0x80000000)?

Edit: Windows 3.0a seems to crash to the MS-DOS prompt on a #GP(0) due to a limit violation on DS pointing to base 0x20 offset 1 with a limit field of 0?

Just found a bug in the 32-bit LSL instruction that made it compare the RPL of the last whatever 16-bit read value from/for anything(or processing thereof by another instruction) 'selector' instead of the proper 32-bit value read from memory it loaded the descriptor with(the actual selector to use, which is a different variable).

That just points out how some bugs can be incredibly hidden in plain sight. I didn't notice that one until I actually went though the instruction and saw it was using the wrong value by chance(based on the Windows 3.0a loading a descriptor that's present with a 0 as it's limit(thus only 1 byte accessable, at offset 0 of the descriptor)).

Edit: Having fixed said LSL 32-bit instruction properly, Windows 3.0a now finally boots into the GUI instead of crashing back to the MS-DOS prompt!!! 😁

Edit: The same for Windows 3.0! 😁

Since 3.1 and 3.11 already worked fine for some time now, this means that finally all Windows 3.X versions of Windows boot without any problems now! 😁

Just tried Windows 95 C(running fine in Dosbox SVN Daum) in UniPCemu. It seems to crash during IOS.vxd loading now, the same as Windows 98 First Edition?

I see it throwing infinite Stack Faults. Somehow the SS descriptor pointing at location FFFF0? Thus it's in the memory hole or HMA area? Paging is disabled.

Edit: Windows 98 FE is trying to execute a 0xFFFF instruction. That throws infinite #UD faults?
Edit: So all Windows 9X versions still crash during the first boot. Windows NT 3.1 still crashes after rebooting during the setup. But all Windows 3.X versions now run(due to the LSL 32-bit fix).

Just tried Rise of the Triad again in UniPCemu. From CD-ROM it gives a (apparently known) permission error for files on the CD-ROM.

But after copying it to the hard disk image, it runs like a charm (as much as a charm as it is on 24% emulation speed).

But at least that one works properly now. Another first-person game to add to the list of running software for MS-DOS/Windows 3.x.

Try running some known-to-be-unstable software on Windows 3.1, like Titanic: Adventure out of time (requires Win32s).

keenmaster486 wrote:

Try running some known-to-be-unstable software on Windows 3.1, like Titanic: Adventure out of time (requires Win32s).

Tried running that about a month ago. It crashed Wfw 3.11 at the time. Although it might have been fixed with other CPU bugfixes by now(or might still fall into the same case that's crashing Windows 9x). I'll check when I have time.