On the 15th anniversary of the release of SkoolKit 1.0, SkoolKit 9.5 has been released. To get a copy, please head over to the download page, the Python Package Index, or GitHub.

When it comes to annotations, SkoolKit has always stayed out of the way and allowed the reverse engineer (that’s you) free rein to decide where to place comments in the skool file and how to word them. Which is how it should be, because only the reverse engineer (that’s you again) really understands what the code is doing and how to convey that information to a reader of the disassembly. However, if you’ve ever, when starting a new disassembly project, been filled with dread by the daunting sight of a completely bare skool file, then SkoolKit 9.5 is here to help (a little). New in this release is a comment generator component, which can be enabled by using the --comments (or -C) option of sna2ctl.py or sna2skool.py. For example:

$ sna2ctl.py -C game.z80 > game.ctl

Now take a look at game.ctl and revel in the ready-made comments that describe what each individual instruction is doing. What if you’ve already started on a control file, for which sna2ctl.py did not employ the comment generator? No problem. sna2skool.py can use it to generate comments for the instructions that don’t yet have any:

$ sna2skool.py -C -c game.ctl game.z80 > game.skool

Of course, the comment generator is not in any way smart, doesn’t understand how the game you’re disassembling actually works, and should never be used to produce a ‘complete’ disassembly automatically from scratch. But if you’re a bit hazy on how an arithmetic or logic operation works on the flags, or what one of the rarely used instructions (e.g. RLD or OTIR) actually does, then the comment generator can provide a useful jog to the memory. Which is better than nothing.

If, by chance and over time, you find the comment generator to be more useful than not, you can enable it by default for both sna2ctl.py and sna2skool.py by setting their Comments configuration parameters to 1 in skoolkit.ini.

Anyway, moving on to other new features, trace.py, when running with screen contents displayed, will now respond to keypresses. This means you could use it to enter programs into the simulated ZX Spectrum, or even play games, though I wouldn’t recommend it. With no border, or sound, or menus to control its operation, trace.py is a poor substitute for a proper emulator. But in a pinch it could be useful if the code you’re tracing depends on user input.

Another new feature for trace.py - which makes more sense now that it can respond to keypresses - is the --map option. Just like the --map option of rzxplay.py, it produces a code execution map. And, just like a code execution map produced by rzxplay.py, one produced by trace.py can be used with the --map option of sna2ctl.py when generating a control file.

Finally, with an eye to the looming SkoolKit 10.0 (no release date planned yet, so don’t panic), there are several macro-related deprecations in the works in this release. They all concern syntax oddities that have been around for a long time, and which I’m now determined to eradicate (eventually) by encouraging the use of parentheses where appropriate. Specifically, #CALL, #LINK and #FONT now support alternative syntaxes that do away with the ugly colons, and the new #FRAMES macro is an aptly named drop-in replacement (more or less) for the frame-splicing #UDGARRAY* macro that avoids the weird asterisk. In addition, the plain #UDGARRAY macro now strongly prefers its UDG specifications to be enclosed in parentheses, and its attribute address range specifications to be enclosed in square brackets.

For details of the other new features that may or may not be overshadowed by the comment generator, check out the changelog. After that, why not download a copy of 9.5 and use the comment generator to remind yourself what RRD and INIR do, and how ‘RET C’ works after a CP?