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!
Statically analyse this January 8th, 2013
It’s time for SkoolKit 3.3. As has become quite the tradition by now, release tarballs, zip archives and whatnot are available from the trusty download page, which has been reliably serving up SkoolKit releases since January 2010. Why not pop by and grab yourself a copy?
The main new feature in 3.3 – which, since we’re all here, I should take a moment to explain – is support for reading code execution logs produced by the Fuse, SpecEmu, Spud, Zero and Z80 emulators. Perhaps that doesn’t sound very exciting, but it actually is. One of the more tedious things about starting to disassemble a Spectrum game is figuring out what’s code and what’s not. SkoolKit will perform a static analysis of the memory snapshot, and do a fair job of finding some of the code, but it cannot get everything right (except by chance); the final decision on whether a chunk of bytes is code or data still requires a human eye (and brain). And given the pressures of daily life in 2013, who really has time for this?
Enter the code execution log. Each of the emulators mentioned in the previous paragraph has the ability to produce a file containing the addresses of the machine code instructions that are executed while a program is running. Some call this file a map, some call it a profile, and others call it a trace; to keep things simple, we’ll call it a code execution log, or log for short. Now SkoolKit has the ability to read such logs, and thus do a much better job of finding the code in a memory snapshot. Of course, this does mean that a bit of work may be required to create the log itself, but playing a Spectrum game while the emulator does the hard work of identifying code should be more fun than trying to find the code by eye. However, if your chosen emulator has the ability to play back RZX recordings, you could take the hands-free approach and just sit back and sip coffee while the emulator does all the work for you. Sorted.
So there it is. Now that SkoolKit has support for reading code execution logs, there’s never been a better time to get started on that Spectrum game disassembly you’ve always wanted to do but were too daunted by the sheer mass of unidentified code and data. Get to it!
About time December 3rd, 2012
Pyskool 1.0 is out! See the download page for the relevant tarballs, zip archives, DEB packages and RPM packages for your OS of choice.
Why the major version number bump from 0.6 to 1.0? Well, it’s been over four years since 0.1 was released with Skool Daze mode complete, and over two-and-a-half years since 0.2.2 was released with Back to Skool mode complete, and in any case, it’s about time, isn’t it? In addition, saved games from 0.6 are also not compatible with 1.0, and there’s nothing quite like a version number bump – especially a major one – to drive that point home.
As for the changes since 0.6, the most noticeable from the player’s perspective is that F11 will toggle full-screen mode. Which, given the preponderance of widescreen monitors these days, means that under certain combinations of scale and monitor resolution, going full-screen will add a border to the traditionally sized 4:3 play area, giving the game a more Spectrumlike feel. The less noticeable changes include various bug fixes, and a fix for the audio latency that can occur when using Pygame version 1.8 or later (in which the default audio buffer size is 4096, compared to 1024 in earlier versions).
Even less noticeable than these changes is the addition of the
--create-ini options to each of the game launcher scripts (
back_to_skool.py, etc.). The
--get-images option will download the TZX files for Skool Daze and Back to Skool (or use existing TZX tape files or SNA, Z80 or SZX snapshots, if present), and dump the required images from them into
~/.pyskool; this means that Pyskool can be distributed without the stock images if need be. The
--create-ini option dumps a fresh set of game ini files into
~/.pyskool; the utility of this option is left to the reader to discover.
That’s about it, but as always, more detail may be found in the changelog. Don’t delay: download Pyskool 1.0 today!