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.

SkoolKit 8.1 has been released. Whenever you’re ready, please head over to the download page, the Python Package Index, the Ubuntu PPA, or the Fedora copr repo to pick up a copy.

After the fanfare of 8.0, SkoolKit 8.1 is a relatively quiet release with some modest enhancements across the board. First on that list of enhancements is the ability of skool2bin.py to parse a skool file in @rsub or @rfix mode (via the aptly named --rsub and --rfix options). So now skool2bin.py can parse a skool file in any of the possible modes, which means you may no longer have to reach for an assembler in order to build a bugfixed TAP file of your favourite game. Well, that’s the plan, anyway.

Second on the arbitrarily ordered list of enhancements is skool2bin.py again, this time with its new --data option, which makes it process @defb, @defs and @defw directives. This enables manipulation of the memory snapshot derived from a skool file beyond the ability of any assembler operating on the output of skool2asm.py. Perhaps now the only reason to reach for an assembler is to place it in a drawer, out of the way of the actually useful tools cluttering your desktop.

Still on the subject of @defb, @defs and @defw, these directives no longer require an address parameter. If that parameter is omitted, it defaults either to the address of the next instruction, or to the address immediately after the last byte of the previous @defb, @defs or @defw directive attached to the same instruction. After you’ve let that idea sink in, I hope you’ll agree that it makes sense.

Last on the list of enhancements I will be giving air time to today is the humble register name field (in the register section of a skool file entry header) and its ability to contain whitespace and skool macros (which will be expanded). In earlier versions this field was limited to a single, space-free sequence of characters in which macro-like tokens were ignored. But now, by the use of a special syntax, you can go crazy and place such strings as B, C or #R49152 there.

To see what other changes are lurking in this release, I suggest giving the changelog a quick scan. After that, why not grab a copy of 8.1 and see if that trusty assembler of yours really can be put to bed?

No, I haven’t become impatient (or lost the ability to count) and skipped straight from version 8.0 to version 10.0. Today is SkoolKit’s 10th birthday! Or, to put it another way, SkoolKit 1.0 was released ten years ago today.

Not surprisingly, SkoolKit has improved a bit since version 1.0 (if I do say so myself). Back then, the documentation was a single HTML page, and contained very little info on how to use ref files. A control file was a plain list of block-level directives and addresses only - block titles, comments, register values etc. were not supported. skool2html.py was designed primarily to build the disassemblies of Skool Daze and Back to Skool, with the ability to process an arbitrary skool file tacked on as an afterthought. sna2skool.py was quite buggy - it disassembled several instructions incorrectly. Of the 40 available skool macros, no fewer than 14 were specific to (i.e. useful only in) the Skool games. And if you wanted to work in hexadecimal, you were out of luck.

Since we’re in a nostalgic mood (well I am, anyway), let’s sit back and enjoy some snippets of SkoolKit history that you may not have been aware of.

• The initially buggy sna2skool.py was something of a rush job, added to the SkoolKit source code repository on 2010-01-25, three days before 1.0 was released. Before it was developed, I used a modified version of D52’s Z80 disassembler to create skool files. D52 was also the source of inspiration for SkoolKit’s control files.

• skool2html.py first appeared in the repository on 2008-07-26, as a consolidation of several scripts previously used to build specific parts of the HTML versions of the Skool Daze and Back to Skool disassemblies. It gained the ability to work with a skool file other than sd.skool or bts.skool on 2010-01-26, two days before 1.0 was released.

• skool2asm.py first appeared in the repository on 2009-07-03, almost a year after skool2html.py. I developed it mainly because someone showed interest in modifying the source code for Skool Daze, and (understandably) found it awkward to work with the skool file as opposed to a conventional assembler source file.

• Of the skool macros that are still around today, the first one to be implemented was #R. It was used for the first time on 2008-07-16 in the Skool Daze disassembly. Before that, the first macro to be implemented was $TAPS (which later became #TAPS), on 2008-07-08.

• The name ‘SkoolKit’ first appeared in the documentation on 2010-01-20, eight days before 1.0 was released.

So, let’s raise a glass to SkoolKit’s 10th birthday, and wish it well for the next 10 years of Spectrum game disassembly!