10ae5383   
   From: et472@FreeNet.Carleton.CA   
      
   turnkit (turnkit@gmail.com) writes:   
      
   >> I have been thinking I should make a real good disassembler, one that   
   >> would analyze what is data a and what is code by understanding the Z80   
   >> and know all the ROM and DOS entrypoints and data. But I will probably   
   >> never have the time.   
   >>   
   >> Play CAS is finally finished. I will update my site later today. I'll   
   >> announce it when it is there. :-)   
   >>   
   >> --   
   >> Knut   
   >> (delete 'nogarbage.' for email)   
   >   
   > Have you looked at DISNDATA -- it was distributed by the Alternate   
   > Source Magazine folks.  Very good at seperating data vs. code.  I   
   > didn't know how to use it well because my Z-80 knowledge was (is) so   
   > limited but it was one of the few software purchases I made in high   
   > school and I never regretted it.  Made the code all the much more   
   > interesting to try to understand.  Unfortunately I didn't understand a   
   > lot of the architecture so even with good disassembly I wasn't too   
   > sure what I was looking at.  (For instance, I tried to understand why   
   > the Model 1 game, HEADON/CMD, when played on the Model 3, would never   
   > put out double-score dots like it would when running on the Model 1-   
   > that was beyond me... something in the random number generator I   
   > guessed.)   
      
   I don't know.  Those automated disassemblers do the work, but they   
   still don't tell you what the code does.   
      
   Realistically they make several passes at the raw code, and each iteration   
   provides information to restructure the next results.   
      
   But that's what you do when disassemblying code.  Do it once, and you get   
   a pretty blank picture.  Go through it and pick out the system calls (or   
   calls to ROM), and that helps define the picture.  Find the messages that   
   get sent to the screen, and obviously that can't be code, but it also   
   helps you to define what the code is doing.  If it's a prompt that you   
   get just before a keyboard input, then the following code must be something   
   to do with the keyboard input.   
      
   Those steps are relatively simple, thought tedious.  But they help to   
   define the code.  I actually disassembled something recently for the first   
   time in a long time, and the effort needed to mark the system calls were   
   useful in understanding what the code was supposed to do.  I needed to   
   look them up to figure out what that system call was about, which helps   
   to define the code around it, so having some computer do it for me   
   wouldn't have helped much.   
      
   You could have a really fancy disassembler, and it at best it could   
   only guess at what was going on in the code.  You'd still need to figure   
   that out, so you'd end up with a "perfect" disassembly that you still   
   had to study to figure out the code.   
      
   There was once a "disassembler" that provided a perfect listing of   
   the code, but it was intended for a specific bios or something (I forget)   
   so the comments were hardcoded into the program.  It didn't magically   
   parse the code, someone had done all the work previously and this   
   was a legal workaround to provide a user with a disassembled listing   
   of the code without outright publishing that code.   
      
   Usually, you'd not be so lucky and would still have to spend a lot of   
   time over the code.   
      
   Nowadays, it is helped because one can disassemble to a file, and then   
   work in a text editor.  The time I tried to figure out the model 100   
   program to control the portable floppy drive, I had no choice but to   
   print out the disassembly, go through it by hand, make comments,   
   and then disassemble again with the previous information in hand.  Now,   
   I could just do it with a text editor, and when there are messages just   
   reformat the listing by hand.  A text editor also helps because you can   
   search for specific things, like the system calls and prompt messages, and   
   get those out of the way without spending time scanning the code.   
      
   And of course, why you need to disassemble something comes into play.   
   Other than bragging rights, you rarely need to disassemble everything,   
   you just need enough to do something specific.  I once modified   
   edtasm for the Color Computer so I could print a left margin before   
   the rest of a printout (so I could put the pages in a 3 ring binder),   
   and while I had to get the listing for the full program, I didn't need   
   to figure out every line of code.  I needed to find the part where   
   it prints a new line, and that was fairly easy.   
      
   Even if you need a larger picture, good enough will usually do and   
   getting it all will require quite a bit more work.   
      
     Michael   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)