The Maiden Voyage of DOSBochs (Gentoo in DOSBochs in QEMU on Void Linux on PowerPC)

Well, this is a doozy.

A while ago, I wrote and released DOSBochs to the NCommander discord server. It's a really jank, and VERY, VERY slow port of the Bochs PC emulator to DOS. After I wrote it, I didn't really use it for much. Until now.

You see, N recently launched a competition on the server to see who can have the most painful computing experience possible. I immediately knew DOSBochs was perfect for this.

You see, when I say DOSBochs is slow, I mean DOSBochs is slow. Running it inside QEMU KVM on my Ryzen 7 system, I can boot Windows 2000 just fine... in 18 hours or so. So I did the logical thing, and decided to run it on my PowerBook G4.

Now, the plan here is to install Gentoo inside of DOSBochs, running inside QEMU, on my PowerBook G4. However, there are a couple roadblocks we need to get past:

Let's address these one by one (minus the speed).

First of all, the networking issue. Gentoo (obviously) requires that you download a whole lot of source code in order to build the system. Therefore, we simply can't install it in the usual way. Thankfully, it's possible to cheat a bit, and pre-download all the things we'll need.

In order to do this, I decided to do a regular, minimal i486 Gentoo install in a virtual machine, to gather the ebuilds and distfiles we'll need for the DOSBochs install. And so the prep (and my entry) began, on November 4th, 2022, at 3:18 PM MDT.

I won't bore you with the details of installing Gentoo here, but the install itself went pretty smoothly. The key here is (once we have a working system) to back up the /var/cache/distfiles and /var/db/portage folders. The former is all of the source code portage needs to build our system, and the latter is the ebuild snapshot we downloaded during the install process. We should be able to just put those two folders in a disk image, which we can mount in DOSBochs later in order to satisfy portage enough to install our system.

So, with networking out of the way, now we can try booting Gentoo. I set up DOSBox first, but quickly ran into problems.

First of all, normal builds of DOSBox only support up to 64MB of RAM. This is entirely reasonable. I don't blame them. I shouldn't really be doing this. But it is annoying. Thankfully, I was able to track down a patch to increase the amount of RAM you can allocate, and I applied it fine. I put the Gentoo install CD into DOSBochs, started it booting, and went to bed...

And woke up to catastrophe! DOSBox had crashed with a page fault. This is strange... if anything, DOSBochs should have crashed. Chalking it up to the sketchy memory patch I applied, I decided to use QEMU instead. This was about 19 hours in.

I set up FreeDOS in QEMU (with a short break in the timer when I had to go run some errands), and got the Gentoo CD loaded. Back on track. I waited and waited... and got another page fault.

Fine. It's probably running out of memory.

DOS is quirky UwU

DOSBochs is built with DJGPP, a port of GCC to DOS. Like many other "modern" things for DOS, DJGPP uses a DOS extender, in order to run itself and things compiled with it in 32-bit mode. This is good for compatibility, and greatly increases the amount of memory you can address in your software.

Now, there's one problem with this. DOS extenders use an interface called DPMI in order to do the do. Unfortunately, DPMI is really, really jank.

You see, memory management on DOS is a bit quirky. For one thing, it doesn't really exist. Remember "640k ought to be enough for anyone?" Well, DOS can only address 640kb of memory, under normal circumstances. Therefore, extended memory managers were quickly developed (you've probably heard of HIMEM, right?), which basically kludge around the problem by allowing you to use a separate, "high" memory region.

There's one problem with this: there's a LOT of extended memory managers. FreeDOS alone in a default install includes 3 of them. And they all work differently, and all with varying levels of compatibility.

What does all of this have to do with DPMI?

Well, DOS extenders take advantage of that high memory area. See the problem yet?

640k 128MB ought to be enough for anyone

The problem, of course, is that it's really fucking hard to get any of FreeDOS's extended memory managers to see more than about 128MB of RAM. I tried several command line options, and banged my head against it for a solid couple of hours, with no success. No matter what, we're stuck with 128MB for now.

Now, although (as I said above) I thought we might be running out of RAM, which was causing the page fault, I discovered a ray of hope right around this time. I found some old forum posts of people running Gentoo on systems with much less RAM than mine (even as low as 64MB!), so I knew it had to be possible. In other words, the RAM limit may be slow, but it should still work. Our problem is elsewhere.

VGA time, bb

Well, you remember how I said that DOSBochs can only support one graphics mode? That mode is 640x480 at 8bpp. That's a pretty common resolution for VERY, VERY old machines, but it's a bit odd in 2022. This gave me an idea. I watched for when Gentoo crashed. It seemed to be as soon as any console output started.

So I booted the Gentoo CD in another VM, waited for that point, and...

Saw that it moved to a 1280x960x32 framebuffer console. There's our problem.

The solution here was nice and easy: just boot gentoo-nofb instead of gentoo on the CD. 30-some hours to figure that one out. Yippee.

Where we are now (2022-11-06 8:48 PM MST)

And that's where we sit. Gentoo's been sitting there for about 9 hours (I had to restart completely at one point after forgetting to transfer the stage3 tarball), just decompressing the Linux kernel. This is gonna be a long haul one. More updates to come.

Mastodon