I’ve been wanting to create some Bible study software for DOS for a while now. Why target DOS? Because it’s a cool platform, it’s still in use in some areas of the world, and I haven’t been able to find readily available Bible software for DOS, whether open-source or not. Over the weekend, I was thinking about this project again, and decided that, for the sake of development ease and avoiding emulator quirks, I should set up a DOS installation on physical hardware and create the software on that machine.
I have tons of old computers in varying states of decay or usefulness; three of them still work pretty well. I decided to pick the weakest of the three for this project since it probably had more than enough grunt for the project at hand, but wouldn’t be useful for much else. The chosen system was a Compaq Presario 6000 desktop, featuring some iteration of an AMD Athlon XP processor, 256 MB RAM, a 20 GB hard drive (which I was about to expand for reasons I’ll get into later), a floppy drive, and dual optical drives (only one of which works). This particular system is a bit strange since its USB controller and network card are both NVIDIA hardware, even though NVIDIA is typically associated with graphics cards. Beyond that though, the system was pretty typical for the kind of hardware you’d see in the early 2000s - all of the drives use IDE to communicate with the motherboard, and most of the expansion slots are PCI (except for a couple of mystery slots, one of them might be AGP, and another one seems to be intentionally blocked off and I can’t tell what it is). The back panel features PS/2 ports for a mouse and keyboard, a parallel port and a serial port, a VGA port for the monitor, and a few USB (probably USB 2) ports. There was also a 3Com network card installed in one of the slots, which I had put there when experimenting with OpenBSD on this system. The front panel had a couple more USB ports.
One downside of using DOS for development is a lack of good source code versioning systems. Git doesn’t exist for DOS, and I don’t have the time or willingness to learn RCS or similar (maybe I should?), so I decided I would implement version control by just copying the project every so often to a backup location, probably zipping it in the process. Anticipating that this would probably require a hefty chunk of disk space, I decided to add a 40 GB Maxtor drive taken from a Pentium 4 desktop I had laying around. Getting the drive installed was a bit of a challenge; many older computers have the drives slide out backwards into the system, but this Compaq has them slide out forward out the front of the machine. This meant I had to get the front panel off of the machine, which was hard because it was held on by four extremely stiff plastic latches that had to all be disengaged at the same time. Thankfully the plastic of the front panel was able to bend enough that I could disengage each latch individually, then keep it that way while I worked on another latch.
After getting the cover off, I had to fight with Compaq’s drive mounting hardware. Rather than just screwing the drives directly into the bay like a normal computer would, Compaq elected to use a system of rails and latches to keep the drives fully hooked into the machine. The screws had very thick heads, and were intended to slide along the rails and then latch in place once inserted far enough. As strange as this already was, there was also the problem that the secondary drive bay had a malformed rail, that was just barely too narrow for the mounting screws to actually slide in. There were also separate screw types for the optical drives and the hard drives. What I ended up doing was using optical drive screws on the Maxtor hard drive, which seemed to fit correctly and were able to latch in place. After getting this kludgy setup to work, I then remembered that I needed to set jumpers on the drives to configure them as “master” and “slave” properly, so I then took both drives out, reconfigured the jumpers, and slid them back in. After a bit of cable routing shenanigans (including removing a rather unfortunately located zip tie), I finally had both drives installed.
To confirm that I hadn’t made a total mess of my drive configuration, I decided to take some time to power the system on and check the BIOS. I had an old PS/2 Microsoft keyboard, and a small, 4:3 aspect ratio flatscreen display with a built-in VGA cable, so I decided to use those for the project. Nothing caught fire when I plugged it in and powered it on, and after getting into the BIOS settings I found that both drives appeared to be properly recognized. I also saw “Removable Media Boot”, which made me hopeful that this machine might support USB boot. I turned off a bunch of settings related to “fast startup” to minimize the chances of having issues, then saved my changes and exited.
Since I thought USB boot might work, I downloaded the FreeDOS 1.4 FullUSB and flashed it to a USB drive. Unfortunately, my hopes were soon dashed; the USB drive did not appear in the BIOS’s boot order settings. Crud.
I don’t generally like burning CD-Rs if I don’t have to, since they can’t be rewritten, they probably won’t keep being manufactured for much longer, and I only had 48 of my original stack of 50 left (oh horror!), but I didn’t see another good option at this point, so I dragged out one of the other working old computers, a Panasonic Toughbook that had an old-ish install of Void Linux on it. This particular machine looks like it’s been through a warzone, but it still works well enough, and most importantly, the CD burner in it seems to work flawlessly. In the hopes of not having to waste any further CDs in the future, I decided to burn Plop Boot Manager to the disc rather than burning FreeDOS itself. The burn went smoothly enough, the Compaq was happy to boot from it, and next thing I knew I was able to boot into FreeDOS from the USB! Woohoo!…
…or…. not. FreeDOS itself seemed to run without issues, and partitioning and formatting the drives wasn’t a problem, but for some reason FreeDOS’s installer didn’t work when booted in this way. Despite the fact that it was installing to what it considered drive D:, it kept trying to write files to drive C:, which was the read-only volume on the USB drive. This resulted in lots of “Abort, Retry, Ignore, Fail?” error messages, and while the installer did seem to work (kinda) if I just "ignored” all the errors, I didn’t trust the finished installation was going to work. I also couldn’t just sit there and press and hold the “I” key to keep ignoring errors, since doing so slowed the copy process down (probably because it was spamming the keyboard interrupt, I would guess). So, one CD-R apparently wasted. Next!
Back on the Toughbook, I used wget to download both the FreeDOS 1.4 LiveCD and BonusCD. I needed both discs, since the OS was on the LiveCD and the development tools (like the C compiler I wanted to use) was on the BonusCD. Burning the discs was pretty easy, and FreeDOS seemed much happier installing from a CD than trying to install from a USB. Soon enough I had a working FreeDOS installation, and a little bit later I had a good text editor and the Open Watcom 1.9 compiler installed.
At this point I was almost ready to sit down and start coding, but decided I had better figure out how to get data off the system before I dedicated a bunch of time working on my project. I didn’t want it to just rot on the machine it was coded on. At this point I discovered two frustrating facts:
-
The USB driver included with FreeDOS only works with UHCI controllers, but the controller in this system is an OHCI controller.
-
The network card wasn’t supported out of the box - there were packet drivers out there for it most likely, but those weren’t very useful since I couldn’t get outside data onto the machine since USB didn’t work.
(At this point one might reasonably ask why I don’t just use the floppy disk drive. That’s because I have exactly one functional computer with a floppy disk drive, that being the Compaq I was setting up. I can use floppies as storage if I’m willing to risk catastrophic data loss, but they’re useless as a data transfer mechanism. There are also OHCI drivers for DOS available online, even open-source drivers, but of course those would have to be transferred to the system in order to use them.)
At this point what a normal person probably would do is accept the fact that they’re going to have to burn some more CD-Rs, and proceed to get some USB and network drivers onto the machine. But due to being paranoid about running out of CD-Rs, that was an absolutely unacceptable solution to me. I had the OpenBSD disc I used some months ago laying around, so…
Dual-booting FreeDOS and OpenBSD didn’t end up being all that hard. For one, BSD’s partitioning system actually works really well for multibooting. Even though OpenBSD generally uses a whole bunch of partitions, it doesn’t try to create them all directly on the drive. Instead, it creates one “container” partition, and then creates a bunch of OpenBSD-specific partitions within that container, separate from the drive’s usual partitioning scheme. On top of that, the installer is pretty straightforward (once you realize that you need to skip all forms of network setup if you don’t intend to plug the machine into a network), and an OpenBSD installation without an X server or games fits in 3 GB of disk space with a bit of wiggle room to spare. I don’t expect I’ll be able to update this installation without pain, but since all I need it to do is let me move files to and from a USB drive, I don’t need to update it (and won’t be connecting it to a network).
The only really painful part of the installation process was partitioning - every operating system seems to have a radically different idea of how fdisk is supposed to work, and OpenBSD’s idea of fdisk is the most… um… interesting one I’ve seen to date. Rather than working in terms of unallocated space and partition creation, OpenBSD’s fdisk just acts as if all four partitions MBR allows for always exist at all times. You don’t create a partition, you just configure each of the partition slots you’re interested in working with. If you don’t want a partition to exit, you set its type code to “00” (unused). If you do want a partition to exist, you set its type code to whatever’s appropriate for your use case, define a start and end sector, and you’re done. I’m guessing this is probably a more accurate model of how MBR actually works, but it was nonetheless surprising to me. More surprising is that there don’t seem to be any safeguards to make sure you don’t do something completely ridiculous like define partitions that overlap each other, or put sector 0 as part of a partition. OpenBSD’s fdisk also does not try to guess things like how large you want the partition to be, so you have to calculate everything by hand and double-check your work to keep from making a mess. To be honest, I actually kind of like this system, it was just very unexpected.
After fighting with the partitioner a bit, I made a 3 GB partition at the end of the 40 GB Maxtor drive to install OpenBSD to. The remaining 37 GB would still be dedicated to a FAT32 DOS system. (In retrospect, I wish I had split the drive 50-50 between DOS and OpenBSD so I could play with both, and in all likelihood I’ll probably go back and do that at some point in the future, but this is the setup I have now.) Once that was done, OpenBSD installed just fine…
…and then I realized that the BIOS in this machine doesn’t allow me to specify which hard drive I want to boot from. The boot order settings fail to list the secondary drive anywhere, and there’s no boot menu button.
Thankfully there was a good workaround. Remember the Plop Boot Manager disc I burned near the beginning of this ordeal? Turns out it had no problem recognizing all of the partitions on all of the drives in this system. All I have to do is just leave the Plop CD in the bootable drive, and then I can choose whether i want to boot into FreeDOS or OpenBSD effortlessly.
That pretty much describes where my setup is at so far. I have been able to successfully transfer files between my main work laptop and the FreeDOS system using this OpenBSD “shim”. I haven’t gotten USB working in FreeDOS yet, and I haven’t managed to get either of the network cards to work yet, but the system does work, and I had a lot of fun using “edit” and “fed” to write up a README.TXT for the Bible software project that inspired this whole endeavor. There’s still more to do for setting up the workstation though:
-
I really would like to have working USB in FreeDOS. There’s a Panasonic driver floating around the Internet that people claim to have success with, I’ll probably end up using that.
-
I should replace the broken optical drive. Then I can have both Plop Boot Manager and the FreeDos 1.4 BonusCD inserted at the same time, which would make life quite a bit easier.
-
I’m already regretting only giving OpenBSD 3 GB of space on the secondary drive. I’d like to be able to use it to chat on IRC, which means connecting it to the Internet, which means keeping it up-to-date, so I’ll probably repartition the drive, allocate 20 GB to OpenBSD, and leave 20 GB for DOS. Even that’s probably huge, but we’ll find out. (I don’t intend to connect FreeDOS to the Internet since I’m a bit scared of the security issues of doing that.)
-
Embarrassingly, I’m using a Chromebook to let me look at Open Watcom’s documentation in a web browser. I should set things up so that I can read the documentation from within DOS itself.
Other than the above points though, the system is working quite well, and I’m happy with it. Hopefully I won’t end up spending so much time setting it up that I never use it for its intended purpose! :P
from Planet Ubuntu https://ift.tt/5X6L97q
No comments: