I made a maintenance release of my ubox MSX libs back in April, which updated one dependency and the docs after I run some tests with the newest SDCC. It was the first release of 2022, because the project is mature and stable –although there’s interest to make changes–.
Since then, I made another round of dependency updates, with special interest in rasm, because this excellent assembler has changed the way it builds, and it required a bit of work to move to the latest version. So yesterday I thought I would make a release, to not keep those changes in the main branch without being “official”; and I found a small bug that needed fixing.
It was an interesting one. Some of the python tools that convert PNG images to different data formats used on the MSX was using a set, and looks like in the python version coming with my current Debian (3.9.2), the order of the elements have changed. Long story short, the sprite of the player character in Green –the demo game– was not green any more. It was easy to fix, and I decided to make some changes to the project website to look marginally better and give visibility to the fix.
And then I was checking some files randomly and I ended reading the TODO file, and without noticing I started implementing CAS support.
The CAS files are a representation of cassette data used by most emulators. You can load them on your emulator, or convert them to WAV –if not play them directly– and load them on the actual hardware. Most MSX aficionados will have more sophisticated ways of loading software, but if you don’t, the CAS files are the easiest –and cheapest– way of loading homebrew games.
The official take of the community is that “cartridges are best”, and I agree; but it is also true that by releasing my games in CAS format –as well as in ROM format–, more people had a chance to play them –including some extreme cases of models with 16K of RAM and two memory expansions so for example Uchūsen Gamma would load–.
Some time ago I released as OSS my mkcas tool, that I wrote to generate the CAS files of my games, and in the case of ubox MSX libs it was just matter of adding the tool to the build pipeline so the user could get the ROM file –just a cartridge image– and, optionally, a CAS version of the same code. Including a loading screen, of course.
The CAS file uses a multi-stage loader:
- Firstly, a short BASIC program is loaded that will load and execute a binary loader.
- Then the binary loader loads two blocks, using the BIOS functions and some fancy code to show multi-colour loading bars.
- The first block is the compressed loading screen, that is decompressed and uploaded to the VDP, so there’s something nice to watch as we wait.
- The second block is the
ROMitself, compressed as well. It is uncompressed and setup like it was running fromROM, but inRAM.
The only tricky part is configuring the slots so we have ROM, RAM, RAM and RAM; and that’s why I made this optional, because it will not work in machines without enough memory.
To start with it requires more RAM than the cartridge, like 32K more –which is the size of the ROM–. There are also other limitations –like the compressed ROM being less than 24576 bytes–, but all in all I think having a CAS file as an extra is totally worth it (based, as I say, on my experience with my games).
I spent way too much time reviewing the code because I forgot that any MSX model with disk needs to boot pressing the shift key to disable the disk BIOS or the BIOS will use some memory that the loader needs, but it wasn’t too complicated at the end. I’m happy with the result!