[Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!

[Tormod Volden]

On Sat, Sep 6, 2014 at 1:20 AM, Chad H wrote:
> Well when the Rainbow IDE compiles it I get a 4K .CCC file that is mostly 00
> 00 00.  The "FF" clearly marks the spot.  Since its overwritten by the .BIN
> data, it's really not adding any size to the code.

OK, that surely works fine. Some would maybe prefer to use for
instance lwasm to compile, and with the --raw option it will just a
produce a file with the actual assembled code, say LOADER.BIN. Then
just merge this on the Windows command line "COPY /B
LOADER.BIN+GAME.BIN ROM.BIN". I don't know if padding ROM.BIN is
needed for your burner program. To pad I would use "dd" on Linux,
MacOSX or MinGW, don't know about any built-in Windows tools.

Tormod


>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Arthur Flexser
> Sent: Friday, September 05, 2014 1:23 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
>
> On Fri, Sep 5, 2014 at 8:03 AM, Chad H wrote:
>
>> Does that put a hex FF at the end?
>>
>
> Well, no, but where the binary goes should be pretty clear without it, just
> by looking for the bytes that comprise the final instruction of your
> program.  Besides, an $FF byte occurs so frequently in "empty" memory as to
> not be a reliable flag anyway.
>
> Art
>
>
>> On Sep 5, 2014 2:29 AM, Arthur Flexser <flexser at fiu.edu> wrote:
>> Why not just BINLOD EQU * at the end?
>>
>> Art