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, 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 later became the -m option on, 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:

As the name suggests, 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 Naturally, in this release has gained the ability to read map files produced by

In the initial stages of development, 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 As a consequence, gains the ability to execute code in +2 snapshots for free, as it were. You are welcome.

Barging in alongside in this release is its sibling, 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, arrived in SkoolKit 3.5, but had to wait until 5.0.) Not this time, though, thank goodness.

One thing that became clear during the development of 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 is not the only beneficiary of this speed boost:,, #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) - 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.