SkoolKit 2.0: Now with rounded corners

By | November 23, 2010

Load? Save? Start? Where?SkoolKit 2.0 is ready for release, so I have released it. Grab a copy from the download page.

It hasn’t been long since the previous release, but there have been many changes under the hood (as the saying goes). Before I list the main ones, though, a little history. SkoolKit 1.x supported four different types of macro and directive in skool and ref files (the ‘source’ files for a disassembly): skool macros, ASM directives, skool directives, and ref file macros. That’s a large number of macros and directives to remember the purposes of, differences between, and syntax for. SkoolKit 2.0, on the other hand, supports only two types of macro and directive: skool macros and ASM directives. All instances of and support for skool directives and ref file macros are gone. Trust me: you won’t miss them.

Continuing the quest for simplification, support for five (yes, five) of the skool macros has disappeared: #ASM, #LOAD, #SAVE, #START and #PT. But again, trust me: you won’t miss them. Anything they could do can now be done by the enhanced #R macro.

Simplification was not the only goal for 2.0, however. Clarification was high on the priority list as well. To that end, load.skool, save.skool and start.skool – which confusingly used to serve as source files for code in both Skool Daze and Back to Skool – have been split into separate files for each game. Also on the clarification front, the mysteries of the ref files have now been exposed: every section that may appear in a ref file is fully documented in the user manual.

In other documentation news, the user manual has been tidied up a bit. There’s now a separate page describing each of the commands that ship with SkoolKit:,,,, and And the ‘Disassembly DIY’ page – which was previously a rather feeble and disorganised attempt at explaining how SkoolKit could be used to develop a disassembly of some game other than Skool Daze or Back to Skool – should now be much more accessible and useful. It even includes tips on using to create a control file from a skool file, in case you ever (understandably) supposed that that was a completely pointless and backward thing to do.

No one complained about it – so I suppose no one actually noticed – but owing to a cockup by my incompetent release manager (that is, me) the loading code, save code, and startup code disassemblies for Contact Sam Cruise that were promised in 1.4 never actually made it into the tarball and zip archive. Let me dwell on this blunder no further other than to say that the omission has been rectified in SkoolKit 2.0.

Last and most definitely least – because SkoolKit is not just for skools any more, remember – the Skool Disassemblies have seen a minor update in celebration of the SkoolKit 2.0 release. As usual, you can browse these disassemblies online, or download a copy for offline viewing, or download SkoolKit and build a copy yourself. Full instructions are (still, despite the skool de-emphasis) included.

Well, that’s about it. Now go forth and disassemble.

2 thoughts on “SkoolKit 2.0: Now with rounded corners

  1. falso


    Im trying to disassemble another game, but im having a lot of problems trying to figure out how does SkoolKit extracts the UDGs from the data part?
    From what I believe, SkoolKit requires PIL so it surely creates images, but I cant figure out how to do this.

    On my .ref file I have:

    And on my .skool file I have this, to define a UDG that is at address 16384:

    ; First Sprite Test
    ; #UDGTABLE(udgs)
    ; { #UDG16384,6 }
    ; TABLE#
    ; @label=TESTUDG

    But I’m not getting any generated images, do you care to explain to me what else should I do?

    Thanks in Advance!

  2. admin Post author

    Your #UDG macro should create an image of the UDG based on the 8 bytes 16384-16391, with attribute 6. By default, the image will be written to the images/udgs directory (which will be created if it doesn’t exist). After running on your skool file, the UDG image should appear on the disassembly page for the routine that contains the #UDG macro in its description. Check the images/udgs directory: does anything get written there at all?

    Don’t be distracted by the ‘Graphics=1’ entry in the [Features] section of the ref file. What that does is create the ‘Other graphics’ page, and show a link to it on the disassembly home page. The contents of the ‘Other graphics’ page are determined by the Python methods called ‘write_graphics’ in lib/; currently there is no way to declare the contents of the ‘Other graphics’ page using the ref file. But it would be good if you could do that, so I’ll add it to my feature request list.

Comments are closed.