[Coco] Portal-9 disassembler
rtaylor at bayou.com
Mon Dec 27 23:10:19 EST 2004
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.
More information about the Coco