SkoolKit

Blurring the border lines

2026-08-14

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

Back in SkoolKit 9.2, the upstart new command was rzxplay.py with its ability to play RZX files (hence the name). It also had the ability to display a (borderless) screen, so you could sit back and watch the action as the command mapped out the executable code in whatever game you were reverse-engineering. Soon after that release, trace.py kept bugging me for its own screen-drawing capability, which I added (still borderlessly) in 9.4. Then, in 10.0, I added a border area to the screen displayed by rzxplay.py and trace.py. It could only display one colour at any given time, but despite that limitation, it caught the attention of tap2sna.py. That command then started bugging me for its own screen-drawing capability, but with support for multiple colours in the border area - think ‘loading stripes’ - or else. All of which is a roundabout way of bringing us to the current release, with tapsna.py boasting a new --screen option, and all three commands in this story now enjoying a border that can display multiple colours simultaneously all day, every day, and twice on Sundays.

However, though it might be fun to watch the previously headless tap2sna.py show off the speed of its phantom typist, or slowly draw a loading screen (or a little more quickly draw a loading screen, if the ScreenFps configuration parameter is set to 0), I can tell you from experience that the appeal soon wears off. I imagine the --screen option will come in most useful for troubleshooting tricky tapes that refuse to load - no longer will such troubleshooting have to be done ‘blind’, as it were. That said, the visual reassurance that tap2sna.py really is simulating a real tape loading on a real Spectrum (and not just cheating while you’re not looking) is somewhat comforting.

In other screen-related news, rzxplay.py now has a --cmio option, which simulates memory and I/O contention and the MEMPTR register. How is that screen-related, you ask? Well, some games employ border effects whose timing relies on memory and I/O contention: Aquaplane is a good example. So now you can use rzxplay.py to watch the RZX of that game as nature intended. The --cmio option will also come in handy for playing an RZX file whose execution path depends on accurate emulation of the MEMPTR register. I’m not aware of any such RZX files at the moment, however - at least, none that correctly play to completion in a modern emulator.

So much for the visual improvements in SkoolKit 10.1. What about the audio improvements? Well, after AY audio support was added in 10.0, it only makes sense that trace.py and the #AUDIO macro should gain the ability to tweak that AY simulation experience via the --volume option and vol parameter for setting the volume; the --ay-mode option and aymode parameter for setting the AY stereo mode (to ABC, ACB or MONO); and the --ay-res option and ayres parameter for setting the AY sampling resolution (in T-states). The default AY sampling resolution of 622 T-states - equivalent to 5700Hz on a 128K Spectrum - should be good enough for capturing most AY speech and other sound effects, but if you ever find it lacking, now there’s a way to adjust it.

Finally, speaking of the screen and AY audio - as I have been - I should also mention that the ‘Screen’ (to give it its official name) and the AY audio writer are now pluggable components. So if you don’t like the way SkoolKit draws pixels or rips AY audio, you can bloody well write your own components and plug them in via the component API. More power to you.

Finally finally, for even more details on what’s new in 10.1, visit the changelog. After that, get a copy of 10.1 and use the --screen option of tap2sna.py (along with the acceleration-disabling, real-time-matching -c fast-load=0, -c accelerator=none and -c cmio=1 options) to watch Skool Daze take over four minutes to load, just like the good old days.

Offering a few MEMPTRs

2026-08-14

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

Before we get into the meat of what’s new in 10.0, a word of warning. As is often the case with an N.0 release, there are some compatibility-breaking changes, which you can read about in the migration guide. In particular, the #UDGARRAY* macro is no more, the syntax of the #AUDIO macro has had a complete overhaul, and the #CALL, #FONT, #LINK and #UDGARRAY macros no longer support the syntax that was deprecated in 9.x. But never fear - in keeping with tradition, there is a migration script (skoolkit9to10.py) to help you get your skool files, control files and ref files ready for 10.0.

When support for simulating code execution on a 128K Spectrum was added back in SkoolKit 9.1, you might have been forgiven for thinking that it would also gain the ability to convert AY audio into a WAV file. However, you would have thought wrong. A couple of years later, though - which, as the saying goes, is better than never - SkoolKit 10.0 steps in to provide that missing functionality. So, for example, you could capture the AY speech at the beginning of Robocop with:

$ tap2sna.py -c machine=128 "Robocop - Side A.tzx" robocop.z80
$ trace.py --ay --stop 39978 robocop.z80 robocop.wav

Of course, the #AUDIO macro can now capture AY audio as well by setting its brand new ay parameter to 1. And for those cases where you want to capture both AY and beeper audio at the same time, you can use the --ay and --beeper options of trace.py, or set the ay and bpr parameters of the #AUDIO macro to 1.

In other simulator-related news, fans of MEMPTR (or WZ, as the case may be) can rejoice in the fact that 10.0 brings full support for this often overlooked internal register pair. It is simulated whenever memory and I/O contention are enabled, i.e. when the --cmio option of trace.py is specified, and when the cmio parameter of the #AUDIO, #SIM or #TSTATES macro is set to 1. In addition, snapinfo.py now shows the value of MEMPTR in SZX snapshots, and bin2sna.py, snapmod.py, tap2sna.py and trace.py can all set the value of MEMPTR. tap2sna.py and trace.py can also log the value of MEMPTR via the r[memptr] replacement field. So what does all of this mean in practice? Well, you could, for example, now use trace.py to play MEMPTR Snake properly. The possibilities are truly endless.

Speaking of using trace.py to play games, that experience - still not recommended, by the way - should be slightly less awful in 10.0 thanks to the border area now being included in the display. It won’t show multi-colour border effects (at least not yet), but the effect of entering ‘BORDER 0’, for example, being distinguishable from nothing counts as progress in my book. Obviously rzxplay.py benefits from this new feature as well.

Remember the comment generator introduced in SkoolKit 9.5? No need to apologise if you don’t. Anyway, it has been updated to handle some keyboard-reading instructions a little more intelligently. Specifically, the comment for ‘IN r,(C)’ immediately after ‘LD BC,$XXFE’, along with the comment for ‘IN A,($FE)’ immediately after ‘LD A,$XX’, now indicates the half-row of the keyboard being read when eaxctly one bit of XX is reset. Which should make it easier to spot that all-important keyboard-reading code in a freshly made skool file.

And that’s about it for the main new features in this release. For details of the non-main new features, visit the changelog. After that, get a copy of 10.0 and test your mental MEMPTR-tracing skills against trace.py running on your favourite game.

Two sides of the same tape

2026-08-14

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

Although tap2sna.py has recently transformed into something that’s actually easy to use (thanks to the introduction of a Z80 instruction set simulator in SkoolKit 8.7), it still lacks a couple of abilities that would make it even more useful: loading from two tape files (as when side 1 and side 2 are in separate files), and simulating keypresses while a tape is loading. Until now, that is.

If you do happen to be trying to load one of those annoying games that require both sides of a tape that are in two different files, you can now do the natural thing and supply each filename as an argument:

$ tap2sna.py side1.pzx side2.pzx

And if you happen to be trying to load one of those even more annoying games that require you to stop the tape for no good reason at some point in the middle of a load, and then press a key and start the tape again to continue loading, the new --press option is there to help. For example:

$ tap2sna.py --press 5:ENTER more-annoying-game.tap

This will stop the tape when block 5 is reached, simulate pressing the ENTER key until the row containing that key has been read, and then resume playing the tape. If more than one keypress is required before the tape can resume playing, don’t worry: --press can simulate as many as are needed.

And as a bonus, if you happen to be trying to load one of those annoyingest games of all that require you to stop the tape at some point and do some fast-forwarding before continuing the load - yes, such games, though rare, do exist - then the new --tape-skip option comes to the rescue. It can fast forward over one or more blocks like this:

$ tap2sna.py --tape-skip 4-5 annoyingest-game.tzx

In other tape-related news, 12 new tape-sampling loop accelerators have been added, and tap2sna.py can now accelerate both types of ‘DEC A’ delay loop (the more common one that ends with ‘JR NZ’, and the less common one that ends with ‘JP NZ’) at the same time, instead of just one or the other exclusively.

But if all of that fails to capture your interest, perhaps SkoolKit 9.6’s new component - the RST handler - can fail to capture it even more. As its name suggests, it handles RST instructions, which means it can alert its consumer - sna2ctl.py or sna2skool.py - that a byte or word argument follows. To activate the RST handler, use the new --handle-rst option:

$ sna2ctl.py --handle-rst --org 0 some-rom.bin

By default, the stock RST handler recognises the byte argument of ‘RST $08’ instructions, and nothing else - which is useful (if at all) only for the 48K ROM. But it can be configured to recognise the byte or word argument of any RST instruction by setting the RSTHandlerConfig configuration parameter in the [skoolkit] section of skoolkit.ini, in case you’re interested in disassembling some other ROM.

When used with sna2ctl.py, the RST handler inserts B (byte) and W (word) sub-block directives as appropriate immediately after the RST instructions of interest. But if you want to bypass the control file stage and go straight to disassembling a ROM image, you can activate the RST handler thus:

$ sna2skool.py --handle-rst --org 0 some-rom.bin

When used with sna2skool.py, the RST handler inserts DEFB and DEFW statements as appropriate immediately after the RST instructions of interest. Note that the RST handler only needs to be invoked once on any ROM image or snapshot; if you use it with sna2ctl.py to generate a control file, and then again with sna2skool.py on that same control file, confusion will result - both for sna2skool.py and for you. You have been warned.

For details of the other new features that have nothing to do with loading tapes or recognising the arguments of RST instructions, visit the changelog. Once you’re done there, grab a copy of 9.6 and see how much quicker tap2sna.py is now at loading Basil or Lone Wolf.

No instruction left uncommented

2026-08-14

On the 15th anniversary of the release of SkoolKit 1.0, SkoolKit 9.5 has been released. To get a copy, please head over to the download page, the Python Package Index, or GitHub.

When it comes to annotations, SkoolKit has always stayed out of the way and allowed the reverse engineer (that’s you) free rein to decide where to place comments in the skool file and how to word them. Which is how it should be, because only the reverse engineer (that’s you again) really understands what the code is doing and how to convey that information to a reader of the disassembly. However, if you’ve ever, when starting a new disassembly project, been filled with dread by the daunting sight of a completely bare skool file, then SkoolKit 9.5 is here to help (a little). New in this release is a comment generator component, which can be enabled by using the --comments (or -C) option of sna2ctl.py or sna2skool.py. For example:

$ sna2ctl.py -C game.z80 > game.ctl

Now take a look at game.ctl and revel in the ready-made comments that describe what each individual instruction is doing. What if you’ve already started on a control file, for which sna2ctl.py did not employ the comment generator? No problem. sna2skool.py can use it to generate comments for the instructions that don’t yet have any:

$ sna2skool.py -C -c game.ctl game.z80 > game.skool

Of course, the comment generator is not in any way smart, doesn’t understand how the game you’re disassembling actually works, and should never be used to produce a ‘complete’ disassembly automatically from scratch. But if you’re a bit hazy on how an arithmetic or logic operation works on the flags, or what one of the rarely used instructions (e.g. RLD or OTIR) actually does, then the comment generator can provide a useful jog to the memory. Which is better than nothing.

If, by chance and over time, you find the comment generator to be more useful than not, you can enable it by default for both sna2ctl.py and sna2skool.py by setting their Comments configuration parameters to 1 in skoolkit.ini.

Anyway, moving on to other new features, trace.py, when running with screen contents displayed, will now respond to keypresses. This means you could use it to enter programs into the simulated ZX Spectrum, or even play games, though I wouldn’t recommend it. With no border, or sound, or menus to control its operation, trace.py is a poor substitute for a proper emulator. But in a pinch it could be useful if the code you’re tracing depends on user input.

Another new feature for trace.py - which makes more sense now that it can respond to keypresses - is the --map option. Just like the --map option of rzxplay.py, it produces a code execution map. And, just like a code execution map produced by rzxplay.py, one produced by trace.py can be used with the --map option of sna2ctl.py when generating a control file.

Finally, with an eye to the looming SkoolKit 10.0 (no release date planned yet, so don’t panic), there are several macro-related deprecations in the works in this release. They all concern syntax oddities that have been around for a long time, and which I’m now determined to eradicate (eventually) by encouraging the use of parentheses where appropriate. Specifically, #CALL, #LINK and #FONT now support alternative syntaxes that do away with the ugly colons, and the new #FRAMES macro is an aptly named drop-in replacement (more or less) for the frame-splicing #UDGARRAY* macro that avoids the weird asterisk. In addition, the plain #UDGARRAY macro now strongly prefers its UDG specifications to be enclosed in parentheses, and its attribute address range specifications to be enclosed in square brackets.

For details of the other new features that may or may not be overshadowed by the comment generator, check out the changelog. After that, why not download a copy of 9.5 and use the comment generator to remind yourself what RRD and INIR do, and how ‘RET C’ works after a CP?

Tracing with a screen near you

2026-08-14

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

With the 9.x series well under way, and full 128K support (9.0 and 9.1), RZX support (9.2) and PZX support (9.3) now firmly entrenched, 9.4 quite reasonably steps down a gear and modestly introduces some minor enhancements to the Skoolkit commands and skool macros that we have come to know and love.

First, the --screen option of trace.py. As its name suggests, it displays the contents of the Spectrum’s screen while code is executing (so long as you have pygame installed). This can help if you want to produce a snapshot at a particular point that’s easier to judge by eye than by, say, the number of instructions executed (--max-operations) or the number of T-states elapsed (--max-tstates).

By default, the screen is refreshed at a rate of 50 frames per second (i.e. normal Spectrum speed), but that can be changed by setting the ScreenFps configuration parameter. A value of 0 sets trace.py (and screen updates) running at maximum speed. Also by default, the screen is rendered with a scale factor of 2 (i.e. 512x384 pixels), but that can also be changed by setting the ScreenScale configuration parameter.

In addition to writing a snapshot file or WAV file after code execution has completed, trace.py can now write a PNG image file of the screen contents. Or, indeed, all three at the same time, now that multiple output file arguments are allowed. By default, the image scale factor is 2 (i.e. 512x384 pixels again), but that can be changed by setting the PNGScale configuration parameter.

In other command news, skool2bin.py can now read configuration from skoolkit.ini, and can also pad its output with zeroes on the left by using the PadLeft configuration parameter, or (perhaps more usefully) on the right by using the PadRight configuration parameter. So if PadRight is set to 65536, you can (for example) use bin2sna.py on the output of skool2bin.py without ever having to specify the origin address.

Turning now to skool macros, this release bestows upon #FOREACH support for a new special variable: POKEname. This expands to a list of the POKEs made by the #POKES macro on the named snapshot created by the #PUSHS macro. For example, if the udgfix snapshot has three POKEs:

#PUSHSudgfix #POKES30000,1;30001,2;30002,3 #UDG30000 #POPS

then:

#FOREACH(POKEudgfix)(p,p,: )

would expand to:

POKE 30000,1: POKE 30001,2: POKE 30002,3

Individual POKEs and subsequences of POKEs on a snapshot can be specified by using Python’s square brackets notation for indexing ([i]) and slicing ([start:stop]) a list. For example, POKEudgfix[0] yields the first POKE, and POKEudgfix[1:] yields every POKE but the first.

There are more new features to discover, but for details on those and the bug fixes in SkoolKit 9.4, head over to the changelog. When you’re finished there, get a copy of 9.4 and start rendering POKE lists with absolute precision.

Let's talk about PZX

2026-08-14

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

As if introducing support for RZX files in SkoolKit 9.2 wasn’t enough, 9.3 continues on the new file format bandwagon by introducing support for PZX files. In case you’re not aware, PZX is a tape file format that’s much simpler than TZX, and leaves no room for ambiguity about where one pulse ends and the next begins. Which is quite important for a computer whose tape-loading routines are all about those ‘edges’ between pulses (and in some cases about whether those pulses are high or low, another topic on which PZX is unambiguous).

So now that you are aware, you will no doubt want to convert your entire collection of TAP and TZX files to PZX format. And you can do that safe in the knowledge that SkoolKit 9.3 has you covered: tapinfo.py can show information on the blocks in a PZX file, and tap2sna.py can LOAD that same PZX file. On top of that, bin2tap.py can now write PZX files too.

In other news, sna2skool.py has finally gained the ability to disassemble some of the more obscure ‘undocumented’ instructions in the Z80 assembly language, such as ‘IN F,(C)’, ‘OUT (C),0’ and ‘RLC (IX+d),B’. It can also now disassemble ED6B0000 to ‘LD HL,(0)’ if you want it to, along with a batch of other variant opcode sequences, such as ED4E to ‘IM 0’, or ED4C to ‘NEG’. This new feature is disabled by default, though, for good reasons. One is that your assembler might not recognise some of these instructions, which will be a problem if you want to run it on the output of skool2asm.py. Another is that your assembler probably won’t assemble instructions with variant opcode sequences back to the original byte values.

But if you want to enable this feature despite these dangers, you can set the Opcodes configuration parameter for sna2skool.py to one or more of the following values in a comma-separated list:

ED63 - LD (nn),HL
ED6B - LD HL,(nn)
ED70 - IN F,(C)
ED71 - OUT (C),0
IM - IM 0/1/2 variants
NEG - NEG variants
RETN - RETN variants
XYCB - RLC (IX+d),B etc.
ALL - all of the above

One other potential danger with instructions that have variant opcode sequences is that skool2asm.py and skool2html.py won’t assemble them back to their original byte values, thus creating a discrepancy between the internal memory snapshot derived from the skool file and the snapshot that was used to create the disassembly. To work around this, the new @bytes directive can be used to remove any ambiguity. Whenever sna2skool.py encounters an instruction with a variant opcode sequence, it will automatically insert a @bytes directive. For example:

@bytes=$ED,$4E
 $8000 NEG     ; This assembles to ED4E (not ED44)

On a completely different note (pun intended), trace.py can now write a WAV file after code execution has completed. This means, for example, that you could create a WAV file of the Fairlight theme tune like this:

$ tap2sna.py https://worldofspectrum.net/pub/sinclair/games/f/Fairlight48V1.tzx.zip fairlight.z80
$ trace.py --stop 49217 fairlight.z80 fairlight.wav

And that’s just some of the news. Information on the the other new features and bug fixes in SkoolKit 9.3 can be found in the changelog. After you’re done reading that, grab a copy of 9.3 and unleash it on your new collection of PZX files.

Let's talk about RZX

2026-08-14

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

Back in SkoolKit 3.3, I added the -M option to sna2skool.py, which could be used to read a code execution map produced by an emulator, and thus generate a more accurate control file than is possible by default. That -M option on sna2skool.py later became the -m option on sna2ctl.py, which is still there to this day. That’s all well and good, but one thing that has bugged me all this time is the need to use an external tool (external to SkoolKit, that is) to produce the code execution map. Which is why I’m pleased to announce, 11 years later, that SkoolKit 9.2 includes its very own map-producing tool: rzxplay.py.

As the name suggests, rzxplay.py plays RZX files. It can draw a screen if you want to watch the playback, but this is not its intended purpose. Instead, I would expect the dedicated reverse engineer to use the --map option (in conjunction with the --no-screen option, to maximise playback speed), and feed the resultant code execution map file to sna2ctl.py. Naturally, in this release sna2ctl.py has gained the ability to read map files produced by rzxplay.py.

In the initial stages of development, rzxplay.py could only play RZX files that were recorded in plain 48K or 128K mode. However, there are many RZX files out there that, for reasons unknown, were recorded in +2 mode or above (even for 16K Spectrum games). So, in order to increase compatibility with existing RZX files, I added support for +2 mode to rzxplay.py. As a consequence, trace.py gains the ability to execute code in +2 snapshots for free, as it were. You are welcome.

Barging in alongside rzxplay.py in this release is its sibling, rzxinfo.py. This tool can be used to show the contents of an RZX file (down to individual frames), and extract the snapshots from an RZX file. In the past I’ve made the mistake of adding support to SkoolKit for a particular file format without providing a tool to dump the contents of such files. (For example, tap2sna.py arrived in SkoolKit 3.5, but tapinfo.py had to wait until 5.0.) Not this time, though, thank goodness.

One thing that became clear during the development of rzxplay.py is that, for RZX files more than a few minutes long, producing a map file is a rather time-consuming process. In other (less kind) words, SkoolKit’s pure Python Z80 simulator is, frankly, way too slow. To address this, SkoolKit 9.2 includes a new Z80 simulator implemented in C, which is quite a bit faster than its predecessor. But rzxplay.py is not the only beneficiary of this speed boost: tap2sna.py, trace.py, #AUDIO, #SIM and #TSTATES will also use the new simulator if it’s available.

So for old times’ sake, let’s look at the improvement in speed the new Z80 simulator brings. Tradition requires that I include loading the Skool Daze TZX in such comparisons, so I will do that. I’ll also look at running Patrik Rak’s z80doc test suite, and using #AUDIO to generate a WAV file for the Fairlight theme tune. These are the relevant timings on my PC:

19.6s (Python) v. 1.3s (C) - tap2sna.py skooldaze.tzx
54.4s (Python) v. 1.2s (C) - z80doc tests
12.0s (Python) v. 1.9s (C) - #AUDIO12(fairlight.wav)(49164,49217)

And that’s all the news. More information on the the new features and bug fixes in SkoolKit 9.2 can be found in the changelog. After you’re finished there, grab a copy of 9.2 and a few RZX files, and start cranking out some code execution maps.

Zone of contention

2026-08-14

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

Continuing the theme of “more 128K support” that started in 9.0, this release does indeed bring more 128K support. Specifically, bin2sna.py can now create 128K snapshots, bin2tap.py can create 128K TAP files, skool2bin.py can create 128K binary files, snapmod.py can modify 128K snapshots, and skool files can create internal 128K memory snapshots.

I think most of that was self-explanatory, but perhaps the internal 128K memory snapshots in skool files need a little more explanation. The new @bank directive either specifies the RAM bank mapped to 49152 (0xC000), or loads the contents of another skool file into a 128K RAM bank - and converts the snapshot to 128K at the same time. When that happens, the 128K ROM is loaded as well. After that, how do you actually access all the extra memory? Enter the new #BANK macro, which switches the RAM bank that is mapped to 49152. Got a sprite in RAM bank 4 you’d like to create an image of? Do a quick #BANK4 and you’re ready to go.

One other thing about snapmod.py: not only can it now modify 128K snapshots, but it can also modify SZX snapshots. That brings it up to par with its friends bin2sna.py, tap2sna.py and trace.py, which gained the ability to write SZX snapshots in the previous release.

In other news, SkoolKit’s Z80 instruction set simulator has gained the ability to simulate memory and I/O contention. It’s much slower when this feature is enabled, but it can be useful for various reasons. For example, there are a few game tapes out there that require it in order to LOAD correctly (the original release of Gold Mine being the quintessential example), so tap2sna.py can certainly benefit from it. For another example, the sound created by routines running in contended memory can now be captured precisely by the #AUDIO macro (instead of being approximated in post-processing). And finally, the #TSTATES macro can now do its job accurately when presented with code that’s subject to contention.

On the subject of #AUDIO and #TSTATES, those two macros can also now simulate the execution of interrupt routines, for extra faithfulness to the behaviour of the original hardware. In the case of #AUDIO, this means its two post-processing options (approximating contention and interrupt delays) are now redundant when simulating code execution.

In case you were wondering, yes, of course the #SIM macro has not been left out when it comes to memory and I/O contention and interrupts. It also now has parameters for specifying the value of the simulator’s clock, the interrupt mode, and whether interrupts are enabled. In addition, if the stop parameter is omitted, all other parameters are evaluated, but no code is executed. This technique can be used to prepare the simulator with the required initial register values and hardware state for later use by #AUDIO or #TSTATES.

And that’s about it. Anyone wanting more information on the the new features and bug fixes in SkoolKit 9.1 should pop over to the changelog. After that, go and get your copy of 9.1 and enjoy contending memory and switching RAM banks until the cows come home.

128K ought to be enough for anyone

2026-08-14

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

Yes, the 8.x series has come to an end. It had a good four-year run, but now’s the time for it to step aside and let 9.0 in. As you might expect from an N.0 release, there are some compatibility-breaking changes, which you can read about in the migration guide. But unless you were particularly fond of the #DEFINE macro (deprecated since 8.5), there’s not much to worry about. Most of the other breaking changes are in tap2sna.py and trace.py, but I hope you’ll agree they’re all changes for the better.

The main new feature in this release is support for the (original) 128K Spectrum in tap2sna.py and trace.py. That is, tap2sna.py can load 128K games from tape, and save 128K snapshots. And trace.py can then execute code in those 128K snapshots (or any other 128K snapshots you care to throw at it). The t2sfiles repository (a collection of ready-made tap2sna.py argument files) has already celebrated this new capability by including over 1400 recipes for 128K games, which now accompany the more than 11000 recipes for 48K games.

The next most important feature in this release is support for a ‘phantom typist’ in tap2sna.py. Now, the right-minded among you will surely agree that there are few things more annoying in this world than a tape that requires something other than LOAD "" (or LOAD ""CODE) in order to LOAD and RUN correctly. Unfortunately for us, quite a few such tapes exist out there, but the phantom typist is here to help: it can enter a custom command line before starting the tape. For example:

$ tap2sna.py -c 'load=CLEAR 35000: LOAD ""' Tridex.tzx

And perhaps the third most important feature in this release is support for writing SZX snapshots, which has been added to bin2sna.py, tap2sna.py and trace.py. Until this release, SkoolKit’s one and only output snapshot format of choice was Z80, because it’s well supported by other software and adequate for most purposes. But tap2sna.py occasionally runs into a deficiency in the Z80 format: it has no slot for the last OUT to port 0xFE. This value actually matters for some games that have poorly written keyboard-reading routines.

And there I shall stop, and advise any readers who want more information on the the new stuff in SkoolKit 9.0 to consult the changelog. After that, go and grab a copy of 9.0 and enjoy the 128K’s worth of goodness within.

No rest for the simulated

2026-08-14

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

As the title suggests, this release of SkoolKit is (again) almost entirely about Z80 instruction set simulation. And to rub salt in the wounds of those who still have no interest in the subject, it’s specifically about Z80 instruction set simulation in the service of LOADing tapes. To my recollection, never has a single SkoolKit command received so much attention over a sequence of releases as tap2sna.py has since 8.7 came out in October last year. So, to the fans of tap2sna.py that are still reading: strap in.

First up is the finish-tape simulated LOAD configuration parameter, which (when set to 1) forces tap2sna.py to play the tape to the end before stopping the simulation at the given start address. This is particularly useful for custom loaders that hit the start address more than once during the loading process, and also for stopping purely ROM-based loaders at $053F (SA/LD-RET) after the last block on the tape has loaded.

Next is the contended-in configuration parameter, which (when set to 1) makes tap2sna.py interpret ‘IN A,($FE)’ instructions in the address range $4000-$7FFF (i.e. contended memory on a standard 48K Spectrum) as reading the tape. Lest you think this couldn’t possibly be useful, it’s actually required by such games as Fly Swatter, Removal Deluxe and Sapper, all of which have custom loading routines located in the aforementioned address range.

After that, there are 32 new tape-sampling loop accelerators in this release, brought in to accompany the original 11. And although the casual user will rarely need to think about them, if you are curious which accelerators (if any) a game uses, you can now set the accelerator simulated LOAD configuration parameter to list, and tap2sna.py will do just that:

$ tap2sna.py --sim-load -c accelerator=list GYROSCP2.TZX gyroscope2.z80
Program: GYROSC.II
Fast loading data block: 23755,1250
Data (602 bytes)
Data (46414 bytes)
Tape finished
Simulation stopped (end of tape): PC=64809
Accelerators: rom: 12857; speedlock: 113290; bleepload: 632000; misses: 25/62
Writing gyroscope2.z80

The Accelerators line here shows that a rom-style tape-sampling loop was entered 12857 times, a speedlock-style loop 113290 times, and a bleepload-style loop 632000 times. In addition, the tape-sampling loop detectors, which are triggered by ‘INC B’ and ‘DEC B’ instructions, counted 25 misses for ‘INC B’ (i.e. 25 instances of ‘INC B’ not inside a recognised tape-sampling loop) and 62 misses for ‘DEC B’.

For those even more curious about custom loaders, the format of the trace log file produced by tap2sna.py during a simulated LOAD can now be defined via the TraceLine and TraceOperand configuration parameters. In addition to the current address and instruction, you can log the current value of any register, and also the current time (in T-states) as recorded by the simulator’s internal clock. In conjunction with the new --tape-analysis option of tap2sna.py, which provides an analysis (including timestamps) of a tape’s tones, pulse sequences and data blocks, this enables you to figure out what’s being loaded and where at any point in the loading routine. If that’s your kind of thing.

But if all of this so far seems like too much information, and all you want is for --sim-load to just work for a particular tape, you could do worse than consult the t2sfiles repository. It contains ready-made ‘t2s’ (tap2sna.py argument) files for thousands of games, with appropriate start addresses already figured out, and appropriate accelerators already specified.

And on that note, I shall direct any readers who want even more information on the goodies (simulation-related and otherwise) inside SkoolKit 8.10 to the changelog. When you’re done there, please download a copy of 8.10, and perhaps a copy of the t2sfiles repository, and give --sim-load a good workout. For real this time.