All the disassemblies

By | May 20, 2017

SD/BTS/CSC/MM/JSW/ROMWith SkoolKit 6.0 came many compatibility-breaking changes that rendered all but one of the current versions of the disassemblies hosted here utterly broken. Not one to let a disgraceful situation like that stand (for too long, anyway), I have stepped in and published updated versions that build successfully with 6.0. And I could just leave it there, possibly breaking the record for the shortest post ever on this site, but there are a few things besides the porting to 6.0 to mention.

First, the hexadecimal versions of the Skool Daze, Back to Skool and Contact Sam Cruise disassemblies have been greatly improved, in the sense that thare are now far fewer jarring instances of decimal numbers floating around in them. For example, animatory states, character numbers and message numbers are all shown in hex rather than decimal, which should make things more comprehensible for the base-16-minded among you. In addition, the Skool Daze disassembly has two new trivia items.

Next, the hexadecimal versions of the Manic Miner and Jet Set Willy disassemblies have also seen a purge of extraneous decimal numbers, albeit on a smaller scale than in the SD/BTS/CSC disassemblies (which were staunchly decimal until now). And the Jet Set Willy disassembly has a new bug entry concerning the in-game tune.

Finally there is the 48K Spectrum ROM disassembly (decimal version here). It didn’t require porting to 6.0, but I have added register tables to all the routines that take input values or produce output values, which I hope will aid in the general understanding of this seminal work of Z80 assembly language programming.

So there we are. These disassemblies are now safely buildable for another major series of SkoolKit releases. See you again when 7.0 is released (or shortly thereafter).

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?