Roger Williams wrote:
> Well, Thomas didn't answer this, so I'll give you a little insight.
>
> Disassembly is much more difficult than writing your own code.
For me, it takes much longer to write code, because thinking about how to solve a problem, coding the solution efficient and debugging the result takes much longer, than just looking at an already working code and trying to find out what it does.
> The first steps are also the hardest. You must wade through a sea of
> unfamiliar and uncommented hex codes and potential instructions (since
> you don't know what's code and what's data at first) looking for a
> "Rosetta Stone."
At least this first step has become quite easy with DiStella (especially with my modifications :-)
> Fortunately the 2600 is chockablock full of potential
> Rosetta Stone material. You could look for references to the joystick
> ports, or the very universal snippets used for vertical sync which bracket
> a kernel. You can quickly figure out where bitmaps are, where sprites
> are being positioned, and so on.
A very good explanation!
I'm starting by dividing the code into the well known four sections (vertical sync and blank, kernel, overscan) every 2600 programm must have. This is done by looking for accesses at VSYNC, VBLANK, TIM64T and INTIM.
Next, I'm looking for LDA (ZP),Y, that helps me finding the first important RAM addresses, the pointers to the graphic data. Those pointers most be loaded somewhere, and then I know where the pointer tables are.
That also helps, to find the part of the kernel where the score etc. is displayed (48 pixel routine). From there it's only a little step to find the variables for score, lives etc.
I'm verifing the new variables by looking for collision register access before they are changed.
With searching for HMxy and RESxy, it's often easy to find variables for the positions of the objects. Those might be linked somehow to joystick inputs.
Playfield access data might also come from extra tables, so they can be identified quite easy too.
And there are a lot of other TIA registers (audio, joystick, switches,...) that might help me.
After those basic steps, it depends on the game how to continue. As a programmer, I have an idea, how something could have been implemented and I'm starting to search for signs of that code.
>From indexed RAM accesses, I can find the size of a RAM block, which helps me to identify, what it's used for.
It's an often repeating process, but slowly the RAM address map is getting filled.
Then I start searching for the missing RAM addresses to get an idea what they are used for. That's the most frustrating step, because usually, I have to search several different addresses before I find one, that I can identify. Very often, there is a combination of variables that has to be identified together.
When all variables are identified, it's getting easier to understand the code. Then I'm starting to name the lables and tables, which makes the code more readable. That allows to understand the code even better and so on...
Finally I'm adding some extra comments to the variables and interesting code sequences.
And that's it :)
> Reverse assembling the output of a Real Programmer (tm) Mel type
> 2600 programmer is undoubtably the hardest type of reverse assembly
> of all. Your source programmer may be relying on obscure properties
> of little-used instructions, behavior of flags, or other things you would
> take for granted in your own code. You may also not know whether
> cycle counts are critical until you count them. 4K or 16K doesn't sound
> like much but it's a great deal of information presented to human eyes
> 1 byte at a time.
Actually, after having done my first disassembly, it's getting easier. The Activision games I did, were all from the same period, so some of the routines are (nearly) identical, i.e. the screensaver code or the 48 pixel routines. That helps a lot.
And I'm getting a feeling for the Activision coding style. Maybe, when I'd try an Imagic or Parker game, I had to start all over with that again. The Surround disassembly was also quite hard and frustrating, because the coding was sometimes very obscure (everything ws quite new then) and I found it hard to find the expected code patterns.
So I'll continue concentrating on games arround 1982 (if I do any more disassembly at all) and leave the other periods for others.
> My hat is off to the people who have bothered to
> do this, and who have shared the results of their archaeology with us.
Thanks for all those compliments, maybe this encourages some others to join our task.
Have fun!
Thomas
_______________________________________________________
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at web dot de |
_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
IhrName@xxxxxx, 8MB Speicher, Verschluesselung - http://freemail.web.de
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
