While developing DOSContainer, I restarted my efforts multiple times over due to me underestimating the complexity of the task. The current
attempt starts at the very beginning and works up from there. The very beginning of the PC-era being the IBM 5150 with two 160KB 5.25" floppy
drives. IBM had sourced an operating system from Microsoft that it would sell as PC-DOS to go with the system. How that deal came to be is
the subject matter for another article. Right now, let’s dive into what’s needed for IBM PC-DOS 1.00 to accept an empty floppy for use.
After failing to install a number of packages from upstream binaries I decided to host
my own FreeBSD packages mirror using Poudriere. I must say: the Poudriere software is
the most elegant solution I encountered to allow users of an operating system to build and
host their own package repositories. Actually integrating the resulting packages into a
workable infrastructure is not entirely obvious. Here’s how I did it and why, which may be
of use to others. Mind you: I use FreeBSD on a laptop as my daily driver, but this strategy
should work just as well for server use cases. I’m assuming you somewhat know your way around
administering FreeBSD systems and have a specific need to fiddle with the package mechanism.
One of the main reasons why I’m building DOSContainer in Rust is ease of use, both for myself as a developer as
well as the end user. Sure you can get the source code and build your own, but that’s not what I’d call user
friendly. Yet I am intensely lazy, so I’d rather spend half a day automating the build/release process than do
the steps manually whenever I have something meaningful to share. So today I managed to tweak my Jenkins
environment up to the point where it now spits out everything DOSContainer needs.
As I’m coding DOSContainer, more and more games turn up on my hard drive in a playable form
and I want to share those with the world. I decided to rip them out of the actual project’s
Git repository and just host them on my website. If you’re looking for the current list, look
no further because this is it and I will be updating this page as time goes on.
Suddenly I realized that it’s been months that I wrote about my efforts to port
Leisure Suit Larry to the Commodore 64. The good news here is that the project
is still on my radar and far from abandoned. The reason why I’m not posting any
progress is the fact that I’m upping my skills on the back of the other project
I’m working on. The skills I need are in the area of Rust programming. Why would
I need to program in Rust when creating a game for the C64? Hear me out.
DOSContainer the Bash version functions, but it really is just a proof of concept for what I really
want this product to be. As such, I ceased maintaining the Bash version except in case of glaringly
hideous bugs. Instead, I’m now working on a version in Rust. The result should be a native binary for
a number of platforms that does exactly what I want and comes in a simple, monolithic binary that
simply works. This post is the status update on the project for Q1 2024.
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.
Rising electricity cost made me reconsider the economy of running a homelab this summer. Combined
with a short period of sweltering heat, I was motivated to find a different solution to hosting
my own services than to do it from home. Worst case was when I had a NAS sitting on the floor with
a table fan strapped precariously to a chair in order to keep the disks’ temperature within spec. My
choice was to either upgrade the housing and hardware of my lab substantially, to replace it with
something rented, or to keep on messing with 3rd-rate hardware to keep up some semblance of stability.
After some quick calculations I went for option 2: rent a box with Hetzner and migrate. To my surprise
Hetzner had stopped supporting FreeBSD but I had no intention of migrating to anything else. Here’s
how I dealt with this situation.
As I’m slowly plodding along porting Leisure Suit Larry to the Commodore 64,
I was becoming ever more convinced that Sierra simply never bothered to do
this because of technical limitations. While this may well be a significant
part of the truth, there also seemed to be a far more human issue at play
between Sierra’s leadership and Commodore at the time.
Ok, so scratch the previous post. Generative AI is a nice gimmick but
the free version of ChatGPT is not the boon I thought it could be when
coding stuff that’s a little off the beaten track. I’m back to coding
my own Assembly generator and switched back to Rust for that. As I go,
I’m also reconsidering the architecture of the input parser. As it
turns out, the idea I had wasn’t all that conducive to being generated
automatically by a script and I REALLY want to avoid hand-coding all
of the word parsing logic.