Over the past few months I’ve been working not on SkoolKit, but on a brand new disassembly: Skool Daze! Not the Spectrum version of the game, of course (because there would be nothing new about that), but the Commodore 64 version of the game, which was released some time in 1985, after the original Spectrum version.

The main reasons for going through this exercise were twofold. First, I wanted to give sk6502 (the SkoolKit components for 6502 disassembly) a workout by reverse engineering a game from scratch, and see where improvements for supporting 6502-based machines could be made. Secondly, I was curious how well and how faithfully one of my favourite games of all time had been ported from my favourite 8-bit platform of all time to a platform I’d never used before.

On that second point, I can report that the investigation was rather interesting. For one thing, I had to read up on how sound and sprites work on the Commodore 64 in order to understand how the game uses them. (This explains why the annotations for the sound-producing and sprite-animating code in the game are somewhat dry, for which I apologise.) For another thing, in many instances there is a one-to-one relationship between routines and data blocks in the Commodore 64 version and corresponding routines and data blocks in the Spectrum version, which I have pointed out where I noticed them.

The Commodore 64 version also has its own unique bugs and trivia, some of which suggest that the port was made from an earlier cut of the game code than was used for the Spectrum version (because they could easily have been in the Spectrum version too, but apparently were fixed before release).

Anyway, do take a look and see for yourself, and if you spot any errors in the disassembly (or my very recently acquired and very incomplete understanding of the Commodore 64), please let me know. And with that, time to get working on some changes to sk6502 and SkoolKit that were inspired by this experiment.

SkoolKit 8.3 has been released. To get a copy, please head over to the download page, the Python Package Index, the Ubuntu PPA, or the Fedora copr repo.

For the first time since SkoolKit 2.0.5, this release brings with it a new image macro: #PLOT. Unlike the other image macros, though, #PLOT is less (in fact, not at all) about building an image from graphic data, and more (in fact, totally) about modifying an existing frame that’s already been built. With it you can set, reset or flip a single bit in a frame, which enables you to fix it up however you like before writing the image file. This provides an alternative to modifying the graphic data itself (using #POKES) before creating the frame in the first place. And I suppose for dedicated artists who prefer drawing from scratch, it offers the opportunity to paint pixels wherever they like on a completely blank frame.

Still in the image macro department, #UDGARRAY* now has the ability to specify, for each frame in an animated image, the coordinates at which to draw that frame (relative to the top-left corner of the first frame). This is particularly useful in images where only a small region is actually animated, and the second or later frames can therefore be smaller than the first.

Elsewhere in the macro department, every macro that takes integers anywhere in its parameter string now accepts replacement fields where those integers are expected. In 8.2, only the SMPL macros accepted replacement fields, but now that all the other macros do too, there’s no longer any need to use #EVAL (if that’s what you were doing) to get around that deficiency.

So much for macros, image or otherwise. 8.3 does of course boast other new features, such as the ability of tapinfo.py to show the entire contents of header and data blocks in a TAP or TZX file (instead of just the first few and last few bytes in each block, as teasingly done in earlier versions). For details on that and the other changes in this release, head over to the changelog. And after that, why not whip out your artist’s beret and paintbrush and give #PLOT a whirl?

SkoolKit 8.2 has been released. Please pop along to the download page, the Python Package Index, the Ubuntu PPA, or the Fedora copr repo to pick up a copy (no mask required).

First up in the list of new features worth talking about is the ability of snapinfo.py to produce call graphs. Supplied with a snapshot and a control file, it will spit out a DOT file that can be converted into an image by Graphviz (for example). So if you’ve ever longed for a pictorial representation of which routine calls what in your favourite game, 8.2 might be just what you were looking for.

Still on the subject of snapinfo.py, that command has also picked up the ability to read raw memory files, and to read configuration from skoolkit.ini. And still on the subject of call graphs, the new @refs directive (not to be confused with the old !refs skool directive in SkoolKit 1.x) may come in handy for declaring relationships between routines that snapinfo.py cannot deduce on its own, i.e. where one indirectly jumps to another.

Elsewhere, the family of SMPL macros has grown by three: #LET defines an integer or string variable that can be accessed via a replacement field; #FORMAT performs a Python-style string formatting operation on a format string containing replacement fields; and #DEFINE defines a new skool macro.

“But we already have @replace for creating new macros!” I hear some of you cry. That is indeed true, and you may carry on using @replace for that purpose, if you wish. But I would urge you to consider using #DEFINE as well, for two reasons in particular. First, with #DEFINE you can define a new macro named #ONE, say, and then define another new macro (#TWO, say) in terms of #ONE. (Try doing that with @replace; it’s tricky, if not impossible.) Second, macros defined by #DEFINE accept replacement fields in their integer arguments, which means you can easily use variables defined by #LET in their parameter strings. If that’s not enough to at least make you want to learn more about the power of #DEFINE, then I don’t know what is.

Finally, the image macros (#FONT, #SCR, #UDG and #UDGARRAY, in case you’d forgotten) now have tindex and alpha parameters for specifying an alternative transparent colour and opaqueness factor on a per-image basis (overriding the defaults). Meaning that even unmasked images can now be given a transparent background.

Of course there are other changes in this release, but we’re out of time here, so you should head over to the changelog if you’re interested. When you’re done, I strongly recommend taking #DEFINE for a spin, and seeing whether it really can put @replace to shame.