It had just hit me that I’d never actually installed NetBSD 1.0
So here we go! Â For whatever reason Qemu and NetBSD 1.0 see the floppy as a 1.2 MB, so I had to make 1.2 MB images. Â For anyone feeling like shuffling a whole lot of floppies here you go!
I’ve setup the networking, so you can telnet into the VM, and of course access outside, but remember with SLiRP, things like FTP & NFS aren’t going to work.
I tried the x86 version from Apple’s Darwin web site. Â For those who don’t know Darwin was (is?) an open source version of the OS X kernel and userland. Â This was on parity with the OS X 10.1 release. Â It was notoriously picky about hardware back in 2001, let alone anything today, and much to my amazement it installed fine on Qemu 2.7.
For anyone who wants to run this under newer versions of Windows as I know I can’t install it on Windows 8 or 10, I installed it on my Windows XP x64 machine, and uploaded it here as vc2003toolkit.7z
By the time this came out, Microsoft had started to admit that they had lost serious ground to GCC, as for years they had neglected the low end $99 market that they had dominated during their fights with Borland in the QuickC vs TurboC days.  Once Borland had withdrawn from the market, Microsoft felt no need to compete and this left plenty of time for GNU tools to take hold in the marketplace.  This was a stopgap reaction as a prelude to the Visual Studio Express that would happen in 2005 onward.
Elsewhere I’ve been able to find an old Windows 2003 SP1 Platform SDK image, it should certainly let this compiler build far more interesting things. Â Although unless you really need 2003, you really ought to look at newer stuff. Â Unless you like really old stuff, then as a reminder the Win32s 1.1 SDK includes the version 8.00 compiler from 1993 as well. Â You can download it from here:Â win32s-1.1-build-88-msvc32sdev.7zÂ
I know one thing right off is that the quake server status is ‘mixed content’ aka it’s retrieved over http.
The new version of Chrome is going to start alerting to non HTTPS sites, so it’s only a matter of time before everyone else starts to require it.. Sigh.
While on the road, I stumbled onto a link that referred to this program called Exchange, which is a decapitated ‘port’ of CP/M that simply allows you to read and write CP/M disk images. Â While on the surface it may not seem much, but the fact it actually uses the 68000 kernel from CP/M seemed really interesting to me. Â With minor fighting I had it running on MinGW!
And what fun would that be if we left it there? Oh sure you can get files in and out of standard 8″ images, but can you run them?
Over at the Takeda Toshiya’s page, not only does he make the MS-DOS player, and a whole host of other Japanese machine emulators, but he also has a CP/M player that works in the same style!
So, combine the two, and now you too can trivially export and import files for emulators like SIMH, or just run files naively at the Win32/Win64 command line!
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:
