Compiling DOSBox on a 400MHz Via Eden CPU

Overview

Ever wonder how painful it is to compile software on ultra-low-power hardware from the 2000s? I took a 400MHz Via Eden thin client with 512MB RAM and attempted to compile DOSBox Staging from source under Linux. The compile took over 4 hours. Then I tried to run Doom and 3D Pitfall. The results were… not encouraging. Spoiler: I eventually moved the SSD to a 1.6GHz Intel Atom thin client for a much better experience.

Key Moments

• Starting with a 400MHz Via Eden CPU and 512MB RAM thin client
• Discovering the pre-compiled DOSBox packages don’t work (wrong SDL libraries, 64-bit only)
• Compiling DOSBox Staging from source: 330 files, 4+ hours
• Tweaking config: lowering RAM to 4MB, disabling bilinear filtering, setting core to “simple”
• Installing Doom 1.9—installation took 10+ minutes
• Doom loading screen: black screen after 30+ minutes of waiting
• Trying 3D Pitfall—runs but at ~1 FPS, unusable
• Swapping SSD to Intel Atom 1.6GHz thin client for successful gaming
• Lessons learned about hardware requirements for DOSBox emulation

Full Transcript (Edited)

Hey there everyone, welcome to Nostalgia PC. This is my YouTube channel where I kind of experiment with a bunch of different vintage and modern computers and just tinker here in my lab and videotape what I do. Sometimes I do something interesting, and sometimes I just test old random things.

Tonight what I’m doing is working on a little thin client here. It’s a little bit of an underpowered thin client. I started by trying to load Windows 98 on it, and I couldn’t find drivers for the video card. It kept restarting and acting very strange, so what I ended up going with was Linux. But what I’m doing here is I’m trying to run DOS under Linux and have it kind of like an instant-on—or as instant-on as I could possibly do it—so that the computer starts up and loads the DOSBox, and then it’s ready to run DOS programs.

Here is the little thin client. Like I said, it’s got a Via Eden CPU and it has 512 megs of RAM, and it’s all embedded on the motherboard. So the only thing that is actually upgradeable here is the SSD IDE disc-on-module. This came with a 1GB disc-on-module, and what I ended up doing was I had an 8 gigabyte drive hanging around and I switched it to the 8GB one, because most Linux installations were not installing in the 1 gig drive. You need more space, and 8 gigs appears to be enough.

I went ahead and tried a couple of Debian-based installs here. My goal was to get it so that it boots up into just the command line like this. My first experiments were to install DOSBox using the packages that are available out there, but this is a 32-bit CPU, and most of the DOSBox—not most, all of the DOSBox packages that I’ve been able to find out there—either are compiled for 64-bit, or they are compiled against the old SDL libraries, the 1.2 libraries. When I ran DOSBox in this little guy, the 32-bit version that was installed using the package installer, it created a bunch of garbage on the screen.

I was reading online and they say that the old version of the libraries that DOSBox is compiled against might lead to garbled images and things on the screen. I heard that if I used the DOSBox Staging version of DOSBox, that one actually runs against the more modern SDL2 libraries. Unfortunately, the images that were actually available on the website were compiled against a 64-bit CPU, and that didn’t run on this obviously because this is a 32-bit CPU.

What I’m doing now is I was able to download the source code for DOSBox Staging. As you can see here, this is pegged at 100% CPU because the CPU is really slow, and it’s using up almost all available memory with 22MB of swap, and it’s compiling here. There’s a total of 330 files that need to be compiled, and I started compiling this at 8:10 PM. It’s now 9:14 PM, so it’s been going for 1 hour and I’m still only at 125 out of 330 files. So at this rate, assuming that nothing fails—as you can see here there’s some warnings, and warnings are okay, errors would cause this to completely error out obviously—but hopefully this goes all the way through to 330 files and I end up with a DOSBox executable that will run on this 32-bit machine.

[Time passes]

All right, so this just finished right now. It is 12:30—it’s past midnight. I’ve been at it since 8:10 PM, so that was like many hours. Let me see where DOSBox ended up. We have build. Alright, so if I run this—that works! So let me run DOSBox and see what happens.

“Initialized window mode… SDL failed to put the mouse in relative mode.” What does that mean?

[After setting up X Windows]

I managed to get a window manager installed. It’s definitely not instant-on—it takes about a minute for it to get to this screen, and I haven’t even loaded DOSBox yet. My dreams of making this an instant-on machine probably not going to happen unless I really work on having a bare-bones Linux install—I mean bare bones as in just a kernel that has been compiled with the bare minimum and then boots up. But that’s a lot of time investment, so I’m not going to go that route.

For now, for demo purposes, I’m going to see if I can actually run the DOSBox Staging on this now that I have X Windows working.

[After configuration tweaks]

For some reason this stopped recording when I was showing you that I was going to mess around with the resolution. What I did was I lowered the screen resolution to 640x480, and I also modified the configuration. I changed it so that it always starts up in full screen. I also changed it so that it doesn’t use bilinear filtering when rendering the video, which will make it look kind of ugly but it’s faster. I also changed the RAM from 16 megabytes down to 4 megabytes. The CPU core I changed from auto to simple.

With these settings, it’s a little bit more usable. If I run DOSBox now, it’s loading. Doesn’t look as nice, still slow, but it’s definitely much faster. I can run Mavis Beacon typing on this, though it must be a nightmare because it doesn’t capture all the keystrokes—I have to type slow. But as you can see here, it works. I got the Sound Blaster, PC speaker, OPL, master volume—so this is a very good emulation system here. Obviously very slow, but I can probably drop this into a faster thin client and actually get a nice working DOSBox with even Voodoo graphics.

[Installing Doom]

Here’s what I ended up doing: I logged into my other computer and I SSH’d into this one and copied over Doom 1.9. Then I mounted that directory as the C drive. I’m going to try to install it. This is probably going to take forever if typing is an indication of what is to come.

Oh my God, that’s going to be awful. The font looks ugly without that bilinear filtering—maybe I should re-enable it. This part right here is probably going to take a while, so I’m going to cut into the future and spare you this.

[After 10+ minutes of installation]

I’m presented with the Doom setup. I’m going to go keyboard only, Sound Blaster 220, IRQ 5, DMA channel 1, save parameters and launch Doom.

[After waiting 30+ minutes]

After waiting for over half an hour for Doom to load and just being presented with a black screen and the occasional floppy icon on the bottom right corner trying to load something from the drive, I decided that it was going to take forever. I’m not going to wait for Doom to even display the first screen because after half an hour I just think that was way too long.

[Trying 3D Pitfall instead]

I downloaded a different game, 3D Pitfall, which I’m hoping runs better. Oh look, it’s starting to show something! That is so slow. I see 3D Pitfall starting to be formed there. This is obviously running like an 8088 or something. Let me actually download DOS Bench while this runs.

[Moving to Intel Atom 1.6GHz thin client]

Alright, so I just went ahead and swapped the SSD into the other thin client. Now if I go to DOSBox, it’s going to be a much different experience. I actually changed the config so that I use OpenGL with a nice font because now I can actually afford those CPU cycles. If I run 3D Pitfall now, that is much faster! Now let’s see how Doom runs.

Doom is now loading much faster—oh, music! Still very slow but not horrible. The key to getting some decent performance out of these slow old computers is to make sure that you’re running at 640x480 in X Windows. That way it’s pushing a lot less pixels.

As you can see here, you need some horsepower to actually run DOSBox on old hardware. Some old games will play, but you know, depends on what you consider old. Doom barely plays on this emulation, so this is not an adequate system for this. I’ve run DOSBox on an Atom 1.6 before and it ran really well within Windows, so maybe it’s just this port under Linux that has some issues.

Let me know what your experience has been with DOSBox in the comments below. If you like this stuff, make sure you subscribe. I have a lot of videos in progress, and it will be great to hear your thoughts on them as they come out.