SkoolKit 8.4 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.

Perhaps the most noteworthy change in this release is that the image writer component is now pluggable. So, for example, if you’re sick of the PNG files that SkoolKit currently creates and would rather produce ASCII art instead, or embed base64-encoded image data in your HTML documents, or perhaps even do something as perverse as revive the ability to write GIF files, then you now have that option. Go for it.

In the ref file department, there’s a completely new section on the scene - in fact, the first new section to be introduced since 4.0: [EntryGroups]. Here you can define groups of entries, surprisingly enough. To what end? Well, once a group has been defined, the entries belonging to it can be given custom titles and page headers in the HTML output - such as ‘Sprite buffer’ or ‘Character variables’ - instead of the boring stock ones (‘Data’, ‘Routines’ etc.).

Over in the snapshot analysis arena, snapinfo.py has acquired the Peek and Word configuration parameters for controlling the format of each line of the output of the --peek and --word options. So, for example, if you wanted to produce a series of POKE commands for a range of addresses, you can now do something like this:

$ snapinfo.py -p 30000-30010 -I 'Peek=POKE {address},{value}' game.z80

Shifting to the control file domain, instruction comments are now repeated when they appear in a loop (as defined by the L control directive). Full disclosure: this is not actually a new feature, but a bug fix. Instruction comments were repeated in control file loops back when loops were introduced in SkoolKit 4.2, but that stopped happening in 7.2, and I didn’t notice until quite recently. Oops.

With that damning admission out of the way, I will now point you to the changelog for details of all the other new stuff that I haven’t mentioned here (such as the ability to spread @expand directive values over multiple lines, and the ability to initialise the system variables in a snapshot when using tap2sna.py). Once you’re done there, please do grab a copy of 8.4 and perhaps start thinking about what obscure image format you’d like to add support for.

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?