A lot of my “free time” in 2022 so far has been pre-occupied but have had some successes resurrecting old source code and fixing bugs in ancient code.
As previously mentioned, I have located the “BRU” backup files I made from my Amiga A1200 and thus have been able to effectively build an emulated Amiga with the exact content of my old machine. Thus I have access to ALL my development files with their original dates. Sadly directories don’t keep their dates.
I’ve been having some ideas about how to continue this blog (even though have long drafted out several blog posts) and even my goals for this Amiga development, and I think I have a radical plan.
I’m going to semi-scrap what I’ve done so far and change my development environment massively… I’m going to switch to working on a Raspberry Pi 400. I’m still going to be using FS-UAE as I plan on using stock Rapberry Pi OS (Raspbian). Also I’m going to settle on just Amiga OS 3.2 as the development system.
I’ll be maintaining a repository on GitLab that can be cloned into a “transfer” hard drive folder with files and scripts to easily “bootstrap” a fresh Amiga OS install with developer tools. It will also be home to some “host” tools and scripts and over time collect each “project”.
I’m going to “go back” to using HWGRCS, an Amiga port of RCS which is a source code versioning system. I will bring back my original code (with original dates), commit this to RCS (except rare instances where I had used RCS in the original project), then re-apply the changes made to each project.
After revisiting the tools so far I’ll be probably working on some other tools that were custom made at the time, at least one “reverse engineering” tool, and maybe some new tools.
Then instead of just getting old music disk productions to the point they can be re-assembled from component parts (almost) as they were I’m thinking of doing a sort of low grade “remastering”. Whilst I did a crude “hack” to fix A500+ (Kickstart 2.04) compatibility on the first disk there is potential for Kickstart 3.0 and beyond to further cause issues. With that in mid I’m considering making these “remastered” versions require 1MB of “chip memory” as a minimum. For machines with only 512K chip memory, real or emulated, the original first two disks will be fine.
Another change I’m considering as part of a remaster is bringing the “disk change awareness” of the second disk (originally for future expansion) to the first disk, maybe even proper mouse control. Plenty of obstacles to overcome though.
Also related to this I had an idea for an “enhanced” disk format where there could be “meta information” about the disk that a music loader could use to display some information, and this could be a good opportunity. to implement that.
I think most likely I’ll break things down to getting all the pieces of the first music disk to be re-built, then the second disk, then what I’d made so far of the third, because I already have the changes required, and then look at updating things.
I’m starting to get really excited about this again.