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

Chad H chadbh74 at hotmail.com
Fri Sep 5 19:20:45 EDT 2014


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.

-----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 <chadbh74 at hotmail.com> 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
>
>
> On Thu, Sep 4, 2014 at 7:07 PM, Chad H <chadbh74 at hotmail.com> wrote:
>
> > I have no intention of ever relocating the assembly code.  The FCB 
> > 255 just marks for me in the compiled .CCC file where I need to 
> > start merging in the .BIN file.  The FF is overwritten by the first byte
of the .BIN.
> >
> > This is a 'bootloader' for .BIN files. The code and .BIN are merged 
> > then flashed to rompak.  It performs a kind of LOADM:EXEC on boot.
> >
> > On Sep 4, 2014 3:22 PM, Tormod Volden <lists.tormod at gmail.com> wrote:
> > On Thu, Sep 4, 2014 at 4:31 PM, Johann Klasek wrote:
> > > Putting altogether:
> > >
> > >         org     49152           CoCo and compatibles map in ROM Paks
> here
> > >
> > >         * LOADER
> > > BININ   LDX     #BINLOD         INIT XFER DATA ADDRESS OFFSET
> > > CHKBLK  LDA     ,X+             GET BLOCK TYPE BYTE (00 = PREAMBLE,
> > 255=POSTAMBLE)
> > >         BNE     ENDBIN          IF <>0 THEN MUST BE END OF .BIN DATA
> > (POSTAMBLE)
> > >         LDY     ,X++            GET BLOCK LENGTH(Y)
> > >         LDU     ,X++            GET BLOCK START ADDRESS(U)
> > > XFER    LDA     ,X+             GET SOURCE BYTE(A) FROM X
> > >         STA     ,U+             PUT BYTE(A) AT U
> > >         LEAY    -1,Y            MOVED BLOCK?
> > >         BNE     XFER            NO
> > >         BRA     CHKBLK          CHECK NEXT BLOCK
> > > ENDBIN  JMP     [2,X]           SKIP BLOCK LENGTH (0000)
> > >                                 AND JUMP TO EXECUTION ADDRESS
> > > BINLOD  FCB     255
> > >
> > >
> > > Anything wrong with this?
> >
> > Why the FCB at the end, anyway?
> >
> > If you want to keep it relocatable you should use LEAX BINLOAD,PCR
> >
> > Tormod
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco



More information about the Coco mailing list