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 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.
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 from
ROM, but in
The only tricky part is configuring the slots so we have
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!