It seems like every Retrochallenge something happens to distract me from my project. A year ago I had hardware problems; this time around I’ve lost a week to spending my free time playing the recently released Bard’s Tale IV. (Quick review: performance-wise the game is a mess, but the combat system is really interesting and the dungeons I’ve seen have been cool and the music is really good, and I’m totally addicted to it).
But I haven’t been completely neglecting this project. One of the things I’ve wanted to do for a while is improve the way that I’m building disk images for the game. Right now, my build script creates two .d64 disk image files which I can load into the VICE C64 emulator or copy to an SD card and use on my real C64 with my 1541 Ultimate II.
The test.d64 disk is straightforward. It contains the executables, the custom character sets, the conversation scripts, and so on. It’s built using the c1541 command, which is part of VICE:
del test.d64 c1541 -format ice,cj d64 test.d64 c1541 -attach test.d64 -write ice.prg ice c1541 -attach test.d64 -write play.prg play c1541 -attach test.d64 -write edit.prg edit c1541 -attach test.d64 -write wilderness_chars.bin wchars c1541 -attach test.d64 -write test.bin testcon
The other disk, data.d64, contains all the map data, and is a little more complicated. I’ve talked about the way I’m storing maps before, which is a little unorthodox. Instead of using regular files to store the map data, I’m allocating blocks individually. This is so that I can store a 256-byte map section in a single block of disk space. Blocks in the 1541 format are 256 bytes, but usually the first two bytes are a pointer to the next data block. This way, I was able to use all 256 bytes for my data.
This certainly seemed like a good idea at the time, although I wasted some time working around bugs in the 1541 ROMs. But now that I’m further along, I’ve got a small problem:
- I have some actual map data that I want to be sure to preserve.
- As the design of the project has matured, I want to change the data structures.
Now, I could do this entirely in code running inside the game engine on the C64, but it would be a pain. For example, I have some unused fields in the map info structure that I want to get rid of. I could change the map loader to shift bytes around in that structure, and then load and save every map. But that sounds like a pain. If I want to make a more invasive change, like reorganizing how the indexing to individual blocks of map data work… that doesn’t sound pleasant at all.
I decided that the most robust way to move forward was to create a separate map extractor / writer program. My goal is to combine this with the script compiler into a sort of general “Ice Age Adventure Resource Compiler”. Is this too complicated of a solution? Probably. But it sounded like fun.
Next I had to decide how to read the .d64 data. I’ve been using c1541, so I could have just stuck with that – it can read an arbitrary block and print it out in hex. But then I’d be launching a bunch of processes and reading a bunch of text output and that didn’t sound like fun.
A few years back I wrote some code (originally in Python, then in C++) to read .d64 and .g64 disk images, because I wanted to learn about the formats. I never finished the code for writing data, but that didn’t seem to be such a big deal – I could copy most of it from the code I wrote to make the map editor work.
So far, I’ve gotten as far as reading all the maps into memory so I can manipulate them, and outputting the map data to the console to verify that it looks basically correct. Now I just need to write the data back out to a new disk image and make sure it’s the same as the original.