DooM, GCC & AI

One of the things that always annoyed me about DooM is the fixed point math. It relies on a 64bit data type, which many 32bit platform just lack. Namely the FixedMul & FixedDiv.

fixed_t FixedMul
( fixed_t a,
fixed_t b )
return ((long long) a * (long long) b) >> FRACBITS;

They are generally re-written into assembly, at least for the i386 getting around the whole 64bit on a 32bit platform.

	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
	imull 12(%ebp)
	shrdl $16,%edx,%eax
	popl %ebp

	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
	shldl $16,%eax,%edx
	sall	$16,%eax
	idivl	12(%ebp)
	popl %ebp

So that’d always been the ‘catch’ when porting Doom is that you either need a ‘long long’ data type, or the custom assembly or you basically are out of luck.

I know I’m a weird person, but I do like going backwards in terms of software, while most people want latest GCC 14 targeting old machines or some other hack, I prefer the opposite, trying to get the oldest stuff running on something new(er). In this case, it’s GCC 1.27.

While much of the old GCC history is lost, I did my best to collect as many versions as I could find here, along with doing patches in reverse to ‘reconstruct’ many old versions. The results are on And what is significant from this, is the first version of GCC with i386 support appears in version 1.27.

From the internals-1 file we can find out that we all have William Schelter to thank for doing the bulk of the 386 port of GCC.

William Schelter did most of the work on the Intel 80386 support.

Internals-1 – gcc 1.27

With the first commit being on May 29th, 1988:

Sun May 29 00:20:23 1988 Richard Stallman (rms at
* tm-att386.h: New file.

GCC 1.25

The first GCC with i386 parts is 1.25, however it tends to emit the instruction movsbl, which GAS doesn’t like. Comparing the output to GCC 1.40 reveals this:

-	movsbl -12(%ebp),%ax
+	movsbw -12(%ebp),%ax

It’s trivial enough to change to a movsbw, but there are some other issues going on, and even the Infocom ’87 interpreter won’t fully build & run. The files input.c & print.c have to be built with a later version of GCC, in this case I used GCC 1.40.

8&% compiled with GCC 1.25!

However when using the old XenixNT build thing I did, I do get a runnable EXE!

GCC 1.25 targeting DJGPP v1

I added the BSD targeting files from 1.27 allowing it to generate the needed underscores in the right places, as 1.25 by default only supports AT&T syntax. I guess the best way to illustrate it is to compile the compiler twice, once as the AT&T compiler, and the next being the BSD compiler, and compare their output:

cc1-att.exe hi.cpp -quiet -dumpbase hi.c -version -o hi-att.s
GNU C version 1.25 (80386, ATT syntax) compiled by GNU C version 4.8.1.

        .byte 0x31,0x2e,0x32,0x35,0x0
        .byte 0x68,0x65,0x6c,0x6c,0x6f,0x20,0x66,0x72,0x6f,0x6d
        .byte 0x20,0x25,0x73,0xa,0x0
        .align 2
.globl main
        pushl %ebp
        movl %esp,%ebp
        pushl $.LC0
        pushl $.LC1
        call printf

And then looking at the BSD syntax:

cc1-bsd.exe hi.cpp -quiet -dumpbase hi.c -version -o hi-bsd.s
GNU C version 1.25 (80386, BSD syntax) compiled by GNU C version 4.8.1.

        .file   "hi.c"
        .byte 0x31,0x2e,0x32,0x35,0x0
        .byte 0x68,0x65,0x6c,0x6c,0x6f,0x20,0x66,0x72,0x6f,0x6d
        .byte 0x20,0x25,0x73,0xa,0x0
        .align 1
.globl _main
        pushl %ebp
        movl %esp,%ebp
        pushl $LC0
        pushl $LC1
        call _printf

As you can see main: becomes _main:, just as labels (LC0/LC1) have a prepended, while in BSD they do not. There are no doubt countless other nuanced differences, but for the assembler & operating system to match you want these to align. Thankfully calling conventions are mostly the same per processor so you can add the underscores to the AT&T target and get something that’ll run, not only on DJGPP but also Win32, as MinGW32 uses BSD syntax at its heart!

C:\xdjgpp.v1\src>gcc hi-bsd.s -o hi.exe

C:\xdjgpp.v1\src>wsl file hi.exe
hi.exe: PE32 executable (console) Intel 80386, for MS Windows

hello from 1.25

Not that we really need to go all the way and have GCC 1.25 running on anything much, although at the same time it’s kind of fun!

Reaching out for help

The oldest & most robust GCC is 1.27, and I’d been able to use that to build DooM before, but the caveat is of course the fixed point math. I’d asked smarter people than I years ago about this problem, and basically was told to figure it out for myself. After all its ‘trivial’. But alas, I’m not smart. What I would do is build the fixed point math with GCC and try to re-work that into other compilers, although again for platforms without GCC or the target CPU lacking the 64bit data type is well.. fatal.

But AI, sadly for it, is compelled to help. So I just went ahead and asked and got a surprising result!

Sydney strikes back!

It’s very C++ like but it’s trivial enough to make it into old C.

Sydney’s fixed-point guess

Well on the one hand it does actually load up and play. But the controls go wild and I’m pulled into the intersection of these boxes, and unable to move. And as I rotate the floor and walls clip in and out. It’s very weird.

Not knowing anything about anything, I saw this ‘guard’ on the fixed division and tried to add that to the multiply:

	if ( (abs(a)>>14) >= abs(b))
		return (a^b)<0 ? MININT : MAXINT;

And I got something even weirder!

Now with absolute guards!

Not only that but the engine crashes! Not good.

After thinking about it on and off, asking for more help and going nowhere, I just gave up. It’s something beyond my skill, and apparently the AI as well. Until I had one of those moments in a dream where I had somehow told myself I bet the integers are not unsigned, and obviously fixed-point math needs all the bits, and it’s such a trivial fix, that even I should have figured it out.

I woke up at 4am and fired up the computer to see if it did anything. I was surprised to see that yes, in fact the integers were signed. I added the one key word, and recompiled using GCC 2.2:

Now with unsigned integers

And it RAN! I tried GCC 1.39, and too ran! I then made sure there was no assembly modules being called accidentally, and then re-built with GCC 1.27, and yeah, it runs!

Armed with a simple port of DooM to Win32, I went ahead and put in the fixed-point solution, and used Visual C++ 1.10 aka Microsoft C/C++ 8.0 to build DooM, and yes it works there too!

In the end I guarded it around a long long type, as I’m sure it’s much more faster, but for those without the types or any assembly skill, here is the solution:

/* Fixme. __USE_C_FIXED__ or something. */
        ( fixed_t a,
        fixed_t b )
    return ((long long) a * (long long) b) >> FRACBITS;
    unsigned int ah,al,bh,bl,result;

    ah = (a >> FRACBITS);
    al = (a & (FRACUNIT-1));
    bh = (b >> FRACBITS);
    bl = (b & (FRACUNIT-1));

    /* Multiply the parts separately    */
    result = (ah * bh) << FRACBITS;     /* High*High    */
    result += ah * bl;                  /* High*Low     */
    result += al * bh;                  /* Low*High     */
    /* Low*Low part doesn't need to be calculated because it doesn't contribute to the result after shifting

    // Shift right by FRACBITS to get the fixed-point result                                            */
    result += (al * bl) >> FRACBITS;

    return (fixed_t)result;

/* */
/* FixedDiv, C version. */
/* */
        ( fixed_t a,
        fixed_t b )
        long long c;
        c = ((long long)a<<16) / ((long long)b);
        return (fixed_t) c;
        double c;

        c = ((double)a) / ((double)b) * FRACUNIT;

        if (c >= 2147483648.0 || c < -2147483648.0)
                I_Error("FixedDiv: divide by zero");
        return (fixed_t) c;

        ( fixed_t a,
        fixed_t b )
        if ( (abs(a)>>14) >= abs(b))
                return (a^b)<0 ? MININT : MAXINT;
        return FixedDiv2 (a,b);

I haven’t tested it on Big Endian machines yet. I’ve updated my terrible DooM engine port, along with Doom-New for DOS. Additionally, I’ve been able to confirm it works with Watcom 9-OpenWatcom 2. It might even work with 7 & 8 but I haven’t tried.

Adding the missing part of DoomNew – audio

DoomNew, is a rather ambitious project by Maraakate, to attempt to revert the old linuxdoom-1.10 to something more akin to what shipped for DooM 1.9 using Hexen/Heretic source code to fill in many of the blanks in a very Jurassic Park like manipulation of it’s DNA (source code). It’s great and gives you a very cool MS-DOS based engine using the original Watcom tools. But there is always the one catch, which is that it relies on the original sound library, DMX.

And unfortunately, nobody has been able to get ahold of Paul Radek to see if he’d be okay with any kind of open-source license. So, sadly DMX has been a long-standing stumbling block for that ‘authentic’ super vanilla DOS DooM.

Enter the Raptor

Raptor: Call of the Shadows

Fast forward to a few days ago, and I come across dosraptor on github. I had a copy of this back in the day, it was bundled on CD-ROM or something. I am absolutely terrible at games like this, but I did remember this one being incredibly fluid, and fun despite me having no skill. Raptor was written by Scott Host, and it’s still on sale over on steam! The source had been cleaned up with help from skynettx, nukeykt and NY00123.

I went ahead and built it from source, and in no time I was up and running. I found Watcom 9.5 was the best path to go with. I even made a ‘release‘ for those who don’t want the joy of building from source, and of course picked up a copy on both steam and his site. While building the source code, and looking at the directory tree that’s when I noticed apodmx:

This is a DMX sound library wrapper, which is powered by the
Apogee Sound System, the latter being written by Jim Dose for
3D Realms. When used together, they form a replacement for DMX.

The DMX wrapper was written by Nuke.YKT for PCDoom, a DOS port
of id Software's Doom title from the 90s.

It also includes the mus2mid converter, contributed by Ben Ryves for
Simon Howard's Chocolate Doom port, as well as the PC Speaker frequency table, dumped by Gez from a DOOM2.EXE file and later also added to Chocolate Doom.

A few years later, this wrapper was modified by NY00123; Mostly to be built as a standalone library, while removing dependencies on game code.

So it turns out that Raptor used DMX, just like DooM!

Well, isn’t that incredible!

Now the first question I had, was apodmx a direct drop-in replacement for DMX? Well basically, yes! Let’s check out the Adlib driver!

DooM 1.9 intro
NewDoom intro

As you can hear, the intro is very different. But it’s playing at least. Ok how about E1M1?

DooM 1.9 E1M1
NewDoom E1M1

The Apogee Sound System is softer, and not quite the same as DMX, but compared to nothing I’m more than happy with it. The AdLib is kind of a weird card to drive, and I guess it’s not to surprising that there is such a variance.

How about a Roland Sound Canvas?

Nuked-SC55: Roland SC-55 emulation

Sadly, mine is inaccessible, but thanks to nukeykt there is the Nuked-SC55: Roland SC-55 series emulation. I had to setup the MidiLoop as expected, and configure DosBox for the Loop and now I have a virtual Sound Canvas. So let’s see how the two engines deal with a common instrument!

DooM 1.9 Sound Canvas 55
NewDoom Sound Canvas 55

Pretty cool, if I do say so myself.


I’ve uploaded my modifications to github, along with a copy of that old ZeeDooM I had slapped together ages ago. I’d taken the map source code from Romero, and the graphical/audio resources from Freedoom and slapped them together.

zeeDooM Xenix!

So a few months ago, gattilorenz had told me he managed to work out how to do direct video under Xenix, and was able to get DooM running! He made the source available, and I meant to do something back then, but I must have gotten distracted.

So I went ahead and added the zeeDooM thing I had been working on a while ago which is a combination of the John Romero released maps, and the FreeDoom assets. So it’s not 100% the released version, it just looks that way.

I’ve gone ahead and created a qemu disk image (if you convert it, it does run on VMware, so probably far more 386 capable emulators than I can imagine), along with an old Qemu exe for some stand alone fun on

There is no sound, nor music. I should look closer one day, and see if I can drive some direct music to an Adlib since it’s just IO ports, and maybe grab all the direct sound code from viti95’s FastDoom?

Anyways, it’s zeeDooM!.. on Xenix!

Amongst all the DooM and gloom, DooM 64 was released for PC!

I guess I missed all the excitement of the new DooM whatever, but Bethesda decided to dig up that N64 ‘DooM 3’ aka DooM 64. It’s a unique game unlike all the other console ports that were straight ports of the original DooM, although some like the 32x (Mars) or Jaguar versions that had a bunch of details removed from the levels to either spare the limited processors, and/or save precious cartridge space.

At $39 HKD, it’s $4 USD, so it’s a bit ‘pricy’ for something that is a 23 year old game, but at least I guess it’s out in the wild in a legal format. No idea if it made it to as that whole thing collapsed quicker than Fallout 76 became a meme riddled disappointment.

Anyways I know I’m late to the party, but it’s all new to me.

How much DooM is there in the Doom 3: BFG Edition version?

Another follow up to my ages old “Just how ‘original’ is the Ultimate Doom on steam?“, I thought I’d follow up with the DooM 3 BFG version.

I already have DooM 3, but this is apparently remastered, and includes the previous versions!?

It’s not like it really offers anything I don’t have, but it’s on sale so whatever let’s go.

And in the base/wads directory there they are!

fb35c4a5a9fd49ec29ab6e900572c524 DOOM.WAD
c3bea40570c23e511a7ed3ebcd9865f7 DOOM2.WAD

And sure enough the are the latest versions of the game files to be found according to Great! So to further the abuse I tried them under my mutilated DooM.

Ultimate Doom seems to work just fine on it’s own I tested it briefly warping to a few levels but yeah it just works! Doom2 however bombs out that the resource TITLEPIC is missing from the wad. How disappointing!

Naturally I just took the easy way out, and basically checked for the resource, and load another if it’s missing.

@@ -477,7 +477,11 @@
  pagetic = 170;
  gamestate = GS_DEMOSCREEN;
- pagename = "TITLEPIC";
+ /* the Doom 3 BFG EDITION version of Doom 2 is lacking the titlepic */
+ if(W_CheckNumForName("TITLEPIC")>0)
+ pagename = "TITLEPIC";
+ else
+ pagename = "DMENUPIC";
  if ( gamemode == commercial )

It’s a shamefully basic patch. But it works.

Another interesting thing is that DooM 3 BFG also includes the gravis ultrasound bank data, so you could load them up into some other emulator and enjoy that gravis experience. I don’t know if it’s licensed or what, but it’s a nice touch.

AVGN reviews Chex Quest

Okay that was funny. I never thought of even trying Brutal DooM + Chex Quest. Sounds awesome.

Although I’d played a little with Chex Quest before, I never tried it on the DooM source. Oddly enough it’s Ultimate DooM. In d_main.c you can do some simple test for chex.wad and pass it off as the ‘retail’ version.

	if ( !access (chex,R_OK) )
		gamemode = retail;
		D_AddFile (chex);

Or you can simply just rename chex.wad to doom.wad or doomu.wad. Many of the strings for DooM are compiled into the EXE, not taken from the WAD file (although it could have been, I guess it was to prevent people from making overtly cheeky mods?).

So firing up the wad under my crappy DooM port thing to MS-DOS (for the sane people just use some other Win64/OSX/Linux thing like zdoom), and when selecting an episode you’ll see the Ultimate DooM levels.

Chex Quest, Thy Flesh Consumed!

Wait? What? I though Chex Quest was a ‘total conversion’ WAD. Well it turns out that it is, and it isn’t. They replaced a lot of the default stuff from a retail version of Ultimate DooM. And what they didn’t replace, well it’s still there. And yes that does mean everything outside of the first 5 levels are the original DooM levels. And that includes the music as well!

E2M2 from Chex Quest

Well isn’t that surprising! And yes that means that it’s possible to just replace the first 5 levels with the default DooM levels and have that reverse conversion. In the same way the menu screens are very Chexy too:

It certainly gives that kid like feeling to it. Although the replacement Barrons of Hell are a little too big so they do look kind of silly.


So as always I’m late to the party. I’m sure someone out there didn’t have the retail version of DooM and instead used Chex Quest for those LAN games. Although it does detect that the WAD has been modified so I don’t think it would just be all that fine.

Not that finding the original WAD files, or source to the maps, and just compiling them yourself is all that difficult, but I guess it is something else to load up.

Bethesda DooM for the PC

$1.70 USD!

With all the excitement regarding the DRM, disapearing Xbox versions and the terrible music in the Unity port, I thought I’d check out the PC version that is thankfully on sale on I really have lost track the number of times I’ve bought this game, but here we go again. The last time I went through this was back in 2014, with the aptly titled: “Just how ‘original’ is the Ultimate Doom on steam?” story.

And much to my surprise they use the same version of DOSBox, 0.71, and have the same AdLib pre-config, along with the missing SETUP.EXE to allow you to change it.

HOWEVER, there is one big difference, the WAD file.

The steam version includes this wad file:

c4fe9fd920207691a9f493668e0a2083 doom.wad

Where the uses this wad file:

e4f120eab6fb410a5b6e11c947832357 doom.wad

And looking on the DooM Wiki, that means that the wad file is from the PlayStation Network version.

Now with extra hell!

And it’s true they really did change the cross to a pill for the medical kit, per the red crosses request:

iD DooM on the left, Bethesda DooM on the right.

There is a few changes here and there but overall it looks pretty standard to me. Am I missing anything else?