SkoolKit 3.7 has been released. As usual, copies of this release are available, in various formats, from the download page. If, however, the idea of downloading SkoolKit from this site repels or offends you, you can install it via PyPI or the PPA instead. The choice is yours.

The last release to get an announcement on this here website was version 3.5 over six months ago, so I should probably go over a few of the changes that have taken place since then. For the image-creating fans among you, the big news is that the #UDGARRAY macro is now capable of building animated images from an arbitrary sequence of frames (each of which is built using a special form of the macro). SkoolKit has had support for building animated images that contain flashing cells since 3.0.1, but the new, enhanced #UDGARRAY macro enables you to be a bit cleverer and produce animated sprite images such as the ones of Miner Willy in the incomplete Manic Miner disassembly.

On the subject of disassemblies, a new one has joined the examples distributed with SkoolKit: the incomplete Spectrum ROM disassembly. It was made possible in part by the (new) support for disassemblies with a start address below 10000, and sits proudly alongside the incomplete Jet Set Willy disassembly and the aforementioned Manic Miner disassembly. In addition, built versions of these example disassemblies are now published online (as you may have gathered).

In the number bases department, SkoolKit now supports binary numbers in DEFB, DEFM, DEFS and DEFW statements. That is, they can be parsed in skool files for the purpose of building a snapshot (as demonstrated by the character set in the incomplete Spectrum ROM disassembly), and can be preserved in and restored from control files and skool file templates. The base of decimal and hexadecimal values can be preserved too by using the new --preserve-base option of skool2ctl.py and skool2sft.py.

Finally, on the control directive front, the ‘z’ and ‘Z’ (zero) directives have been deprecated in favour of the new ‘s’ and ‘S’ (space) directives, which can encode DEFS statements with non-zero byte values (e.g. ‘DEFS 8,255’) - something that was not possible with the old ‘Z’ directive. Now that the ‘s’ and ‘S’ directives are here, I really do wonder how we ever did without them.

As ever, more details on the changes since 3.5 can be found in the changelog. Here’s hoping they keep you going until 3.8 arrives!

Update: The Jet Set Willy disassembly is now here, the Manic Miner disassembly is now here, and the Spectrum ROM disassembly is now here.

SkoolKit 3.5 has been released. Not only that, but copies are available, as you’ve probably come to expect, from the aptly monickered download page. Feel free to pop over there and pick up a tarball, zip archive, RPM package or DEB package. I aim to please with a variety of download formats. Alternatively, you could use easy_install or pip to install SkoolKit from PyPI. So, got your copy? OK then, now sit back while I lay out the main changes since the last version I bothered to write an article about (3.3.2 in May).

First, the bad news. This is something you should pay special attention to if you’ve created (and are using) your own custom CSS file(s) with SkoolKit: the StyleSheet and Font parameters have moved from the [Paths] section of the ref file to the [Game] section. In addition, the Logo parameter has also moved from the [Paths] section to the [Game] section, so take care to update your ref file accordingly if you’re using a custom game logo. And, to add insult to injury, the JavaScript parameter has moved from the [Paths] section to the [Page:*] section. Why all these apparently senseless and inconvenient moves of oft-used parameters from one place to another? Well, truth be told, they should never have lived in the [Paths] section in the first place; that section is supposed to contain parameters specifying where files that don’t yet exist should be written, and the aforementioned parameters do not fit that description. Case closed.

Now, the good (or, at least, not annoying) news. On the subject of CSS files and themes, SkoolKit 3.5 brings support for multiple themes, and includes three new sample themes (in addition to the traditional dark and spectrum): green, plum and wide. As the names suggest, green makes your HTML disassembly mostly green, plum makes it mostly dark purple, and wide makes the tables on disassembly pages and the boxes on the Changelog, Glossary, Trivia, Bugs and Pokes pages stretch to full width. So if you want your disassembly to look green and wide, you can do this:

$ skool2html.py -T green -T wide game.ref

Also note that if you want to use your own custom theme, then for ease of maintenance and portability between SkoolKit versions, it’s a good idea to create a CSS file that contains only the differences required from the stock skoolkit.css, and to use both skoolkit.css and your custom CSS file (in that order) when building a disassembly. All the alternative CSS themes that come with SkoolKit have been written (or rewritten and much reduced!) to work in conjuction with skoolkit.css.

Next up, SkoolKit has a new command in its library: tap2sna.py. This command can convert a TAP or TZX file (remote or local, in a zip archive or not) into a Z80 snapshot. Big deal, I hear you snort. But hang on! The idea is that if you’re still in the control file phase of your disassembly, or you’d rather use a skool file template instead of a skool file, you can provide instructions to other users on how to create the ‘perfect’ snapshot that can be used to build the disassembly (from your control file or skool file template) with every byte having the value it’s supposed to have. See the documentation for all the gory details on how to start creating perfect snapshots today.

And that’s probably it for the most newsworthy changes. If it were a slower news day I could mention that skool2html.py now supports ASM labels in HTML output and can hyperlink the operands of LD instructions, that the #NAME macro is dead (and presumably unmourned), and that you might find the new --erefs option of sna2skool.py somewhat useful; but all that would take up too much space in an already bulging article. The curious SkoolKit user can always check the changelog for details.

Have fun with 3.5!

SkoolKit 3.3.2 is now available. Should you want a copy - whether in raw form as a tarball or zip archive, or in pre-packaged form as an RPM or DEB file - just head over to the always-welcoming download page and click the appropriate link.

Or, alternatively, you could head over to GitHub and clone the SkoolKit repo. Yes, the SkoolKit git repo is now hosted on GitHub, which means that staying on the cutting edge of SkoolKit development is just a git pull away. Incidentally, it’s also the place to report bugs and suggest enhancements.

So, besides being the first version of SkoolKit to have been developed ‘in the open’, what’s new in 3.3.2? Well, to begin with, setup.py now installs the resources directory, which means that a local copy of that directory is no longer required when SkoolKit has been installed via setup.py install. Whether this counts as a bugfix or an enhancement is probably up for debate.

Also new (since 3.3.1, actually) is the ability to use a standalone extension module that is not part of an installed package. For example, if you’ve implemented an HtmlWriter subclass named GameHtmlWriter in an extension module named game.py that you’d like to keep in ~/.skoolkit, you can make skool2html.py use it by setting the HtmlWriterClass parameter in the [Config] section of your ref file thus:

HtmlWriterClass=~/.skoolkit:game.GameHtmlWriter

If, on the other hand, you are a traditionalist who prefers to keep your extension module inside the skoolkit package itself, then you may find the new -p option of skool2html.py useful: it prints the path to the skoolkit package directory. This takes the guesswork out of installing game.py; now it’s as easy as (something like):

$ sudo cp game.py $(skool2html.py -p)

As if all that weren’t enough, skool2html.py also has a new -T option that makes switching between CSS themes as easy as pie, and there are a bunch of bugfixes; anyone curious about the finer details can always check the changelog.

And that’s all the news. Git pulling!