VOGONS


Reply 60 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Well, the display is even higher than that atm. It's at 800x600x64K colors(the emulated ET4000 in it's maximum color depth setting).

It's still strange that Windows triple faults on it's own stack. Is that a CPU bug, or is that common behaviour for win32s or the Windows for Workgroups 3.11 kernel?

Edit: Just found a slight 'bug' in the far call instructions, as well as GRP5 push and call instructions, in that they were checking for the pushing on the stack after it was already read during a previous part of the instruction. Thus it might have been causing a bit of instability on the paging side of things(due to having checked and went through some paging accesses, before checking the stack to be valid(which is supposed to happen between the segmentation and paging checks, but was done after the paging checks(and memory reads) of the instruction, thus marking pages as used when actually supposed to be faulting before that).

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

Reply 61 of 591, by keenmaster486

User metadata
Rank l33t
Rank
l33t

Like I said, this sort of thing is unstable even on real hardware in "ideal" circumstances.

The Titanic game requires your resolution to be set to 640x480 at 256 colors; it will refuse to run at any other display setting.

World's foremost 486 enjoyer.

Reply 62 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

The game I'm trying(Pink Panther in Hocus Pocus Pink) is running using win32s afaik. Could it be that what's crashing the Windows 3.11 environment(triple fault) is actually the win32s drivers themselves? Or is that just a bug in my CPU emulation?

Edit: Just tried Windows 3.1 in 386 enhanced mode. It seems to properly boot, but running the MS-DOS prompt gives a black screen(running fine in 3.11)?
Edit: Windows 3.0 only runs in real mode and standard mode. 386 enhanced mode of 3.0 seems to weirdly return to the MS-DOS prompt(not reloading command.com)? Any idea what might be the cause? swapfile.exe seems to keep saying(within real mode windows 3.0) that the MS-DOS version is unsupported(I'm using 6.22)?

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

Reply 64 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Trying it with Windows 98 (which was copied to c: by a sys command) results in WIndows complaining about it:

You started your computer with a version of MS-DOS incompatible with this version of Windows. Insert a Startup diskette matching […]
Show full quote

You started your computer with a version of MS-DOS incompatible with this
version of Windows. Insert a Startup diskette matching this version of
Windows and then restart.

The system has been halted. Press Ctrl+Alt+Del to restart your computer.

That is what happens with my older Windows 98 boot disk(installed to C: using the "sys c:" command).

One strange thing I still notice is that Ctrl+Alt+Del isn't applied to a reboot until it's seen it typed twice? Is that normal behaviour(happens in all versions of MS-DOS and Windows)?

Edit: Just tried Debian again from a freshly installed Windows 98 MS-DOS installation(MS-DOS 7.1). It still tries to execute a near RET(opcode C3) to user space from kernel mode, which causes a #GP(0) fault due to it being illegal(CS is set up with a base of C0000000 and a limit of 0x3FFFFFFF, so essentially mapping the kernel high using segmentation). So that means this happens pretty early in the boot part, doesn't it(as linux abandons segmentation for flat mode paging somewhere later on)? The value of CS is 0x10.

I'm using the files from https://hackaday.com/2011/08/12/installing-li … n-a-386-laptop/ , following said documentation up to the loadlin execution(at which point it crashes after displaying the video card information and a bit more).

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

Reply 65 of 591, by keenmaster486

User metadata
Rank l33t
Rank
l33t

You have to use the version of MS-DOS "7.1" that was modified to let Windows 3.1 install on it.

You can find it on the China DOS Union boot disk.

World's foremost 486 enjoyer.

Reply 66 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Interestingly, Linux crashes in a far return(opcode C3) to 0x79536e61, while the CS has a limit of 3FFFFFFF(the top part of the 32-bit address space). It's in kernel mode at said point.
It happens at 0010:001e3439.
That's an invalid return address. Probably something set up by code?

Edit: I've placed breakpoints on stack pushes that write the high 4 bits of the 32-bit value as value 7. I see no stack pushes that write said value, but I do see a near return using said value(popped from the stack)? So the cause isn't a stack push instruction, but instead some instruction that might be malfunctioning and writing to that location on the stack?

Edit: ESP was 00205716 before the instruction, so at 00205716(actually 00205719) is an invalid byte(or dword at the first mentioned) address? That ESP address is one of the few information that is correctly reported by the Linux fault handler on the screen.
Edit: I now see it returning to 746f6e20. Interestingly, ESP doesn't seem to be aligned to a dword address(MOD 4 == 0)?

Edit: I see a MOVSB writing said value to said location(it's a REP(or some variant of) MOVSB)? ECX has a pretty large value(in the 2MB range)?
Edit: Now something strange, a kernel Oops due to a page fault on address e0xxxxxx, which the kernel doesn't like?

Edit: It seems that said value is written by the very first REP MOVSB executed by the linux kernel while it's booting(or extracting itself into memory?)? The ECX count at the start of it is 8E0000.
Edit: That's the instruction at 0010:00001000(probably in head.S of the arch\i386\boot\compressed\head.S, row 109).
Edit: The decompression method seems to have written said value to memory at that location. So the issue might be in stack management somewhere?
Edit: After the boot.S, said memory locations aren't overwritten by ANY instructions, including 32-bit stack pushes, it seems. So is the kernel setting a custom stack pointer to return to?
Edit: Weirdly, I see ESP or EBP being loaded with the value of 2. That seems a bit odd? I see it loaded with a value of 3 afterwards, then normal values again? Then I see a value of 1D and then 4. Those are quite strange (if not disturbing) values for EBP(and maybe even ESP, since they're used together)? That happens at EIP 8160ED. I see 20710a (or was it 21710a) being loaded, just before the fault being raised?

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

Reply 67 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

One interesting thing to report now: after improving 16-bit pushes to write 16-bits to memory or 32-bits when the operand size is 32-bits(zero-extending), I now see Windows 3.0a throwing a Page fault on address A0000. So that means the primary loading of the kernel is succeeding and it's progressing to graphics mode?

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

Reply 68 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Anyone knows what effect the operand size has on 16-bit segment register push operations? Are they pushed zero-extended to 32-bits?

Also, what effect does the gate descriptor size(16-bit vs 32-bit gate, so bit 3 of the Access Rights byte of the IDT entry) within an IDT have on interruots from V86-mode tasks? Are all pushes still 32-bits (DS,ES,FS,GS,SS)? It will at least have effect on the resulting EIP, but does it have any effect besides that? What about the D-bit within it's protected-mode code segment such an interrupt results in having?

When thinking about the data segments pushed on the stack, what about IRET(D)? Will those data segment popping always be 32-bit stack pops?

Edit: Also, I notice with my patching all 32-bit segment selector pushes(e.g. push fs) to write 32-bits(zero-extended), many MS-DOS applications(except command.com, california games, Ultima II and mem.exe as far as I saw) within the WFW 3.11 command prompt seem to crash(with Windows reporting the VM as becoming unstable and please reboot the computer). That crash even happened to edit.com? Oddly, even Alley cat crashes in the MS-DOS prompt now(was working earlier before the fix)?

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

Reply 69 of 591, by Stenzek

User metadata
Rank Newbie
Rank
Newbie
superfury wrote:

Anyone knows what effect the operand size has on 16-bit segment register push operations? Are they pushed zero-extended to 32-bits?

In my emulator: push segreg -> 16-bit, write 2 bytes, 32-bit, write 4 bytes, sign-extended. Bochs writes 2 of the 4 bytes, but decrements (E)SP by 4.

Wrote a quick test, it looks like bochs is correct, the upper 2 bytes are not written to on a Broadwell CPU. Can't say for the 386, don't have access to one. So, 32-bit push segreg -> write 2 bytes to [ESP-4], decrement ESP by 4.

Last edited by Stenzek on 2019-05-06, 02:56. Edited 1 time in total.

Reply 70 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

And what effect does the interrupt descriptor size(16 vs 32-bit) have on pushes on the stack during an interrupt or fault from V86 mode? Is it always only pushing 32-bit entries on the stack(for the segments, SS, ESP, EFLAGS, CS and EIP), only affecting the masking of EIP to load 16-bits of IP data into EIP(clearing upper bits)? Or does it have other affects as well?

None of any documentation I can find says anything about it, except the 80386 one, which says the segments are pushed as 16/32-bit, depending on the IDT entry size(bit 3 of it's access rights byte)? Or is it always 32-bit pushes for all of them, ignoring said setting(for compatibility with IRETD, as a 16-bit IRET can't return properly)?

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

Reply 72 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Doesn't that cause troubles when using IRETD to return to the V86 task? Since IRETD always pops DWORDS?

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

Reply 73 of 591, by Stenzek

User metadata
Rank Newbie
Rank
Newbie
superfury wrote:

Doesn't that cause troubles when using IRETD to return to the V86 task? Since IRETD always pops DWORDS?

I'd think an os which used 16-bit gates would use iret, and if it used 32-bit gates, iretd.

edit: FWIW, Win95 seems to use 32-bit gates and IRETD.

Reply 74 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Well, I see that emm386(either windows 3.x or MS-DOS 6.22's or both) seems to use a 16-bit IDT gate. But that doesn't combine with IRETD if it pushes 16-bits entries(as IRET would pop FLAGS instead of EFLAGS, setting EFLAGS.VM incorrectly)?

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

Reply 75 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried to install Internet Explorer 5.0 (5.0.0913.2200) for Windows 3.x on WFW 3.11. It seems to succeed at part of the full installation(the very first one), but once it gets to the Internet Explorer installation step(the second step of of 6), I see the rest of the steps failing with red X'es, then a window pops up telling me that setup didn't/couldn't complete? Does that mean some 16-bit error?

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

Reply 76 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Will 16-bit gates affect stack pushes to become 16-bit at all? If EFLAGS is pushed as 16-bits, VM won't be restored properly during IRET? Since 16-bit pushes during INT require 16-bits pops during IRET, but EFLAGS.VM is truncated off, so that can't work? How does your emulator handle that? Force 32-bit pushes for V86 PL0 task to 16-bit interrupt/trap gate? Or do you do something undocumented on 16-bit IRET, or on IRETD?

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

Reply 77 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Looking at your emulator, I see x86 interrupts from V86 mode to 16-bit interrupt/trap gate actually pushing words instead of dwords? But IRET doesn't do anything that reverses said behaviour, only IRETD does(properly handling like a 32-bit interrupt return to V86 mode)?

Or is the OS supposed to patch up the stack before executing IRETD in that case(extending to 32-bits and setting EFLAGS.VM to 1), before returning from the 16-bit handler?

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

Reply 78 of 591, by Stenzek

User metadata
Rank Newbie
Rank
Newbie

Are you sure that emm386 uses 16-bit interrupt gates? Using the emm386.exe provided with WFW 3.11, for the DOS interrupts at least, I'm seeing an invalid (type 0) descriptor, which results in a #GPF, which is a 32-bit interrupt gate. External interrupts (e.g. IRQ0) are a direct 32-bit gate.

edit: if we presumed there was a mismatch here, the V86 monitor is going to pop the parameters from the stack anyway because it has to know why there was an exit, so pushing them again as dwords is plausable.

Reply 79 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found and fixed a 80(1)86-specific bug, which caused the GRP5 PUSH r/m16 to push the old SP value(like a 80286+ CPU) instead of it's correct 8086 behaviour(pusing the SP value after it has been decremented by 2). Although that doesn't affect 80386+ emulation(because it's a 80(1)8X-specific behaviour).

I don't see the 16-bit IDT being used anymore in V86-context. So far tested WFW3.11 and MS-DOS 6.22's EMM386 drivers. Perhaps a Windows 3.1 or 3.0-specific bug(or maybe even JEMM386, which I used before that for testing(as EMM386 all crashed back then)). Or maybe a now fixed CPU bug?

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