Found a mirror of the old MS Ftp site

The part that is interesting to me is the old OEM test directory, specifically the stress test, and the MS-DOS apps/games!

That’s right it’s Flight Simulator 4! .. Although it was more fun downloading it directly from Microsoft back in the day. That said you may find this one, from more interesting as it’s got a patched exe giving et4000 support!

Naturally you need to configure dosbox, or pcem to use an ET4000 compatible adapter to play this, but the driver does support 800×600 gameplay!

Yes, everyone is going nuts about the new Microsoft Flight Simulator, but I still have X and have barely touched it.

I should be all over this, but I’m not.

Going back to the FTP site, you’ll find various test builds of Excel & Word for Win16, Win32, and Windows 95! This could be the thing you need if you have to work with old documents and don’t want to go through the conversion fun. It’s a treasure trove of testing apps for mucking around on a typhoon kind of day.

Games! Games! Games!

Come on Sal, never miss a game!

Yeah! Over the MS-DOS collection over at is well over 2,500! Isn’t that great?!?

Well let’s take a peek at a few favorites…

Sadly DataEast’s greatest hit RoboCop doesn’t work correctly on the site, however if you were to do something evil like open up the inspector, and manually download the asset yourself it’ll load fine in actual DosBox. It’s a great side scroller, even 30 years later. Yes, 1989 was a long long time ago.

Buck Rogers – Matrix Cubed was a great fun SSI Action/RPG of the day, more of a maze crawler unlike Buck Rogers: Countdown to Doomsday being more older style top down. And speaking of, for any SSI/Buck Rogers fans out there I hope you have checked out I am not a Monster: Complete Edition, which rides the fun line of homage & parody.

And speaking of SSI, Curse of the Azure Bonds and it’s ilk are available as well! I’m not sure how a board game company with a vast library (and IP rights licensed) could possibly fail so hard. Maybe the games were too difficult? Maybe they were too involved? I guess I’m guilty of it too, as I’m the uncleansed masses that preferred Fallout 3 to 1&2. Just as Diablo took off as it removed the clock, and turned it into action.

Project-X was a favorite shoot-em-up on the Amiga, although it being PAL was surprisingly significantly harder to play on my NTSC Amiga, with not being able to see all the screen, running faster, and the insane blinking of some timing with the sprites. I didn’t know there was a PC version, but yeah it looks pretty much like the Amiga version. And it was one of the larger issues that a 386 PC with VGA & a SoundBlaster really not only was as good as an Amiga, but was just plain better as PC hardware kept on improving while Commodore trapped in their downward spiral just didn’t innovate.

Rise of the Triad – The Hunt Begins, this was a soso shooter, but where it really shone was it’s multiplayer maps and combat. It was a awesome time waster on the LAN. I never tried it dialup, or even in modern times, but many fond memories of this game. And it didn’t need insane requirements, unlike say Quake. And it was surprisingly more fast paced than DooM. I wonder sometimes if they had released the source code to ROTT (2002) much sooner than ID released DooM (1997), or around the same time if it’d have achieved more retro popularity? Or was it more of as LAN game, and my experience with it kind of lacking in single player the prevalent feeling?

MechWarrior was at first this incredible 3D game where you could pilot a battle mech in the 31st century! How awesome! It changed the world from the table top rules of BattleTech – The Crescent Hawk’s Inception into something action based. Amazingly the genre for some reason never seems to get the massive appeal I always felt it should have. Although Mark Kern is trying to do something with Mechs & Kaiju over at Em-8er.

3D games like NASCAR Racing arriving in 1994 were really pushing the boundaries of what you could realistically do in MS-DOS with 3D. And of course Quake basically drew the boundary of MS-DOS into Windows with the primary reason being better and uniform 3D drivers. You need a STRONG MS-DOS machine for this, so for me at least DosBox in javascript on a 2006 Mac Pro just wasn’t really up to the task.

Turbo Out Run, a SEGA classic game. The graphics are … well caught in a world between 1987 and 1990. I guess they either didn’t want to push the PC too hard, or accidentally release a superior game on a non SEGA platform? It could have looked better. It should have sounded better. It’s ‘fine’ but I kind of call shenanigans. Golden Axe is way better.

So this is by no means an exhaustive list, I left out a LOT, as 2,500 is way too much to give any reasonable review without it turning into a book, but I scanned the first hundred or so and picked out what caught my eye.

Adding DOSBox’s MPU401 to Qemu 0.90

I thought this may be something cool, if not kind of pointless. Anyways the MPU401 UART can be run like a traditional serial port with an IRQ, in intelligent mode, or just as a ‘dumb’ device you can just bit bang to talk to MIDI devices. So while playing with DOSBox I thought it’d be fun to take it’s emulation and plug it into Qemu.

And this is the end result.

It’s far from perfect, when it works it does tend to work well, although it fails to work with things like Return to Zork, but it does work with DMX’s sound code in DooM and the MPU401 driver for Windows 3.1

While doing this I was originally struggling with mapping the IO ports. Qemu has some functions to map in the memory model to assign a function that will trap read/write space. In this case base is 0x330 the base of the MPU401 device.

register_ioport_write(base, 8, 1, mpu401_ioport_write, s); register_ioport_read(base, 8, 1, mpu401_ioport_read, s);

I was thinking that the port 0x331 needed to be mapped in the same way, but it turns out after looking through more of the source, it’s actually a word aligned access. So in that case you can use a switch to see which port is actually being accessed.

static uint32_t mpu401_ioport_read(void *opaque, uint32_t addr) { switch(addr&0xf) { case 0: return(MPU401_ReadData(addr,0)); break; case 1: return(MPU401_ReadStatus(addr,0)); break; default: return(0xff); break; } return(0xff); }

Pretty simple, right?

And from there it’s a matter of mapping the DOSBox MPU code, along with the Windows interface code. Since I’m not using intelligent or IRQ mode, I just amputated the code where applicable.

If anyone wants to look at what I did to merge into anything else (and probably do a better job!) it’s on sourceforge as mpu401.c.

Otherwise the binary is available on sourceforge:

Download Qemu090b

Quake 2 for MS-DOS full playthrough

Playthrough by TheSlipGateUser

I was just alerted to this playthrough of Quake 2 for MS-DOS by TheSlipGateUser which showcases the game play under DOSBox.

Honestly I’m terrible at Quake, QuakeWorld and Quake 2, but it’s great to see someone who knows that they are doing, and more so that under emulation the game is holding up.

I know the MS-DOS port isn’t exactly the most popular in the world, although I suspect if it had been a thing in 1997 there would have been an audience with people that didn’t want to have Windows in the background as a distraction.

That said, any new people will of course want to check out the excellent (if I do say so myself!) series “Porting Quake II to MS-DOS“.

Visual Studio 2003 on Windows 10 & Errors with Desktop Compositing/Themes

While building the latest DOSBox SVN using Visual Studio 2003 I found something kind of annoying under Windows 10.  The first thing is that if I search through the source code base, the application locks up, hard.   It turns out that this has been an ongoing issue with Windows 8 (maybe Vista/7?) with Aero rendering of all things.  The fix is to disable Desktop Compositing & Desktop Themes, but the application comparability tab is hidden on many applications for Windows 10.

Broken Visual Studio

See how the application preview doesn’t render anything at all?  This is the hint that it’s broken.  I think it may be worth sharing this ‘fix’ as I’m sure that other applications that behave strangely have the same issue.

I found the solution to this over on stackoverflow in this discusstion:[].  The fix is a registry entry in the “HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers” key.

The required settings to devenv.exe is:


Which, will run Visual Studio as Administrator allowing you to debug, and disable all the Aero assists for the application allowing things like search to work again.

I had gone further and enabled the Windows XP SP3 compatibility settings, however on doing a clean build I was presented with this error:

fatal error C1033: cannot open program database ''

Which I never could find any good source on what caused it, other than by guessing to remove the Windows XP flag, and now I’m able to build.

While debugging and re-building the debug database is held open on Windows 7 (maybe Vista?) and beyond on x64 based OS’s. You’ll get the annoying LNK1201 error.

There is a fix on (local backup that involves patching/replacing natdbgde.dll . All I can say is that it seems to be working for me.

In order to do a full build of DOSBox I had to re-build SDL, SDL-net, zLib, libPNG, and set them to a common C runtime linker setting to get a build where the final link didn’t complain.  However when it came to existing project files I did have to find some older Visual C++ 6.0 stuff for many of the components, but using those I was able to ‘upgrade’ them to the 2003 environment and produce a working set.

I’ve got to say, that the AVI capture in the newer branches (I’m using build r4177) is really great!

Building MAME 0.1 for MS-DOS / DJGPP

So as promised, a while back I had built a GCC / Binutils 2.8.1 cross compiler toolchain suitable for building old Allegro based programs, such as MAME.  Of course the #1 reason why I’d want such a thing is that being able to do native builds on modern machines means that things compile in seconds, rather than an hour + compiling inside of DOSBox.

Why not use a more up to date version of both GCC/Binutils?  Well the problem is that the pre EGCS tools ended up with macro and inline assembly directives that were dumped along the way so that later versions simply will not assemble any of the later video code in Allegro, and a lot of the C needs updating too.  And it was easier to just get the older tool chain working.

It took a bit of messing around building certain portions inside of each step of the tools, but after a while I had a satisfactory chain capable of building what I had needed.

So for our fun, we will need my cross DJGPP v2 tool chain for win32, MAME 0.1, Allegro 3.12 and Synthetic Audio Library (SEAL) Development Kit 1.0.7 .

Lib Allegro is already pre-built in my cross compiler tool chain, all that I needed to add was SEAL, with only one change, 1.0.7 is expecting an EGCS compiler, which this is not, so the -mpentium flag won’t work, however -m486 will work fine.

Otherwise, in MAME all I did was alter some include paths to pickup both Allegro and SEAL, and in no time I had an executable.  And the best part is checking via DOSBox, it runs, with sound!

MAME 0.1 on DOSBox PACMAN hiding

Thankfully MAME has been really good about preserving prior releases, along with their source tree, and it’s pretty cool to be able to rebuild this using the era correct vintage tools, and I can’t stress how much more tolerable it is to build on faster equipment.

DOSBox 0.74 can run Windows 3.0/3.1 in 386 Enhanced mode!

DOSBox… in a box!

I don’t know why I never tried it before, but it actually works!  And it’ll even spawn out to a window two.  Although without share/record locking it’ll end up being a world of pain, I suspect.  Maybe vDOS/vDosPlus will work?  I know it’ll work fine if you boot MS-DOS inside of DOSBox, but for some reason I never actually tried to stress the v86 mode of DOSBox from within Windows.

Porting Catacomb3D to MS-DOS (DJGPP v1/GO32).

Catacomb 3-D for GO32

No really, it’s Catacomb 3-D: The Descent.  First ported to 32-bit SDL by NotStiller.  Me being the person I am, I fixed a slight bug regarding binary files on Windows, and MS-DOS, then cleaned up some of the C++ syntax (yuck!) making it far more C89 friendly.  And of course, hot off the heels of DooM for GO32 DPMI, I was able to get it to build and run using GCC 1.39 and GO32.

I know most people really won’t care, but I found it kind of interesting.  I should try to see if it’ll run on actual hardware, just as a comparison of tightly optimized Borland C++ / Assembly vs 100% pure C on DJGPP.  The best tech of 1991 for sure!

At current I just put the source up, you can git it here.

Installing Borland C++ 3.1 in DOSBox: Too many subdirectories!

too many subdirectories?!

So I wanted to install Borland C++ 3.1 under DOSBox to compile something ancient.  I’m on a MAC so MS-DOS player is not currently an option.  I have disk images, which p7zip can happily break down into files, giving me a bunch of files in a single directory, the perfect thing to mount as a ‘disk’ under DOSBox.  However I had subdirectories with patches, source and other stuff in my virtual ‘floppy disk’.  And the installer bombed.  Turns out it wasn’t any file limitation, or anything in the guest C: drive, no the Borland installer doesn’t like sub directories on the install source.

Remove those, and it’ll install just fine.

Also, maybe it’s the weird Borland extender, but Borland C 2.0 runs WAY faster under DOSBox than version 3.1

Null DooM, GCC 1.39, GO32 and DPMI


DooM via DJGPP v1 GO32

Around the time of the x68000 port of DooM, I was cutting down the DooM source for a null/portable version.  I never could get it to actually run either using EMX or  DJGPP 1.03, as I couldn’t get it to link to save my life with a constant never ending battle of unresolved symbols. After a while I just used what I had towards the x68000 version and concentrated on getting it up and running, and just shelved the null/portable effort.

Later on I wanted to get it running again as part of messing with another cross compiler, as DooM isn’t a trivial application to port and verify correct operation. And in the process of trying to get the null version to build and run on Windows using TDM GCC, I wanted to make sure it at least kept compiling with GCC v1.x.

Once more again I was able to compile individual files but unable to link.  But this time, I just looked at the diffs for binutils, I thought it should be somewhat easy to get hosted on Windows.  Although versions may point to binutils 1.0, I had to use binutils-1.9.tar.gz even though the diffs are against Mar 24 1991, and the source for 1.9 is dated April 17 1991.

My first effort gave me a linker that would happily link, but go32 would either refuse to run the executable, or just crash.  I was going to give up again, but I found mention in another file that DJGPP actually uses the linker from G++, the C++ compiler which was a separate thing in the late ’80s and early’90’s.  This time it worked, and I could link a trivial hello world style application!

Now that I finally had a cross linker actually working, I didn’t want to compile under emulation, so looking at the other diffs, they didn’t look too extensive. I went ahead ,and took DJGPP v1.06 and patched up the compiler & assembler to get a full cross toolchain.  And in no time, I had a null version of DooM running on MS-DOS well at least tested on DOSBox.

This was fun, and all but I didn’t see any easy way to do fun things like hook interrupts so I could get the keyboard & clock like any good MS-DOS program.  DPMI greatly eased this kind of stuff, so looking at the DJGPP history, DJGPP v1 version 1.10 actually adds preliminary DPMI support!  And in the next version, DPMI was much more better supported, however the binary format had changed from a.out to COFF as part of the move to v1.11. I was able to take the memory, and DPMI portions from the final v1.12 libc, and manually build and run them against the v1.06 library / dev tools.

And much to my surprise, it actually worked!  At least having the wrong format didn’t have any effect on how GO32 worked for me.

So feeling lazy, I snagged some of the support code from Maraakate’s revamp of DooM, just to make sure of the timer code, and the keyboard code, and again verified that I can build with the keyboard & timer ISR and I’m able to play the v1.9 shareware & commercial levels fine.  I haven’t done a thing to clean up or update the DooM source itself against all the dozens of bugs and issues with Ultimate DooM, or other games like Chex Quest etc.

I’m sure 99% of people wouldn’t care but you can download it here:

Download crossdjgppv1

Although I’m using DPMI to drive realtime events, if I looked further at the GO32 v1.06 environments I could either figure out how it operates it’s timer, or modify the extender directly to drive the PIC timer and keyboard as I need.  But overlooking that, the vintage 1991 software is more than capable of running DooM.