Hi! Always happy to see another PC emulator!

The CPU is difficult in proportion to how accurate you want it to be. I have a set of 8088 and V20 CPU tests you might find useful in validating your CPU implementation, assuming you start with basic real mode: https://github.com/SingleStepTests/8088

Reimplementing the BIOS is a lot of extra work - I'd suggest just using ROMs and then you have the real thing. There's an excellent open source clean room implementation of the PC BIOS called GlaBIOS you can use. https://glabios.org/

You're going to need the PIT, *both* PICs for an AT, both DMA controllers, a floppy and hard disk controller. For the PC you'll need the PPI, for AT you will need the keyboard controller, and the quirks that are routed through it like the a20 gate. If you want a mouse you'll need a serial UART of some sort, or you can do the PS/2 ports like you said. As for video you can start with a basic VGA and expand to some well-known SVGA card as you go. You don't even need a full CRTC implementation; I got windows 3.0 working just drawing video memory basically, although you will need the basic graphics controller pipeline. It's not the worst thing in the world. Just don't forget to make your VGA registers writable *cough*.

You could probably get Windows 3.0 to run without DMA - maybe if you implemented an XTIDE instead of a DMA-based disk controller. You'd need a floppy bios capable of PIO mode or your own routines.

Maybe superfury can weigh in on what hardware is required for Windows 95. I haven't gotten that far, myself.

GloriousCow wrote on 2025-01-21, 16:53:

The CPU is difficult in proportion to how accurate you want it to be. I have a set of 8088 and V20 CPU tests you might find useful in validating your CPU implementation, assuming you start with basic real mode: https://github.com/SingleStepTests/8088

I had already found these 😀 Thank you for generating them! They were very useful for debugging my implementation.

I'll happily admit that I don't care much for cycle accuracy or UB, which does indeed make the implementation less difficult.

GloriousCow wrote on 2025-01-21, 16:53:

Reimplementing the BIOS is a lot of extra work - I'd suggest just using ROMs and then you have the real thing. There's an excellent open source clean room implementation of the PC BIOS called GlaBIOS you can use. https://glabios.org/

So far, I have been using the 8086tiny BIOS from here: https://github.com/adriancable/8086tiny . With it, I can boot DOS 5.00 to the initial setup screen (it might run further, but it requires me to press enter which I cannot do without a working keyboard...). Unfortunately the BIOS outputs escape sequences, which makes it a real pain to render the output if you are not directly printing to a terminal. And it also doesn't support the video modes needed to run Windows.

With regards to GlaBIOS -- and please forgive my ignorance here -- it seems to require a Video BIOS option ROM. While I think I understand what that is, it still seems like quite a daunting task to write one from scratch. Are there any existing ones that you would recommend using?

GloriousCow wrote on 2025-01-21, 16:53:

You're going to need the PIT, *both* PICs for an AT, both DMA controllers, a floppy and hard disk controller. For the PC you'll need the PPI, for AT you will need the keyboard controller, and the quirks that are routed through it like the a20 gate. If you want a mouse you'll need a serial UART of some sort, or you can do the PS/2 ports like you said. As for video you can start with a basic VGA and expand to some well-known SVGA card as you go. You don't even need a full CRTC implementation; I got windows 3.0 working just drawing video memory basically, although you will need the basic graphics controller pipeline. It's not the worst thing in the world. Just don't forget to make your VGA registers writable *cough*.

You could probably get Windows 3.0 to run without DMA - maybe if you implemented an XTIDE instead of a DMA-based disk controller. You'd need a floppy bios capable of PIO mode or your own routines.

Thanks!! This is a useful list!

xsaveopt wrote on 2025-01-21, 18:14:

I had already found these 😀 Thank you for generating them! They were very useful for debugging my implementation.

thrilled you found them useful. Do you have a name / repo for your emulator? I've been keeping a little list of everyone who's used them.

xsaveopt wrote on 2025-01-21, 18:14:

So far, I have been using the 8086tiny BIOS from here: https://github.com/adriancable/8086tiny . With it, I can boot DOS 5.00 to the initial setup screen (it might run further, but it requires me to press enter which I cannot do without a working keyboard...). Unfortunately the BIOS outputs escape sequences, which makes it a real pain to render the output if you are not directly printing to a terminal. And it also doesn't support the video modes needed to run Windows.

With regards to GlaBIOS -- and please forgive my ignorance here -- it seems to require a Video BIOS option ROM. While I think I understand what that is, it still seems like quite a daunting task to write one from scratch. Are there any existing ones that you would recommend using?

A standard PC BIOS, like GlaBIOS, will initialize a CGA or compatible card. You'll need a video BIOS for anything better than CGA/Hercules. There is an open VGA bios from Bochs that Andreas Jonsson did some work on porting to 8088, you can find it here: https://github.com/andreas-jonsson/virtualxt/ … ios/vgabios.bin

Basic hooks to change resolution might be sufficient to run a lot of stuff, but there are a considerable number of convenience functions in the extended BIOS int10h interface and occasionally stuff will use it. To me, it just seems simpler to use a BIOS and know that all that testing has been done for you. The only downside is sometimes there are extensive hardware checkouts in the BIOS bootup code that you have to pass or otherwise hack your way around. If you get stuck i can offer advice.

xsaveopt wrote on 2025-01-19, 10:45:

Hi!
I'm building an emulator, and I have come to realize that emulating the CPU is not actually the difficult part. Up to Windows 3.1 you just need to do real mode, and for everything up to at least XP you can get away with protected mode and maybe x87.

Hi there, as for Windows 3 I recommend checking out sources of OTVDM/WineVDM and Win3mu.

https://github.com/otya128/winevdm
Win3mu Soon OpenSource

For Windows 3.x, I would choose an 80286 as the bare minimum.

Emulating at least 4 MB of RAM, the HMA and 64KB or more free RAM in the UMA region might be recommended.

Windows 3 also wants memory that's contiguous, so a higher memory expansion is not a bad idea per se.
It helps against memory fragmention caused by applications, which slows Windows 3 down.

If support for Windows 3.0 in Real-Mode is a thing,
then emulation of a LIM 4 or EEMS compatible EMS board should be provided.
(It support Small-Frame and Large-Frame type; 64KB and 256KB page frame AFAIK).

EMS for Real-Mode Windows is no luxuray, I think.
Windows 2 and 3 are so big that little conventional memory will be left to Windows applications.

That being said, many Windows 3 applications available in the wild need the Protected-Mode kernals (krnl286.exe, krnl386.exe).
Applications like Visual Basic, Turbo Pascal for Windows, Quick C for Windows etc. won't run in Real-Mode.

Also, many of the early professional Windiws 3.0 applications were made using Win386 extender by Watcom (FoxPro, SQLWindows etc. I think).
It requires an 80386 and has its own 32-bit version of Win16 API - it's very interesting. OpenWatcom still has Win386 support.

So all in all, a good old 386 might be the practical real-world minimum to fully support Windows 3.x with all its features.
Things like WinG, SVGA drivers/DCI, Win32s, WinMem32, virtual memory etc.

Speaking under correction, though, since I'm just a layman and no emulator writer.

Good luck, though! 😃🤞
Jo22

PS: Better avoid emulating PS/2 mice and use serial or bus mouse etc.
The combined PS/2 keyboard+mouse VXD of Windows 3.x in 386 Enhanced Mode is quite complex.
Also, serial mouse is less likely to be "jumpy".

Edit: I forgot, there were patches for Windows 3.0 by intel for the Inboard 386.
That's an 386 accelerator board for IBM PCs.
Anyway, the thing is that these patches make Windows 3.0 run in 386 Enhanced Mode on an XT architecture (one DMA controller, one IRQ controller).
The patched DLLs can also be injected into Windows 3.1, I read.
So Windows 3.1 (Enhanced Mode) can be run in an XT environment.

Edit: I recommend emulating the AT&T/Olivetti extension to CGA, if CGA is being chosen.
It can do 640x400 mono and is a simple, logical extension to 640x200 hi-res mono mode.

Windows 2 and 3 do ship with the Olivetti/AT&T driver and by using it will look much better than in ordinary 640x200 pixel resolution.
Also, most Windows applications will need 350 lines anyway to fit on screen (same amount as Hercules and EGA had).

Just to be safe please make sure the BIOS string contains the Olivetti part, so no patching is needed.
QuickBasic applications needed a bit of patching.
Olivetti/Logabax/AT&T/Toshiba 640x400 hi-res graphics mode

Edit: Please have a look at how pretty Windows 3 can be in 640x400 mono (we're not affiliated):
https://www.retrospace.net/infoseiten/readm.php?id=125

GloriousCow wrote on 2025-01-21, 18:35:

thrilled you found them useful. Do you have a name / repo for your emulator? I've been keeping a little list of everyone who's used them.

Oh right now I'm nowhere near anything that I would even consider releasing. But I'll let you know if I ever end up publishing (and naming) it.

GloriousCow wrote on 2025-01-21, 18:35:

A standard PC BIOS, like GlaBIOS, will initialize a CGA or compatible card. You'll need a video BIOS for anything better than CGA/Hercules. There is an open VGA bios from Bochs that Andreas Jonsson did some work on porting to 8088, you can find it here: https://github.com/andreas-jonsson/virtualxt/ … ios/vgabios.bin

Ahhh, I was reading the assembly as "if there is no option BIOS or it failed to initialize then halt" but I probably should have read it as "if there is an option BIOS and it failed to initialize then halt". Thanks for clarifying that!

Jo22 wrote on 2025-01-21, 18:40:

[...]

So all in all, a good old 386 might be the practical real-world minimum to fully support Windows 3.x with all its features.

[...]

Thanks for the rundown! As soon as I have the necessary peripherals for DOS and Windows 1-3 working, I'm definitely aiming for a 386. I'll need it anyway for Windows 95/98, so running Windows 3.x in protected mode might be a good intermediate step to make sure everything is working. Then later on I'll move to a Pentium for Windows XP.

I'm trying to work my way up to 95/98/XP as quickly as I can, so I'll leave the memory expansion for later on.

Jo22 wrote on 2025-01-21, 18:40:

PS: Better avoid emulating PS/2 mice and use serial or bus mouse etc.
The combined PS/2 keyboard+mouse VXD of Windows 3.x in 386 Enhanced Mode is quite complex.
Also, serial mouse is less likely to be "jumpy".

From what I gathered, serial mice are not well-supported in Windows XP and later versions of 98. So my thought here was that a PS/2 mouse would be easier first target.

I can now pass GLaBIOS POST 😁...

And boot into the MS-DOS setup:

Looking at the assembly of GLaBIOS it seems like it doesn't support HDDs.

Is there a common model of IDE HDD that is typically used for emulation and has an option ROM available?

For anyone who might stumble upon this topic in the future -- this is what I had to implement to get to this point:

The minimal needed to run through the entire POST (but still with keyboard and FDD errors): […]
Show full quote

The minimal needed to run through the entire POST (but still with keyboard and FDD errors):

- DMA: address registers (they don't need to do anything besides return the values you write to them)
- PIT: working registers, but ignoring the timer modes and just always decrementing by 1 works well enough
- PIC: working IMR register as well as triggering timer interrupts
- PPI: switches (correct lower 4 bits of PPI C depending on the value of the switch select bit in PPI B)

Then to POST successfully and boot MS-DOS:

- PPI (keyboard): PPI A & PPI B: working keyboard reset (interrupt with scancode 0xAA pending)
- FDD: Sense interrupt status, Specify, Recalibrate, Seek & Read commands

Good work! 😃👏

Is there a common model of IDE HDD that is typically used for emulation and has an option ROM available?

XT-IDE Universal BIOS (aka XUB) is often being mentioned.
But perhaps any int13h handler will do (for MS-DOS, which uses BIOS routines only).

Other HDD controllers can be found in PCem/86Box..
Among PC/XT users, 8-Bit SCSI controllers were popular alternatives to MFM/RLL controllers (WD1003).
They had their own option ROM, as well, but were more reliable.

Edit: Photo attached.

PS: I recall that there were two PC emulators being written in VB6 and Quick Basic.
If the terms in the supplied readmes allow it, you could borrow the int13h routines.

Jo22 wrote on 2025-01-25, 20:32:

Good work! 😃👏 […]
Show full quote

Good work! 😃👏

Is there a common model of IDE HDD that is typically used for emulation and has an option ROM available?

XT-IDE Universal BIOS (aka XUB) is often being mentioned.
But perhaps any int13h handler will do (for MS-DOS, which uses BIOS routines only).

Thanks! 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.

Everything seems to work, but I've run into a strange error when trying to install MS-DOS 5.00:

The following disk error was detected.
The listed file was not copied.

Error reading --> dosshell.vid

This error happens after switching to the second disk. It seems to continue running fine for a while but then gives this error.

Is there an interrupt or some registers I need to update after switching disks? The 8272A datasheet isn't very clear on this. Did anyone else maybe also run into this issue?

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

Thanks! 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.

You did IDE in a day? Damn.

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

This error happens after switching to the second disk. It seems to continue running fine for a while but then gives this error.

Is there an interrupt or some registers I need to update after switching disks? The 8272A datasheet isn't very clear on this. Did anyone else maybe also run into this issue?

I haven't implemented any disk change notification stuff at all, and I would doubt it is required. Most floppy code i've seen frequently resets the controller anyway because dealing with the floppy was janky and unreliable.

If you don't have some way of logging FDC commands and your response bytes I'd recommend implementing that, then you can see what operation is failing.

GloriousCow wrote on 2025-01-28, 18:28:

You did IDE in a day? Damn.

Well I just did the main bits to get the XTIDE universal bios to recognise the drive etc., it's by no means a full implementation. I'll just implement the other commands as I encounter them.

GloriousCow wrote on 2025-01-28, 18:28:

I haven't implemented any disk change notification stuff at all, and I would doubt it is required. Most floppy code i've seen frequently resets the controller anyway because dealing with the floppy was janky and unreliable.

If you don't have some way of logging FDC commands and your response bytes I'd recommend implementing that, then you can see what operation is failing.

So I did some more digging, and this probably wasn't related to IDE at all. Somehow, some memory corruption is occurring which is probably causing the error. When I open the country selection screen in the setup, the entire screen starts glitching and DOS eventually crashes. This happens without the IDE BIOS as well. So I'm now just trying to debug and fix the memory corruption that happens during boot.

I've run through all your single-step tests again, fixed a bunch of flag issues, and as far as I can tell my implementation is now fully correct modulo some undefined behavior and some 8088/8086 differences. But that didn't fix the memory corruption unfortunately.

I also compared all FDC reads with the reads MartyPC does. I didn't find anything obviously wrong, and all DMA addresses are correct as well. At some points there are some extra reads, but those might also be because DOS is loading different stuff because the simulated hardware isn't exactly identical? I'm not sure it matters much, because I can't really debug it effectively if the effects of the corruption don't show up until a few million instructions later.

Is it by any chance easy to use MartyPC as a validator? By that I mean that every time I execute an instruction, I'd have your implementation execute the same instruction on the same state and then compare outputs to make sure they are identical. I quickly searched through the code but I couldn't figure out a good hooking point.

GloriousCow wrote on 2025-01-28, 18:28:

I haven't implemented any disk change notification stuff at all, and I would doubt it is required. Most floppy code i've seen frequently resets the controller anyway because dealing with the floppy was janky and unreliable.

The PC Backup and PC Restore programs from PC Tools Deluxe of the 1980s do auto-sense a floppy disk change without user input (no key press needed).
I always found this to be really cool!

Jo22 wrote on 2025-01-28, 22:59:

The PC Backup and PC Restore programs from PC Tools Deluxe of the 1980s do auto-sense a floppy disk change without user input (no key press needed).
I always found this to be really cool!

Would be fun to figure out how they did that!

I have now verified the full boot of the MS-DOS setup against a real CPU running in virtual 8086 mode -- but I still haven't discovered the bug 🙁

So it's must be somewhere in the non-CPU code, probably the FDC/DMA as those are the only ones that write to memory.

I've made some good progress! Turns out the DMA has a verify mode where it doesn't write to memory at all, and if you don't implement that you end up overwriting random memory. After fixing that everything worked fine.

I am now able to install DOS and Windows 2 on the IDE disk and boot from it:

I'm now working on a serial mouse. I can see that Windows initializes the mouse and reads the data when INT 4 occurs, but I don't see a mouse on the screen. I've also noticed that the setup isn't copying any of the mouse*.* files to C:\WINDOWS. Did Windows 2 require extra set-up to use the mouse?

xsaveopt wrote on 2025-01-31, 23:25:

I've made some good progress! Turns out the DMA has a verify mode where it doesn't write to memory at all, and if you don't implement that you end up overwriting random memory. After fixing that everything worked fine.

Hah, yeah that would do it.

xsaveopt wrote on 2025-01-31, 23:25:

I am now able to install DOS and Windows 2 on the IDE disk and boot from it:

Nice!

xsaveopt wrote on 2025-01-31, 23:25:

I'm now working on a serial mouse. I can see that Windows initializes the mouse and reads the data when INT 4 occurs, but I don't see a mouse on the screen. I've also noticed that the setup isn't copying any of the mouse*.* files to C:\WINDOWS. Did Windows 2 require extra set-up to use the mouse?

I don't recall anything extra. You could try to load a mouse driver and see if it works in another program like PC Paintbrush

xsaveopt wrote on 2025-01-31, 23:25:

Did Windows 2 require extra set-up to use the mouse?

Hi, not that I know of. Windows 2.x has support for most common mouse types.
The setup program features a selection of mice to choose from.

But that being said, there were different versions of 2.x.

Here are screenshots from Windows 2.11 (/286 version):

Edit: Please don't load CuteMouse on DOS. Windows 2.x doesn't like it.
Running MS-Mouse driver 6.24, for example, does no harm.

Jo22 wrote on 2025-02-01, 04:09:

Hi, not that I know of. Windows 2.x has support for most common mouse types. The setup program features a selection of mice to c […]
Show full quote

Hi, not that I know of. Windows 2.x has support for most common mouse types.
The setup program features a selection of mice to choose from.

But that being said, there were different versions of 2.x.

Here are screenshots from Windows 2.11 (/286 version):

Edit: Please don't load CuteMouse on DOS. Windows 2.x doesn't like it.
Running MS-Mouse driver 6.24, for example, does no harm.

I am indeed selecting "Microsoft Mouse - Serial or Bus" in the Windows 2 setup. I'm using Windows 2.01 (in real mode) if that makes any difference.

I also tried installing Windows 3.0 (still in real mode), and it automatically installs a DOS driver for the mouse as well. When I boot I see this message pop up: "Driver not installed - Microsoft Mouse not detected".

GloriousCow wrote on 2025-02-01, 03:44:

I don't recall anything extra. You could try to load a mouse driver and see if it works in another program like PC Paintbrush

I tried installing DOS 5.00 + Windows 3.0 in MartyPC to snoop on the serial port and figure out what I was doing wrong, but it gives me the same "Driver not installed - Microsoft Mouse not detected" error (I did set machine.serialmouse). It's supposed to work there, right? Then I'm probably doing something wrong in the setup...

Does the port send data?
I'd be pulling out hyperterm if it exists

xsaveopt wrote on 2025-02-01, 11:49:

I tried installing DOS 5.00 + Windows 3.0 in MartyPC to snoop on the serial port and figure out what I was doing wrong, but it gives me the same "Driver not installed - Microsoft Mouse not detected" error (I did set machine.serialmouse). It's supposed to work there, right? Then I'm probably doing something wrong in the setup...

You can see if you go to martypc.net that the ctmouse driver loads and detects a mouse. You could try that.

myne wrote on 2025-02-01, 12:18:

Does the port send data?
I'd be pulling out hyperterm if it exists

Yes, I can see from the emulator's side that it is resetting the mouse and then reading a few bytes including the 'M' identification byte.

But I must be seriously misunderstanding what mice were supported by the early Windows versions because I can't even get a serial mouse to work under Bochs. So I'm just going to trash it all and implement a PS/2 mouse instead, which hopefully will work better.