VOGONS


Reply 20 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Although the Mouse is still buggy somehow(jumping all over the place moving it), installing with a keyboard only does the job(takes a while, though). The installation runs until the end and reboot/ms-dos. The MS-DOS option returns to MS-DOS without problems.

After reboot and fixing my custom autoexec.bat to use the proper path, running win(without parameters) shows the Windows 3.1 logo(apparently it actually was 3.1, not 3.11), then right after drawing returns to text mode doing nothing at all(input buffer fills when typing, resulting in beeps when full). Otherwise, it doesn't respond to anything at all.

The current results are:
- Windows 3.0 real mode: booting and working.
- Windows 3.0 standard mode: booting. black screen afterwards.
- Windows 3.0 386 enhanced mode: returns to MS-DOS prompt
- Windows 3.1 standard mode: booting and working.
- Windows 3.1 386 enhanced mode: shows logo, then back to empty screen in text mode with cursor. unresponsive to input.

So only 3.0 in real mode(/r) and 3.1 in standard mode(/s) actually work. Without parameters or other settings crash when booting.

Any idea what might cause this?

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

Reply 21 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Do you have logs in common log format for:
- Windows 3.0 starting in standard mode.
- Windows 3.0 starting in 386 enhanced mode.
- Windows 3.1 starting in 386 enhanced mode.

So far got working:
- Windows 3.0 in real mode.
- Windows 3.1 in standard mode.

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

Reply 22 of 46, by Stenzek

User metadata
Rank Newbie
Rank
Newbie

Fantastic, glad the traces helped!

superfury wrote:

Edit: Whoops, it's the same, but your log puts the segments within brackets, while the common log format uses it OUTSIDE the brackets. Also things like ptr isn't used in said format(just byte, word or dword). The same with spaces, only between instruction and the first operand(if any). Also, no h suffixes(it's assumed hex already).

Right you are. Also noticed I was inconsistent with the segment/bracket placement in my disassembler, depending on the instruction form! Thanks 😀

superfury wrote:

You already have some 486/pentium+ flags set in CR0, while I have the upper 12 bits set and bits 1-3 cleared(fff1).

That's intended, my CPU emulation supports 486, and most of the Pentium instructions. I was running in 486 mode when generating the trace. I haven't actually checked what the lower bits should be, I just mask them away to zero.

superfury wrote:
Do you have logs in common log format for: - Windows 3.0 starting in standard mode. - Windows 3.0 starting in 386 enhanced mode. […]
Show full quote

Do you have logs in common log format for:
- Windows 3.0 starting in standard mode.
- Windows 3.0 starting in 386 enhanced mode.
- Windows 3.1 starting in 386 enhanced mode.

These traces were recorded from the first pmode switch after displaying the windows logo (all done in real mode, and knocked 1GB off the log), until the graphical mode switch, and the cursor/background was rendered. Note, the 386 enhanced mode traces are quite large (4GB+).

https://drive.google.com/file/d/1xzyAhsnJxr6C … iew?usp=sharing

Some things I remember when debugging this myself:
- Make sure you're handling split pages correctly, i.e. unaligned reads, where the adjacent pages in virtual space are not adjacent in physical memory.
- Paging and V8086 mode behavior has to be correct (e.g. GPF on unknown instructions, IIRC earlier versions of Windows used an ARPL instruction to trap to the monitor, instead of an INT).
- Intra-privilege stack changes do matter. I can't remember if Win3x did any task switching.
- In standard mode, if there was too much RAM, Windows 3.0 would crash. If I remember right, it did this with 32MB, but was fine with 8MB.

I'll look through my commit history when I have time, to see if I can spot any other mistakes I made..

Reply 23 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Some things I remember when debugging this myself:
- Make sure you're handling split pages correctly, i.e. unaligned reads, where the adjacent pages in virtual space are not adjacent in physical memory. Already handled in the BIU in recent commits.
- Paging and V8086 mode behavior has to be correct (e.g. GPF on unknown instructions, IIRC earlier versions of Windows used an ARPL instruction to trap to the monitor, instead of an INT). ARPL only does #UD when in real mode. Otherwise, it executes normally, no faults(other than memory faults)? Are there faults to be thrown based on the CPL? All 0F0* 80286+ instructions currently throw #UD in real mode. Succeed otherwise. Except when CPL isn't zeroed(or Virtual 8086 mode, which uses CPL=3) and LLDT, LTR, LGDT, LIDT, LMSW, CLTS is used, #GP(0) is thrown.
- Intra-privilege stack changes do matter. I can't remember if Win3x did any task switching. Should already be handled(required for WIndows 3.1 in standard mode, as well as the Haribote OS I've improved my emulator with.
- In standard mode, if there was too much RAM, Windows 3.0 would crash. If I remember right, it did this with 32MB, but was fine with 8MB. Shouldn't be a problem atm. Only have 4MB installed with the currently used settings(using automatic memory detection with memorylimit.txt containing "4M" as it's text contents.).

So of those points you've mentioned, maybe some issue with ARPL?
Edit: Just fixed ARPL requiring to #UD fault on 8086 mode too. It was just #UD faulting when in real mode. Now it's always #UD faulting when not in protected mode(without VM flag set).

Is said behaviour correct?

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

Reply 24 of 46, by Stenzek

User metadata
Rank Newbie
Rank
Newbie
superfury wrote:

So of those points you've mentioned, maybe some issue with ARPL?
Edit: Just fixed ARPL requiring to #UD fault on 8086 mode too. It was just #UD faulting when in real mode. Now it's always #UD faulting when not in protected mode(without VM flag set).

Is said behaviour correct?

I believe so. CPL is not relevant. I usually consult the Intel SDM (3-76 in this case) for these sorts of things, which says ARPL should raise #UD in all modes if the LOCK prefix is used, otherwise #UD only in real and V8086 modes. The #UD with lock prefix is the case for many instructions, but you can get away without having that emulated for most software. I haven't encountered anything which requires this behavior yet, but of course long term, for accurate emulation, we should check for it.

Reply 25 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

The invalid lock prefix already throws a #UD for all known invalid opcodes(that are always invalid for usage with LOCK according to documentation), which is of course based on the opcode itself(combined with modr/m parameters for opcodes using that).

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

Reply 26 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Yay! That ARPL fix fixes the mouse in Windows 3.1 standard mode! 😁

Windows 3.1 in 386-mode goes a bit further, reading some of the hard disk, then crashing to text mode once again!

Windows 3.0 in Standard mode now tells me it cannot run Windows in Standard mode and to run it in real mode.
Windows 3.0 in 386-enhanced mode still triple faults the CPU and resets.

I guess I'll try and fix Windows 3.0 in standard mode first, before starting to tackle the 386-enhanced modes(so at least basic 286 protected mode should work by the time I get to that).

Edit: Do you have HIMEM&EMM386 loaded with those logs?
Edit: Hmmmm.... I see my breakpoint at "0110:000009bb" in protected mode being triggered quite a few times on Windows 3.0 in Standard Mode(had to disable EMM386 for it to boot)?
Edit: Hmmmm... 3.56GB log and still not crashing to real mode(3.0 in Standard mode)? Also no VGA mode switch yet. Aborting...
Edit: Some more hard disk reads, then a black screen?
Edit: I see it doing some LSL stuff and loading something in ES afterwards over and over again?
Edit: Said LSL tries to load an zeroed segment descriptor(except the limit field) into BX, with the source operand in CX?
Edit: Restarted the log. So far 12GB without said video switch.

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

Reply 27 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just added a little option(advanced log) that disables all my logging extensions(all memory accesses, information about task switches(and it's progress processing it) and protection faults with errors codes). I'll need to make a new log later when I have the time and compare the logging with what you've posted.

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

Reply 28 of 46, by Stenzek

User metadata
Rank Newbie
Rank
Newbie
superfury wrote:

Edit: Do you have HIMEM&EMM386 loaded with those logs?

MS-DOS 6.22, and just himem. Pretty sure I disabled smartdrive, but I can't remember for sure. I suspect emm386 won't make a huge difference since Windows has its own V8086 monitor, however, I haven't compared with it on/off.

Reply 29 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've made a common log format log of Windows 3.0 starting on MS-DOS 5.0 with only HIMEM.SYS loaded.

https://www.dropbox.com/s/d48ig1416iv2tnc/deb … _MSDOS5.7z?dl=0

Can you see what's going wrong?
Edit: I already see differences at the first LSL executed.

Edit: Just reupdated the OS from MS-DOS 5.0 to 6.22. Also recreated a boot menu for all basic configurations I use(Base, XT, AT, Compaq. Then for AT/Compaq with(out) CD-ROM and with(out) Windows(on the second hard disk).
That should make it easier to use my own testing and configure it for all possible situations I can imagine in UniPCemu(testing across XT/AT/Compaq with any combination of possible CD-ROM and Windows(and base).

So now the disk images are reduced to three: Basic image for testing, Windows 3.0 disk image with some 386+ software(also buffer) and Windows 3.1 disk image. I can now freely combine the Windows 3.0/3.1 image with the Basic image(which is a sfdimg disk image to make it less large when transferring it) and test stuff accordingly.

Edit: The log redone with a MS-DOS 6.22 with himem.sys only loaded through a three-step boot menu(Basic XT/AT/Compaq system > Windows 3.0 > Windows 3.0 on AT (which loads only basic settings(keyboard modified to be /k for california games and other software that might need it) and HIMEM.SYS).

https://www.dropbox.com/s/7kyjl5i4187e1zo/deb … DOS6.22.7z?dl=0

Edit: OK, Windows 3.1 in Standard mode(only HIMEM&6.22) returns to the MS-DOS prompt with the messages about ALT-TAB and exit, then gives a very unresponsive MS-DOS prompt? Only a few keys sometimes give output? Most keypresses(or scancodes) are lost?
Edit: Windows 3.1 programs that are installed with the OS itself seems to run fine. Added Sound Blaster 1.0(actually 2.0) using the control panel and played some .wav files using the media player. No problems there. So maybe a problem that got something to do with it returning to real mode somehow? 386 enhanced mode crashes, but later than before (with the ARPL bugfix), about 2-3 seconds into booting.

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

Reply 30 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Recording from a Sound Blaster 1.0 using the recorder application in Windows 3.0 triple faults the 80386 CPU(IRQ5, base 220h)? I see it triggering a BOUND exception at a certain point, as well as reading the Parallel port status register(Port 179)? I also see it executing from segment F000 in protected mode, which sounds a bit alarming?

Last edited by superfury on 2018-08-24, 07:54. Edited 1 time in total.

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

Reply 31 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmmm.... Maybe I could take the logs in the common format, then use diff -u -I"someregexhere" yourlog mylog to simply exclude any data from the diff that doesn't matter directly(several registers, especially EAX-EDX, ESI, EDI and CR0), then use that to diff a filtered version of the logs to find where execution flow and/or EBP/ESP diverge? Would that help finding the bugs in my emulator(taking into account that all ignored registers are CPU-specific)?

Edit: Yay:/ diff straight up fails in 32-bit windows mode due to file size(5GB). 64-bit I cannot find. kdiff seems to hog memory and grind windows to hang(requiring hard reset button on the case to reboot and become responsive again). Keyboard hangs as well with kdiff.

Anyone knows a non-resourcehungry diff for 4GB+ text files?

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

Reply 32 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Continuing on from the test386.asm thread installing Windows 95...

658-Ready to reboot.jpg
Filename
658-Ready to reboot.jpg
File size
107.68 KiB
Views
1885 views
File comment
Finally, after an all-nighter(more than 12 hours), reboot ready!
File license
Fair use/fair dealing exception

Backed up the hard disk image when rebooting.

661-Preparing the first session.jpg
Filename
661-Preparing the first session.jpg
File size
45.91 KiB
Views
1885 views
File comment
Preparing the first session.
File license
Fair use/fair dealing exception

Edit: Unfortunately, the first reboot failed. It's executing a ADD DL,CH(opcode 5) IRET in an infinite loop?
Edit: It's triggering a breakpoint interrupt(INT1) in an infinite loop?

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

Reply 33 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just looked at the debugger interrupt call. The breakpoint(INT1) puses CS, EIP and EFLAGS on the stack, but when retrieving it when returning, the resulting data at said memory locations is somehow 0xFFFF for all of them?

Edit: I see it pushing the EFLAGS at memory location E91F7, which is unmapped RAM(the lowest memory hole)?

Just verified the reboot disk image in Dosbox. Windows 95 is booting correctly in there, so there's still a software bug in UniPCemu that's somehow using an invalid stack.
It has updated the configuration(after which Dosbox boots the GUI, while UniPCemu crashes).

Dosbox eventually crashes loading explorer.exe?

Edit: Placing a breakpoint at invalid memory accesses, I see Windows 95 trying to access SS(DBDB):48D2, which is an invalid memory access. It's an ADD(007BE9) instruction at 001E:01D1(real mode). I seem to slightly remember 7B being a segment value used in some of the Windows 3.X code. Maybe the previous instruction was incorrectly decoded?
Edit: I think said 1E segment is already a strange thing. That would resolve to memory location 1E0, which is the location of interrupt 78h?
Edit: After that, I even see it trying to execute(into #UD) opcode 0FCD, which is a 80486+ BSWAP BP instruction?

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

Reply 34 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Segment selector 1E is privilege level 2 LDT index 3? Maybe protected mode(CR0.PM without V86) is missing for an unknown reason?

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

Reply 35 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Even with the latest bugfixes on the 80386 CPU, it still jumps to segment 1E(using the FF opcode to jump there using a far jump) and eventually seems to hang on a 0FCD opcode(which is a 80486+ opcode)?

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

Reply 36 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've decided to start again from scratch on the Windows 95 disk, completely reformatting it(in Bochs and Dosbox-compatible C/H/S format) using the Windows 95 boot floppy.

Perhaps the latest bugfixes will fix the problem that was in there(maybe even a bug in the MS-DOS 7.X executable files).

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

Reply 37 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

With the latest fixes and reboot flushing it's caches properly(by smartdrv), it now ends up at an #UD FE11 opcode at 001E:02AE?

Edit: Just tested the disk image out in Bochs 2.6.9. It continues on and runs fine. So there's a problem with UniPCemu's CPU emulation in that regard?

Edit: Just ran Bochs with a breakpoint at that location. It doesn't trigger, so it's never supposed to be there. So there's definitely some kind of jumping error there.

Edit: Having improved the SBB flags to be more accurate, it now throws a #UD at 206A:12C0?

It's opcode 0FA6?

I see 206A being loaded for the first time using a RETF at 00CD:1041. It's returning to 206A:1707.
Edit: Bochs reaches said point too. Now let's compare memory logs...

After that, in UniPCemu, I see an interrupt being triggered to 206A:12E0.
Edit: Then it's trying to execute 0FCD on a 80386 0000:0001(last opcode at 0000:0000?), which shouldn't be executed?
Edit: It's once again trying to use the SS value in the C000-F000 range, thus pushing interrupt data into unmapped memory:S

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

Reply 38 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

After having fixed the (I)MUL flags(logic flags without CF/OF specifics added to 0F and 6X opcode IMUL instructions) according to Bochs, limit checks added on IRET&RETF instructions, BSR/BSF flags(same as all other logic instructions) and LMSW only setting the low 4 bits of CR0, the Windows 95 setup no longer throws the 0FCD #UD fault, but only throws the FEFF instruction fault?

So the 0FCD opcode is now fixed, but the FEFF instruction is still executed(which is an invalid instruction no matter what processor)?

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

Reply 39 of 46, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried Windows 3.0 in standard mode with all those latest bugfixes applied, but I notice that the entry point in Windows 3.0 protected mode is at 0837:09B6 instead?

Edit: Having adjusted the logging, I now get this as a full log in common log format without memory transactions etc.:
https://www.dropbox.com/s/2mom9c0gmny4vf3/deb … Sprompt.7z?dl=0

The main issue with the logs is that they're too huge to even process using any diff tool I know of(at least the MinGW and related diff tools all run out of memory with it).

Edit: The latest log was made using a Compaq Deskpro 386 emulation(UniPCemu) with 8MB RAM. It used the rev J ROMs for the machine, combined with the latest XT-IDE AT BIOS from the official website and IBM VGA ROM running MS-DOS 6.22 with only HIMEM from the Windows installation loaded(through a 3-step boot menu). Advanced logging is disabled(so no memory I/O is logged).

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