Retro Computing

The Retro LAN Party Cart

There's a kind of fascination I can't seem to explain about running games on the real thing, a kind of captivation that comes from assembling a capable machine with my own hands.

Saxxon

• 14 min read
The Retro LAN Party Cart

There's a kind of fascination I can't seem to explain about running games on the real thing, a kind of captivation that comes from assembling a capable machine with my own hands. I get this from both PCs and game consoles.

I've spent some time in the last month building and testing two retro-capable PCs so that I can play some games in both MS-DOS and Windows 98 without emulation. There were many surprises along the way.

Both Appia and Ironwood, installed in a 12U rack.

The Externals

The computers are mounted to a StarTech 12U adjustable rack. They're both built inside the same model of case: the iStarUSA D-400.

Networking

I'm using a TP-Link TL-SG1008 gigabit ethernet switch. Both computers and a Raspberry Pi are connected to it.

There is not a single router on the network just in case it would mess with IPX connectivity between the computers. Each of the three devices on this network required their own manually configured IP address.

Power

I'm using a Furman M-8x2 as a power conditioner for the whole rack. Theoretically this could improve signal quality too, but it's really only here for the sake of cable management.

A/V Routing

I managed to find a pretty stacked Extron SMX Series Switcher complete with 8x4 VGA, 4x4 DVI PRO, and 8x4 Phoenix audio cards for a really great price. I'm only using the VGA module for now, but audio routing might be set up through this later if I decide I need that kind of routing capability.

Raspberry Pi

A Raspberry Pi is being used as a file server via Samba. I started with the NOOBS image. I just installed Raspbian and then used a very helpful guide to learn how to install Samba. A couple package installations and a few lines of configuration later, it works. More details below on how to do this yourself.

The Internals

Two computers were built for this, and they are named after towns in the Commodore 64 game, The Legend of Blacksilver. The first machine I built was named Appia, and the second machine was named Ironwood.

Appia

This machine was built a few months ago into a rack case with the intent of doing a project like this someday. I've tested a number of motherboards in this chassis, settling on the Soyo K7VTA PRO for my primary machine.

This was originally going to be a Pentium 4 setup, but I found that for some DOS programs, the AMD solution here ends up being better performing, and also uses way less power.

I had some problems when using the Voodoo5 5500 with the Soyo SY-K7VTA Pro, it would work on a cold boot from complete discharge but then immediate shut down 3 seconds after attempting to boot it again. I would have to turn the machine off, wait for it to completely discharge, and try again. So now, I'm using a Soltek board.

Ironwood

This is a computer built from other parts I had sitting around, but they aren't bad parts by any stretch.

The Windows game storage is notable absent from this machine. My 2.5" SATA drive dock has not yet arrived (which connects to an internal USB header, that rocks) so instead I just map Appia's SSD to the same drive letter so that I don't need to reconfigure anything.

Populating the Chassis

The first thing I did when I opened up the D-400 case was remove a bunch of stuff. There was a stock fan that I replaced with a quieter Noctua one. I installed a couple other smaller Noctua fans for the rear. There was a cage of some sort beneath one of the 5.25" bays (where the CD-ROM drive eventually went,) I removed this as well. This case also has a solid metal bar along the top - I really liked this for structural integrity, so I remove and reinstall this every time I need to get underneath to replace or move expansion cards around.

Screw in motherboards standoffs, IO shield, mount the board, all that jazz. I then installed all the drives, but waited until all the larger pieces were installed before running any internal cables.

Cable Management

Sellers will often sell IDE cables that have both a Master and Slave connector, but seeing as I'd only be using two IDE devices, I decided to opt for cables that were strictly for a single device. I prefer round cables with mesh and shielding.

After connecting cables, I grouped some of them up with felt strips. Keeping cables clear of the air channel in the case means better cooling and in turn, longer lasting components. That's especially important when many of these components are decades old already.

First Boot

I run a smoke test with only the motherboard, slow Athlon CPU, trash RAM and some S3 graphics card I have plenty of. Once things work at this stage, I start populating the board with the devices I plan to use.

Via KT133A + Fast Athlon XP Caveats

Many of the later chips with high multipliers aren't directly supported by the motherboard manufacturers that use the KT133A chipset, and many BIOSes don't recognize them. Often, these BIOSes will simply try to run the CPU anyway, but report the name as "Unknow CPU Type" (or even more humorously "AMD Pentium III".) The motherboards I've chosen for this project do just this.

With permissive BIOSes, generally if a Thorton or Thoroughbred model CPU works, a Barton model with the same FSB and multiplier should also work. Doubling the size of the cache from 256kb to 512kb is only really noticeable in Windows.

My search criteria for ideal processors: the model number starts with AXM (mobile), ends with C (266 FSB), and is a 462 pin package. It just so happens the 3000+ works perfectly.

AMD Athlon XP-M

I chose the AMD Athlon XP-M CPU line for my build because there were boards available that had ISA slots and support for Socket A processors. Not too many of these exist, but they aren't obnoxiously rare either.

XP, MP, XP-M?

It turns out that there is little difference between the XP, MP and XP-M processors in the Athlon series. The XP-M processors are binned to work at a lower voltage, which is very ideal for mobile computing in the interest of conserving battery life. They also have an unlocked multiplier, meaning they can be underclocked through software (and the BIOS, if there's baked in support.)

The boards I chose for this both have on-board jumpers for multiplier configuration, and the XP-M processors I have do indeed go all the way down to 5x and up to 12.5x.

Multipliers

If the maximum multiplier according to the manual is 12.5x, how do we get up to the stock multiplier of 16.5x found on my 3000+? Well, at some point during the development of the Athlon XP, an additional fifth bit was required to express lower (down to 3x) and higher (in excess of 20x!) multipliers. BIOSes shipped with KT133A boards generally don't know how to handle this second set of multipliers so they just ignore the new bit, and interpret only the lower four. Fab51 has some lovely tables that demonstrate this. My 3000+ might have a stock multiplier of 16.5x, but my BIOS is going to interpret that as 8.5x, and that's well below what I can configure it for. The maximum the boards will allow is 12.5x, which is the highest value achievable using only the lower four bits. I set the jumpers accordingly and leave them there.

I can really only increase the multiplier further in Windows using CrystalCPUID, which can be downloaded at this link. But I really don't need to run these chips at 16.5x. Most games can't even really show the performance difference.

Voltage Considerations

When using XP-M processors in a desktop board, it'll be immediately apparent that the reported desktop voltages appear much higher, sometimes even by .2 or .3 volts. That's a significant difference in heat generation. In the BIOS of both machines, I attempt to undervolt wherever possible to compensate. The Soltek board lets me set a specific voltage down to 1.5v, which is great for higher voltage chips but not so great for Geode NX (which can run down to 1v, I'm better off just letting the BIOS decide.) The Soyo board only allows me to configure a differential instead, and doesn't go very far, so this is great if the reported voltage is somewhat close to the actual rated voltage.

I can often get an additional 0.05v to 0.10v reduction past the rated voltage of the CPU and still remain stable on XP-M chips. This makes my system run even cooler yet.

Initial BIOS Setup

When I get a new board, I've gotta check out the BIOS.

Unused Onboard Devices

I turn off every feature I won't be using. Onboard serial and parallel connections are disabled to easily free up a bunch of IRQs. I might disable USB if I'm not using any of the onboard ports.

Onboard sound definitely gets disabled. On boards of this era, it's common to try and emulate a Sound Blaster, overlapping the IRQ and DMA settings I plan to use elsewhere.

IRQ & DMA Reservation

The idea is to disable automatic PnP for DOS, and try to avoid Windows reconfiguring any non-PCI devices.

In PnP/ISA IRQ reservation, I turn off "PnP OS", reserve IRQ 5 and 9, and reserve DMA 1 and 5.

IRQ 5, DMA 1 and DMA 5 are reserved for Sound Blaster compatibility. Though DMA 5 is not strictly necessary, I like having the option to install a real Sound Blaster 16 and have a DMA available for 16-bit audio playback in games that support it. IRQ 9 is reserved for MPU-401 functionality, which even games that can't be configured will often discover. Amusingly, configuring a game for MPU-401 on IRQ 2 will sometimes work if high IRQs can't be selected, simply because of the way IRQ cascading works.

Housekeeping

The time can be set now too while it's convenient, but it can also be set during Windows setup.

I configure the boot order of devices here too. I'm generally not booting from a floppy unless I need to set up a system, so my order is generally CD-ROM/HDD-0/Floppy. There are some fickle old games that must be run from a floppy; in that case, I will reverse HDD-0 and Floppy.

I like to turn off all special screens and logos and whatnot to reveal the bare POST screen as well.

Initial Software Setup

I've got 16GB CF images that I'll be using to make the process of replication way easier. But what if I'm starting from scratch: a blank CF card?

Partitions

Since I'm using MS-DOS 7.1, I'm able to take advantage of some of the more modern storage support. I have a boot floppy with some DOS utilities on it, one of which is Fdisk. This will allow me to configure the partitions on the drive before doing anything else.

I create a 2GB partition with the intent to boot from it as FAT16, and fill the rest of the drive up with (maximum) 4GB FAT32 partitions. After this, I throw in a bootable Windows 98 SE install disc (the OEM one is a bootable image.)

Windows Install

I restart, boot from the CD, and select the "boot from CD" option. I then switch to the CD drive, and type setup /nm /is. What this does is bypass the minimum requirements check and skip ScanDisk.

The prompts are pretty straightforward. Just install Windows 98 SE as usual.

Post Install

Now, I reboot into the DOS command line. On one of my non-OS drives (in this case D:), I copy over all the files from an MS-DOS install. I've got folders for files from 7.1 and 8 (some of the Windows ME stuff is different.) I use D:\DOS7 and D:\DOS8 folders to indicate them individually.

I modify my Autoexec.bat, Config.sys, and Msdos.sys files to my liking at this point. (I'll post the contents of these later.)

Crippling Some "Features"

I don't care for Windows automatically loading Himem.sys every time I go into the command line, even when it's not in any of my configuration files. It loads the file from the Windows directory on the OS drive. So, I run COPY D:\DOS7\ECHO.SYS C:\WINDOWS\HIMEM.SYS and I agree to overwrite the file. I chose Echo.sys for this because it's small, does not install a TSR, and it's silent. If I want Himem.sys to be loaded, I'll do so myself from Config.sys.

Driver Time

This is the point where I start installing Windows drivers. See the Drivers section below for more information on what I use in my builds.

Power Saving

The power saving features of Windows can cause display drivers to crash when the screen is turned off. I always switch the power profile over to Always On, and switch the below options to "Never". There's no good reason for this feature to actuate when the system is primarily going to be used for gaming and little to no idle time.

The Fun Stuff

This is a perfect opportunity to fill up the remaining drives (that aren't C: or D:) with games that should be run in pure MS-DOS mode. Much of my stuff fits on just E: and F:.

Drivers

Since both machines are very similar, I was able to use a similar suite of drivers to make them go.

Via KT133A Chipset

I used the Via 4-in-1 Driver, version 435, 4in1435v.zip. I downloaded this from Phil's Computer Lab on the Via chipset driver page.

I leave all the settings as default for this installation.

Nvidia GeForce

I used the Nvidia GeForce driver version 81.98, nvidia_9x_81.98.zip, also available from Phil's Computer Lab on the Nvidia Win9x driver page.

Once installed, I find that with my capture card, the GeForce likes to run at the highest refresh rate possible, and that ends up being 200 or 240 hz. That causes problems, so I have to set it to something lower such as 60.

3dfx Voodoo2

I use the FastVoodoo2 driver, version 4.6, fastv2-win9x-v46.zip, once again from Phil's Computer Lab on the Voodoo2 driver page. Be sure to only install this driver on computers that actually have a Voodoo2. I experienced some issues when this coexisted with the Voodoo5 driver listed below.

I turn Vsync on for compatibility with older games that rely on a capped frame rate.

3dfx Voodoo5

For the 5500, I use the 3dhq driver, version 1.09 beta 10, 3dhq-w9x-1.09-beta10.zip. Phil's Computer Lab has this driver as well on a dedicated driver page.

I force Vsync on the Glide/OpenGL section for compatibility with older games that rely on a capped frame rate.

Yamaha OPL3-SAx

There are official drivers for this line of cards. But why would we go that route when Tiido gave us a better one on his website? His SETYMF utility is the most fully featured setup utility for cards that use the OPL3-SAx, including but not limited to his very own.

Because these are all PnP cards, Windows likes to reconfigure them. Windows 98 SE comes with a driver. Disabling the device in Windows also disables its sound output. So, I actually delete opl3sax.sys from my C:\Windows\System folder. It'll complain about the card's driver not being found, but it also won't try to mess with the legacy sound support. DOS games will still see the card just fine, and still output sound properly.

I do not use this card for Windows sound at all. But in order to use all its features in DOS, I need setymf /initonly in my Autoexec.bat. The setup utility can add this automatically.

Yamaha DS-XG

This is the card I use for Windows. Some folks swear by the VXD driver. I've had better success in Windows games with the WDM driver.

Whichever driver is preferred, they can all be found as part of a driver package on Vogons Drivers, courtesy of Vogons user betamax80.

I disable all legacy and gameport features of this card, because these are covered by the OPL3-SAx. Windows will use this device for MIDI playback. The bundled sample bank sounds excellent for its size, and a few games such as Final Fantasy 7 can utilize some of its special features.

Since I route the audio internally from the OPL3-SAx through the DS-XG (so that I only need one audio connection for capture), I also need the DOS driver from that pack. Note that while it is a DOS driver, the installer can only be run in Windows. I just need to set the mixer inputs I plan to use in setupds.exe, then run it in my Autoexec.bat with setupds.exe /s so that the settings work in pure DOS mode.

Intel Pro/1000

There are two driver packs that are required: one for Windows 98, and one for MS-DOS. Both can be obtained from Intel's Download Center page for the Pro/1000.

The Windows driver pack is PRO98M.EXE, this simply installs the network driver for Windows 98. There is no further configuration needed - although I went back in and set static IP addresses for both machines since they were not connected to a router.

The driver that can be used in DOS is called PRODOS2.EXE, and this contains files that will be needed for DOS IPX networking. This can be opened with 7-zip; the installer is not necessary. The important files are in the ODI folder. I extract just that folder to the hard drive. Then, in order to utilize IPX functionality, I run these three commands, in this specific order - but only when I plan to use IPX networking:

LSL.COM
E1000ODI.COM
IPXODI.COM

This also requires that Himem.sys (or similar substitute such as Himemx.sys) be loaded in Config.sys.

The first successful IPX network game between Appia and Ironwood.

Raspberry Pi File Server

I slipped a 400GB SD card into the Raspberry Pi, imaged with NOOBS. The installer booted up and I chose to install Raspbian. Once I went through the initial configuration, I then opened a terminal and ran these commands to make sure I had the latest packages (this should already have been done by the installer if it was provided with an internet connection, but it's here just in case):

sudo apt-get update
sudo apt-get upgrade

Now, I followed a very helpful guide that demonstrates how to install Samba. I'll reproduce the steps here to save you some time.

I installed the Samba packages:

sudo apt-get install samba samba-common-bin

After that installed, I created a share folder at the root for easy access (this is a private network for unimportant things after all, so I can be a little more lax)

sudo mkdir -m 1777 /share

Finally, I configured the share in the Samba configuration. I opened up the editor with:

sudo nano /etc/samba/smb.conf

And added this at the bottom of the configuration:

[share]
Comment = Pi shared folder
Path = /share
Browseable = yes
Writeable = Yes
only guest = no
create mask = 0777
directory mask = 0777
Public = yes
Guest ok = yes

Now, just a simple ctrl+o and ctrl-x closes Nano, and the file share should immediately be accessible. It will require a TCP/IP connection, so the Windows 98 machines must be able to communicate via that protocol in order to connect. After that, it should be trivial to map network drives to the Raspberry Pi.

Conclusion

I had a lot of fun putting these two machines together, and I'm sure this won't be the last time I post about them. I'm constantly refining my process and improving these machines wherever I can, while still maintaining the ability to enjoy pure MS-DOS gaming.

Thanks for reading!