Sometimes I get writers’ block. I’m in something of a rut when it comes to Larry on the C64. Nothing to worry about. I know myself and I’ll get back into it soon enough but that’s why I always have more than a single project cooking. Some may remember that I used to be working on DOSContainer, an attempt at creating a generator for bootable hard drive images for use with MS-DOS in emulated environments like the MiSTer’s AO486/PCXT cores, PCEM86 or DOSBox. I picked that back up yesterday and I’d like to report on the status for a bit because there’s good news to report: we have lift-off! That’s to say my jumbled mess of cowboy-code now generates a bootable hard drive image that my MiSTer accepts and launches The Secret of Monkey Island as if it were a console.

DOSContainer conceptually takes the approach we’re seeing from Docker: layered construction of fully working environments. The first layer is by FAR the most annoying: generating a properly working and compatible bootable hard drive image. I’ve now managed to do this on FreeBSD, which is my personal platform of choice. Sure I could probably have done it in Linux or maybe even in a platform-independent way but hey.. it’s a hobby and I digress. It works though. My script generates image files from anywhere between 32 and 2048 megabytes in size on demand and installs the absolute bare minimum of system files on there. That’s layer 1: OS foundations.

Layer 2 is the minimal OS. Many games don’t need an installed OS at all beyond this bare minimum, although things like SMARTDRV.EXE, HIMEM.SYS and assorted goodies would be nice. Those go into what I’m now calling minimal DOS. There will be a C:\DOS directory containing just these few items and the commands needed to offer a bootup menu from batch files.

Layer 2 can also be a full MS-DOS that populates C:\DOS with the whole kitchen sink from Microsoft so that you can also run things like Windows 3.x on top of it, or run proper applications in there that expect a sane MS-DOS environment.

The next foundational layer is a device drivers layer that includes things like the CuteMouse driver so you can use a mouse in your games/apps and other assorted device drivers that may need to go in there, like support for CD-ROM and even networking if you feel really crazy.

The last layer is the application itself. I’m currently leaning heavily on the zipfiles in eXoDOS to pull ready-to-run games into my disk images. Works like a charm, although they need some different glue batch files to boot op properly. Those batch files will be in my code.

Pulling all of this together will be a pile of Bash code that forms the framework, combined with configuration files that constitute individual games. You run the bash script against a configuration file and the result will be a raw disk image file that you can directly boot your game from.

Why even do something like this??

Because I can, and because I personally detest those HUGE multi-gigabyte game collection images that need to be managed and updated as one large blob. I’m old-school UNIX and I like to keep it small so you get what’s needed but no more, packaged into a small disk image, and it’s still very simple to use. Updating the images is a matter of pulling in the configuration files and a quick rebuild later you’ll have a new and clean disk image ready to run your game as if it were a console cartridge dump. Remaining bit of work: how to handle savegames and other dynamic user-generated state?

None of my code is ready for release yet, but I thought I’d let my dear readers know what I’m up to when Larry gives me the blues.