Making WAVEs December 1st, 2013
Pyskool 1.1 has been released. As always, the download page is waiting to serve up tarballs, zip archives, DEB packages and RPM packages.
It’s been about a year since the last release, so I thought it was time to venture into the pyskool.ca vaults, track down and dust off Pyskool 1.0.1, and check that everything was still in good working order. Turns out everything is, but I updated a few things anyway while I was there.
Chief among the updates is a completely new set of sound files. The old sound files – most of which first appeared over five years ago in Pyskool 0.0.3 – were actual recordings of the audio output of a Spectrum emulator, made at the lofty frequency of 11.025kHz. Not surprisingly, then, they sound a little rough when you listen carefully (especially safe-key.ogg). The new sound files, however, are 44.1kHz streams programmatically generated from a precise analysis of the delays between speaker flips in the sound routines of the original games (taking into account contended memory and interrupts). Whether they sound more or less authentic than the emulator recordings, I’m not sure, but they are undoubtedly of much higher quality.
With a Spectrum-speaker-to-WAV library in place, then, I also took the liberty of adding hitting sound effects to Skool Daze. (Be honest: did you realise they’d been missing all this time?) In addition, Skool Daze and Back to Skool now have their own distinct sound effects for the bell, lines-giving, and Eric walking (instead of sharing them, as they had done up till 1.0.1).
So that covers the main changes to Pyskool itself, but in other news, the latest Pyskool code is now hosted on GitHub, and stable releases of Pyskool are just a
pip install away via the Python Package Index. The avid Pyskooler can find even more details on the changes since 1.0.1 in the changelog.
Download Pyskool 1.1 today and hear the difference!
The perfect snapshot September 1st, 2013
SkoolKit 3.5 has been released. Not only that, but copies are available, as you’ve probably come to expect, from the aptly monickered download page. Feel free to pop over there and pick up a tarball, zip archive, RPM package or DEB package. I aim to please with a variety of download formats. Alternatively, you could use easy_install or pip to install SkoolKit from PyPI. So, got your copy? OK then, now sit back while I lay out the main changes since the last version I bothered to write an article about (3.3.2 in May).
First, the bad news. This is something you should pay special attention to if you’ve created (and are using) your own custom CSS file(s) with SkoolKit: the
Font parameters have moved from the
[Paths] section of the ref file to the
[Game] section. In addition, the
Logo parameter has also moved from the
[Paths] section to the
[Game] section, so take care to update your ref file accordingly if you’re using a custom game logo. And, to add insult to injury, the
[Paths] section to the
[Page:*] section. Why all these apparently senseless and inconvenient moves of oft-used parameters from one place to another? Well, truth be told, they should never have lived in the
[Paths] section in the first place; that section is supposed to contain parameters specifying where files that don’t yet exist should be written, and the aforementioned parameters do not fit that description. Case closed.
Now, the good (or, at least, not annoying) news. On the subject of CSS files and themes, SkoolKit 3.5 brings support for multiple themes, and includes three new sample themes (in addition to the traditional dark and spectrum): green, plum and wide. As the names suggest, green makes your HTML disassembly mostly green, plum makes it mostly dark purple, and wide makes the tables on disassembly pages and the boxes on the Changelog, Glossary, Trivia, Bugs and Pokes pages stretch to full width. So if you want your disassembly to look green and wide, you can do this:
$ skool2html.py -T green -T wide game.ref
Also note that if you want to use your own custom theme, then for ease of maintenance and portability between SkoolKit versions, it’s a good idea to create a CSS file that contains only the differences required from the stock skoolkit.css, and to use both skoolkit.css and your custom CSS file (in that order) when building a disassembly. All the alternative CSS themes that come with SkoolKit have been written (or rewritten and much reduced!) to work in conjuction with skoolkit.css.
Next up, SkoolKit has a new command in its library:
tap2sna.py. This command can convert a TAP or TZX file (remote or local, in a zip archive or not) into a Z80 snapshot. Big deal, I hear you snort. But hang on! The idea is that if you’re still in the control file phase of your disassembly, or you’d rather use a skool file template instead of a skool file, you can provide instructions to other users on how to create the ‘perfect’ snapshot that can be used to build the disassembly (from your control file or skool file template) with every byte having the value it’s supposed to have. See the documentation for all the gory details on how to start creating perfect snapshots today.
And that’s probably it for the most newsworthy changes. If it were a slower news day I could mention that
skool2html.py now supports ASM labels in HTML output and can hyperlink the operands of LD instructions, that the
#NAME macro is dead (and presumably unmourned), and that you might find the new
--erefs option of
sna2skool.py somewhat useful; but all that would take up too much space in an already bulging article. The curious SkoolKit user can always check the changelog for details.
Have fun with 3.5!
KitHub May 13th, 2013
SkoolKit 3.3.2 is now available. Should you want a copy – whether in raw form as a tarball or zip archive, or in pre-packaged form as an RPM or DEB file – just head over to the always-welcoming download page and click the appropriate link.
Or, alternatively, you could head over to GitHub and clone the SkoolKit repo. Yes, the SkoolKit git repo is now hosted on GitHub, which means that staying on the cutting edge of SkoolKit development is just a
git pull away. Incidentally, it’s also the place to report bugs and suggest enhancements.
So, besides being the first version of SkoolKit to have been developed ‘in the open’, what’s new in 3.3.2? Well, to begin with,
setup.py now installs the resources directory, which means that a local copy of that directory is no longer required when SkoolKit has been installed via
setup.py install. Whether this counts as a bugfix or an enhancement is probably up for debate.
Also new (since 3.3.1, actually) is the ability to use a standalone extension module that is not part of an installed package. For example, if you’ve implemented an HtmlWriter subclass named GameHtmlWriter in an extension module named game.py that you’d like to keep in ~/.skoolkit, you can make
skool2html.py use it by setting the HtmlWriterClass parameter in the [Config] section of your ref file thus:
If, on the other hand, you are a traditionalist who prefers to keep your extension module inside the skoolkit package itself, then you may find the new
-p option of
skool2html.py useful: it prints the path to the skoolkit package directory. This takes the guesswork out of installing game.py; now it’s as easy as (something like):
$ sudo cp game.py $(skool2html.py -p)
As if all that weren’t enough,
skool2html.py also has a new
-T option that makes switching between CSS themes as easy as pie, and there are a bunch of bugfixes; anyone curious about the finer details can always check the changelog.
And that’s all the news. Git pulling!