SkoolKit 4.1.1 has been released. Copies are available from the download page, as usual. Or, also as usual, you can install it (or upgrade your existing installation) from PyPI or the PPA.

4.1.1, as the semantic version number suggests, is a maintenance release, adding no new features to 4.1. Indeed, the main point behind 4.1.1 is to update all the links (in the documentation and the code) to SkoolKit’s new home, here, at skoolkit.ca. However, there are still a few things of interest to mention, in part because there was no announcement for 4.1 itself, which means there is some catch-up to do.

First of all, skool2asm.py and skool2html.py now have a --writer option for specifying the ASM or HTML writer class to use. This option makes it possible to use a SkoolKit extension module wherever it’s located - in the skoolkit package, or somewhere else as a standalone module - without modifying the skool file or ref file.

Next, skool2html.py now has a --search option for adding a directory to the resource search path. This means, for example, that if you have CSS files somewhere other than the current working directory, or the resources directory, or the directory where your skool/ref files are, you can make skool2html.py aware of them without moving them into the standard resource search path. Which could be useful.

Also new in 4.1 was the LinkInternalOperands parameter in the [Game] section of the ref file. This enables hyperlinks on a disassembly page to addresses on the same page (i.e. in the same routine), which is particularly useful in large routines, where a JP at the top of the page could point to an instruction way down at the bottom of the page. (In earlier versions, such hyperlinks were enabled only if you used ASM labels in the HTML output.)

Finally, in 4.1.1 itself, although there are no code changes, there is a change of example disassembly: Manic Miner has moved out and is now being developed separately, and in its place comes a bare-bones control file for Hungry Horace. Whether this new example disassembly will eventually migrate to its own home outside the SkoolKit distribution (like Contact Sam Cruise, Jet Set Willy and Manic Miner before it) remains to be seen.

For any remaining details, curious users may consult the changelog. Have fun with 4.1.1!

In something of a departure from the typical Microsphere-centricity of this site, I have released my fourth major Spectrum game-related reverse engineering effort: The complete Jet Set Willy RAM disassembly. This actually began life back in April 2012 as a bare-bones example disassembly bundled with SkoolKit, but a little while ago I decided to extract it, flesh it out, and release it separately. So here it is.

“But,” I can hear many of you exclaim, “why bother with Jet Set Willy? It’s already been disassembled, deconstructed, analysed and otherwise picked apart by a million other people!” That I cannot deny - and in fact I’ve made use of some of these pre-existing bodies of research - but the difference here is that this is a complete disassembly, of every byte, with annotations, all in one place. And in keeping with the tradition started by the Microsphere game disassemblies, there are bugs and trivia pages too.

So while most (if not all) of the content of this disassembly is probably already familiar to the Jet Set Willy fans among you, I’d encourage you to take a look anyway. You might learn something. You might spot some mistakes (in which case let me know). At the very least, you can rest assured that Jet Set Willy has been given the SkoolKit treatment for posterity.

One more thing: if you want a copy of the disassembly for offline viewing or archival purposes, you can get one here.

SkoolKit 4.0 has been released. In keeping with age-old tradition, copies of this major new version are available in various formats from the download page. And in keeping with more recent tradition, you can also obtain this major new version from PyPI or the PPA.

The numerically minded among you might have noticed that 4.0 is a whole major version number up from 3.7, the previous release. (For the benefit of the innumerate among you, I hinted at this with the phrase “major new version” - twice - in the first paragraph. You are welcome.) Why 4.0 instead of 3.8? Mainly because there have been some changes that make SkoolKit 4.0 incompatible with skool files, ref files, control files, skool file templates and CSS files that work with SkoolKit 3.7 and earlier versions. For example: the [Info] section of the ref file is no longer supported; the ‘z’ and ‘Z’ directives, which were deprecated in 3.7, are no longer supported; and the class attributes of many HTML elements have changed, which means your custom CSS files may need some modification to make them work with 4.0. See the documentation on migrating from SkoolKit 3 for a comprehensive list of the compatibility-breaking changes, and for information on the skoolkit3to4.py utility, which might ease some of the pain of switching to SkoolKit 4.

So much for the incompatibilities. What of the new features? The biggest one is the introduction of HTML templates, from which every page in an HTML disassembly is built. No longer is the format of the HTML produced by skool2html.py determined by code buried inside the skoolkit package; now you, the format-conscious user, are in control. Don’t care much for the layout of the disassembly index page? Then create your own [Template:GameIndex], [Template:index_section] and [Template:index_section_item] sections in the ref file. Need HTML5 for some pages instead of the default XHTML 1.0? Simply tweak the relevant [Template:*] sections, and away you go.

The next new feature on the list is support for keyword arguments in the image macros: #FONT, #SCR, #UDG and #UDGARRAY. These macros have several numeric parameters, most of them optional, which means that their parameter strings can be unreadably long. For example:

#UDG32768,,,,,,1

Any idea what parameter the value 1 corresponds to here? If not, take comfort in the fact that this macro can now be written more clearly thus:

#UDG32768,rotate=1

Also new in the realm of image creation is support for AND-OR masks. In previous versions, SkoolKit has assumed that sprite mask data is used as follows: take a background byte, OR on the sprite byte, and then AND on the mask byte. I refer to this masking scheme - which is used by Skool Daze, Back to Skool and Contact Sam Cruise - as OR-AND masking. However, it turns out that some games use mask data the other way round: take a background byte, AND on the mask byte, and then OR on the sprite byte. If you’ve had trouble producing masked images, it may be because AND-OR masking is required instead of OR-AND masking. If so, the new mask parameter of the #UDG and #UDGARRAY macros should fix the problem: use mask=2 to specify AND-OR masks.

That’s about it for the main new features; see the changelog for further details. Be brave and upgrade to SkoolKit 4.0 today, and be sure to report any bugs you find, or incompatibilities I haven’t documented!