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.