SkoolKit 10.2 has been released. To get a copy, please head over to the download page, the Python Package Index, or GitHub.

Over the years, SkoolKit has built up a comprehensive automated test suite, growing from 54 tests for version 1.1 up to 4950 tests for this latest version. Their main purpose is, of course, to ensure that I don’t accidentally break things that used to work - or, to put it another way, to ensure that the “happy paths” continue to be happy. But what about the sad, dejected, or downright depressed paths - by which I mean error conditions? Perhaps SkoolKit has historically not been particularly strong on that point, so recently I have concentrated quite a bit on what happens when things go wrong. To cut a long story short, this version of SkoolKit is slightly less likely than all of its predecessors to produce a confusing Python stack trace when an error occurs, and is correspondingly slightly more likely to produce a somewhat helpful error message explaining what went wrong. Fingers crossed, anyway.

Another area where SkoolKit has historically been quite weak is web design. The default HTML templates and CSS rules are functional, but that’s about all that can be said for them. In particular, one aspect of web design that has been conspicuous by its absence from those templates and that CSS is responsiveness. True, SkoolKit itself is older than the concept of responsive web design - but not by much. Anyway, things have improved a little in this release. The next time you go looking for a SkoolKit disassembly on your phone, then so long as it’s using the stock templates and CSS from 10.2 (or some theme derived from them), the fonts should be legible without having to zoom, and the amount of horizontal scrolling required should have drastically reduced. Fingers crossed (again), anyway.

In keeping with the theme of “little things that should have been done ages ago”, the rest of the new features in this release fall mainly in the category of what might be called “housekeeping”. For example, rzxplay.py now reads configuration from skoolkit.ini (alongside all the other commands for which a central configuration file makes sense and were already enjoying that feature). So if you’re sick of the screen popping up every time you run the command, add Screen=0 to the [rzxplay] section of skoolkit.ini and you need never supply the --no-screen option again. But if you like the screen, never fear: there are also configuration parameters for setting its default scale (ScreenScale) and frame rate (ScreenFps). And for those more interested in tracing code execution, the format of the trace log can now be configured via the TraceHeader, TraceLine and TraceOperand parameters (as they already could be for trace.py).

Other such changes to be aware of include the addition of the --analyse option to tapinfo.py. This provides exactly the same information on a tape’s tones and pulses as the --tape-analysis option of tap2sna.py has done since version 8.10, but at least now it’s accomplished by the command you’d expect it to be accomplished by. Also, the --map option of trace.py now updates an existing file instead of replacing it - which makes it behave exactly as the --map option of rzxplay.py has always behaved, and much more useful for building a code execution map over multiple runs.

For a full list of all the new features and fixes since 10.1, I recommend consulting the changelog. And after that, go ahead an create an animated PNG of your favourite game character that contains more than 255 frames - just because you can now.