[Coco] Portal-9 disassembler

[Roger Taylor]

At 04:38 PM 12/27/2004, you wrote:
>Sounds great, Roger! So far the only program I know of for the Coco that 
>would come close is "Source3" by Bill Vergona, an interactive 
>disassembler. This program only knows RSBasic 6809 code and is very quirky 
>if the binary loads in lower RAM system space.
>
>Are you going to attempt OS-9 code, higher level languages, or straight ml 
>6(3/8)09? I'd suggest sticking to straight ml, but if patterns could 
>easily be found that suggest higher level programming, report it. For 
>example, if your program found many SWI2, FCB combinations, OS-9 could be 
>suggested as the creating system.

I will eventually make it smart enough to convert a binary into C, but 
don't hold your breath.  There's no immediate plans to support OS-9 
binaries.  I have to start somewhere then progress.  There's way more Disk 
BASIC and ROM binaries out there than anything else, so I'll start there.


>Have you given any thought to game/programs on copy protected disks? That 
>is a whole other major problem in preserving Coco programs and outside the 
>current scope of Portal-9. At the very least, Portal-9 should state as a 
>disclaimer that many programs can not be reproduced because parts of the 
>code will be unseen on the source disks without special programs.

I really don't want to get into copy-protection breaking.


>What would your disassembler do if the binary loads multiple times to the 
>same address but a different MMU block? That would be a major problem for 
>any disassembler as code would be constantly overwritten or might even 
>switch out the disassembler.

It will reconstruct the source code to include all of the necessary ORG 
statements that would cause the same behavior.  You won't find many LOADM 
programs that do such a trick, but they do exist.  I'm not aiming to 
support all the trickery out there, but rather allow most of the old games 
to be turned back into source code for further development.

My Radio Shack parts lookup program, not officially released, did this to 
load a large database into RAM outside of the CPU space, by POKEing to the 
MMU registers during the LOADM process.  The catch is.... some CoCos do not 
PEEK the same values back from those MMU registers, so when you POKE a 3, 
for instance, and a 3 does not get PEEKed back, the LOADM routine will 
abort.  So... you have to tell the LOADM program to OR in a bitmask with 
the 0-63 MMU value so the PEEK will match up with the POKEd value.  Kinda 
hard to explain, but I know you know what I mean.



-- 
Roger Taylor