DOSContainer moved! The project has its own page on the internet that will closely track all progress. It’s set to expand beyond a simple list of blog posts in the near future as the project progresses. For now, see the new page for all things related to DOSContainer.
DOSContainer is still progressing, even though I skimped on the updates. Let’s rectify that. There’s a lot that happened over the past months, but unfortunately there still isn’t a stable release to be made. The main effort went into reimagining the configuration file format and structure behind it, and I’m hoping this’ll be the last such major overhaul because it’s no fun writing code that only does boring stuff like config file parsing. I really want to get into the nitty gritty bits of ancient DOS and making sure that gets reproduced as faithfully as possible. Let’s go over the changes though.
There comes a time in the life of many an aging geek, that some toy needs to be hooked up to the internet. For me that time was last week and the toy was a Nintendo Switch with Animal Crossing New Horizons on it. Nintendo made a few absolutely bone-headed decisions here. The first: only supporting peer-to-peer connectivity for gaming. The second: pretending like IPv6 does not exist. The result? You need to do a lot of stupid twiddling with NAT on the IPv4-side of your network to get online gaming to work. There’s so much well-meaning but wrong information floating around, that I decided to write down for posterity and my fellow geeks how I set this up with an OPNSense firewall.
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.
Why not use a tool if it’s available, right? I’ve been experimenting with ChatGPT for a while and it writes generally abysmal Assembly code for the C64. That’s probably because its training data on this specific language is tiny. Now I would really like to have a generator that does all of the boring stuff discussed in the previous post. Writing reams of repetitive code to parse out individual words is not my idea of fun, but it’s a necessary evil to get this game working. So I recruited the machine to do the machine’s job!
Following up on yesterday’s conceptual musings, here’s some more meat to the actual implementation. In this blog I’m exploring the actual Assembly code that converts individual words to tokens for use by the input parser later on in the process.
Leisure Suit Larry originally featured a free text input system that allows the player to enter instructions for Larry to carry out. These instructions take the form of sentences in plain everyday English. Parsing and interpreting this so that a video game can make sense of it is quite a challenge. Can we teach a computer English? It seems so, but not one from the 1980’s. The Commodore 64 does not have the RAM nor does it have the CPU to completely parse English setence structures and grammar. But the good news is: neither did the PC on which Larry first came out. There are tricks involved!
As mentioned earlier, I’m not porting AGI but writing Larry again from scratch to cater to the specific strengths and weaknesses of the C64 as a platform. I’m doing this in 6502 Assembler as that’s the only way for me to gain the required speed and control over the hardware that is needed to pull all the tricks I need. In this post I’ll provide more detail on how the screen actually gets drawn.
To borrow the words of the greatest hero of all time who never was, Samwise Gamgee: I’m back! And it’s been quite a ride this past month. Let’s stick with the project and surrounding computer stuff for now.
Nobody knows why exactly, but my cartridge code is now alive. The problem is on the C64 side of things and mainly has to do with the routine that would copy my bootloader into a safe RAM location.
Started a new Git project for Larry on cartridge. Adapted the framework I found online and things now work. I can actually load a cartridge reliably and get the machine into a state that I can work with. Decided to do an intro sequence for the game. It helps that this forces me to deal with bitmapped graphics again, which is something I hadn’t incorporated into the automated build before.
Spending a little bit of time today on my EasyFlash generator. Decided to feed the tool YAML files instead of command line parameters. Defined the YAML spec in the README that goes with the tool.
Not much time to work on Larry or its surrounding projects today. Read up on the cartridge formats most of yesterday and decided on implementing EasyFlash as a CRT image. The CRT format seems to be canonically defined by the VICE emulator nowadays, so that’s what I’m going to use. The main problem there is a lack of scriptable tooling. I will not proceed with a game of this size without the ability to automate the build process.
The C64 community on Twitter pointed me in the direction of releasing Larry in a cartridge format. That’s something I never even considered because it used to mean creating physical hardware. Nowadays cartridges are just files so it could be useful, so next steps: figure out what they are and how they work.
In the last post I explored why porting the AGI engine would be a fruitless endeavour. So now what? Hand-code the whole thing 6502 Assembler! Yes! Well, sure, but how to go about that? This blog describes some of the design choices I made while weighing my options on the Commodore 64.
Back in 1987 Sierra OnLine released an adventure game that shaped a significant part of my “gaming upbringing”. Leisure Suit Larry may not have been very appropriate for my 10 year-old self but it was fun! Walk the guy around a city and try to get him to do all sorts of things in order to finally win the game. The game came out on the IBM PC, which is also what I played it on. Later on, I saw the very bad Amiga port and at some point I wondered why it never came out for the C64. Looking for a hobby project, I decided to bite off a lot more than I can chew and started porting the game.