The #BUG-free edition

By | May 6, 2017

Alternative #FACTsSkoolKit 6.0 has been released. And in anticipation of your next question, let me just say that copies are available from download page, the Python Package Index, the Ubuntu PPA, and the Fedora copr repo.

Before we get into what’s new in this initial release of the 6.x series, a quick reminder of the some of the more prominent features you’ve come to know and love in previous versions that have been ruthlessly removed: the #BUG, #FACT, #POKE, #EREFS and #REFS macros; the [PageContent:*] ref file section; the parse_params() function, and the parse_image_params(), flip_udgs() and rotate_udgs() methods on HtmlWriter. But do not despair: check the migration guide for details on how to restore these features (should you wish to).

Now, what’s new in 6.0? Strangely, there are no new commands or ASM directives, and only one new (and trivial) skool macro (#VERSION). (The 6.x series is still young, so let’s give it time to venture into those areas.) But the sna2img.py command does have a new option: --expand. This allows you to expand an image macro (#FONT, #SCR, #UDG or #UDGARRAY) outside the context of a skool or ref file. Which could be useful if you just want to make sure you’ve got all your macro parameters straight before committing an image macro to said skool or ref file. Or if you just want to create a standalone image from a game snapshot, and don’t want to bother creating a skool or ref file first.

Also sporting a new option is the tapinfo.py command with --basic. Like the option of the same name sported by snapinfo.py since 5.3, it lists the BASIC program in a specified tape block. Yes, at last, SkoolKit provides a convenient way to examine the first thing any reverse engineer worth his salt will want to look at when starting work on a new game: the BASIC loader. Previously you might have been able to convert the tape into a snapshot with tap2sna.py and then used snapinfo.py --basic on it, but you probably (justifiably) thought that was too much work.

Yet another command enjoying a new option in 6.0 is snapinfo.py with --find-tile. This one enables you to search the RAM for the graphic data of a tile currently on screen. By default it will search for a contiguous block of 8 bytes that match the tile at the specified coordinates, but it can also search for graphic bytes separated by a fixed distance (e.g. 2, as is common with 2×2 sprites), or a range of distances (e.g. 1-256) if you’re unsure about how the graphic data is organised.

By now you might be thinking that new options for old commands is the entire story for 6.0, and you’d be mostly right. But if you want to find out about the non-option-related new features, you should check the changelog.

And that’s all the news. You are now encouraged to download a copy, and migrate your existing disassemblies to the new reality that is SkoolKit 6.0. Good luck!

Deprecation’s what you need

By | January 8, 2017

Snapshots to screenshotsSkoolKit 5.4 has been released. And if you’d like a copy, you can get one (as usual) from the download page, the Python Package Index, the Ubuntu PPA, or the Fedora copr repo.

This is a somewhat sad moment for the 5.x series, since 5.4 will be the last instalment. However, let’s see if we can bring some cheer to the occasion by taking a tour of some of the new features in this release before 6.0 comes along and stomps on the faces of all the deprecated ones (about which more later).

First up is sna2img.py – the sixth new command this series. As its name suggests, it extracts data from the display file and attribute file of a snapshot (or a SCR file) and converts it into an image of the PNG or GIF variety. Which could be useful if you want some screenshots for your disassembly, but the required graphic data won’t fit in your skool file, so the #SCR macro is not an option. sna2img.py also comes with the ability to crop, flip and rotate the screenshot, not to mention set the scale as large as you like. Once you’ve got your desired screenshot (or portion of it), you can incorporate it into your disassembly by declaring it in the [Resources] section of your ref file.

Also new is the @equ directive. No prizes for guessing that this directive produces EQU directives in the ASM output, allowing you to define labels for arbitrary values or addresses that don’t appear in the skool file. (Spoiler: the next version of the Spectrum ROM disassembly will use @equ directives to define labels for the system variables.) Now I look at it, I’m really not sure how SkoolKit has survived for so long without this particular ASM directive.

I could go on about the other new things in 5.4, but I need to leave space to discuss the features that are being culled before 6.0 arrives. So if you’re curious, pop along to the 5.4 changelog for all the details.

Now for the sad part. I won’t beat about the bush – on the chopping block are the following features: the #BUG, #FACT, #POKE, #EREFS and #REFS macros (which have been with us since SkoolKit 1.0); the [PageContent:*] ref file section; the parse_params() function, and the parse_image_params(), flip_udgs() and rotate_udgs() methods on HtmlWriter. And to top all that off, support for Python 2.7 and 3.3 will be dropped: SkoolKit 6.0 will only work with Python 3.4+.

Before you start tearing your hair out and cursing the day you decided to use SkoolKit to reverse engineer a game, let me say that even though they are deprecated, you can keep all your #BUG, #FACT, #POKE, #EREFS and #REFS macros and [PageContent:*] sections in place, because they can easily be reactivated in SkoolKit 6.0 by judicious use of the @replace directive (in the case of the skool macros) and the #INCLUDE macro (in the case of the [PageContent:*] section). And although the aforementioned API functions and methods will be gone, there will be near or exact equivalents available.

So that’s it for the current release and the road ahead. While you wait for SkoolKit 6.0, why not take 5.4 for a spin and create some screenshots of your favourite games with sna2img.py?

ROM here to eternity

By | October 23, 2016

ORG 0It’s not every day that a new disassembly is added to the gallery here at skoolkit.ca, but today is just such a day. The new addition to the family is the Spectrum ROM disassembly, which showcases SkoolKit’s ability to produce disassemblies of not only games, but also, well, ROMs. Or, at least, this particular ROM.

This disassembly of the 48K Spectrum ROM began life as a control file back in SkoolKit 3.6 (version 20131102), and was recently ‘completed’ and published on GitHub (version 20160709). Since then, the control file has been shed in favour of a skool file, marking the disassembly’s eligibility for publication here in both browsable and downloadable forms (in decimal format, to boot).

There’s not much more to say – the Spectrum ROM’s source code speaks for itself, I think – except that since the inaugural ‘complete’ version (20160709), the system variables have been added, with complete lists of the routines that use them. Happy browsing!