Disassembly hall

By | October 21, 2009

disassembly-hallFor the last few months I’ve been busy not with Pyskool, but with a related project: the skool disassemblies. Disassembling Skool Daze and Back to Skool (to see how these fascinating games actually worked) was something I started around 1987, and continued until I had filled up half a dozen large notebooks with opcodes and operands, data tables, sketches of the game graphics, and other notes. By that time I’d almost completed the disassembly of Back to Skool, but only just started the disassembly of Skool Daze.

Fast forward to 2001, when I decided that the disassembly of Back to Skool should migrate from the dead-tree world to HTML format, with a few updates added in the process. I pushed the result into the little allotment of webspace provided by my ISP at the time, but the disassembly was still just almost complete (and, as I discovered later, horribly inaccurate in places).

Fast forward again to 2008, when I started Pyskool. The first goal with Pyskool was to get it functioning as a near-clone of Skool Daze. To that end, I got working on the Skool Daze disassembly again, finished it, and used it to get certain Skool Daze-specific features (such as the “special” playtimes) just right for Pyskool 0.1.

Fast forward (just a little) to 2009, when I thought it would be good to dust off the Back to Skool disassembly, and finish it and fix it (at last). Which I did. (And that’s good, because now I know the nitty-gritty details of how the mice and the frog operate, which will be important for Pyskool 0.2.) Since then I’ve been adding more details, fixing inaccuracies, and generally trying to leave no byte of RAM undocumented.

Which, if you are still awake, brings us to today, and the latest release of the skool disassemblies. You can either browse them online, or download a copy for offline viewing. Whatever your choice, I hope you will be informed and entertained. Let me know if you spot any errors, too!

7 thoughts on “Disassembly hall

  1. Grunaki

    Glad you’re still going with this. (As of last week anyway..)

    Any new updates planned soon?

  2. admin Post author

    I’m preparing another update of the skool disassemblies at the moment, but after that I have no plans. Which means I should really get back to work on Pyskool itself, I suppose. 🙂

  3. ChromBurst

    Great effort! I’ve been toying with dissassemblying Stonkers for a while. Which tools / methods have you found useful in the process? Could you perhaps share these for other would-be dissassemblers?

    Thanks,
    Chroma

  4. admin Post author

    The two main tools I used for creating these disassemblies were a text editor, and the dz80 disassembler (part of the d52 suite of disassemblers), which I modified to accept SNA files.

    As for any “method”, I suppose it boils down to this:

    1. Use dz80 to produce an ASM file from a SNA file.
    2. Examine the ASM file and try to find the boundaries between code and data.
    3. Run dz80 on the SNA file again, this time feeding it the info from step 2 (so that data blocks come out as DEFBs).
    4. Figure out what the code blocks do and what the data blocks contain (by examination), and add comments to the ASM file accordingly.
    5. Run dz80 again with updated block boundary info whenever required (i.e. a code block mistakenly marked as data, and vice versa).
    6. Profit! 🙂

    The “source” for each HTML disassembly is basically one long ASM file (the result of executing steps 1-5 above until I consider the job done) with some special markup to provide hints for the conversion to HTML. The conversion from ASM-with-markup to HTML is done by a Python script. So perhaps that Python script is the third tool in the chain.

    Not sure any of that is much help, but there it is!

  5. admin Post author

    Some more details on the “method”.

    My approach to figuring out what the code blocks do and the data blocks contain is not to go through them one by one, in order, and move to the next only when it’s fully documented. That way lies a nervous breakdown! Instead I would do something like this:

    1. Skim the code blocks for any code whose purpose is familiar or obvious, such as drawing something on the screen, or producing a sound effect.
    2. Document that code (and any related data) as far as possible.
    3. Find another code block that calls the code block just documented, and figure out when/why/how it uses it.
    4. Document that code (and any related data) as far as possible.
    5. If there’s anything left to document, return to step 3.
    6. Profit (again)! 🙂

    It also goes without saying that figuring out what a piece of code or data might be used for is easier if you’ve played the game to death already. (But, there, I said it anyway.)

  6. ChromaBurst

    Superb! Greatly appreciated – this has definitely got me started!

  7. admin Post author

    If you were to ask me these questions today, I’d say all the software tools you need to get started with this “method” are included in SkoolKit.

Comments are closed.