[Coco] Rainbow IDE 2.0 Basic and Gold in the works
robert.gault at worldnet.att.net
Sun Dec 31 09:29:03 EST 2006
Stephen H. Fischer wrote:
> I think that the OP is talking about a disassembler that is part emulator.
> Starting at an entry point or other point that is suspected is code, the CPU
> registers are set up with normal initial contents and the code sequence is
> followed, all branches are remembered and are followed taken in turn until
> all possible code sequences are found.
> This allows the code and data parts of the program to be identified without
> the user doing anything other than saying "do it".
> Instruction types for data access effective addresses are marked as data.
> The closer to a real emulator, the better the automated process.
> This is a much harder process than any of the 6x09 disassemblers I have
> seen. No grease required and this will produce better results for most all
> people without them being an really good expert programmer, of which there
> are fewer and fewer today.
> Stephen H. Fischer
> ----- Original Message -----
> From: "Roger Taylor" <webmaster at coco3.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Saturday, December 30, 2006 4:18 PM
> Subject: Re: [Coco] Rainbow IDE 2.0 Basic and Gold in the works
>>At 02:29 PM 12/30/2006, you wrote:
>>>Cool! How about a disassembler of the same class as "The Source III"
>>>for the CoCo?
>>A partial and incomplete interactive disassembler exists in the
>>current Rainbow IDE versions, but no documentation or support is
>>provided because it's totally useless at this point. It's easier for
>>me to just hide those features for now while I keep working on it.
>>The idea is to let the IDE import a binary such as a CoCo game, which
>>produces a .dsm file containing intermediate code (not .asm source at
>>this point) that the IDE can understand and display in an
>>editor. The dsm editor will let the programmer set label points and
>>names, mark data sections, etc. then the disassembler can be called
>>again and again on this intermediate file to produce more correct dsm
>>files. The dsm files will be turned into asm files in the end, and
>>if they can be reassembled with CCASM and run then the disassembly
>>process was successful. I want to make the whole process seamless...
>>binary to dsm, dsm to asm, asm to bin, in one click of the Disassemble
>>While the intermediate code editor is up you can make on-the-fly
>>changes and then try to rebuild each time until you see the game or
>>program running in the emulator. Keep in mind that the game or
>>program that you see running is not the original binary, but the
>>disassembled and reassembled binary. Wow. If it crashes then
>>something is wrong in the intermediate code.
>>Ofcourse, I'm talking in the future tense on some of these ideas
>>because that is what my goal is and where it's heading now. I'll try
>>to put as many automatic features in the intermediate code generator
>>as possible, but anybody who's tried to disassemble code before knows
>>that it's 50% elbow grease no matter how ya cut it. :)
That's a great idea but far far beyond what SourceIII does if the OP is
More information about the Coco