SkoolKit

Spectrum game disassembly toolkit

Take Five

@assemble=1

SkoolKit 5.0 has been released. As dedicated followers of this website have no doubt already guessed, copies of 5.0 are available from the ever-present download page, the Python Package Index, and the Ubuntu PPA.

As even the not-so-dedicated followers among you might have noticed, 5.0 both looks and smells like a major new version, and there is little point in pretending that it isn’t. Not to put too fine a point on it, there are some changes that make SkoolKit 5.0 incompatible with some skool files and control files that work with SkoolKit 4.5 and earlier versions, which is why this new version isn’t simply 4.6. For example: the ‘D’ directive can no longer be used to define a mid-block comment - you must use the ‘N’ directive instead. Also: an ASM directive can no longer be declared by starting a line with ‘; @’ - you must use the ‘@’ directive in a control file, and omit the semicolon and space in a skool file. See the documentation on migrating from SkoolKit 4 for a comprehensive list of the compatibility-breaking changes, and for information on the skoolkit4to5.py utility, which might ease some of the pain of switching to SkoolKit 5.

But a major new version should be about more than just a bunch of backwards incompatibilities, and I’m glad to say that 5.0 is no exception to this rule. First of all, there are two new commands: skool2bin.py and tapinfo.py. As the name implies, skool2bin.py converts a skool file into a binary (raw memory) file, bypassing the need to create an ASM file with skool2asm.py first and then assemble it. Let’s be clear up front, though: skool2bin.py is not an assembler. At least, it’s not a fully fledged assembler, in that it knows nothing about labels or any kind of assembler directive besides DEFB, DEFM, DEFS and DEFW. As for tapinfo.py, this new utility displays information about the blocks in a TAP or TZX file. It will be most useful for determining the block numbers to use when creating a snapshot from a tape file with tap2sna.py.

Second of all, SkoolKit 5.0 says goodbye to XHTML 1.0 and hello to HTML5. Yes, the output of skool2html.py has left the 20th century behind and belatedly come crashing into the 21st. To be specific, the stock full-page HTML templates have been converted from XHTML 1.0 Strict to HTML5. And to drive the point home, they also sport <footer> elements, instead of the generic <div> elements of the bygone era.

Third of all, there is the new @assemble directive, which controls whether assembly language instructions are converted into byte values for the purpose of populating the memory snapshot. In previous versions of SkoolKit, only DEFB, DEFM, DEFS and DEFW statements were converted into byte values, but now we have the ability to convert regular instructions as well. Does your skool file contain any data definition entries (‘d’ blocks) whose only purpose is to provide the byte values for a block of code? Time to consider using the @assemble directive instead, and save some space into the bargain.

That’s about it for the main new features; see the changelog for further details. I hope you can all pluck up the courage to upgrade to SkoolKit 5.0 - if not today, then some time soon. And be sure to report any bugs you find, or backwards incompatibilities I have not (yet) documented!

Unlock the speed

BUG OFF YOU BIG WALLY

SkoolKit 4.5 has been released. Fresh copies are available for collection, as usual, from the download page, the Python Package Index, and the Ubuntu PPA.

But enough inane banter. What of the new features? Well, tap2sna.py has seen its first update since it was introduced in SkoolKit 3.5. Back then it could only read TZX block types 0x10 (standard speed data) and 0x11 (turbo speed data), but this set has been expanded by one (that’s 50%) to include block type 0x14 (pure data). In addition, tap2sna.py can now load the first and last bytes of a tape block (which are usually, but not always, the flag and parity bytes), and also modify memory with XOR and ADD operations. In case you’re struggling to see the point of all this, one word: Speedlock. Speedlock TZX files typically have the bulk of their data encoded in pure data blocks that have no flag or parity bytes and are scrambled by XOR and ADD operations. If the point is still not clear, come back to it later and try again with fresh eyes.

Elsewhere in the arena of SkoolKit commands, bin2tap.py has picked up a couple of new abilities. First, the --clear option, which creates a BASIC loader that has a CLEAR command, and otherwise leaves the stack pointer alone. This option enables you create a TAP file for a program that will run and then return to BASIC without crashing. Second, bin2tap.py can now convert not only a raw memory file, but also a SNA, SZX or Z80 snapshot into a TAP file. Just use the --org option to specify the origin address, and the new --end option to specify the end address of the section of memory to dump onto the tape.

Speaking of origins and ends, skool2asm.py, skool2ctl.py and skool2sft.py now sport --start and --end options for specifying how much of the input skool file to convert to ASM, CTL or SFT format. And the --start and --end options of sna2skool.py now also take effect when used in conjunction with the --ctl or --sft option to read a control file or skool file template. In short, we all now have the power to tell SkoolKit where to start and where to stop, and it will obey.

Which brings us to the end of this brief review of 4.5. As always, a more detailed list of changes can be found in the changelog. After that, if you’re convinced that 4.5 is worth the upgrade, go get a copy and descramble yourself some Speedlock tapes.

Of bases and characters

Bases

SkoolKit 4.4 has been released. You may obtain a copy, as usual, from the download page, the Python Package Index, or the Ubuntu PPA.

First, a little SkoolKit history, to provide some context for the main new feature in this release. Back in SkoolKit 3.7, support for binary numbers was added, along with the ability to specify (in a control file or skool file template) the base of numeric values in DEFB, DEFM, DEFS and DEFW statements: binary, decimal or hexadecimal. Which was all well and good, but it left regular assembly language instructions out in the cold. You could disassemble 3E24 as DEFB $3E,%00100100 all day long if you wished, but if you wanted LD A,%00100100 instead, you were out of luck. Cue sad trombone.

Suffice it to say that this sorry situation has been rectified in SkoolKit 4.4. If you want 3E24 to disassemble as LD A,%00100100, you can now do so to your heart’s content. What’s more, if you want 3E24 to disassemble as LD A,"$" instead, you may also do that until the cows come home. (Of course, the options to disassemble 3E24 as LD A,36 or LD A,$24 are also still available.) All that’s required is the careful use of ‘b’ (binary), ‘c’ (character), ‘d’ (decimal) or ‘h’ (hexadecimal) prefixes in the control file or skool file template. Cue fanfare.

In other news - and in the “this really should have been in SkoolKit 1.0” department - 4.4 brings support for @ssub block directives. The only excuse I can offer for not implementing them sooner is that I never found a pressing need for them in any of the disassemblies I’ve worked on. But there have been @bfix, @ofix, @rfix, @isub and @rsub block directives since day one, so it only makes sense to add @ssub block directives and round out the family. I hope someone finds them useful, even if I have yet to.

Also possibly in the “this really should have been in SkoolKit 1.0 (or thereabouts)” department, sna2skool.py now has an -e/--end option to complement the -s/--start option it’s had since SkoolKit 1.0.4. Many’s the time I’ve wanted to disassemble just a bit of a snapshot (without a control file) instead of everything up to the end of RAM, and now I can do that by using --start and --end together. I encourage you to try it, too.

And that’s about it. For details of other changes less interesting than these, you can consult the changelog. Then get your copy of SkoolKit 4.4 and start disassembling FE21 as CP "!" like there’s no tomorrow.