Really, all the hard work was by neko68k, I just mashed enough old GCC to get something to do something.
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:
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.
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!
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.
For anyone who cares you can follow more of the porting adventure here:
Source & binaries are here:
And my cross compiler toolchain is here:
So the first thing you’ll need is Neko Project II. It can be a little hard to track down downloads, but there is a whole slew of them here:
http://ux.getuploader.com/emu/index/1/date/desc the site has since moved to here:
So for now this link, is the latest build, which was last updated on
Extract that, and rn np21nt.exe
You’ll want to configure the sound.
If you choose to use the MIDI you’ll have to map them to a MIDI-OUT port, and I used the default Microsoft GS Wavetable. Of course you could use MUNT, or any other MIDI mapper or port. Also you may want to setup the serial port MIDI as a backup plan.
The sound effect settings work best for the PC-9801-86 audio board.
I’ll save installing MS-DOS, and installing DooM for another fun episode, but to configure DooM.
Run setup.exe to setup DooM!
The menu is simply:
- 1 graphics
- 2 Background Music
- 3 sound effects
- 4 not sure
- 5 controller
The PC9821A driver works best from what I’ve done in my limited testing. I guess if you had a different emulator, or a real PC-98 you’ll get more out of this.
Next is the BGM or music
You really have 2 options here, #3 for the PC9801 driver which uses the YM2608 chip. Or the General MIDI either option 4 or 6. I didn’t notice any difference between the two of them, they both sound kinda slow, but workable.
Now for the audio board, select the PC-98
The PC-9801-86 is what you want here. Now with either a 100% PC-9801-86 config, or a 50/50 of the MIDI/PC-9801-86 we are ready to run DooM! Selection option 6 and away we go!
And all being well you’ll get the start of DooM!
Otherwise you’ll get this fun error:
In this case I had emm386.sys in my config.sys which conflicts with the dos extender DX386.
Personally I find it easier to boot off the #1 install diskette which will automatically start DooM!
If you are feeling brave, listen!
I found this talk rather interesting!
I didn’t know that the Jag DooM was considered a reference platform. It’s an interesting talk about the rush job that was 3DO DooM, along with a small talk on fixed point math and other inside information on software development. It is a little long, just over an hour.
From his twitter post:
It’s been 21 years since I made a DOOM level. Here’s my version of E1M8 using DOOM1.WAD.
The download link on dropbox:
From the readme:
Advanced engine needed : Limit-removing source ports
Primary purpose : Single Player, Co-op, Deathmatch
Title : Tech Gone Bad
Filename : e1m8b.wad
Release date : Jan 15, 2016
Authors : John Romero
Email Address : email@example.com
Others Files By Author : doom1.wad, doom2.wad
Misc. Author Info : My previous Doom levels were made in 1995 for The
Ultimate Doom (e4m2, e4m6), so this is a warm-up.
Additional Credits to : John C., Adrian C., Tom H., Kevin C., Sandy P., Dave T.
Pascal “CodeImp” vd Heiden for Doom Builder
The Doomworld Community
Linguica and J.P. LeBreton for Testing expertise
General Description : My Boss level replacement for e1m8…22 years later
After exiting the Computer Station you knew the worst was up ahead. You still hadn’t
reached the place where the demons were coming from. The steel door shuts
behind you as you realize you’re there; you’re at the Phobos Anomaly. Cracks from
hell are all over the place as seepage from the portal invades the entire installation.
Now it’s time to find the portal and stop the demons from coming through. You know
UAC had hundreds of scientists working at a high-tech lab somewhere in this area, and
the portal must be connected to it somehow. Time to lock and load.
* What is included *
New levels : 1
Sounds : No
Music : No
Graphics : No
Dehacked/BEX Patch : No
Demos : No
Other : No
Other files required : Doom1.wad or Doom.wad
* Play Information *
Game : Doom 1
Map # : E1M8
Single Player : Designed for
Cooperative 2-4 Player : Designed for
Deathmatch 2-4 Player : Designed for
Other game styles : No
Difficulty Settings : Yes
* Construction *
Base : New from scratch
Build Time : 2 weeks, in spare time
Editor(s) used : DooM Builder 2
May Not Run With : Doom2.exe
Tested With : ZDoom 2.7.1, Crispy Doom
Known bugs : No
* Copyright / Permissions *
Authors may NOT use the contents of this file as a base for
modification or reuse. Permissions have been obtained from original
authors for any of their resources modified or included in this file.
You MAY distribute this file, provided you include this text file, with
no modifications. You may distribute this file in any electronic
format (BBS, Diskette, CD, etc) as long as you include this file
intact. I have received permission from the original authors of any
modified or included content in this file to allow further distribution.
I tried it with DooM v1.1 and v1.9 and they both load up the level but at certain points may bomb out with a R_FindPlane: no more visplanes. So you’ll want to use ZDoom or Crispy Doom as indicated in the readme.
But for those who want vanilla, remember to load up the WAD like this:
DOOM -file e1m8.wad -warp 1 8
Or alternatively you can jump to the level by typing in idclev18
In the mid 90’s the CD-ROM format was becoming insanely popular, and seen as a ‘get rich quick’ scheme for a brief time. And of course one of the greatest, customizable games ever, DooM is from that era! Combine the two, and you have an awesome collection of shovelware CD’s featuring DooM utilities, mods, and levels!
Perhaps one of the more popular CD-ROM distributors was Walnut Creek, which had a good relationship with FreeBSD. Oddly enough it would eventually merge with BSDi, and split, merge, acquire, become acquired by others.
So the floors and ceiling render, but the walls are all screwed up… so close!
More info here:
Everyone is calling it v0.3 as it aptly falls between the 0.2 and 0.4 alphas.
Sadly I don’t have time to check it out, but I had to mention it.
So I was hammering out something with SheepShaver (more on that later!) and I thought a quick test of just how fast SheepShaver is vs a real PowerMAC would be interesting. So I was playing with my old copy of SoftPC, which is 68000 based, but There were PowerPC versions, years ago when I bought a G4 to run OS X to only find out that it wasn’t supported (the dark days of OS X Server 1.0, before the 10.0 public beta) I used to run Windows NT 4.0 on SoftPC on MacOS 8.6. Ugh, dark times indeed!
So with some luck, I got SoftPC 3.0 up and running on MacOS 7.5.3 using SheepShaver for Windows. Then I noticed that unlike SoftPC for the 68000, SoftPC for the PowerPC emulates a 486! So how does DooM run? A little slow, it’s kind of dream like.
But since there is Windows and a 32bit processor, I thought this would be a great time to load up Win32s, Video for Windows, WinG, and WinDooM!
And much to my amazement it runs! And I was further impressed that there is a shim sound driver, and it works!
So I made a quick video to compare DooM for Windows vs DooM for MS-DOS on this setup.
Yes it’s pointless, but I kinda think it’s really cool.
As a bonus, here is E1M1 under MacOS 8.0. The MIDI support in 8.0 is MUCH more stronger than 7.5.3! And I should add, it actually feels faster on 8.0 than 7.5.3
No I’m not dead, just been busy.
But here is some interesting things I’ve seen the last while:
Infer: static code analysis from facebook of all people. Supports C, Objective-C and Java.
Dr Jack Whitham’s blog, with some interesting stuff related to compiler optimizations and how they alter floating point results, along with ‘bug 323‘, and some DOOM fun! Plus he has his updated source repositories online here.
And finally, Building A 10BASE5 “Thick ethernet” network. A fun look at the first gen ethernet cabling on ‘slightly’ newer machines.