SkoolKit 8.8 has been released. To get a copy, please head over to the download page, the Python Package Index, the Ubuntu PPA, or the Fedora copr repo.

Arriving hot on the heels of SkoolKit 8.7, 8.8 is a minor update with just a few (but important) changes, chief among them being an improvement in the performance of the Z80 instruction set simulator. (Yes, strap in for some more simulator-related discussion.)

Now, the simulator’s performance (i.e. speed) does depend to some extent on what the code it is simulating actually does, so allow me to give some concrete examples comparing 8.7 and 8.8 to illustrate the improvement. First, everyone’s favourite (OK, perhaps just my favourite) application of the simulator: tap2sna.py --sim-load (in this case operating on a TZX file for Skool Daze). Second: running the z80doc tests in Patrik Rak’s z80test suite. And third: expanding an #AUDIO macro to generate a WAV file of the Manic Miner theme tune (which runs to 20.25s). Here are the numbers showing the performance of 8.7 and 8.8 on my PC using Python 3.11:

• 2m20s (8.7) v. 0m35s (8.8) - tap2sna.py --sim-load skooldaze.tzx sd.z80
• 2m42s (8.7) v. 0m56s (8.8) - z80doc tests
• 7.56s (8.7) v. 2.98s (8.8) - #AUDIO4(blue-danube.wav)(34351,34358)

Still on the subject of --sim-load, that option now also performs any call, move, poke and sysvars operations specified by the --ram option, in case you want to modify the pristine memory contents - no judgement! - before writing the Z80 snapshot.

Naturally, this improvement in simulator performance also means that the #SIM macro is now faster, and so too is the #TSTATES macro (when it uses the simulator to execute instructions, that is).

The final bit of simulator-related news is that 8.8 has a new command: trace.py. I had originally planned to squeeze this into 8.7, but it didn’t quite make it into that already jam-packed release. Anyway, trace.py uses the simulator to run machine code in a 48K memory snapshot, optionally showing the instructions executed and register values along the way. It can also compute the delays between speaker flips, in case you ever wanted to manually supply the delays parameter to an #AUDIO macro (which might be desirable if the code in question takes a long time to simulate).

Speaking of the #AUDIO macro (again), or more specifically the [AudioWriter] section that controls WAV file creation: the MaxAmplitude parameter has been removed. Its default value was 65536, and roughly speaking it determined the ‘rectangularity’ of the waveform produced when converting delays into samples. But some experiments with low-frequency sounds made it clear that a better default value is ∞ (infinity), for maximum rectangularity and therefore similarity to the sound of a real Spectrum. Leaving MaxAmplitude around just so WAV files can be made to sound less Spectrum-like seems pointless, so out it goes.

And that’s all the news. At this point I would usually direct readers to the changelog for details on any changes not described here, but this time there are no changes not described here, so, well, don’t bother. Just fire up a copy of 8.8 and get simulating.

SkoolKit 8.7 has been released. To get a copy, please head over to the download page, the Python Package Index, the Ubuntu PPA, or the Fedora copr repo.

The tradition in these release announcements is to start by listing the main new macros, commands, or parameters thereof that you can get your teeth sunk into. In this case, however, you may consider that tradition (slightly) bucked. The main bit of newness in version 8.7 is not a macro, or a command - or, indeed, a parameter thereof - but a Z80 instruction set simulator.

The question, then, is how this simulator has been applied to provide the new and exciting features you’ve come to expect from a SkoolKit release. Well, taking centre stage is the --sim-load option of tap2sna.py. It simulates a freshly booted 48K ZX Spectrum running LOAD "" (or LOAD ""CODE, if the first block on the tape is a ‘Bytes’ header). Which means it’s now much easier to convert a TAP/TZX file into a pristine snapshot. No more messing around with --ram load, --ram poke or any of the other --ram commands, and no more worrying about headerless blocks and turbo loaders. Give --sim-load a try and see how much cruft you can remove from your t2s file.

Next, taking stage right, is the #AUDIO macro. It converts a sequence of delays between changes in the Spectrum’s speaker state into a WAV file, and then presents it for playing via an HTML5 <audio> element. But how does the simulator fit into this picture? Good question. While you can provide the sequence of delays manually, a much easier option is to use the simulator to calculate them for you by running the code that produces the sound effect. For example, here’s how you might create an <audio> element that plays the theme tune for Manic Miner:

#AUDIO4(blue-danube.wav)(34351,34358)

Now, taking stage left, is the #TSTATES macro. As its name suggests, it computes the number of T-states it takes to execute a single instruction or a sequence of instructions. Where the simulator really helps here is if the code you want to time is a loop, or contains conditional instructions with variable timing. For example:

; This code creates a delay of #TSTATES(32768,32776,4) T-states.
 32768 LD DE,0
*32771 DEC DE
 32772 LD A,D
 32773 OR E
 32774 JR NZ,32771

And finally in the simulator department, what if none of the applications described so far scratches your itch? In that case, perhaps the #SIM macro will help. Instead of executing Z80 machine code for the specific purpose of loading a tape, calculating speaker flip delays, or timing instructions, it just executes Z80 machine code and lets you do whatever you like with the result - that result being changes to register values (available as replacement fields in the sim dictionary) or changes to the contents of the internal memory snapshot constructed from the contents of the skool file. For example, you could create an image of the Manic Miner title screen like this:

#SIM(start=34278,stop=34332)
#SCR

As for non-simulator-related new features, well, there are some, but they’re just not as interesting. If you really want to know what they are, you can consult the changelog. After that, why not take 8.7 for a spin and see what the simulator can do for you?

SkoolKit 8.6 has been released. To get a copy, please head over to the download page, the Python Package Index, the Ubuntu PPA, or the Fedora copr repo.

So far, the 8.x series of SkoolKit has been a big one for new macros - eight since 8.0 - and version 8.6 continues that theme by bringing along no fewer than three in the shape of #UDGS, #WHILE and #STR.

First up, #UDGS. This macro is an alternative to the venerable #UDGARRAY for creating an image of a rectangular array of UDGs. How is it different from #UDGARRAY? Well, where #UDGARRAY expects a sequence of UDG specifications (including UDG base address, attribute byte etc.) in its parameter string, #UDGS instead expects a single expression that takes a pair of coordinates (the coordinates of the UDG within the rectangular array) and expands to the name of a frame. This makes the typical #UDGS macro much shorter and more readable than the equivalent #UDGARRAY macro. For example:

#UDGS3,4(thing)(#UDGAT($x,$y))

This creates an image (thing.png) three UDGs wide and four high, where the UDG at (x,y) is produced by the #UDGAT macro (which you might have defined with #DEF).

Second up, #WHILE. In the interests of making skool macros more usable as a programming language, this one, as its name suggests, repeatedly expands other macros while a conditional expression is true. So, for example, if you wanted to translate a sequence of character codes starting at address 32768 until a zero-byte is reached, you could do something like this:

#LET(a=32768)
#WHILE(#PEEK({a})>0)(
  #CHR(#PEEK({a}))
  #LET(a={a}+1)
)

Third up, #STR. This one rather undermines the #WHILE example just given, because it expands to the text string at a specific address, by default terminating either just before the first byte that is zero or on the first byte that has bit 7 set. So the example above could be reduced to:

#STR32768

But never mind: #WHILE can no doubt be put to other uses. Meanwhile, #STR can also strip leading and trailing whitespace from strings, and handle strings that terminate somewhere other than the first byte whose value is 0 or 128+.

By now you’re probably feeling some macro fatigue, so let’s move on to a couple of other features. The first one, while not a macro itself, could be described as macro-related, but bear with me. Ever used the @expand directive and liked it, but wondered if there was an alternative that is specific to HTML mode? Wonder no more. The value of the Expand parameter in the [Config] section is expanded before anything else, and thus enables all your macro definitions to be placed in their own section, e.g. [Macros]:

[Config]
Expand=#INCLUDE(Macros)

[Macros]
...macro definitions here instead of in @expand directives...

Finally, a new feature that genuinely has nothing to do with macros. The --ram option of tap2sna.py now supports ‘call’ operations, which call an arbitrary Python function to perform arbitrary modification of the memory snapshot. This will come in handy when the stock ‘move’ and ‘poke’ operations just don’t quite cut it, for example if the RAM needs to be descrambled before it can be disassembled.

Of course, this is not an exhaustive account of all the new features in 8.6. For details on the others, I suggest heading over to the changelog. There you will find details on such things as defining dictionary variables with the #LET macro, and how the #CHR macro is now more friendly towards the ‘special’ members of the ZX Spectrum character set: ‘↑’, ‘£’ and ‘©’. When you’re done there, why not grab a copy of 8.6 and see whether #UDGS can reignite your passion for image macros?