My Custom 486 DX2 Build

Since it's basically complete now, I figured I'd post something detailing it. Actually, it's been mostly complete for a while now, but the last couple small touches came together this week.

Despite the fact that I got a perfectly capable mini 486 PC earlier this year, I still decided I wanted to build my own similar system in a baby AT form-factor case. This way I could customize it more to my liking. I also really wanted to use a specific style baby AT case that matched the old 386 PC my family used to have. It's nothing special at all, but it's kind of stuck in my head over the years and become synonymous to me with "old DOS PC", so I pretty much was unwilling to let this "requirement" of mine go.

I began picking up parts during the summer and piece by piece I've finally got everything assembled. Strangely enough, getting the particular AT case I wanted was hardest, even though from what I gather it was actually a very common style case back then. Maybe just a coincidence that I had a hard time finding one.

Actually this ended up being the second case of this style that I received. The first one was shipped and arrived broken (the plastic front was cracked and broken in multiple places). Got pretty lucky that I was able to get a second one now that I think of it.

So, what's inside? Let's take a look:

  • CPU: Intel 80486 DX2 SX911 66Mhz
  • Motherboard: FIC 486-PVT, 256KB L2 Cache
  • RAM: 16MB
  • I/O Controller: Promise Technology 560C PDC20630, VLB
  • Graphics: S3 Trio32 2MB, VLB
  • Network: 3Com 3C509B-TPC
  • Sound: Sound Blaster Pro 2.0 CT2600 and Gravis Ultrasound Classic 3.74 1MB
  • Hard Disk: Quantum Maverick ProDrive 540MB 3600RPM MV54A011
  • Floppy Drive: 3.5" 1.44MB Sony MPF920-E and 5.25" 1.2MB Teac FD-55GFR
  • CD-ROM: Torisan 6x CDR-S16
  • Power: Athena Power AP-AT30 300W

Since I ended up getting basically every piece separately, it almost certainly ended up costing a bunch more then it would have if I had bought some pre-assembled PC from eBay or some other place (which people do sell, tested and working, even today). However, given all the trouble I had to go through to get this working, it really feels a lot more satisfying having gone this route.

As one may expect given the era, contrary to building a PC today, a lot of things [i]did not[/i] "just work" together out of the box with this PC. This is especially the case when talking about VESA local bus (VLB) hardware where stability was a common problem. Having to adjust jumpers on the motherboard and the different ISA cards to get the settings just right is quite a different problem from today's PC hardware. This can be even more difficult a task today because for some motherboards the documentation is sparse or even outright missing, leaving you to either have to figure it out by trial and error, or hope the (often limited) labels printed on the motherboard or ISA cards themselves are complete enough and self-explanatory.

Luckily for me, with this particular motherboard I was able to find PDF scans of the original manual. The other card that you'll usually want a manual for due to all the jumpers on it is the I/O controller. In my case, I was unable to find a manual, but the labels printed on the card itself were sufficient enough to get it working properly.

Well, actually, I'm not sure on that last bit to be honest! It did seem to be working perfectly fine up until a week or so ago where I started having problems with the BIOS detecting the hard disk. I thought at first that it might have been an indication that the hard disk I was using was dieing or dead, but after swapping it out for another, using a totally different I/O controller card and also trying different IDE cables, I was unable to eliminate the issue. And to make matters worse the issue only manifested itself sometimes. The only thing I've found so far that solved this problem was to connect all of the IDE devices to the IDE channel that runs on the ISA bus instead of VLB. This isn't too big a deal, as I believe that since I'm running DOS 6.22 primarily that I don't see any benefit whatsoever to having the hard disk running over VLB.

It is worrisome though that the problem only started to occur just recently and seemingly not a result of any other hardware changes (since it had been a while prior that I had made any). Either some other component in this build is starting to become a little flakey, or this is just the fabled VLB stability problems I've heard about rearing it's ugly head. At any rate, something I need to keep an eye on.

Two sound cards probably seems strange at first but there is a reason for both. Sound Blaster is a pretty typical card for the era. The Yamaha OPL chip on this one (and many other Sound Blaster cards) has a pretty recognizable sound that I quite like. And it's compatible with a great many DOS games, so it was an obvious choice.

The Gravis Ultrasound however is something I had never seen before, only heard of, and certainly was not nearly as common a choice at the time. It's an interesting card however, as it was one of the first (if not the first?) sound cards to support hardware mixing of multiple sound sources. Sound Blaster cards couldn't do this, requiring programs to implement their own software mixer which took up valuable CPU resources. In practice, this ended up not really helping many games that supported the Gravis Ultrasound though as almost all of these games supported Sound Blaster too and in an effort to keep the code simpler, would implement their sound engine to the lowest common denominator. This meant not utilizing the Gravis Ultrasounds hardware mixing support since no other card had it.

However, what I really wanted a Gravis Ultrasound for was for it's subjectively better sounding FM synthesis / MIDI playback. So far every game I've compared that supports both Sound Blaster and Gravis Ultrasound sounds better (to me) when configured to use the latter. In some cases, such as with One Must Fall 2097, the difference is objectively better.

For a 486 computer, VESA local bus graphics are pretty unique, and until PCI came around (which was quite soon after VLB was introduced), it provided the fastest graphics you could get. To me, it feels almost necessary to use VLB with a 486 machine since you cannot use VLB with anything else. Everything beyond this hardware level would be PCI and eventually AGP. Everything before, ISA. Using an S3 card is a pretty solid choice. All benchmarks I've seen and done personally have them as top-tier cards of the era. Compatibility is also excellent. Probably a more common choice would've been a Cirrus Logic card though.

Nothing much else to say really. A 6x CD-ROM feels mostly right, maybe a little bit fast for the era? I remember we had a double-speed CD-ROM in my family's 386. A 500MB hard disk is also quite large for a DOS PC really. It's funny to think of that, but then again, I remember my family's 386 had a 20MB hard disk and at the time I thought that was large! 16MB of RAM is plenty for a 486. Most DOS games would need less then 8MB of RAM, so 16MB is nice to have the option for running SMARTDRV, or using a RAM drive, etc. My DJGPP boot configuration sets up both and it makes a significant difference with compile times, still leaving 8MB of RAM free for everything else.


Been a while since I wrote about this. When it comes to my own personal coding projects, rest assured that I take it very slowly. Heh.

I released the code that I've been working on for the past month. It's a DJGPP library called libDGL. DGL stands for "DOS Gamedev Library." Yes, I am incredibly unoriginal when it comes to naming things. This is a library aimed at "retro game development" with MS-DOS, targeting VGA Mode 13h using C.

As is mentioned on the Github project page linked above (and as I've mentioned previously here as well), I am using an older version of DJGPP from the late 90's. More specifically, I am using:

15 Jan 1998  
24 Oct 1997  
31 Oct 1996  
18 Jan 1997  
 6 Jun 1998
18 Oct 1996  
 6 Jun 1998
 1 Mar 1998
30 Sep 1997  

I make no guarantees that this code will work with different versions. I'll probably test it at some point, but for now I am more interested in fixing bugs and adding more features. My "todo" list for this library is quite long still. Even so, I do feel like I've got a fair bit accomplished so far.

To help me test out a bunch of this, I wrote a very simple Asteroids game over the past two days. Asteroids is a very simple game, and I feel like two days was a long time to take to write it, but in the process I uncovered and fixed a number of bugs in libDGL, so I guess I should not feel like I was too slow. Finding and fixing bugs was the WHOLE point of writing it after all.

The code is available here.

As you can imagine based on the above screenshot and the game being Asteroids, it's nothing particularly special, heh. In fact, this has not been tweaked to provide any real level of difficulty to the player at all. I was more interested in testing out libDGL then in balancing a game and providing a full layer of polish. As well, I am less than happy with how the code that handles the different game states turned out. It's fairly sloppy honestly, heh.

This game doesn't make use of any sprite blitting. Instead, it uses line drawing and 2D vector transformations for the graphics. This was useful to test out and verify the math functions I had written, and is the main reason I picked Asteroids.

Not really much to say about it honestly. The next test game I'd like to do is probably some kind of simple vertical 'shmup type of game using sprites for graphics. Probably something along the lines of what I was originally going to do on the Amiga 500 some months ago.

So, where am I going with all of this anyway? Well, I don't have any specific plan worked out, but in the back of my head I've got some grandiose ideas about writing some 2D dungeon crawler type game (something I wanted to do as a kid back in the 90's but never finished... actually, that might be a fun post to write in the future, revisiting some of that code from back then which I have sitting here now). As well, I'd like to eventually work my way up to some 3D raycasting games, with a final goal being something Doom-like but with some RPG elements thrown in (and not gritty/dark like Doom is). But this is all quite a long ways off, and first thing's first... gotta work on the foundation.

Island: A Game Of Survival

I was going through an image I took of an old hard drive that died in 2005 or so that my brother and I had in our computer starting from the late 90's. Unfortunately I made an image of the disk after it was already showing a lot of problems, so a lot of content was unrecoverable. Even still, I came across a lot of old stuff... games, old school assignments, code I had written ... and this game that I apparently had copied from one of my school's computers at some point probably in the mid-to-late 90's.

Island: A Game Of Survival, title screen and credits roll

I went to school in Ontario, Canada in Durham Region (Sunderland Public School, and then later Brock High School if anyone knows the area) where the schools are run by the Durham Board of Education. Apparently this game was produced by them. As I understand it, the game itself is a DOS recreation of the C64 game "Island" by Eleanor Rice. Was kind of funny to discover that this particular version of the Island game was written in QuickBASIC 4.5!

Anyway, all of the school computers had a number of education games on them, including this game. I remember playing this game quite a bit on the computers at school back then. Looking back at it now, it certainly wasn't the best game ever... not by a long shot! But it was a lot of fun re-discovering this recently and playing it again for the first time in 20 years or so.

Island: A Game Of Survival, title screen
What will you do today?

In this game, the player is stranded on a small island and must survive alone by collecting rain water, catching fish for food, and making sure not to die from exhaustion. The goal is to escape the island either by being saved by passing ships (possibly by random chance and/or by sending a message in a bottle), or to collect enough planks to build a raft. You can die in a number of ways, and in fact sending a message in a bottle can backfire with you getting picked up by pirates and being forced to walk the plank! After 30 days on the island a hurricane always comes and destroys the island and the game ends.

Choosing a message to send in a bottle
Catching fish
Collecting planks
Dieing from a lack of water

As you can see, it's a very simple game. I'm not actually sure how this port of the original C64 Island game compares as I've never played it. At any rate, I found it to be surprisingly still kind of a fun distraction. Might also be a fun little project to turn into a mobile game one day.

If there is anyone else out there who went to school in Durham Region that remembers this game and wants to play it again, you can download Island: A Game Of Survival right here. The game is a 16-bit DOS executable, so you won't be able to run it natively on a modern version of Windows (at least, I don't think you will be able to, but I don't use Windows so I cannot verify). But it works great in DOSBox.

Follow-up: Unisys CWD 4001

I figured that I would post a follow-up regarding the Unisys CWD 4001 mini 486 PC I picked up earlier this year. I've had a few people now ask me various questions about it. It is certainly an interesting PC, especially for those looking for a nice compact retro PC to play around with so I certainly don't mind posting some more information about it to help out anyone else with questions regarding it.

Almost six months later and I'm actually not using mine that much, as I ended up building another 486 PC in a baby AT case. This was mainly because I wanted to be able to toy around with different hardware customizations, have more options for sound cards and have internal CD-ROM and 5.25" floppy drives. Otherwise my CWD 4001 is still working perfectly fine.

Hard Disk

As mentioned in my previous post earlier this year, the hard drive it originally came with died so I replaced it with a CF-to-IDE adapter. I got a StarTech IDE2CF and a Transcend CF200I 512 MB Compact Flash card. I had to cover the bottom of the adapter with electrical tape as otherwise some of the pins on the bottom would short against the metal part of the case it is resting on (and I could not find any kind of mounting bracket to fit in there instead).

The jumpers I have configured on the CF to IDE adapter set it for 3.3V power and master mode, drawing external power from the adapter you can see plugged in in the photo.

The BIOS configuration that I use for this is 987 cylinders, 16 heads, 63 sectors. If you end up using a CF card to replace a hard disk, make sure you do a FDISK /MBR or you may end up puzzled for a while like I was as to why you are mysteriously unable to boot from it!

You should be able to use a larger CF card if that's all you have (for a short while I was using an 8.4GB IDE hard disk without issue). Though with MS-DOS 6.22 you will only be able to use partitions with a max size of ~500MB.


Mine came with an AMD 486 DX2-66 already and that's what is still installed as I write this. However, these should work fine with up to a DX4 (some even had a DX4 pre-installed). On my CWD-4001 there is a voltage regulator on the motherboard so this should support 5V and 3.3V CPUs just fine, but I've not actually tried this. Do your own research first before trying!

On the underside of the motherboard on my CWD 4001 there is a motherboard diagram showing jumper settings. I've heard some people didn't have this, so I'll share what mine looks like:

The CWD 4001 doesn't include any L2 cache but since these are 486 machines, I believe all CPUs that these would ever have shipped with had 8KB L1 cache. The BIOS has an option to enable CPU write-back cache so if you have, for example, an Intel 80486 SX955 (P24D) then you can make full use of it. Though you will also have to configure the jumpers as shown in the diagram above. However, probably most people won't have a CPU with write-back cache support. Not to worry if you don't, it doesn't make a massive (real world) performance difference anyway.


For MS-DOS, you'll want the NE2000 packet driver. Then you'll want to add this to your AUTOEXEC.BAT with something like the following:

C:\NET\NE2000.COM 0x60 10  

Where the 10 is the IRQ for the network adapter. Mine was set to 10, yours might not be (IRQ 10 or 11 were very commonly used for network adapters). I didn't have to tinker with any BIOS settings to make this work (not that there really is much of anything that you could change that would affect this to be honest).


As mentioned in my previous post, I'm using a Creative Sound Blaster CT4170 (Vibra 16XV). Your options for sound cards are quite limited with a CWD 4001 due to the compact size of the case. As far as Creative cards go, you'll probably be stuck to only a few of the later models that were more compact. Probably the best choice is one of the AWE64 value cards that is more compact but I don't own this card personally. I'm unfamiliar with what other Sound Blaster clone cards may fit.

For me, using IRQ 5 and 7 both worked. Remember that IRQ 7 is also used for the parallel port (LPT1), so if you're using any parallel port device you may want to configure your sound card to use IRQ 5 instead.

I have the following in my AUTOEXEC.BAT for my CT4170:

SET BLASTER=A220 I5 D1 H1 P330 T6  


The CWD 4001 I would say is pretty average for a 486 DX2-66 system. It does not have VLB graphics, but the Cirrus Logic GD5424 isn't too bad really. The lack of L2 cache is also unfortunate, but the RAM speed seems a bit faster than other 486 systems I've tried... maybe something specific to the chipset/motherboard? Not sure really. The two RAM sticks installed in my CWD 4001 are nothing special, two HYM532220W-70 (72-pin 8MB 70ns) sticks.

Versus the other 486 system I built (Intel 80486 SX911 CPU, FIC 486-PVT motherboard, S3 Trio32 VLB, 16MB RAM) just for a slightly apples-to-oranges comparison:

How does this translate to "real world" performance? Well, I can share with you the results from running Phil's DOS Benchmark Pack on both of these systems:

CWD 4001 FIC 486-PVT, SX911, S3 Trio32 VLB
3DBench 1.0 41.6 fps 50.0 fps
3DBench 1.0c 40.4 fps 48.2 fps
Chris's 3D Benchmark 26.9 fps 31.4 fps
Chris's 3D SVGA Benchmark 9.1 fps
PC Player Benchmark 10.1 fps 9.6 fps
PC Player Benchmark (640x480) 4.0 fps 3.8 fps
Doom (min. details) 71.4 fps 70.0 fps
Doom (max. details) 24.3 fps 26.1 fps

Not really too surprising here when comparing ISA graphics to VLB graphics (in particular the S3 VLB graphics cards tended to be top-tier, performance wise).


A few people have asked questions after obtaining their own CWD 4001 (or 4002) after seeing that they were missing some internal components. In particular I've seen some people missing the ISA riser card and/or the bracket that fits onto the inside back of the case which the back plate of an ISA card would slide into when installing one. I'm unsure what people are doing for replacements for these and even if they are easy to come by, but for people's reference I've taken a bunch of photos of the ISA riser card and the ISA back plate bracket thingy.

Anyway, I hope the above helps anyone else looking for information about these Unisys CWD mini 486 computers. Feel free to email me though if you have any additional questions of course (my email address is on the "About" page linked on the left).

DOS coding

Last month I picked up a copy of Fabien Sanglard's Game Engine Black Book: Wolfenstein 3D. In fact, I was eagerly waiting for the day I could order a copy. When it arrived I was totally engrossed in it the whole way through. It's an amazing book, well written and well worth the read for anyone interested in those kinds of topics. Fabien really did a great job with it and I'm eagerly awaiting the next book in the series which will cover the DOOM engine.

It also got me thinking about some DOS code I had started to write a couple months prior and then set aside temporarily. I had begun writing a simple VGA Mode 13h library I had called "DGL" for "DOS Game Library" because naming is not a strong suit of mine. So, I'm going to pick it up again and hopefully continue writing about it here as I work on it and then soon after, some little game demos written with it also.

Of course, there's absolutely no good reason to re-invent the wheel from scratch like this. Libraries such as Allegro exist and any of the 3.x or 4.x versions for DOS would perfectly meet all my requirements and is probably far better implemented than anything I'd cook up myself. But that would be less fun.

Anyway, what I want out of this library is:

  • Support for VGA mode 13h (320x200x256)
  • Primitive drawing (pixels, lines, boxes, circles, polygons, etc)
  • Bitmap/Sprite drawing (aka. "bitblit"-ing)
  • Palette manipulation (loading, rotating, fading)
  • BMP, PCX, IFF image support (period-correct file formats)
  • Font rendering (using BIOS font format). Also add non-fixed width support?
  • Keyboard, Mouse, Joystick input device support
  • PC Speaker sound (maybe even rip off QBasic's PLAY command?)
  • Sound Blaster (and compatible) support (MIDI music, FM synth and digitized audio sound effects)
  • Math function suite (vectors, matrix, etc)

The only thing in this list that I think is (currently) outside my skillset (but totally possible to learn, of course) is the Sound Blaster stuff... simply because I've actually never written an audio engine of any sort, and certainly not ever written code directly for Sound Blaster hardware.

In fact, the only time I've added audio to game projects of mine was via DirectX. Not sure how DirectX is nowadays, but I remember at the time I was using Visual Basic 6 and the libraries for it had play/pause/stop functions for both sound effects and background music out of the box, so it was extremely simple to hook into the projects I worked on. Most game projects of mine tend to get dropped before I get to the point where I need to add audio, heh. And in more recent years, it was always my intent to use something like SDL_Mixer to take care of the lower-level details anyway, but I just never got around to it.

So, needless to say, when it comes to audio for this project I have a bit of fundamentals learning work to do.

Also on the topic of audio, I would like to look into adding support for Gravis Ultrasound cards. These cards are interesting as I think they were the first sound card for PCs to have full hardware audio mixing support. As I understand it, Sound Blasters lacked hardware mixing capability, so game engines would do this in software. But this will be a nice optional extra for later if I feel like it.

Originally, I had planned to use Borland C++ for this and do it all in real-mode DOS code. That probably sounds like totally unnecessary pain to anyone who understands the differences that brings along with it. I even went and bought a copy of Borland C++ 4.0 off eBay:

However, after fiddling around with it for a while I remembered how easy it was to crash your system with real-mode C code and how the debuggers of the time were helpful, but not that helpful in tracking down these types of bugs. This was less clear in my memory prior to this because during this time period I was primarily using QBasic which obviously shielded you from these types of bugs much more.

So instead, I plan to continue using a period-correct version of DJGPP (meaning, a version from the late 90's). Better debugger support for dealing with these types of crash bugs. Still possible to crash your system in weird and wonderful ways of course, but more support than Borland for catching these bugs. Plus having a 32-bit flat memory model is obviously very nice.

I plan to keep the code for this library on Github somewhere when there is something to show for it.