The Nightmare Of Getting DOOM Running On A Serious Business Machine ...
*[DOOM playing with sound on the RS/6000 * *game suddenly locks up* N: It locked up, didnt it? This sleek black monster is an IBM RS/6000 43p, Model 150. On the surface, this might seem like just an ordinary PC, but that’s certainly not the case. Instead, these machines were once the backbone for many businesses across the world, and were designed to perform a wide variety of tasks. However, I’m fairly certain gaming wasn’t a consideration for anyone buying one of these, and I find it greatly amusing to use a serious business machine for playing DOOM. That being said, in this case, this is more a means to an end though. After all, nothing tells you more about a system than the process of actually building software for it, and *chuckle*, Let me tell you let me tell you, from start to finish, this entire process involved pain, suffering, and more than a few obscenities.
[RS/6000]: Left Channel WAV Test ... *chord* However, I consider that suffering well spent, since now I can show you all just what makes a RISC Station tick, and the ups and downs of IBM’s own unique variant of UNIX, known as AIX. As usual, this is your host NCommander, and let’s take a trip. [screen pans out to a circle of with chapter marker name] I won’t be surprised if most people aren’t familiar with IBM’s RS/6000 line, or its successors. The RS/6000 line was essentially IBM’s main line of PowerPC computers, and at one point, they were essentially intended as replacements for IBM’s PS/2 and Personal Desktops. Earlier versions of the RS/6000 were capable of running a variety of operating systems, including special versions of Windows NT, Solaris, and even a port of OS/2. All of this was born out of the AIM alliance, which was a partnership between Apple, IBM, and Motorola, to try and recapture the PC marketplace and break the Microsoft-Intel monopoly.
My system, unfortunately, is a bit too new to run any of those. However, as a last remnant of these lofty dreams, you can still see an Apple Computer copyright message on system startup. Let’s take a moment to look under the hood. As you might expect from the heritage, RS/6000 machines aren’t exceptionally different from Apple’s own PowerPC offerings. Starting from the top, we have a GXT255P graphics card, and an UltraWide SCSI card. I'm not sure if said card is factory original, or something that was added at a later date.
After removing the PCI cards, we can remove this locking screw which lets us lift up the crossbar that holds the 10 GiB HDD in place. Afterwards, we remove the PCI riser card, and get a good look at the motherboard, which is powered by a PowerPC 604e CPU clocked at 375 Mhz. As I originally got it, this machine came with 128 MiB of ECC SDRAM, although I’ve added an additional half gigabyte to 640 MiB in total. Spinning the system around, we have the usual assortment of ports. We have normal PS/2 keyboard
and mouse jacks, a parallel port, and onboard Ethernet. Next to that, we have an UltraSCSI connector and audio jacks, which are powered by a Crystal Audio CS4232. Directly above, we have an Ethernet AUI connector, and then one slight oddity. This DIN connector is labeled as a tablet port in the manual, although I couldn’t find out what tablets may or may not be compatible. Finally, rounding out the set we have two serial ports, with one by
default being the system console. It’s pretty easy to see that aside from the PowerPC processor, the hardware isn’t all that different from what you’d find in a typical PC of that era. Earlier RS/6000s were actually built around IBM’s microchannel architecture, which highlights the many parallels between this and IBM’s PS/2 line of PCs. Turning the system on, we can immediately spot this amber LED for displaying check code, which indicates boot status and more. This is really handy since it can take over a minute before the system actually starts to display anything, and provide diagnostic information as well. I’ve actually had to depend on this more than once, since my system has been
showing signs of dying , and will occasionally fail to start. However, assuming everything goes as planned, you’ll get self-test messages on the display. At this point, hitting F1 on the keyboard will enter “System Management Services” or SMS. SMS is IBM’s take on traditional PC BIOS setup screens, although it feels somewhat incomplete. For example, while I can view the system configuration and boot settings,
there’s no option to set the time or date, or even enter the system diagnostic mode directly. Conversely, it has surprisingly sophisticated UIs for handling network booting, which I can’t imagine would be a common setup. Under the hood, all of this is powered by OpenFirmware, and it's possible to drop to the traditional 0> prompt if so desired. One thing of note though is that it’s also possible to configure SMS to use a serial console, which allows for fully headless operation. In theory, it should be possible to do everything via serial, although in practice, that didn’t quite work when I tested it. The system seems
to get confused if it's running over serial, while still having a graphics card installed. While I could do system configuration, I couldn’t get AIX to properly install in this state. When I tried, it ended up hanging on the first reboot. I will note that the maintenance and diagnostic modes worked just fine. That being said, personally, I think graphics are kinda neat, and you know, are a bit essential if we want to run DOOM after all. However, we’re going to need to load an operating
system before going anywhere, and thus, let’s take a look at IBM’s Advanced Interactive eXecutive, or AIX. Throughout the 80s and 90s, it wasn’t uncommon for the major computer vendors to have their own variant of AT&T’s UNIX. IBM was no exception to this rule, but their offering, AIX, is somewhat quirky to say the least. While it’s generally associated with PowerPC, AIX itself actually dates back to 1986, and it was available on a variety of IBM platforms. Infact, there
was even a PC based version for the IBM PS/2 offered until 1992. For this project, we’re going with AIX version 4.3, which was what this machine would have initially come with. The installation CD is bootable, and after quite a bit of loading, we’re asked to select the system console, and language before being brought to a main menu of sorts. Even at this point, we can already start seeing that AIX has a rather different look and feel to it. For example, options are entered and selected via numeric code.
For the next 20 minutes or so, the installation will simply grind away so this gives us a good opportunity to talk a bit more about how AIX differs from other UNIXes. I suppose the easiest way to describe it is if engineers at IBM looked at UNIX, and went “oh no, that won’t do at all”. Yeah, I'm probably going to hell for animating that Taking it a step deeper, once installed, almost all the system configuration can be done with easy to use tools. AIX’s System Management Information Tool, or SMIT, is one of it’s
more iconic features, and it provides a level of consistency that I find isn’t present on most other UNIX and UNIX-like operating systems. SMIT itself is also complemented by the Web-based Service Management or WSM, which provides a Java-based GUI for controlling the nuts and bolts of the system. In my personal experience, AIX’s SMIT is pretty much the gold standard for UNIX configuration, and it's something we’ll see a lot of in this video. I’m going to gloss through most of the system setup, mostly because it’s just me banging my head on a table for a few hours, but I’ll give you something of a highlight reel.
Right out of the get go, after the first stage system finishes installing, we’re greeted with a graphical install screen to handle things like setting the root password. It’s here I made two critical errors here. First, despite the fact I filmed this in March, I set the system clock to 2021 without realizing it, which caused numerous build issues days later due to clock skew. This is clearly a sign that I’m just living in the past. It was also trivial to fix unlike my second mistake. A few screens later, I accidently left the system paging partition too large. Fixing
this requires studying tomes of eldritch lore in an effort to decode the necessary runes to recreate it at a more reasonable size. May Deep Blue have mercy on my soul. In hindsight, I should have just reinstalled the system, but well, I guess it was good practice? By mistake, I actually went for an encore on this specific footgun. AIX uses very small volumes by default, so you need to grow them as you go. At one point, I made the home logical volume much larger than I intended. That wouldn’t be such a big problem, except on this version of AIX, you can’t shrink them later. Oops.
Anyway, the backup and restore that followed wasn’t too bad. At least the later AIX 5L fixed both of these particular headaches. Another glorious fail came when I accidently broke the entire graphical environment. This was because I changed the system hostname to helios, and then didn’t update the hosts table in SMIT. This was really egregious because I knew old UNIX really REALLY cares about host name resolution, and I should have known better. At least it was an easy fix. Finally, AIX might actually win an award on “worst X11 configuration pain experienced to date”, which is really notable considering its main competition is ancient Linux. While
basic functionality worked out of the box, as it turns out, if you want to commit the sin of using OpenGL, and or having high color modes, you will pay for it, either in sanity, or IBM support contracts. However, we’ll explore that trainwreck more in-depth a bit later because holy hell that needs its own section. I’m also glossing over what I had to do to get a working sound, and more, *DOOM making noises* To say the road to DOOM was built out of good intentions was far more literal in my case than most would expect. Before we move on, I suppose I should give folks a tour of the system but … well, there’s no good way to say this. There’s not a lot to see beyond what I’ve already shown.
AIX shipped with the Common Desktop Environment, or CDE, but there isn’t a lot included in the box. Beside Netscape, the primary things on install discs were server applications like DB2 and WebSphere. There is one exception, but I’m going to let this one speak for itself.
*RS/6000 rocking out* *old NCommander narrating the intro to Space Cadet PInball* Meet IBM’s Ultramedia services or UMS for short, a full set of multimedia tools, including screen capture, editors, and even broadcast utilities. It even includes VideoCD playback support, although I couldn't work. I may have just done something wrong when making the disc though. It appears there was an entire IBM media stack that more or less has been forgotten by the sand of time I've overlaid some screen captures taken by UMS as a demonstration, although sadly it doesn’t stay in sync as it doesn’t record at a consistent framerate. It also causes AIX to lag something fierce. I personally had never heard of UMS
before now, although that’s not entirely surprising, given it was removed in AIX 5. Unfortunately, it seems to require dedicated hardware to do anything beyond the basic basics, but I did set an eBay search alert. This is a good time to remind people to support the channel so I can continue to make weird and wacky videos. However, shameless plugs aside, the only other real graphical application that’s included in the box is Adobe Acrobat Reader. So you know, nothing really to write home about,
It’s nice seeing a native UNIX version though. As far as third party apps go, well, I found this port of Freecell made by Mainwin, you know the same folks who ported Internet Explorer to UNIX … that’s kinda neat … Yeah, OK, even I can’t sugar coat this. The state of AIX’s desktop is pretty sad overall. For the most part, AIX really isn’t suitable as a daily driver, despite being marketed as a workstation for several years. I can’t even find proof a port of StarOffice or another office suite was ever made. As far as I can tell, the only way you could use AIX on a day to day basis is if you loaded it up with a bunch of free software utilities. I suppose that was IBM’s thinking as well,
since they did start offering their “AIX Toolbox for Linux Applications” around this time as well. Now, it might seem weird to bring up Linux in a video about AIX, but this more of an example of IBM having grandiose names for rather mundane things. Instead of some sort of Linux Subsystem or compatibility layer, big blue merely recompiled a large chunk of Red Hat Linux, and made it available for AIX 4.3 and later. This, among other things, provides GCC, support utilities, and more. This is really handy since I was going to need a compiler, and such a collection would make my life much easier. Now, I should note, there are other collections of pre-built software for AIX, such as Bull’s archives, but the Toolbox is still updated for use in modern versions of the system, and personally, I wanted to see what IBM was offering.
Just for the sake of clarity, while IBM does make the Toolbox freely available, it's not officially supported by them. That being said, I’m pretty sure it's a fairly common find on most AIX systems. Now, normally setting up development software isn’t what I call rocket science. However, that process doesn’t typically involve reconstructing damaged archives, reviving long dead desktop environments, or spending days debugging GNU bash, so, we’re going to take a brief side trip into looking into how the machine that built the machine was built. One thing that makes our lives a bit easier is the fact that the Toolbox for AIX 4.3 is
still on IBM’s FTP server. Before we can install it though, we need to system updates, as well as load the RPM package manager. Unlike the nightmare that is Solaris’s install-cluster script, installing patches on AIX is pretty straight forward. You just need to download the archives, decompress them, and point SMIT at the resulting directory. This brings the system up to Maintenance Level 11. After a reboot, you’re more or less good to go,
but we then start to see a problem. AIX shipped with Netscape Navigator out of the box, which I had been using to browse FTP archives, and download files. After installing ML11, it stopped working with a rather cryptic error message. What happened is that AIX actually can suffer from its own variant of DLL hell
which I’d inadvertently stumbled into. The root cause was that Netscape had shipped an older version of AIX’s C library, which was incompatible with the updated ML11 components. I was able to fix this by updating Netscape’s libc.a, but as I found, AIX’s shared libraries, which, confusingly use the .a suffix, are not normally versioned, which means you can
have subtle compatibility issues if you’re not careful. I have to admit that I still find it surprising that IBM shipped an update that broke an out of the box package without warning. That said, even with patches installed, getting the toolbox loaded is not an intuitive process.
First, we need to install RPM itself. There are multiple RPM packages on IBM’s FTP with no useful labeling. For AIX 4.3, I found that RPM 3.0.5.35 works. Once downloaded, this has to be installed with the installp command, which sets up RPM properly. Afterwards, you’re
supposed to download the base set with the provided shell scripts, and then install them with RPM directly. This requires that you have wget from somewhere else, but I managed to use the copy from Bull’s Freeware archive without issue. There’s no high level package manager like YUM for AIX 4.3, but IBM did provide install groups for various package sets. These include dev tools, and alternative desktop environments like GNOME, and KDE. However, it wasn’t long before I discovered some bitrot. A few
of the RPMs such as autoconf, and xpm were missing. In a case that can be best described as “not knowing when to give up”, I ended up reconstructing the missing packages. For those who might be interested, download links are in the description, but I had a bigger goal in mind.
Now, while I’m fond of the the chiseled 3-D goodness of CDE, there were other desktop environments available in this era. As such, I revive this specter of the past, and relive the glory days of KDE. Of course, no KDE system wouldn’t be complete without its long time rival, GNOME.
It was at this point that I actually ended up replacing dtlogin with KDE’s login manager, since I couldn’t figure out how to add KDE or GNOME to the session list. This required futzing with inittab, and GDM didn’t work at all when I tried it. As a side effect, I also lost the graphical boot as a side effect, but honestly, I got a real kick out of using these old desktop environments, since I used to use these versions of both KDE and GNOME extensively back in the day.
I will say, that I’d say with a bit of theming, you probably won’t be able to tell that this was AIX at glance. However, there’s one slight problem. You might notice the background looks a bit … dithered? It’s more obvious in KDE, but we’re actually running in 256 colors, with no acceleration. This wasn’t obvious under CDE due to the simple color palette, but it's looking really bad right now. As it turns out, getting the Toolbox working was a warning that more pain and suffering awaited. At this point, you might think it was more or less downhill from here, but uh … not quite. Infact, it would be more accurate to say that we have merely reached the tip of the iceberg, in part due to missing documentation, system quirks, and more . The problem with X's color mode more or less foreshadowed how the rest of this project was going to go To make a long story short, figuring out how to change the color mode was one more obnoxious things I've done in awhile Nothing, and I do mean nothing, documents how to do this correctly.
More than once, I managed system in a very strange system in a very strange state while experimenting While SMIT has a few options relating to monitor and VESA modes, none of these options affect the color palette On top of that, the operator's manual for the graphics card alludes to various configuration switches and settings, but doesn’t actually provide a working setup. Meanwhile, IBM’s own documentation for X lists all the switches, but doesn’t specify which ones have to be set. From what I can tell, it supposed to autosense the correct mode based on the type of IBM monitor you have attached, but since I'm using a modern LCD for filming, it was going into some kind of failsafe mode It was only through considerable trial and error that I was able convince X to start in 24-bit True Color mode Even then, I still didn't have working acceleration For the record, you need to add the following switches to X’s startup line for TrueColor, and the file you edit depends if you’re using dtlogin or KDE for startup. Success depends entirely if you have enough VRAM, luck, faith, and probably 30 other factors. If you’re trying this at home, honestly,
the only thing I can tell you is “good luck”. Even if you get that far, there’s still more work to be done. AIX, somewhat surprisingly, actually has more graphical capability than one might expect. IBM did market the RS/6000 for use in CAD work, and supported multiple graphical standards. Among these is the tried and true OpenGL, but to say “some assembly required” is kinda underselling it.
To get OpenGL working, you first need to install it off the AIX system CDs as it's not part of the default install. Since I’m running KDM, I also have to modify its Xservers file to load the GLX extension . However, checking the setup is a bit harder than it should be. In a case of what I can only describe as “screw you”, IBM shipped all the test code, including the diagnostic utilities, in source code form. Assuming you have a compiler, and have done
absolutely everything correct, you’ll be able to confirm that GL is present and accounted for, and all the included demos will run. Which brings me to the point that I’ve been dancing for a bit. AIX doesn’t include a C or C++ compiler out of the box. That is not entirely unexpected,
but it’s a point worth talking about. IBM’s official development tool for AIX has changed names a few times, but in this day and age, it's known as XL C. In 2000, it was called VisualAge C++. I’m not going to use it for this project, but I do at least want to talk about it.
For one, I had retroactive sticker shock when I looked up the prices. IBM’s list price for it in 2002 was $2,495 USD *per user* with a slight discount if you got electronic delivery. Corrected for inflation, that's a cool $3,934 USD today.
Now, I can understand paying for tools, but I really do need to question what you actually got for that price, especially considering that GCC is literally free. I did find some benchmarks from 2003, published by IBM, that claim significant performance increases. If you take their numbers “as is”, on integer workflows, then IBM’s compiler generated code is between 10% to 50% faster than GCC. The floating point performance increase is even more significant. If these numbers are accurate, then VisualAge C++ was easily worth the price of admission. However, I know from experience that benchmarks and real world performance are two very different things, so I’m going to take these figures with a grain of salt. Still, even a modest
10% average speed boost is not something to scoff at. Maybe we’ll investigate it one day, but for now, I’m sticking with the pre-compiled version of GCC 2.9 in the toolbox. For the most part, it works just fine, but we’re not quite out of the woods just yet. One of the biggest roadblocks I ran into is that you can get unexpected results due to system specific quirks. I had expected that this would happen at some point, but I was
a little discouraged when things started breaking minutes after I got Toolbox installed. All I wanted to do is get neofetch running, which proved to be a surprisingly difficult task. Neofetch has one dependency, bash 3.2 or later. The version in the toolbox is too old, and I thought it would be trivial to build a newer version, but as turns out, tempting fate is a BAD idea. Bash would build, but as we can see, running neofetch kinda broke things. I spent a lot of time debugging this off camera, and, surprisingly, I actually found that this is a bug in bash caused by a quirk in AIX.
Internally, bash uses a function called strtoimax, which converts a string of numbers into an integer. It’s part of the C library on most platforms, but AIX 4.3 is a bit too old for it to be there. As we can see here, there’s no manual page for it, nor is it in the system headers. Since strtoimax is not guaranteed on any system, bash’s configure script checks if it's present before using it. There’s a failsafe implementation, so this shouldn’t be a problem in and of itself.
However, if we look at configure’s output, bash thinks it exists, and surprisingly, bash builds without a linker failure. For a non programmer, that might not seem odd, but it should be literally impossible for this to work. It wasn’t until I examined AIX’s system libraries more in-depth did I find the cause. While strtoimax isn’t declared in the system headers, it does exist in libc, and configure seems to check for the symbol rather than the declaration. I wrote a small test application
that demonstrates that not only does strtoimax exist, it actually seems to work when given simple test cases. In bash, strtoimax is used in parsing numeric strings from the command line, but IBM undeclared implementation was causing problems. That’s not hugely surprising, since it was clearly never meant to be publicly used. I only managed to fix things when I
rewrote bash’s legal_number procedure to use the older strtol function. After doing so, we can now run neofetch. Now, it might seem like I found this immediately, but I just summarized literal days to find and fix this problem. I actually had DOOM working well before I figured out what had gone wrong in bash The fundamental bug is that configure is simply using a symbol without checking if its part of the public API There's actually a separate check in configure for checking the declaration But it doesn't seem to affect anything This problem is actually still present on the lastest releases of bash due to the broken configure check so I actually did open an issue about it on bash's bug tracker I also filed several bugs relating to broken checks in a similar vein I will note that neofetch still has a few problems with detecting the memory and CPU speed. That’s because it’s using functions that aren’t present on AIX 4.3. Still, I'm pretty sure that I'm the first to run neofetch on such an old copy of AIX. One other unexplained anomaly is the second line of color bars doesn’t
seem to show up properly on the system. As a reminder, it’s supposed to look like this, but I actually determined the behavior depends on what desktop environment I’m running under. If we load up CDE, we can see that the second color bar shows up as pure white. That was rather tame to what almost
everything else did. Under GNOME, neofetch actually aborts unless I reset the COLORTERM variable, although it does properly detect the theme and icon set. Meanwhile, going to a more basic environment, I found AIX’s xterm appears only to be monochromatic, which was slightly disappointing. However, there is a special “aixterm” that supports color. Running neofetch here had the neat side effect of making the text white on white for pure readability.
Finally, for good measure, I ran it on the console. I wasn’t expecting much, since AIX officially calls its console the “low function terminal” or LFT, but that green and gray coloring makes everything look really good. Still, I think we can chock this one up to how terminals have changed over the last two decades If I telnet into AIX from my desktop, the colors do show up as expected. Still, it’s a reminder that just because various UNIX systems are similar, they can have unexpected pitfalls, and trust me when I say this wasn’t the last snag I would hit. It might seem a bit weird that I spent so much time talking about undeclared functions and more on a project that is theoretically about playing DOOM on a serious business machine, but our old friend Captain Foreshadowing exists for a reason. Now, there were two approaches
to porting DOOM I could take. While most people know DOOM’s source was made freely available, it wasn’t the same code as the original 1993 DOS game. Instead, they actually released the code to the 1994 Linux port done by Dave Taylor. I actually did manage to build this port on Debian 2.1,
although it’s not exactly what one might expect. Let’s load it up, and for the moment, please ignore the slightly broken background colors. Instead, right now, I want you all to listen.
*audible silence* Did you hear that? *more silence* If you heard absolutely nothing, then your sound card is working properly, since this version of the game has absolutely no audio support. Ontop that, DOOM has some interesting issues with its palette. The colors go absolutely nuts unless DOOM’s window has focus. When DOOM has focus, then everything else breaks. Oh, and you have to be in 256 colors and no more, or it will just refuse to start at all. If, for some crazy
reason, you still want to check out the original id source code, I really hope you like tiny DOOM windows, and don’t suffer from eye strain. That’s because the display resolution is locked to 320 by 200, with no scaling options. Just to put that in context, it’s pretty small at 800x600, which is what I’m running Debian at. In modern terms, this is what it
looks like at 1080p. Tiny right? Now get a look at 4k. If your microscope is up to snuff, then this version of DOOM is for you. Now, to make a long story short, with significant patching I actually did get id’s original code to build on AIX. There is however a very large difference between building and working however.
While AIXDOOM would start, and properly display the main menu, it would break not long after. Loading the first level, we can see the status bar is missing, and it would also usually crash not long after. I did spend some time debugging this, but AIX’s 4.3 native debugging facilities aren’t great. Part of this might be due to me using GCC, but neither GDB, nor AIX’s native dbx
could provide beyond basic information. My guess is there are byte ordering issues, as I can build my AIX branch on Debian Linux and have it work just fine. However, I’d probably have to fire up Linux on a big endian platform to definitively determine if that’s the problem one way or another. However, even if I got the original source code working, let’s be honest, this isn’t a great experience, and even if I could get it to work, I’d have to write code to scale the graphics, and implement sound. Fortunately, there was always approach two: build a pre-existing source port.
While there’s a multitude of DOOM source ports, one of the more portable ones is “Chocolate DOOM”, which seeks to recreate the authentic MS-DOS experience on a variety of platforms. Several months ago, I bootstrapped Chocolate DOOM on Solaris 7 as part of a livestream. Due to the similarities between Solaris and AIX, this gave me confidence that this wasn’t a fool’s errand. Well, perhaps I should say it wasn’t a seemingly impossible fool's errand … Well, at least it’s not HP-UX. Anyway, before I condemn myself any further, I should point out that Chocolate DOOM is built on top of the Simple DirectMedia Layer, or SDL, which basically is a giant portability library for games.
SDL provides cross-platform ways to draw graphics and play sound. That’s part of how Chocolate DOOM works on Windows, Linux, and Solaris. Assuming SDL worked on AIX, it should make everything relatively easy, and I had reason to be optimistic. Almost every UNIX and UNIX-like system uses a special framework known as X to handle graphics. It’s due to this shared lineage that I’m able to run KDE and other free and open source programs on AIX with relative ease.
If, and I am stressing this if, AIX’s X implementation was not too broken, the graphics side of DOOM was more or less handled, and I had a plan for sound. Still, nothing ventured, nothing gained. We’re going to use the older SDL 1.2 releases since it had much wilder support for non-mainstream platforms, and, as an unexpected bonus, it actually had some native AIX support. With
that said, let’s get building. *building montage* It figures, I get optimistic about something, and immediately hit a build failure. Alright, let’s take a look and see what went wrong. Hrmm ...
Oh, by jove, I’ve got it! The cause of the error is obvious, there is a missing header called XShm XShm, which stands for “X Shared Memory”, is an extension that makes video rendering faster. However, this didn’t make a lot of sense to me since XSHM should be part of every X implementation. For example, if we load up X on Yggdrasil Linux from 1994 we can see the shared memory support extension listed as present. It even has the XShm header right where SDL expects it to be. Cracking the file open, we can see a copyright date from 1989, so this wasn’t a cutting edge feature. It either meant that AIX was missing support for a nearly then
decade old standard, or something more subtle was going on. Investigating a bit further gave me every indication that AIX *should* have X shared memory support. There’s a README file for it, and xglinfo tool reports the shared memory extension was present. Examining X’s core libraries with nm also showed the necessary functions were there.
I initially thought the XShm header file might just be “somewhere else” on AIX, given all the other changes I had seen, but a search turned up nothing. This was appearing to be the inverse of the strtoimax situation we had before. In a bit of desperation, I actually ended up copying the XShm header files from a modern copy of Xorg. My theory was that IBM had simply excluded the XShm headers by accident, and given that X11 uses a client/server architecture, the modern headers *should* be close enough to work. I’ll be honest, I didn't have high hopes though. However, after a bit more hand holding,
libSDL actually did build successfully after this, and most of graphics test code *did run*. It seemed my hunch had been correct. It also did explain why both KDE and GNOME felt laggier than they should be. If they had disabled XShm support when they were built due to missing headers, they'd had likely defaulted to using much slower rendering code. Backtracking slightly, you might have noticed I used the key word “most” when I talked about the tests. I didn’t actually run all the tests at the time, and if I had done so, I MIGHT have caught some serious problems. You’d honestly think I would have learned. It also let me go through this entire project realizing all that OpenGL work I did was pointless.
I didn’t realize it at the time, but the older 2.3 release of Chocolate DOOM that we’re building doesn’t use OpenGL, and only depends on software rendering. I actually didn’t notice SDL’s GL stack was broken until it was time to edit this video. However, in an attempt to make myself look competent, I sorted this out anyway.
Fixing this required learning far too voodoo, and frankly, if you’re ever in this position, may IBM have mercy on you. To make an exceptionally long story short, I had to redefine the GL library path, deal with the very quirky way shared libraries work on AIX, and then hard code in a configuration I found by looking in a copy of GLUT that IBM shipped before I could get the demo code to work. The end result is you get to look at this really fancy rainbow cube. So uh, thumbs up if you like shiny renders. That side trip aside, after getting SDL built, it seemed like the end was in sight. Next up were two add-on libraries, SDL_mixer, and SDL_net. I had to fix some data types for
SDL_mixer, but on the whole, there isn’t a whole lot to say here. Building both were essentially a walk in the park considering everything else up to this point. Now it was time for the main event, building Chocolate DOOM itself. Let’s cue the music in preparation
for the inevitable failure. *montage music sets in* Or you know, I could subvert your expectations, and have *it build successfully*. Hah. Of course, I still had to test it. With a chocolate-doom binary in one hand, and the shareware DOOM1.WAD in the other, it was time to fire it up. I typed in the command, DOOM started and … immediately hung … Gasp! Who would been surprised at such a daring plot twist! Some debugging suggested that DOOM was dying in its sound initialization code which was part of SDL. To narrow down potential problems, I patched SDL to disable the AIX-specific audio backend, and then enable the dummy output. After a recompile, DOOM did fire up, and it
was playable, albeit a bit laggier than I would have expected. Still, we’re on the right track, but I wanted this to be a fully polished experience. That meant I wanted DOOM to be run at an acceptable framerate, with sound effects and music, and let me make this clear, this shouldn’t be a hardware problem. IBM actually did release a few games for AIX. On their FTP, you can find ports of Quake 1 and 2, plus another game called Abuse, which is apparently a run and gun shooter that I had never heard of before. Of these, I only got Abuse to work, and even then, I had to
manually extract the installer to get that far. Quake 2 refused to load, and Quake 1 … well, you can see it for yourself. I fiddled with it for a while, but to no avail. Still, we’re here to build DOOM, not play
Quake but before we move on, there’s one thing I’d like to point out. These ports were done before Quake’s engine was open sourced. Infact, if the disclaimers in the README file are to be believed, IBM apparently licensed both Quake 1 and 2 from id, which must have been one really weird conversation … Still, it means that in the end, the only thing left to do was make some noise.
So, let me ask you a question. If an operating system has a sound subsystem, but no one knows it exists, does it make a noise? This *might* sound like a rhetorical question, but uh, it’s surprisingly not. Early, I demonstrated that AIX had surprisingly rich system for multimedia in the form of its “Ultimedia Services”. However, I didn’t know those existed until after I had DOOM working with sound. In addition, IBM dropped support for UMS in AIX 5, and almost all mention of it
has disappeared off the Internet. Unless you knew in advance that it existed, then “good luck in finding it”. For the record, I only learned of UMS’s existence by reading the README file included with Quake. As such, I went with the tried and true method that people used to make sound on UNIX in the 90s. That is to say, I installed the Open Sound System. *ominous organ sounds* Now, there’s a lot I could say about OSS, some good, some not so good, but it is the closest thing to a de facto standard for audio on UNIX. It basically did for sound what X
does for graphics. OSS was available for AIX as a third-party product from 4Front Technologies, and, surprisingly, it's still for purchase for a whopping price of …. $10 dollars. Yeah no, I was going to try this hell or high water. That said, installing OSS isn’t entirely straightforward. What you’re supposed to do is install the evaluation version, and, once you have it working, you can then install the commercial license file. So, in that vein, I copied the
files across, and launched the installer. After a few prompts, it hung. And when I say hung, I meant the entire system deadlocked. This is off to a great start. I figured it might be a problem with running the installer under X, so after rebooting, I dropped to a console, and tried again. Yeah, no luck, we’re in crash city, population me. The installer was extracting all its files, it just died whenever you tried to load the main interface.
Now, I was valiantly resisting the urge to pull out the kernel debugger at this point. I’ve been to that hell, and nothing good will come from it. However, while examining things in detail, I decided to try creating a blank driver config file, and then re-running the installer. Instead of crashing, I made it to the main configuration menu! Ok, that’s definite progress. However, it was short lived, since when I tried to autoconfigure the audio, it, perhaps unsurprisingly, once again deadlocked. Still, half the battle is knowing the cause. After yet another reboot, this time, I went
into the settings, and manually added the onboard audio. There’s an option for RS/6000 43p’s built in audio in the menu, which then successfully passed the sound test! *BING* Left Channel Wave Test ... *chord* *BING* Right Channel Wave Test ... *chord* Now, NCommander from the future is going to interject here. While this mostly worked,
I started having occasional system hangs, as seen here when I was playing DOOM. I think this is because OSS’s “43p” driver is for another machine, since IBM reused the model number multiple times. I eventually removed this driver, and replaced it with a manually configured Crystal Audio device. This seems to have resolved the system hangs. WIth that aside, let’s go back to old NCommander. At this point, I could start OSS as needed with the “soundon” commands, which pops up a small banner reminding me that this is still an evaluation version. Time to fix that. Around this time, I went to 4Front’s webpage, and paid my 10 dollars. It’s important to
note that there’s no way to select what version of OSS you need. A little later, I got a receipt from PayPal, but no license file appeared … I did send an email to 4Front’s sales support address, telling them I didn’t get a license file for OSS on AIX, and if I was honest, I didn’t really expect any answer. You can imagine my surprise when I got a reply with the necessary license file the following day. Furthermore, the license file that arrived was AIX specific, meaning someone read my email, and then generated the license by hand. I’ll admit, I’m kinda impressed by that. It would be great if it worked though. After installing the license file, OSS stopped loading with a “Read only file system error”, and then complained that no hardware was present.
Switching back to the evaluation license made the problem go away. I did send an email to the support contact about this with logs, so maybe they can figure out what’s gone wrong. However, on the whole, I’m just happy that 4Front makes these old versions available at a reasonable price, so this shouldn’t be seen as criticism. Putting the self-destructing license problem aside, there were few other issues I had to resolve. While I could run the OSS self-test program from the system console, it would die when I was running X. Some further testing showed that more specifically, it was conflicting with KDE. Notably, the soundtests worked fine under both GNOME and CDE.
In hindsight, I should have seen this problem in advance. In the early days of KDE, it used to provide its own sound system known as aRTs, which was likely conflicting. Honestly, I was getting sick of debugging, so instead of tinkering with aRTS I just stopped using KDE, and re-embraced the world of GNOME.
It seemed like at this point that all I needed to do was recompile SDL to use OSS, and then go for broke, right? I mean, given everything else up to this point, there’s not a lot left that can break. Let’s cue the music, and get to rebuilding … Finally, the moment has come. It’s time to hear if the Gates of Perdition will open … *long sigh* And thus a great silence fell upon the land … Yeah, it was false hope it was going to be that easy, but resolving this was nowhere near as straightforward as I would have liked. I quickly discovered that SDL’s own sound library test code was failing, but why it was failing was just flat out bizarre. It
was due to issues entirely unrelated to sound. Instead, it was failing because of a semaphore problem. Furthermore, several of the threading and synchronization tests were failing as well, suggesting I had a serious problem. To explain what I mean, let’s pretend this line is code running on your computer. It goes from left to right in sequence. However, it means your very powerful multicore computer
would only be doing one thing at a time. Not very efficient. To offset this, modern programs use what is known as threading to handle multiple tasks at once. This is again easy to visualize, we just need multiple lines now. However, these threads have no way to communicate with each other, or synchronize their tasks. For example, in a game, you might have one thread that handles graphics, and the other sound.
It’s possible that these threads could desync, leading to mismatched audio. Semaphores are one way to solve the issue by ensuring that multiple tasks reach a common stopping point before proceeding. In this example, the audio thread reaches the semaphore first, and then waits for the video thread to catch up. SDL’s cryptic error message was telling me its semaphores
were failing, for seemingly no discernible reason. Or well … it might be more accurate to say that it failed for the same exact reason that Bash was failing before. Under the hood, SDL uses the POSIX semaphore interface, but AIX doesn’t actually seem to support that. Unlike strtoimax, this interface exists in the headers, but there’s no documentation present. Regardless, this is a major problem. Now, it probably shouldn’t surprise anyone that AIX isn’t the only platform in existence with broken semaphores. Fortunately, there is a relatively simple workaround. By using a specific configure switch to disable POSIX semaphores, SDL will instead emulate them by using a . After setting said switch and recompiling, SDL’s threading and semaphore
tests passed! Furthermore, the sound demo actually started making noise. *typing noises, then music playback* However, it’s frustrating knowing that many of the audio problems up to this point had been caused by a normally unrelated basic interface being entirely broken in AIX, but that isn’t the worst part. When I was reshooting clips for this video, I noticed this comment in AIX’s semaphore.h, showing that IBM appears to have shipped a placeholder implementation of this interface for standards compliance.
Now, to be fair, later version of AIX did add real support for POSIX semaphores, so, in theory, if we were to try this on an up to date version, everything should “just work” if we were lucky. Anyway, I’m just happy it was a relatively straight forward fix in the end. Still, given the sheer mountain we’ve climbed thus far, you’d think that was the last hurdle, right? With an Open Sound System enabled SDL in one hand, and a seemingly working DOOM in the other, you’d *think* we would have audio. So let’s fire up DOOM, and hear what it sounds like. *very distorted music that sounds like a horror movie* Well, I’m going to say that probably doesn’t sound right. It’s also lagging so badly as to be unplayable This led to another extremely long and aggravating debug session. To be
honest, I wasn’t quite sure what had gone wrong. For obvious reasons, I suspected the semaphore code, the sound system, and even GCC itself. I pretty much went around in circles for ages until I noticed something. While testing various configuration options, I ended up disabling music, with just leaving, sound effects enabled. Take a listen. *DOOM sound effects playing correctly* Hear that? That actually sounds correct. Furthermore, while it was still somewhat laggy, it was
playable, and we were capable of making noise. What I eventually realized was that the problem was Chocolate DOOM itself. As it turns out, when Chocolate DOM developers said that they wanted an accurate representation of the original DOS version, they weren’t kidding. Let’s step away from AIX for a moment, and look at the original shareware version of DOOM on MS-DOS. For most people who played this game as a kid, we probably were using a SoundBlaster capable card, which uses FM synthesis to generate the iconic background music. This is done with the onboard Yamaha OPL chip, with sound effects being sampled
PCM audio. When combined together, you get a version of DOOM that sounds like this. *SoundBlaster DOOM Music for E1M1* Without going into the specifics of how 90s audio works, DOOM music is not straight forward to replicate on modern computers. Out of the nox, Chocolate DOOM tries to talk to a physical OPL chip if one is present, and failing that, emulates one in software. From a conversation I had with one of the developers, this OPL emulation apparently can lag out even modern machines. As such, my two decade old RS/6000 likely didn’t stand a chance of getting
authentic sounding OPL music, but that didn’t mean there wasn’t hope here. While we can’t emulate the OPL chip properly, DOOM did have other ways of making music. One of these, the Gravis UltraSound, is a wavetable sound card, and thus is very easy to emulate. Furthermore, Chocolate DOOM supports loading the GUS soundfonts, and a quick review of the code made me semi-confident that this *could* work. Will GUS support be our salvation, or will silence rein? Only one way to find out. *very awesome UltraSound enabled DOOM sound* Oh yeah, I’m digging it. We’re at Hell’s Gate, with the power of UltraSound. I’ll
admit that framerate isn’t amazing, but I’ll be honest, I was on cloud nine getting this far. I did find out not long after that if I set DOOM to use 256 colors specifically, it's playable even in fullscreen mode. There was just one slight issue. *rocking DOOM music and gameplay* *tapping multiple times on keyboard* Past N:Oh locked up! Really? Again? When going to film this clip, the system locked up, not once, but twice on back to back attempts, likely due to OSS.
*keys tapping* Past N: Really? I should note this was nearly a month later in real time since I had that first lockup. I had even filmed and edited that entire section about OSS’s configuration a few days prior! Not going to lie, I was about one step away from finding out the airspeed velocity of an RS/6000 being thrown out the window. Unfortunately, I’m stuck with using OSS, since the native AIX audio driver in SDL isn’t an option. When I tested it, I found it causes the system to lag, and well DOOM goes very slideshow. Sounds good though. *good sounding but laggy DOOM* Sounds good though. I will say, on the *third* attempt to reshoot this footage, I could play through to Nuclear Plant without issue, but it's clear there are some gremlins left. That said, this is
probably the best I can get without breaking out the kernel debugger. Regardless, we do have it working, and maybe I’ll host a livestream playing through the entire game on my newly built AIX port. There’s just one thing left to cover now that we’ve gone to hell and back, and that is what was my final takeaway from this crazy adventure? I initially went into this project with a pretty positive opinion of AIX. I knew it was quirky, but all and all, relatively rock solid. I also knew IBM hardware in general is well built, and tends to have an exceptionally long service life.
When this Model 150 came into my possession, the hard drive wasn’t wiped, and I was able to do some data recovery. From the system logs, I found that it was put into service in 2002, and remained at least semi-active Cuntil 2015! That’s definitely something to brag about. However, I find on the whole I’ve gained somewhat mixed feelings towards the platform, especially when I have to ask the question: “were these systems worth IBM’s asking price in 2001?” Well, honestly, my answer is “probably not”, at least for most customers. After looking through the Wayback Machine for ibm.com, I was able to find the Model 150 in a similar configuration on a page dated April 13, 2001. The list price is, and I swear
I’m not making this up, was an eye watering 10,145 USD. When correcting for inflation, that’s almost 16,500 dollars in 2022. That’s also not counting pricing for any add-on software beyond AIX itself. IBM advertised this machine both as a workstation, and server, but an Intel based system would have been a fraction of the cost and could easily run Windows, Linux, or one of the BSDs. However, just to give you an idea of how absurd that price tag is, Apple was selling PowerPC hardware with much better specs for a literal fraction of the cost. When looking at 2001 pricing, I found I could have bought multiple PowerMac G4s from the same period for the cost of one RS/6000 system. Furthermore, in terms of raw processing power,
even a single G4 would have run circles around the 43p Model 150. The only real difference is that Apple machines don’t run AIX. So, the question becomes: does AIX alone justify that price gap? Well, maybe … if your business was already built on top IBM products, due to the advantages of vertical integration. IBM products generally have a high level of interoperability, so if your business was already built around DB2, or perhaps a z/Architecture mainframe, then AIX starts to make a lot of sense. Furthermore, in an effort to keep AIX competitive IBM added what they called “Linux affinity” which added new APIs and other functionality to help solve many of the compatibility hiccups that we ran into throughout this project.
It should also be noted that hardware isn’t everything. For many cases, raw performance takes a backseat to other considerations, and it’s here we start seeing better value. IBM offered exceptionally long service support periods for their hardware, and we can clearly see that with my machine. Looking on ibm.com, we can see that the earliest RS/6000 43p Model
150 was released in October 1998, and then withdrawn from marketing in 2003. In a separate document, we can see IBM ended support in September 2019. In technology, that’s an absurdly long time, and an essential quality for many industries such as finance, public safety, and more.
As such, if you need high reliability, serviceability, and support, well, you could do a lot worse. Unfortunately, it’s a little hard to check out how much AIX has changed in the interain period. The latest version, 7.3, only runs on very expensive POWER machines which are a bit outside of my budget. That said, IBM’s own cloud services do offer AIX as an option, at a starting price of 40 dollars per month, with hourly billing. Assuming there isn't a minimum price or catch, it might be something worth exploring at a later point.
Anyway, as usual, if you’ve enjoyed this content, consider hitting that like button, or subscribing. If you really enjoyed this content, consider supporting me on Ko-Fi or Patreon with the links in the
2022-05-23 18:31
