This just in, I have just booted Research UNIX v9 on TME’s SUN-3 emulator!
And there we are booted up and logged in.. pardon the disk error..
I’m slightly hesitant about uploading it, as it clearly isn’t right… And this is only the binary component, I have integrated the source tree onto the disk image. But I haven’t actually tried to compile anything except a simple hello-world program. You can download it here from sourceforge: SUN3-research_v9.7z If anyone want’s to browse the source, it’s on my CVS browser thing.
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.
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!
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:
Behind it all is the Scripted Amiga Emulator. What is more interesting is that there has just been a MASSIVE update/rewrite to the project and it is now boasting far more features!
Looking at the features page, there has been quite a number of updates since the last version. The big ones (to me) is that the CPU core has been rewritten, and now supports not only the 68000, but the 68010, 68020, and 68030 (only with fake MMU). OCS, ECS and now AGA as well! Preset models include the 1000,500,2000,500+,600,3000 and 1200. IDE disk files can even be mounted for the 600 & 1200!
But sure enough, the file GNUMPW.SIT, and the later gcc-1.37.1r15-all.sea.bin are the real thing! The file GNUMPW unstuffs to GCC 1.37.1r7(All), although Stuffit 5 and higher won’t unpack the file, I’ve converted it unpacking with version 4 & repacking with 5.5.
The readme from r7 is dated November 2nd, 1990. I found some history on this port on the archives of the GCC mailing list here. The port was done by Stan Shebs, while working for Apple. As he states the port started in 1989 and was first used in an abandoned m68k based project, and later a possible replacement for the Apple compiler for OS 7.
For this experiment I was using the r15 version, as I didn’t find anything out about the prior versions until after I had written this.
GCC on MacOS needs the MPW environment, which for me is incredibly awkward to work with. While some people may love it, it is very strange in that you have to highlight commands in the window, then hit clover+enter to run them. Like a mainframe, you can input commands wherever in the screen.
The next hardest thing was finding a version of MPW that will work with this. It needs the MPW C compiler for it’s includes, and libraries. The 3.5 stuff didn’t seem to work for me, however doing a LOT of searching, and I did find a ‘toast CD-ROM’ image‘ of 3.1 that includes all the C, and Assembler tools that I need to build an executable.
I also don’t know why, but running make just shows me what needs to be done, it never actually makes anything. I’m probably doing something wrong, but for such a long dead tool, trying to find out how to use it, or how do you interrupt a “stream” like manually running cc1 is beyond me. I just have to force quit the emulator.
But beyond that, running make gives me the steps, and I manually select and run the steps, and I was able to get a program to run!
I know it may not look like much, but getting it to actually run something was quite monumental for me!
There were some issues compiling input.c, as it didn’t like the external table, so I made it’s own local table. It also didn’t like some pointer arithmetic, but making GCC happy only gives me a program that can’t recognize any verbs. And from there it won’t quit, basically hanging the system.
I’m sure I’m doing something wrong, but at the same time it was interesting to see GCC on MacOS, during the whole GNU boycott of Apple for the ‘look and feel’ lawsuit against Microsoft. No doubt it let a lot of people sell other C compilers on the Mac Platform during this window of time.
GCC requires a 68020 processor, as GCC’s native 68000 based target would be SUN-2 hardware. While it can compile with the -m68000 flag, I haven’t tested with a 68000 based emulator to see if that’s even true. In the off chance someone wants a combined MPW+GCC I made a disk image here: MPW 3.1 with GCC 1.37.img.gz. Disk Copy 6.3 should be able to mount it OK, or any emulator that likes HFS disk images.
This one should have been much easier to build, it has support for SDL built in, however the include files are a nested mess, and configure fails part of the way in the process leaving the source kinda messy. But a few hours over a couple of days, and here we are.
This version doesn’t run at warp speed, has sound, and is great. It wants a config file though. You can find the specs in the readme, but something like this:
works fine. This later (and seemingly last) branch of UAE incorporates lots from WinUAE, except for the JIT. It’s dated 2008, so it does include support for the 68030, 68040, and the 68881 and 68882. It doesn’t have MMU support, so things like Linux/AMIX/NetBSD/Enforcer are out of the question.
I can’t find any source of the 0.5 versions, and I had issues with 0.6.x but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?). I suppose with this version working I can go back and take a stab at resurrecting 0.6.x
What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.
I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta. So now you can actually use the CLI, and change disks. Double clicking is an impossibility as it simply runs far too fast. I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.
I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast. UAE is from an era where a 100Mhz computer was a luxury item. Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.