So What Software

Archive for June, 2009

Chapter 3: Actual Disassembly (continued)

by on Jun.21, 2009, under Programming

In the previous section of this chapter we examined the process of preparing relocatable code for disassembly. This section deals with the actual disassembly process.

For this discourse we are using a generic 65816 disassembler called D816 which does not know anything about the Apple IIgs. There are some special data structures unique to the Apple IIgs which need to be identified and formatted in order for the disassembled code to read correctly. These structures are the ProDOS, Prodos16 and GS/OS command calls.

Before we get to those, the other compensations you need to resolve is the register size directives, namely REP and SEP. In D816 this is handled by the insertion of REG tags which are invisible. At the very beginning of your disassembly you should insert a REG 00 which sets the disassembler to interpret 16 bit accumulator and 16 bit index registers (X and Y) or as is referred to as native mode . As REP’s or SEP’s come up in your disassembly you should set the appropriate REG insertions to make sure the following code interprets the proper size registers… this is very important!!! Once you have the REP’s and SEP’s defined you can go to the other funny structures of ProDOS8, ProDOS16 and GS/OS.

p8The image to the left shows 4 panels the first of which shows an example of what the disassembler will output for a ProDOS8 command call. You need to identify these calls and give the trailing parameters (3 bytes) some tags to make the following disassembly read correctly as shown in panel 2. Panel 3 shows how the monitor displays the code. The monitor is savvy to these calls and formats it’s output to compensate for this inline data. Panel 4 shows how the final interpretation of this code should look for APW/ORCA.

ProDOS16 and GS/OS have the same inline structure and are similar to the ProDOS8 format but have 2 bytes for the command code and 4 bytes for the parameter table location (6 bytes in all).

The D816 disassembler has a little bug in where it does not discern between JSR (Jump to subroutine) and JSL (jump to subroutine long). All JSx commands are output as JSR, this is another little gotcha you will have to compensate for when disassembling AppleIIgs assembly code. ProDOS16 and GS/OS are identified by a JSL $E100A8 which is the main P16/GSOS dispatcher location. This will be followed by 6 bytes defining the call number and parameter table location.

Carefully start at the beginning of the code and make the needed tags for these commands as they appear one by one and your disassembly output will make more and more sense as you proceed.

Once you have all this stuff in order there will still be areas which look like nonsense in your output. This is pure data and can take any form depending on how the original programmer decided to place this stuff. Here’s where a little detective work comes in. You can check the Dos parameter table locations previously defined to begin to eliminate some of these areas by tagging the appropriate addresses as defined by the parameter table descriptions for the particular calls. This will eliminate the ambiguoity of some of this code but the remaining areas will need further analysis.

There are many parameter table structures in AppleIIgs code which can be Window or Dialog templates, color tables, lookup tables and so on. Finding Window or Dialog templates can be done by finding toolbox calls in you code which use these tables as input data line NewWindow or NewModalDialog ans as such. The data being pushed on the stack prior to these calls will indicate the location of these parameter tables. This is where the ProDOS/GSOS and Toolbox reference manuals become vital to successful disassembley.

After you have exhausted this analysis there will still be some remaining undefined locations. These will be local and global variables defined by the original programmer and you will have to tackle these one by on through reverse osmisis and intuition. I realize this sounds vague but that’s the nature of the beast which you can defeat with some careful dilligence and time. This is where you get into the naming of things which is all important in assembly. You may very well never get the same names as the original code had but this is not really important, what is important is the relationship between tags and addresses and not the actual name.

Once you have completely readable source code output in the disassembler it’s time to copy it out into TextMate where the real beautification and macroization takes place… we’re getting close now.

Next Post: Chapter 3:  Final Disassembly

Comments Off more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...


All entries, chronologically...