[Coco] .BIN to .ROM

William Astle lost at l-w.ca
Mon Dec 23 23:05:37 EST 2013


Even with a human touch, disassembling something can be a problematic. 
Some months ago, I disassembled the Dungeons of Daggorath ROM. (Found 
some dead code in it when I did, too.) It took me days to work out what 
I was looking at for some of the data sections, and there were jump 
tables that were non-obvious. I had to spend a lot of time tracing code 
by hand to work out just what the various bits were doing before I could 
figure out where all the code was. And that didn't count the bits that 
played funny games with the stack (the sound routines were particularly 
bad for that).

Now DoD is already at $C000, but if you needed to relocate it, you would 
be looking at some pretty crazy adjustments to the code, and not just 
addresses of tables and jump instructions. Even with a symbolic 
disassembly, assembling to a new address is like as not to fail in an 
obscure way. This is typical of tight code written for the 6809.

Incidentally, running every permutation of code is an intractable 
problem. It's actually less work to disassemble and then study the code 
for most programs, even Dungeons of Daggorath. That's because you need 
to study the code to identify the conditions to test.

On 13-12-23 08:54 PM, Luis Antoniosi (CoCoDemus) wrote:
> Chad sorry for breaking your bubble, but do you have a trillion of
> years to spare ?
>
> That's what a NP-complete problem might take to solve.
>
> Why ? Because you cannot infer what is data and what is code. How do
> you know that the 3 byte that looks like a LBRA $2000 is not in fact a
> part of a tile image ? A sprite ? or even raw data ? How do you tell a
> jump table from simple data table ?
>
> Worse, how to you infer it's indeed a LBRA and not the middle of 2
> others instructions ? The only way is to emulate each instruction from
> the start of the code, and make the code run on every possibly branch
> condition satisfying every possibility, to make sure you satisfy every
> condition in the code, to be sure that you have executed ALL
> instruction code from the code. What is left is your data. Can you
> count the probability of the problem now ?
>
> It might look simple for a very small program but that's the evil of a
> NP-complete problem. There is no fast solution and the time grows
> exponentially as the problem grows in size.
>
> Have you tried IDA Pro Disassembler ? It disassembles virtually any
> microprocessor on market (even 6809). You begin with full byte code
> then you select an address and tell it is code. Then it analyzes and
> goes disassembling until it can. Quickly you can see that lot of
> routines are missing because they just don't have direct link to the
> main brunch. Pointer arithmetic plays an evil on this case. But the
> experience is fun and very instructive.
>
>
>
> On Mon, Dec 23, 2013 at 9:55 PM, Chad H <chadbh74 at hotmail.com> wrote:
>> Very interesting.  That might just be the info I needed.  I can write a
>> program if that's what it takes.  Curious to me though that the answer to
>> converting a .BIN to a "WAV or MP3" was so complicated when you can just
>> CSAVEM/CLOADM, etc and record the audio as WAV or MP3.  Oh well.
>>
>> -----Original Message-----
>> From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
>> Behalf Of Brett Gordon
>> Sent: Monday, December 23, 2013 7:16 PM
>> To: CoCoList for Color Computer Enthusiasts
>> Subject: Re: [Coco] .BIN to .ROM
>>
>> i dont know of a converter prog, but heres the specs
>>
>> http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.tandy/2007-05/msg00020
>> .html
>>
>> it shouldn't too hard to write a proggy to do this
>>
>> Brett
>> On Dec 23, 2013 7:30 PM, "Chad H" <chadbh74 at hotmail.com> wrote:
>>
>>> Can someone please advise a simple and reliable method to convert a .BIN
>>> file to a .ROM file?  I can extract the .BIN on my PC if need be.   I seem
>>> to recall a ROM extraction function in the RETRIEVE.EXE included with
>>> the CoCo 2 emulator I have that was used for extracting the CoCo ROM
>>> to a DISK, then you use the RETRIEVE to grab the ROM data off the
>>> floppy into a  .ROM file on the PC.  I doubt this would work for many
>>> .BIN files though, especially since many don't start at &HC000.
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
>




More information about the Coco mailing list