Jo22 wrote on 2025-02-05, 05:34:

PM sent.

Thanks! I've seen your PM but I can't reply.

I figured maybe I could just "fix" the mouse problem more easily by switching to VGA -- but unfortunately, no dice. The mouse cursor is still invisible but functional:

So it looks like I'm going to have to painstakingly compare the entire execution by hand with one of the emulators Jo22 mentioned.

xsaveopt wrote on 2025-02-07, 23:38:

Thanks! I've seen your PM but I can't reply. […]
Show full quote

Jo22 wrote on 2025-02-05, 05:34:

PM sent.

Thanks! I've seen your PM but I can't reply.

---

I figured maybe I could just "fix" the mouse problem more easily by switching to VGA -- but unfortunately, no dice. The mouse cursor is still invisible but functional:

The attachment win30_vga.png is no longer available

So it looks like I'm going to have to painstakingly compare the entire execution by hand with one of the emulators Jo22 mentioned.

Just a random thought but when you do an interrupt are you disabling the interrupt flag?

GloriousCow wrote on 2025-02-08, 19:05:

Just a random thought but when you do an interrupt are you disabling the interrupt flag?

Yes, I am. For interrupts from the pic as well as the int n instruction

Implementing the PIC ISR/IRR read on port 0x20 instead of just returning 0xFF fixed the mouse invisibility! 😀

If I had to make a guess, maybe Windows re-draws the mouse in the timer interrupt, but only if another timer interrupt is not already in service. So by returning 0xFF, Windows would see another interrupt in service and skip drawing the mouse.

It took a lot of debugging to figure it out, so looking back I think it would have been worth fully implementing the PIC, PIT and DMA from the start.

xsaveopt wrote on 2025-02-15, 14:30:

Implementing the PIC ISR/IRR read on port 0x20 instead of just returning 0xFF fixed the mouse invisibility! 😀

Glad it works! Congratulations on a job well done! 😃🥳

PS: What comes to mind about Windows 3.1 and mouse/keyboard support..
MS Mouse 9 driver package contains new VXDs for Windows 3.1x.
It uses 1 Byte transfer instead of 3 Byte transfer. It's mostly PS/2 port related.
A new keyboard driver is also included. Might be useful to know in the future, not sure.

Also, there's a Beta of Windows 3.1 that still runs in Real-Mode.
Might be useful for testing purposes, like for example trying out Super VGA (has drivers). I've taken a screenshot.
Also works on real hardware. I've run it on my Commodore PC10 which has a V20 processor, though.

xsaveopt wrote on 2025-02-15, 14:30:

Implementing the PIC ISR/IRR read on port 0x20 instead of just returning 0xFF fixed the mouse invisibility! :happy: […]
Show full quote

Implementing the PIC ISR/IRR read on port 0x20 instead of just returning 0xFF fixed the mouse invisibility! 😀

The attachment winmouse.png is no longer available

If I had to make a guess, maybe Windows re-draws the mouse in the timer interrupt, but only if another timer interrupt is not already in service. So by returning 0xFF, Windows would see another interrupt in service and skip drawing the mouse.

It took a lot of debugging to figure it out, so looking back I think it would have been worth fully implementing the PIC, PIT and DMA from the start.

Great job! Your theory makes a lot of sense.

Your story reminds me of some fun I had debugging an issue with my VGA card, which I wrote up here.

https://martypc.blogspot.com/2023/07/emulator … 30-and-vga.html

Remarkably similar in fact 😉

GloriousCow wrote on 2025-02-17, 01:19:

Great job! Your theory makes a lot of sense. […]
Show full quote

Great job! Your theory makes a lot of sense.

Your story reminds me of some fun I had debugging an issue with my VGA card, which I wrote up here.

https://martypc.blogspot.com/2023/07/emulator … 30-and-vga.html

Remarkably similar in fact 😉

Haha, yes that sounds very familiar!

Jo22 wrote on 2025-02-15, 15:06:

Also, there's a Beta of Windows 3.1 that still runs in Real-Mode.
Might be useful for testing purposes, like for example trying out Super VGA (has drivers). I've taken a screenshot.
Also works on real hardware. I've run it on my Commodore PC10 which has a V20 processor, though.

Thanks! I think I'll go directly for protected mode, though. The instruction set changes beyond the 386 are fairly minor, so once I have protected mode working most of the CPU implementation work will be done. And from there Windows 95, 98 and maybe even XP should all be fairly easy to get to work.

xsaveopt wrote on 2025-01-26, 22:00:

I figured I might as well go for IDE directly since I'll need it for the later Windows versions anyway. I implemented the basic XTIDE protocol today.

I would like to add XTIDE support to my emulator as well (of course).
Can you tell me what I/O port map to what IDE port?
Because I would expect 8 ports to be addressed (starting at 0x300) yet the "XUB" (xtide rom) access 0x300-0x31f.
(I'm using https://web.archive.org/web/20120321035657/ht … 91r4c-ATA-1.pdf as a reference)

xsaveopt wrote on 2025-02-23, 16:44:

Haha, yes that sounds very familiar! […]
Show full quote

GloriousCow wrote on 2025-02-17, 01:19:

Great job! Your theory makes a lot of sense. […]
Show full quote

Great job! Your theory makes a lot of sense.

Your story reminds me of some fun I had debugging an issue with my VGA card, which I wrote up here.

https://martypc.blogspot.com/2023/07/emulator … 30-and-vga.html

Remarkably similar in fact 😉

Haha, yes that sounds very familiar!

Jo22 wrote on 2025-02-15, 15:06:

Also, there's a Beta of Windows 3.1 that still runs in Real-Mode.
Might be useful for testing purposes, like for example trying out Super VGA (has drivers). I've taken a screenshot.
Also works on real hardware. I've run it on my Commodore PC10 which has a V20 processor, though.

Thanks! I think I'll go directly for protected mode, though. The instruction set changes beyond the 386 are fairly minor, so once I have protected mode working most of the CPU implementation work will be done. And from there Windows 95, 98 and maybe even XP should all be fairly easy to get to work.

95/98, maybe. XP? I've been having issues getting both 2000 and XP properly booting at all. 2000 doesn't detect the IDE HDD past CD-ROM file copy's first HDD boot (it doesn't seem to recognise any IDE drive somehow?).
XP afaik has the same problem, from what I remember.
Did a run of the baresifter boot floppy (using SYSLINUX to boot it on i440fx) on Pentium II CPU emulation, but the 0F A6 was the final instruction it logged before triple faulting somehow, so probably a 0F instruction issue present in the current commits somewhere after that before instruction length changes (not in the last release of a year ago before the CPU timing and BIU rework based on the more recent 8088 timings from GloriousCow, which was validated fully errorless). Also got issues with OS/2 warp 4's setup in GUI, where past network configuration some dll crashes called by cmd.exe apparently? It used to work properly in the last release, before the prefetch/timing changes. But I'm poking in the dark unless I know the exact instruction that (triple) faulted last.

Wrt 2000/XP, this is what happened on UniPCemu trying to "Starting Windows 2000..." as the setup calls it in it's status bar after loading all drivers: Windows 2000 setup i440fx boot issues?

Perhaps it's doing something undocumented on the ATAPI drive?

folkert wrote on 2025-02-23, 21:47:

I would like to add XTIDE support to my emulator as well (of course). Can you tell me what I/O port map to what IDE port? Becaus […]
Show full quote

xsaveopt wrote on 2025-01-26, 22:00:

I figured I might as well go for IDE directly since I'll need it for the later Windows versions anyway. I implemented the basic XTIDE protocol today.

I would like to add XTIDE support to my emulator as well (of course).
Can you tell me what I/O port map to what IDE port?
Because I would expect 8 ports to be addressed (starting at 0x300) yet the "XUB" (xtide rom) access 0x300-0x31f.
(I'm using https://web.archive.org/web/20120321035657/ht … 91r4c-ATA-1.pdf as a reference)

Found that it is just the IDE port number shifted 1 to the left 😀

folkert wrote on 2025-02-23, 21:47:

I would like to add XTIDE support to my emulator as well (of course). Can you tell me what I/O port map to what IDE port? Becaus […]
Show full quote

I would like to add XTIDE support to my emulator as well (of course).
Can you tell me what I/O port map to what IDE port?
Because I would expect 8 ports to be addressed (starting at 0x300) yet the "XUB" (xtide rom) access 0x300-0x31f.
(I'm using https://web.archive.org/web/20120321035657/ht … 91r4c-ATA-1.pdf as a reference)

This is the specification I implemented: http://www.freedoors.org/idework/specs/8038-r01.pdf

superfury wrote on 2025-02-23, 22:14:

95/98, maybe. XP? I've been having issues getting both 2000 and XP properly booting at all. 2000 doesn't detect the IDE HDD past […]
Show full quote

95/98, maybe. XP? I've been having issues getting both 2000 and XP properly booting at all. 2000 doesn't detect the IDE HDD past CD-ROM file copy's first HDD boot (it doesn't seem to recognise any IDE drive somehow?).
XP afaik has the same problem, from what I remember.
Did a run of the baresifter boot floppy (using SYSLINUX to boot it on i440fx) on Pentium II CPU emulation, but the 0F A6 was the final instruction it logged before triple faulting somehow, so probably a 0F instruction issue present in the current commits somewhere after that before instruction length changes (not in the last release of a year ago before the CPU timing and BIU rework based on the more recent 8088 timings from GloriousCow, which was validated fully errorless). Also got issues with OS/2 warp 4's setup in GUI, where past network configuration some dll crashes called by cmd.exe apparently? It used to work properly in the last release, before the prefetch/timing changes. But I'm poking in the dark unless I know the exact instruction that (triple) faulted last.

Wrt 2000/XP, this is what happened on UniPCemu trying to "Starting Windows 2000..." as the setup calls it in it's status bar after loading all drivers: Windows 2000 setup i440fx boot issues?

Perhaps it's doing something undocumented on the ATAPI drive?

I'm using execution traces from Bochs to quickly detect bugs in my implementation. It also lets me postpone implementing hardware devices by just substituting my I/O for the correct I/O from the trace. I'm almost able to fully boot Windows 98 this way. Bochs also supports Windows XP, so I'm confident I'll be able to get it to work. I'll let you know if I find anything undocumented when I get to XP!

xsaveopt wrote on 2025-02-26, 21:49:

This is the specification I implemented: http://www.freedoors.org/idework/specs/8038-r01.pdf […]
Show full quote

folkert wrote on 2025-02-23, 21:47:

I would like to add XTIDE support to my emulator as well (of course). Can you tell me what I/O port map to what IDE port? Becaus […]
Show full quote

I would like to add XTIDE support to my emulator as well (of course).
Can you tell me what I/O port map to what IDE port?
Because I would expect 8 ports to be addressed (starting at 0x300) yet the "XUB" (xtide rom) access 0x300-0x31f.
(I'm using https://web.archive.org/web/20120321035657/ht … 91r4c-ATA-1.pdf as a reference)

This is the specification I implemented: http://www.freedoors.org/idework/specs/8038-r01.pdf

superfury wrote on 2025-02-23, 22:14:

95/98, maybe. XP? I've been having issues getting both 2000 and XP properly booting at all. 2000 doesn't detect the IDE HDD past […]
Show full quote

95/98, maybe. XP? I've been having issues getting both 2000 and XP properly booting at all. 2000 doesn't detect the IDE HDD past CD-ROM file copy's first HDD boot (it doesn't seem to recognise any IDE drive somehow?).
XP afaik has the same problem, from what I remember.
Did a run of the baresifter boot floppy (using SYSLINUX to boot it on i440fx) on Pentium II CPU emulation, but the 0F A6 was the final instruction it logged before triple faulting somehow, so probably a 0F instruction issue present in the current commits somewhere after that before instruction length changes (not in the last release of a year ago before the CPU timing and BIU rework based on the more recent 8088 timings from GloriousCow, which was validated fully errorless). Also got issues with OS/2 warp 4's setup in GUI, where past network configuration some dll crashes called by cmd.exe apparently? It used to work properly in the last release, before the prefetch/timing changes. But I'm poking in the dark unless I know the exact instruction that (triple) faulted last.

Wrt 2000/XP, this is what happened on UniPCemu trying to "Starting Windows 2000..." as the setup calls it in it's status bar after loading all drivers: Windows 2000 setup i440fx boot issues?

Perhaps it's doing something undocumented on the ATAPI drive?

I'm using execution traces from Bochs to quickly detect bugs in my implementation. It also lets me postpone implementing hardware devices by just substituting my I/O for the correct I/O from the trace. I'm almost able to fully boot Windows 98 this way. Bochs also supports Windows XP, so I'm confident I'll be able to get it to work. I'll let you know if I find anything undocumented when I get to XP!

The weird thing is that no matter if I use the onboard or seperate card, the same issue occurs.
And NT 4.0 and 9x boot properly in all ways I tested (both from installation CD-ROM and from hard disk after the first file copy and when booting fully). Although I didn't test other than 9x since the last CPU bugs were introduced (95 runs properly at least, somehow Sandsifter (actually running Baresifter from a LILO bootable floppy) crashes at 0F A6 instruction (or just beyond that, A6 is the last thing logged at least before it reboots or triple faults).

Does anyone see what I'm doing wrong here?

The 256-color Windows 98 splash screen displays correctly, but then Windows switches back to 16-color mode and all the colors are wrong. I'm just taking 1 bit from each plane to form a 4-bit index into the DAC. Is that not what I'm supposed to do?

Edit: Apparently I was supposed to initialize the attribute registers' internal palette with [0x0, 0xC, 0xA, 0xE, 0x1, 0x15, 0x23, 0x7, 0xF, 0x24, 0x12, 0x36, 0x9, 0x2d, 0x1b, 0x3f]. I can't even find these numbers in Bochs' source code, so I have no idea where they come from...

https://wuffs.org/blog/windows-3x-graphics

That might give you some pointers or at least background knowledge

You don't need to initialize anything on a VGA card? My emulator starts the emulation with all those registers cleared and the OS (or BIOS) writes those values itself. Actually, that's at least the case with most (S)VGA registers as I remember, unless documented.

Perhaps look at the ET4000 chipsets, I think they mention the default values if there are any, but I think they're all zeroed or undefined.

Also maybe look at my EGA vs VGA differences thread: All the exact differences in programming interface for EGA vs VGA?
Perhaps it offers some insights into what's going wrong in your case.
Edit: Also fixed the Sandsifter crashing after 0F A6. The 0F AA (RSM) instruction wasn't terminating the #UD properly, starting to process the first steps of the RSM instructions (and aborting only after doing that). So in IPS clocking mode, that's stuff like locking the bus, loading the SMRAM values into a cache, loading all state from it (which is incorrect when not in SMM), validating CR0/CR4 (shutdown if incorrect), and performing a shutdown if the data in the memory tells it to (byte 7F23 set to non-zero).
So it's either loading incorrect state, or it's actually shutting down the CPU (thus the CPU reset vector I observed in the middle of shifting).

superfury wrote on 2025-03-01, 11:23:

You don't need to initialize anything on a VGA card? My emulator starts the emulation with all those registers cleared and the OS (or BIOS) writes those values itself. Actually, that's at least the case with most (S)VGA registers as I remember, unless documented.

I had missed the part where attribute register writes also go through 0x3c0 instead of 0x3c1. After fixing that the colors are all correct! (without any special initialization)

superfury wrote on 2025-03-01, 11:23:

Edit: Also fixed the Sandsifter crashing after 0F A6. The 0F AA (RSM) instruction wasn't terminating the #UD properly, starting to process the first steps of the RSM instructions (and aborting only after doing that). So in IPS clocking mode, that's stuff like locking the bus, loading the SMRAM values into a cache, loading all state from it (which is incorrect when not in SMM), validating CR0/CR4 (shutdown if incorrect), and performing a shutdown if the data in the memory tells it to (byte 7F23 set to non-zero).
So it's either loading incorrect state, or it's actually shutting down the CPU (thus the CPU reset vector I observed in the middle of shifting).

Nice, congrats!

I worked a bit on XP, and I encountered PAE, PSE, and IDE/ATA feature 0x03 (which enables DMA). Nothing undocumented so far.

^An i486 compatible Windows XP is now available.
Someone got xp sp3 running on a 486

Jo22 wrote on 2025-03-05, 19:28:

^An i486 compatible Windows XP is now available.
Someone got xp sp3 running on a 486

Got that instruction implemented (on Pentium and up), but it still crashes when starting "Starting Windows 2000..." (or XP at the same booting point), as the driver loading screen names it (after loading all drivers from the CD-ROM). So that can't be it?
It talks a bit to the hard drive controller from what I remember, then crashes with the 0x7B BSOD.

Right now running Baresifter (a Sandsifter on bare metal, modified by me to only test the 66h/67h prefixes, with up to 2 prefixes (so it's actually testing no prefix, 66h only, 67h only and 66h&67h combined)) on my emulator, churning away at opcode:

162:50:51:58.05536: EXC 0E OK | 66 32 14 95 00 00 00 00

And yes, you read that correctly, it's roughly running 62 hours right now (at roughly 11% of 3MIPS (11% being how much it can process in 1 second of system time (of the OS it's running on, gotten from gettimeofday and equivalent OS functions, calculated using the emulated time each second combined with the time passed from the OS)) configured speed, so it's running at 330KIPS speed roughly in realtime emulated speed (including any hardware, which is mainly video card clocks and RAM I/O according to profiling)).

xsaveopt wrote on 2025-03-05, 19:07:

I had missed the part where attribute register writes also go through 0x3c0 instead of 0x3c1. After fixing that the colors are a […]
Show full quote

superfury wrote on 2025-03-01, 11:23:

You don't need to initialize anything on a VGA card? My emulator starts the emulation with all those registers cleared and the OS (or BIOS) writes those values itself. Actually, that's at least the case with most (S)VGA registers as I remember, unless documented.

I had missed the part where attribute register writes also go through 0x3c0 instead of 0x3c1. After fixing that the colors are all correct! (without any special initialization)

superfury wrote on 2025-03-01, 11:23:

Edit: Also fixed the Sandsifter crashing after 0F A6. The 0F AA (RSM) instruction wasn't terminating the #UD properly, starting to process the first steps of the RSM instructions (and aborting only after doing that). So in IPS clocking mode, that's stuff like locking the bus, loading the SMRAM values into a cache, loading all state from it (which is incorrect when not in SMM), validating CR0/CR4 (shutdown if incorrect), and performing a shutdown if the data in the memory tells it to (byte 7F23 set to non-zero).
So it's either loading incorrect state, or it's actually shutting down the CPU (thus the CPU reset vector I observed in the middle of shifting).

Nice, congrats!

I worked a bit on XP, and I encountered PAE, PSE, and IDE/ATA feature 0x03 (which enables DMA). Nothing undocumented so far.

With Undocumented, I mean odd register behaviour, interrupts or timing stuff. Afaik 2000/XP are quite picky about too fast controller speed apparently, for example. Idk if that's the cause in my case though. I hope not, as that would defy standards afaik.

Ran Baresifter again, with only none, 66h and 67h prefixes (one of those three, not 66h&67h at the same time). After some 100 hours running it didn't report anything weird in the Baresifter analyzer (after stripping UniPCemu's log timing timestamps from the logs ofc). All that it finds are the other prefixes and missing 66h+67h pregix combinations (even though I selected operand and address size prefixes only and 2 prefixes in the program parameters (adjusted source code for that is in my github repo: https://github.com/superfury/baresifter, also https://github.com/blitz/baresifter/pull/5 with more info about it)). Might be nice in your case too, as I've lowered it's minimum reqs to support 386-Pentium. Logging using port E9 hack (Bochs/qemu/UniPCemu) requires bit 31 of ECX of CPUID leaf 1 (hypervisor) to be set.

I did try NT 4.o workstation just now, verified to still be booting and operating at least. I can reach the desktop and shut it down. I have an older install of Jazz Jackrabbit 2 on it, but when (in windowed mode, which is automatic) it reaches the 2nd cutscene (after the grayish/white(?) on black first cutscene if the objects moving into each other) it gets an Acccess Violation error reading address 00000004 after fading to black, perhaps followed by a black frame in the window. It then crashes, which after a button click starts Doctor Watson for Windows NT, hopefully pressing OK logs some useful information (it displayed Jazz.exe and the address above it I think)? It's either dumped it after that, or still busy doing so rn. The DR Watson dialog disappeared after I clicked OK at least. No file on the desktop from what I see. Or do I need to configure DR Watson for it first?