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.

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.



MS-DOS 5.00A booting on Neko Project 21

While I’m waiting for my real PC-9821 to arrive, I’ve been playing with various software.  One fun thing was the old DJGPP, as the version 1.x had a customized version of go32 to support the PC-98 hardware.  This is cool, but I’d love to perhaps start down the road of porting something to the PC-98.  There is no VGA adapter, and the I/O is mapped differently so naturally this is why they are only loosely compatible.  So while I was looking for any kind of source code using DJGPP, I found the FCE: Family Computer Emulator (NES).  It includes source code, which is great but it builds against DJGPP 2.x What makes it more interesting is that it has DPMI hooks in place, unlike the old DJGPP 1.x’s DOS extender which is DPMI incompatible.  So how do you magically get a DPMI environment for MS-DOS?  Well one way is to run it under Windows 3.0 or higher.  And certainly with MS-DOS 3.30 that is an option.  However lurking in the disk images of MS-DOS 5.00A was a fun program DPMI.EXE .  Well now that is interesting!

MSDOS 5.00A native memory

MSDOS 5.00A native memory

Using a generic config.sys I have 600kb of low RAM available, and 7MB of extended RAM.

Now the real interesting part is DPMI.INI

network=*vnetbios, *dosnet

As you can see this is pretty much the 386 enhanced portion of Windows 3.0!  So you get all of the DPMI services offered by Windows as part of the OS.

MSDOS 5.00A DPMI activated

MSDOS 5.00A DPMI activated

As you can see, with DPMI running I have access to EMS, and XMS memory now available.  Additionally with paging you can even over commit memory.

My only question, is why was DPMI not an added in feature of the English versions of MS-DOS?  Granted there was a LOT of OEM bundling with new machines so you were forced to purchase a copy of Windows along with MS-DOS on all new computers, regardless of what you were going to do with them, and this would have been a bit more interesting.

This kind of environment was extensively documented in the “Unauthorized Windows 95“, by Andrew Schulman that showed how DOSX.EXE could chain load Win386 + command.com achieving the same thing.  The DPMI environment from MS-DOS 5.00A is dated 11/11/1992, I wonder if he knew about this going into the Windows 95 book.  It’s been too long since I’ve read it to remember, but I don’t recall any details about Japanese PC-98 releases of MS-DOS.  There was also a ‘MSDPMI’ environment created for the beta versions of Microsoft C 7.0, but I’ve been unable to find one to verify.  MSC 7.0 was released in 1992, so it fits in the same timeframe, but the shipping products used QEMM’s DPMI server instead.