Aw: Re: [stella] Pitfall! disassembly

Subject: Aw: Re: [stella] Pitfall! disassembly
From: cybergoth@xxxxxxxx
Date: Fri, 12 Oct 2001 10:56:27 +0200 (CEST)
Hi Roger!

I'd just like to add some things...

> Disassembly is much more difficult than writing your own code.  

I don't agree here...

> The first steps are also the hardest.  

... but definitely here :-)

> 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) 

Distella does a great job here. That task is almost 100% done.
After the first run you can adapt your script file and turn
the display of all data into graphics, so you *see* the graphics
as well and can easy distinguish it from 'just data'

> looking for a
> "Rosetta Stone."  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.  

There's some more easy to detect stuff like the screensaver, the random
and the horizontal positioning subs, a 6 char kernel, the frame counter...

> You can quickly figure out where bitmaps are, where sprites
> are being positioned, and so on.  


> The way I approached this when I was
> young and had a lot of spare time was to make a large memory map of
> the application, as well as a listing of the raw disassembly.  As I figured
> out what a code snippet or subroutine did I'd color it out on the memory
> map and comment it (in pen and ink) on the disassembly.  Nowadays
> I'd probably still use the paper printout, but also flesh it out in a text
> editor as I'm going.  Back when I did this kind of stuff, I didn't have
> disk drives...

I go there without pen & paper. I start from the entry point and just
try to analyse it line-by-line from there. Whenever there's a variable 
used, I highlight it and jump on it through the whole source (On Textpad
you'd do that with STRG/CTRL+F). Doing that I'll try to figure out what 
it's used for. Is it stored somewhere into the TIA registers? Is it 
counting something? Is it storing some data bits? (Hardest to figure out
here are definitely temporary variables, they are very confusing at the 
beginning). When I get an idea what it does, I try to change it's 
behaviour in a certain way, compile, fire Z26, and check if I get the
expected altered behaviour of the game. 

Reading the manual of a game is also a very important thing, giving 
you lots of hints like 'Game Over on 99 points' 'Switch A does 
this'n'that'. Try looking for BCD accessed variables -> Voilà: the

> Reverse assembling the output of a Real Programmer (tm) Mel type
> 2600 programmer is undoubtably the hardest type of reverse assembly
> of all.  

No. definitely not. Try reverse-engineering computer stuff like for 
the C64. There's RAM everywhere (self-modifying code!), you've a 
kernel with obscure jump tables pointing to even more obscure subs,
you've way more stuff to learn (The SID only might be three times as
complex as the TIA, I don't even think about the VIC...) Besides,
all VCS RAM is zero page, you'll get used to that quick, wheras
on other computers you've to take care about zero and normal RAM...
Theres' no STA WSYNC, so cycle counting / timing on the C64 might 
be even worse when doing stuff depending on the raster beams

> 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.  

You'll encounter this on all machines, when seriously coding at-the-edge 
assembler, which top games usually require.

> 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.  

But it's better than up to 64K :-)

> My hat is off to the people who have bothered to
> do this, and who have shared the results of their archaeology with us.

Of course I've to agree 100% here. It _is_ a hard job, on every machine.


Für Schnäppchenjäger ist jetzt Beutemachen angesagt:
Quelle hat knallhart reduziert. Aber nur solange Vorrat reicht!

Archives (includes files) at
Unsub & more at

Current Thread