I got bored, and imported the Jaguar Doom, Linux Doom, the DJGPP Doom, Hexen & Heretic into that cvs web thing.
So building on DOOM, I thought I’d try to build a djgpp cross compiler from my main OS X box, as compiling under DOSBox is… just too slow. Luckily Delorie has a page on building a cross compiler.
I started out with binutils-2.9.1, just as he does, with a few things thrown in…
First I had to run configure like this, as OS X didn’t exist back then, let alone x64 cpu’s..
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
Next the following error is thrown…
strerror.c:463: error: conflicting type qualifiers for ‘sys_nerr’
So I just edited libiberty/strerror.c, and commented out the following line.
Next up was a strange error in gas/targ-cpu.h
targ-cpu.h:374: error: array type has incomplete element type
targ-cpu.h:378: error: previous declaration of ‘flag_16bit_code’ was here
I simply commented out the lines.
Then later while compiling gas/write.c it bombs out because of an undefined type.. One of which was commented out in targ-cpu.h . The easiest fix is to go to the start of the relax_align procedure and just add in the definition:
extern const struct relax_type md_relax_table;
Next up was gcc. I couldn’t get 2.8.1 to build, instead I built gcc-2.95.3.
I had to configure gcc like this:
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
And it threw the same error as binutils… with the same fix (commenting out the line in libiberty/strerror.c).
strerror.c:465: error: conflicting type qualifiers for ‘sys_nerr’
I also had an error pop up like this:
./config/i386/i386.c:142:22: error: macro “strcat” requires 2 arguments
And again I just commented it out.
Under OSX the makeinfo parts crashed, so I simply removed them from the makefile. With a little more tweaking the cross compiler was ready!
REMEMBER TO FOLLOW DJ’s steps too!
The cool thing is that now I can run make with the -j4 flags allowing gcc to run on each of the cpu cores letting me build doom in under 3 seconds!
i586-pc-msdosdjgpp-gcc -O2 -DNORMALUNIX dos/doomdef.o dos/doomstat.o dos/dstrings.o dos/i_system.o dos/i_sound.o dos/i_video.o dos/i_net.o dos/tables.o dos/f_finale.o dos/f_wipe.o dos/d_main.o dos/d_net.o dos/d_items.o dos/g_game.o dos/m_menu.o dos/m_misc.o dos/m_argv.o dos/m_bbox.o dos/m_fixed.o dos/m_swap.o dos/m_cheat.o dos/m_random.o dos/am_map.o dos/p_ceilng.o dos/p_doors.o dos/p_enemy.o dos/p_floor.o dos/p_inter.o dos/p_lights.o dos/p_map.o dos/p_maputl.o dos/p_plats.o dos/p_pspr.o dos/p_setup.o dos/p_sight.o dos/p_spec.o dos/p_switch.o dos/p_mobj.o dos/p_telept.o dos/p_tick.o dos/p_saveg.o dos/p_user.o dos/r_bsp.o dos/r_data.o dos/r_draw.o dos/r_main.o dos/r_plane.o dos/r_segs.o dos/r_sky.o dos/r_things.o dos/w_wad.o dos/wi_stuff.o dos/v_video.o dos/st_lib.o dos/st_stuff.o dos/hu_stuff.o dos/hu_lib.o dos/s_sound.o dos/z_zone.o dos/info.o dos/sounds.o dos/i_main.o \
How’s that for fast?
For any curious OS X 64bit users out there you can download my binary toolchain here.
I would imagine that if you stuck with versions of binutils & gcc that build on your platform you too should be able to build a MS-DOS DJGPP cross compiler. And there is nothing like native 64bit tools for building for DOSBox… Oh and DOOM runs just fine, although I guess screen shots of the cross compiled exe is… redundant.
Today while checking out eets on steam ( yeah I know… ) I came across this sale… It’s Doom, Doom II, and Doom III all together, with all the expansion sets for $8.74 USD!
Well needless to say I couldn’t resist the offer, so I bought it. While playing around with Doom, I was wondering what was the first port of the Linux X11 doom back to MS-DOS. A bit of googling brought me to the doom wiki, and from there it seems that “DOSDoom” version is the first source port returning DOOM back to MS-DOS.
I did find out the hard way that there is a single assembly clause that breaks under newer versions of DJGPP, and there is a small issue with the HOME environment variable that if it’s not set it’ll crash DOOM. So I ‘fixed’ that to use the current directory.
To install this legacy version of DJGPP, I found the needed files..
Simply unzip all of this into a directory that your DOSBox mounts, and alter your dosbox.conf something like this:
# Lines in this section will be run at startup.
mount c c:\dos
Then you should be able to extract the doom source that I’ve patched up, and run make to re-build the exe. I’ve included a shareware wad file that won’t explode on missing demos…
So the end result is the following:
Which… has no networking support, no audio, but it does work! This port is overall minimally invasive to the code, and I’d suspect it’d make it a very easy starting point for yet even more ports of doom… I think there is over 40 out there.
That’s the one great thing about making the source available, is that the product lives on and on!
I came across this 386 emulator, Aeon(updated to use archive.org, as it’s dead now). What is interesting is that it’s written in C#!
That’s right it’s all managed code…!
If you can run .net 4.0 you may want to check it out, it’s quite capable….
The DPMI is good enough to run doom, and quake! While slower then DosBOX, I’d still say it’s a contender, you can never have too many possibilities…
So I got myself a ‘5’ user version of UnixWare 7.1.1 to add to my collection, along with a copy of Word Perfect 5.1 for UNIX (i386 SYSV it would seem).
From the wikipedia link, 7.1.1 was the last release from “old SCO” the company that brought us exciting things like Xenix, SCO Unix and SCO OpenServer (although it’s about as ‘open’ as VMS).
Anyways I went ahead and installed it in Virtual PC 2007, and it was a pretty straight forward install. The only catch has been that if you suspend the virtual machine, the networking will cease to function. And as it stands right now I don’t have any sound, but I doubt that’ll be that big of an issue.
So I broke the nice and new shrinkwrap on the Word Perfect, and went through some minor hell trying to get the first disk to untar, as it states on the diskette and in the installation manual.. Eventually I found this worked in my Virtual PC:
tar -xvf /dev/dsk/f0q18d
Then I just ran the ‘wpinstall’. Now what is weird about this install is that word perfect then just has you hand it all the disks in any random order, then it’ll start to configure itself. While it does support over 200 terminal types, it seems that the “dtterm” console is not among them. Also what was weird is that for the X11 component the Univel UnixWare (the direct descendant to SCO UnixWare) did *NOT* work, while SCO Unix did.
I would imagine if you had a pre 2000 release of any Linux you could run this via iBCS, however that project seems to have died on the vine. The last time I tried to run Xenix stuff on NetBSD/FreeBSD & OpenBSD I was met with kernel panics and disaster. I don’t think anyone runs this stuff anymore, and now that we know how to run Xenix under Qemu/Virtual PC I guess that basically takes care of that.
Speaking of Xenix, it would seem that all of the 7.x releases of UnixWare do not include compatibility for the x.out exe format either.
At any rate, I figured I could just go ahead and run my builds of Quake & Doom on a seemingly ‘slightly’ older 7.1.1 without issue.
That was not to be the case.
dynamic linker : ./quake : error opening /usr/lib/libm.so.1
Well that’s a bummer, if I do say so myself. Thankfully this version of UnixWare included the compiler (and a license) along with the OpenServer/UnixWare development CD so I had the ‘official’ X11 headers & libraries, unlike what I had to do under 7.1.3
So I ended up shuffling around my UnixWare stuff to separate the 7.1.3 from the new 7.1.1 stuff.
In retrospect, I would imagine you can run 7.1.1 binaries on 7.1.3, but not the other way around… But in retrospect, that is to be expected.
I’m not sure how to even play with the X11 configuration so right now I’m limited to 256 colors… But you get the idea.
I’d never actually built Doom from source before… It was more involved then Quake, or maybe I’ve done Quake too many times? Anyways one thing that stuck out to me, is that you HAD to define NORMALINUX, or it wouldn’t pick up wad files or much of anything…
I guess other then that, I didn’t even try for sound… As a matter of fact, I think I’m pretty much done with UnixWare, but at the same point it’s a little more ‘fun’ then I found it.
This reminded me of my own work to add pcap into Qemu back in the 0.9.0 days… SO I figured I’d try to build the thing out and see how they interact!
So the first thing to do was build DosBOX, and add the patch. I found that 0.73 worked pretty well for this!
So after some hammering around, I got it to build, and launched it on two separate machines (one over terminal server) on my lan, and launched the oldest network doom version I could find to get things going.
And there we go. Now in the dosbox.conf you have to make sure that they have unique MAC addresses, and of course, that they are bound to the correct physical nic. in the config file, there is a list option that will print out the possible choices then you can just put the number, or the full name into the right spot on the ini file. I’ve build a prebuilt win32 version of this with all the DLL’s and the gravis ultrasound enabled… You can download it here.
The next thing I did was search high & lo for my patches to Qemu, and thankfully I’d emailed them to myself as it seems all the other places are dead… So with a little playing with Qemu 0.90 to enable the adlib, and remove some logging messages, I’d built a client machine again with Doom. Naturally I had the DosBOX & Qemu face each-other off.. Sadly this is a little SLOW.
Now for Qemu, you’ll need to get that full NIC name… Dosbox provides a great way to see what it is, just paste it into the batch files, and you’ll be good to go.
And remember you’ll need WinPcap installed!!!!!!