Because it's #DOScember, I've been spending a lot of time acquainting myself with the ao486 core. While it might be on the one hand one of the more unnecessary cores, given the number of ways which you can play DOS games on just about any hardware, I do appreciate the flexibility of the device and the fact that it arguably replicates the older hardware more accurately. While I don't need to really make much of an argument for why the MiSTer is cool in a thread like this, the core actually fills a pretty significant niche that a lot of retro thin clients might struggle with, which is specifically to be a core that represents early DOS gaming and attempts to work around a number of hardware setup incompatibilities that make building an all-purpose DOS computer difficult if not impossible. Even this won't cover every use case, because there's obviously no 3D acceleration to be found, and some less-supported but common hardware like the Gravis Ultrasound isn't avaliable.
I've made an unnecessarily long post here detailing my experience using the core so far, and some notes about configuring different parts of the core.
HARDWARE (or simulated equivalent)
In addition to the obvious x86 PC component, the core presents some rather nice audio and video options. Audio is provided by a Soundblaster-16 equivalent that, unlike actual later Soundblaster devices, will support games that are designed for use with the Soundblaster Pro; actual SB-16s did not have backward compatibility past SB 2.0, not Pro (or Pro 2.0, whose only difference as far as I can tell is the choice of OPL chip). This alone makes it close to the only DOS machine anyone would need, because I'm sure the OPL3 implementation in this card is excellent, and does a very good job of matching the sound quality of the one in my Gateway Solo laptop (which, to be honest, I picked up on the basis of it having a discrete OPL3). Other FM implementations in cores are basically indistinguishable from what they're based on, and I would say the OPL3 is overall just a bit simpler than some of the 4-op chips like the 2612 and 2151, so it's not surprising that the sound hardware is very well-replicated here.
The aformentioned SB16 also has the advantage of supporting both IRQ5 and IRQ7. I believe it defaults to 5 but changing it to 7 will keep it running. This would break compatibility with a printer, but I don't think a printer matches the use case for the core, and besides most DOS-era printer drivers are for hardware that is on a level of obsolence with floppy disks.
Video is the equivalent of a Tseng Labs ET4000 (see also the drivers section). Supports high color depths and resolutions, but I find that since I'm not multitasking and almost exclusively running DOS games anyway that going above 640x480 really isn't all that useful, especially since I keep integer scaling on (so I get effectively 2x-scaled to 1280x960), and then I don't have to worry about font sizes breaking some games.
There are 2 dedicated hard drive slots and 2 other drive slots that can be used as CD drives or more hard drives. I use them for CD images. They have a rather unfortunate limitation that they do not actually function for playing CD audio! Any game whose soundtrack uses the redbook format will not play on this core. The number of games that used that are fairly limited, but I have a number of CD games that do, like Pitfall: The Mayan Adventure and Sonic CD.
NOTES ON COMPATIBILITY
There is surprisingly little that I've thrown at it that I haven't been able to run. The biggest challenges have been Lemmings 2 (which you'd probably rather run on Minimig -- it runs, but only when booting from the hard disk I have that is FAT16 formatted running DOS 6.22 / Windows for Workgroups), Blackthorne (which seems to have issues with using the specific SB Pro soundtrack -- adlib is fine, MIDI seems to be fine as well), and Descent (which doesn't want to run in any pure DOS mode, throwing up a memory protection issue related to DOS4GW, but runs quite well from Windows 95). Some later DOS games don't run perfectly; Duke 3D seemed to be pretty choppy, and I got some slowdown in Tyrian 2000 when I tried playing it. System Shock had framedrops and crashed (though, again, I think this is related to DOS4GW issues and would probably be fixable in either Windows or with DOS4GW replaced).
The later games pushing up against the core's limited power tend to run without issue on fast hardware; thin client PC gaming is on the rise due to such devices being low-power and often having chipsets with good DOS compatibility, and I think those would be a better choice for these later games, which will probably run from Windows 98 without issue.
That said, when I've tried to play the DOS version of King's Quest VI I've had some issues with the audio coming in choppily, which were improved running the game at 30MHz (all cache on) and using the Thunderboard voice settings (go figure, a soundblaster clone). Trying to speed up sound past that seems to screw up MIDI playback (and yet here I think I've never played the game without using soundblaster setups on other DOS machines). Teen Agent (one of a handful of GOG-provided DOS freebie games) works sometimes, but not always very consistently.
If I set up the ScummVM core I could probably run stuff like KQ6 without issues, but I don't know that I care all that much to bother; it's not the sort of setup that this hardware is really designed for, nor do any of the auto-updaters install it. That's, again, more something for a thin client setup -- though I think ScummVM is often the better way to play these games given the option. I mean, DOSBox requires additional overhead for emulating system components, and ScummVM gets to be flexible with features, like allowing the high-res portraits and/or intro AVIs from the KQ6 Windows version, the icons from the DOS version, and the ability to enable both text and speech together.
MIDI
MIDI is interesting because it's one of the few pieces of hardware that is by its nature not tied to components in the core. MIDI data can be fed out by a USB adapter, fed out via UDP connection (to a port on a PC or raspberry pi, for example), or rendered on-device using either fluidsynth or MUNT on the Linux (ARM) side of the MiSTer.
MIDI with fluidsynth is quite nice; I've been using an SC-55 soundfont and it works very well overall. Some games require intelligent mode MPU-401, which is easily provided in software with SoftMPU, which doesn't have a particularly significant memory or CPU footprint from what I can tell. Intelligent mode is not provided by the core. SoftMPU's one drawback is that it requires EMM386; you probably won't need it in the face of Windows's MIDI mappers, but you will need it to run a lot of MT-32 stuff, like the many Sierra and LucasArts adventure games. (Loading can be very slow too, if the game is sending voice data into the unit; there's a delaysysex switch in the config file for the midi driver, but it only does so much).
Speaking of MT-32, the code also supports MUNT, which like Fluidsynth runs off the ARM CPU on the device. It would be accurate except it simply can't run fast enough sometimes. The intro to King's Quest V...oof! This is one case where it's best to edit the midilink.ini file (probably under the MIDI or Linux folders on the SD card root if you use a standard updater) and just forward stuff to your computer, or a raspberry pi, or something similar. Games that don't load data into the MT-32 are probably going to be fine without using SoftMPU, though ones I've tried (such as Lotus 3: The Ultimate Challenge) don't run properly inside Windows anyway. Outside of some of the stuff that has issues tied to DOS 4GW, it's best to play DOS games in DOS. It's as simple as looking up your local network IP for your computer or whichever, installing loopmidi, launching udpmidi, and then loading up the loopmidi port in MUNT -- which is a few steps but not very difficult; there's a guide with links to the relevant software
here. I do not know of a script that lets you modify the midilink.ini file, so you'll either have to do something like load up an LXDE image, open the file by sticking the MiSTer SD card into your computer, or use the PuTTy suggestion in that guide. It's also possible to connect a real MT-32 up with a proper adapter, but I haven't the hardware necessary to test that.
If you have that set up, you can do almost the exact same thing with MIDI OX for soundtracks that actually follow a MIDI standard, but because fluidsynth isn't so resource-intensive, it runs pretty well without requiring an external module.
OPERATING SYSTEM SETUP
Actually setting the device up isn't terribly difficult, but it's obviously more elaborate than running stuff in DOSBox where you don't usually need to do more than point to the right folders and launch the programs. You first have to create a VHD file or two, then you will need to set up a master boot record for them. If you are creating the VHDs in Windows 10, the disk management console is quite well suited to this. Create a VHD from the drop-down menu, set the size, and make sure the MBR is set (you'll have to do this if you're going to try to write files to it).
Then you can either install DOS 6.22/Win3.1 or Win 95. Both have their pros and cons (Win 3.1 is more closely tied to DOS, boots faster, and is easier to edit system configs for -- but Win 95 has better memory management, more out-of-the-box driver support, and more native programs). You can even install both and use a boot manager to switch between them, but I figured it was easier to just set up two different VHDs, each of which I'd switch between depending on which OS setup I wanted to use.
If you have DOS installation media, you can boot into that and run FDISK to create partitions -- each one is a max 2GBish each up to the first 8 GB of the VHD. I'm not going to go into a ton of detail here when fdisk is pretty well-documented, but the basic idea is to create a primary partition, then an extended partition filled with multiple logical volumes. After that, load up a Windows 95/98 boot disk and you can use fdisk to partition whatever's left as FAT32. Once all the fdisk stuff is done, you can (if you want), install DOS. You have to install DOS before you install Win 3.1, because the Win 3.1 disks aren't boot disks. If you don't boot off the hard drive, the Windows installation will try to edit the system config files on whatever boot disk you used instead of the hard drive. This was where I discovered that the premade VHD file I used was lacking an MBR -- fortunately, all I needed to fix that was a quick `fdisk /mbr` command. Then Windows 3.1 installed without too many issues.
Windows 95 does not seem to want to install off an iso directly; the files should be copied from a hard drive. I would encourage using an OSR2 disc for this. The setup should then proceed fairly straightforwardly. Later releases that come bundled with IE4+ and the active desktop features are not recommended, as they have trouble installing and don't work well. Some people have managed to install Win 98, but I didn't see much point as 98 expects a math unit by default, which this core emphatically does not include. Still, it works. You can even play some Windows-native games in it, though not all of them run very well (though, say, the King's Quest games are perfectly fine). Tempted to copy over Sonic & Knuckles collection for the hell of it, fully expecting that it will not run well.
I do not advise installing a memory manager like quarterdeck -- I tried installing it a few times and it didn't work well on 6.22, and with 7.1/Win9x this is even less useful due to better memory management. It did not install properly. What does seem to work is launching EMM386 with the configuration seen here:
https://misterfpga.org/viewtopic.php?f=13&t=955&p=8269 Specifically, the arguments to call are as follows:
Code:
DEVICE=C:\DOS\EMM386.EXE RAM 8192 FRAME=D000 D=256 I=C800-CDFF X=CE00-CFFF I=D000-EFFF
Beyond that, I strongly encourage setting up the PhilsComputerLab launchers for DOS. Use
this setup for 6.22/Win 3.1 and
this stuff for Win 95. For both, you'll want to use the SB16 setup instructions shown in the latter; it's necessary for sound in 3.1 (where you will want to ignore the steps about skipping Windows driver installation, obviously), and encouraged for use in Win 95's DOS mode.
For the DOS launcher, I also highly recommend creating an additional option for booting Windows 3.1, specifically duplicating the EMS settings but not loading ctmouse.exe, because it will conflict with the Windows mouse drivers, meaning your mouse won't work. And in case it's not clear, you're gonna want to change the EMM386 lines in those launchers to look like the one above. But those will do a lot to get most games working.
There are some additional drivers for ao486 here. The PhilsComputerLab stuff includes the most important drivers -- mouse and CD-ROM -- but you will also want the appropriate Tseng ET4000 drivers for Windows 3.1 as those are not included and the other high-res/high-color modes available in Windows 3.1 WILL NOT WORK. I didn't bother with the other drivers, but I'm not particularly concerned with networking and stuff from Windows right now.
If you are running Windows 95, CD-ROM hotswapping tends to have issues; I found I needed to unload currently active disc images before I could load a new one. That's done by selecting the image in the main core menu, as if you were going to load a new one, and then pressing BACKSPACE. I think the menu mentions this on the bottom when you're loading an image. Just swapping the images without doing this step seems to not work well. I did not have this issue in pure DOS or 3.1.
Shared folders are easy to set up in a Win 3.11 environment, but Win 95 doesn't play nicely with pre-launch instructions most of the time. If you stick
misterfs.exe from the project github on a disk/floppy/CD image, you can run that to access a shared folder in the AO486 main folder. There is very little hassle in mounting the VHD with the Windows disk tools, and then transferring files is simple.
Something I might try later on is building a single disk image that I'll have both Win 3.1 and 95 on (over different partitions, most likely) and use a tool like
plop boot manager to switch between them. I wasn't going to do that until I was confident that I had a suitable starting disk image for each OS, though.
SPEED CONFIGURATIONS
In terms of real-time hardware modification, CPU speed is the only one I change regularly. Swapping out the Soundblaster stuff for a Gameblaster equivalent is possible, but I don't have any games right now that are specifically designed for Gameblaster, so I've never bothered. Memory changes from 256MB to 16MB rarely seems to matter either (though it might help with some DOS4GW issues). However, because a lot of early DOS games tied framerate to a fixed CPU speed, tweaking can definitely be helpful (and also prevents some driver initialization crashes). The settings for ao486 include multiple clock speeds and the ability to change cache levels. These values won't directly map to speeds of common CPU architectures, so I ran
3DBench from the PhilsComputerLab benchmark pack and compared that to
the results here for various pre-Pentium architectures. Here are the established values for real old x86 CPUs, top row being CPU classes and bottom being respective benchmark values:
And this matrix is the benchmark values for each AO486 clock rate with the various cache settings. Values without any cache enabled wind up somewhere around
1 at highest clock rate. This core had a reputation for being slow before cache was added to it, and given how long it took to run the benchmark, no kidding. Maybe surprisingly, the L2 cache is almost as fast as the L1 cache is.
Clock Speed (Hz) | Result with L1 & L2 cache | Result with L1 cache only | Result with L2 cache only |
15 | 7.1 | 3.3 | 2.3 |
30 | 14.4 | 6.5 | 4.9 |
56 | 27.7 | 11.4 | 9.4 |
90 | 45.4 | 16.6 | 15.3 |
Note that my results come from the original 3DBench 1.0, whereas the previous ones come from 3DBench 1.0c, but the benchmarks are nearly identical for pre-Pentium CPUs. I would have used 1.0c but something about ao486 causes it not to work correctly, inflating the numbers for low levels -- 15Hz with all cache got a 14.4 while 15Hz with only L1 cache got 59.8, which can't possibly be correct.
This means that at top level (90Hz, all cache), the core is around where 486-66 processors tended to be and would probably match up with some stuff Cyrix was putting out. All cache and 56 Hz gives roughly a 486-33. Going lower with cache on gives a mid-range 386, whereas 386-40 is matched closely by 90Hz and L1 cache.
It might be possible to get more fine-grained results by messing with a tool like setmul, but I don't think that's going to be very useful. These values match up nicely with expected hardware options from the era that most games that were speed-dependent would be targeting. Something like 30Hz and both cache levels on will probably get you a very suitable game of Wing Commander (designed for 386-33), for instance.
CLOSING THOUGHTS
This core is just easy enough to use that I've become somewhat addicted to it. It's fun to experiment with and to see what I can and can't get running, and what settings I might need to change to enable it. I've been impressed with performance and it does a great job in getting games running effectively-natively in a way my Gateway 2500 laptop notably doesn't. While it is never going to deliver the experience of a Pentium (I highly doubt we'll ever see a floating-point unit, even, not that many games would use it), it is unquestionably one of the best ways to do a set-it-and-forget-it setup for DOS machines this side of, well, DOSBox. It's the right level of virtualization to abstract away the physical issues of expansion cards and storage, while still being nigh-authentic to the experiences that some of the nicer hardware of some of the eras provided. Sure, it's nice to point to the FM synth MIDI sound and say that it's indistinguishable to how it sounded on your old computer back in the day, but who wants to re-create the experience of shuffling a series of 12 floppy disks to install an adventure game?
A few years back, retro PC aficionado LGR put out
a youtube video on retro gaming setups, collecting a set of opinions on what the best way to play these older DOS-era games is. The answer that shows up most often winds up being DOSBox, and it really isn't surprising. DOSBox abstracts most of the hardware compatibility away to the point that you don't even have to think about it -- it's got high sound compatibility, with every generation of Soundblaster, Tandy/PC Jr. sound (the SN76489, notably supported in other MiSTer cores like the TI-99/4A, BBC Micro, and Master System), Gravis Ultrasound, etc., with rare need to tweak IRQs, and said IRQs being configurable per game. It also supports the Tseng graphics (useful for Win 3.1 installations!). CPU speeds are configurable to the individual cycle. Some enhanced releases (Dosbox-X, Dosbox ECE) even support some forms of API passthrough to host graphics cards for games like Tomb Raider. It runs on basically everything. If your goal is to play DOS games (and probably 16-bit Windows games!) then this will not replace DOSBox.
AO486 is, however, much better suited as a general-purpose DOS-era machine. DOSBox is not designed to be a legacy-system VM for any application despite all the hardware it can support; there's
a VOGONS thread that says as such in all caps! AO486's compatibility is, well, actually
better than a lot of era-specific hardware, because drivers were still nonstandardized up until Windows became the default -- there is no universal hardware for DOS games and applications. Older systems are obviously not going to play nicely with modern devices. Nobody makes gameport controllers any more, but also good luck running USB devices on a 286 computer! Even when it comes to stuff that's pushing the end of the DOS era (and would, frankly, be likely run inside a Windows DOS prompt), AO486 does a noble attempt getting it to play. This is what FPGA clones are great for -- efficiently interfacing the stuff that needs to work
precisely with components that are modern commodities. An only
slightly idealized version of what the hardware of the last parts of this era did; plug-and-play at its apotheosis.
While the lack of support for graphics expansion boards (don't expect anything fancier than what we have) and some less-common audio hardware (though I can't write out, say, Tandy compatibility as a possible feature to come) means that even the AO486 obviously can't cover every pre-Pentium use case. Still, it does a damn good job trying. This is definitely my ideal DOS experience right now, and for anyone who turns their nose up at DOSBox for not being bare metal enough but still want to, say, play on a modern TV, it's the clear choice.