Getting started
DooM is without a doubt one of the most popular PC games of all time. Â And thanks to it being written in C is also an incredibly portable game. Â One platform that mysteriously was lacking DooM was the SHARP x68000.
After a bored day of playing with the source to Mariko’s GCC 1.42 / 1.30 that targets the x68000, I thought I would take a stab at trying to compile DooM. Â Since I’m using such an ancient version of GCC the first stumbling block is that DooM is FULL of C++ style comments, which older K&R & ansi based compilers of the late 1980’s simply cannot handle. Â So the first phase was to convert all the comments.
In order to convert the comments, I came across this great tool, uncrustify. Â The pain is that it doesn’t seem to take wildcards, but you can use make to have it do your work for you, or just a batch file…
uncrustify.exe --replace -c 1.cfg cl_main.h
you get the idea.
The key thing is the configuration file that tells uncrustify what to do. Â To convert C++ comments to C is quite simply:
cmt_cpp_to_c = true
And away we go. Â Having learned the ‘null’ lesson of Quake 2 the hard way, I started out with a working copy from Windows, via GCC 1.40 for Windows/RSXNT. Â I figured that by having a ‘known good’ build with the a very close compiler level would be a good start as I don’t want to fight too much with the compiler. Â After it was running with minimal changes, it was time to start the real fun.
Starting the actual port aka platform issues
The first error I hit was:
Error: Couldn’t realloc lumpinfo
For some reason the SHARP/Hudson LIBC has issues doing a realloc.  I have no idea why.  Over on nfggames Neko68k had mentioned that he had a disk image with a working version of GCC, that uses different includes/libraries that was able to get further.  I wasted some time by trying to bypass the Sharp LIBC malloc function by calling the HumanOS’s malloc directly which did get further but ran into issues when switching from usermode to supervisor mode to directly access the hardware.  Once when he shared his disk image, I was able to see how his GCC setup worked, and more importantly linked, so I could alter the GCC cross compiler I was using, and get much further in terms of progress.  I could then get from failing malloc to this:
startup errors
And from there after trying different assemblers, flags, and all kinds of other things we could finally get null DooM running on the x68000 via 68030 emulation on XM6 TypeG.
null DooM running on the x68000
DooM comes to life
From there, Neko68k was able to do something amazing, add in system support! Â Which to be honest would have taken me forever to do, I was more impressed that I was even able to get the null version running, but Neko68k blew me away with this:
There is no correct palette setup at this point, there is all kinds of issues but you can see the startup logo being painted!
Then with a lot of improvements, and an added keyboard driver it was starting to look like DooM!
And then Neko68k had a major breakthrough with the video, timer and keyboard, and we now have a playable port!
Issues while cross compiling
Around this time I had noticed that when I built a cross compiled version the video for me was garbled. Â After some investigating it turns out that m_swap was not being compiled correctly but rather the endian order was being reversed!
 .dc.l $00000000,$40f00000
instead of:
.dc.l $40f00000,$00000000
I tried re-building, re-configuring my host setup, and I still had the same issue. Â I tried downloading GCC 1.42 and building an i386 SYSV to AT&T 3b1 cross compiler as it too is 68000 based, and I got the same issue. Â Maybe it’s a bug in GCC 1.x cross compilers? Â I don’t know, but since the procedure is small enough, it was easier to just have the native GCC produce an assembly version which I just assemble and link without issue.
Behold! DooM on the x68030!
Yes, there is no audio, but wow it’s playable! Â I do need to map the keyboard better in the emulator, but the key layout in the source is fine.
Downloads
For anyone who cares you can follow more of the porting adventure here:
http://nfggames.com/forum2/index.php?topic=6140.0
Source & binaries are here:
https://sourceforge.net/projects/x68000-doom/
And my cross compiler toolchain is here:
