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.