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

[Arthur Flexser]

It's not as difficult as you might think at first glance.  I'd start out
with the simplest case:  programs that don't use any commands from Disk
Basic or Super Extended Basic, so that they could run on a CoCo 1/2
cassette system.  Also, restrict yourself to the case of stand-alone
programs that don't load any other program.  You do not need to do any
PEEKing in advance:  You can assume the program's start address, which goes
in location $19-1A is $1E01, with the byte at $!E00 required to be zero.
(This assumes the default PCLEAR 4 is in effect on a cassette system.
Sorry, doing this in decimal makes my head hurt.)  The end address, which
goes in $1B-1C can be determined by the loader program, as it is in The
Other Bob's loader.

Art

On Mon, Sep 8, 2014 at 8:12 AM, Chad H <chadbh74 at hotmail.com> wrote:

> I found the web page where 'Theotherbob' had done just that.  Tried
> contacting him but no response :(
>
> http://tinyurl.com/rompak
>
>
> From the complexity of what he's talking about, not exactly how I would
> make
> a utility on a PC read a .BAS file and determine all the data manipulation
> that would need to take place.
>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Arthur
> Flexser
> Sent: Monday, September 08, 2014 12:15 AM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
>
> A useful accompanying utility to this one would be one that does the same
> for tokenized Basic programs.  Should be pretty easy to write--I recall
> years ago writing something similar that ran a Basic program contained in a
> Rompack.  You just attach a loader to block move the file to where it would
> normally be loaded in and then execute the ML equivalent of the RUN
> command.
>
> That way, the big EPROM could contain both ML and Basic programs, as
> desired.
>
> Art
>
>
> On Wed, Sep 3, 2014 at 10:47 PM, Chad H <chadbh74 at hotmail.com> wrote:
>
> > Ahh... when I was looking in the Rainbow IDE HELP > 6809 refernce at
> > the opcode table and saw the DECD, I failed to see the note that '*'
> > represented
> > a 6309 code...oops.  Anywhoo, I FINALLY got this bugger going perfectly!!
> > :)
> > Thanks to William Astle, Johann Klasek and Tormod Volden, you guys all
> > made points that helped me debug this ..umm..bugger.
> >
> > Since I only have a CoCo 2 64K, which I believe can only access 16K of
> > cartridge ROM at a time, I decided to load the maximum size .BIN file
> > I could find that would still fit into 16K.  I chose FLTSIM.BIN as it
> > is just over 15K.  The Assembly loader is 33 bytes with the .BIN
> > copied into the .CCC image just after that.  I wrote a quick and dirty
> > .NET application that will prompt the user for the source .BIN,
> > destination .CCC/.ROM file, then write out the 33 bytes and combine in
> > the .BIN file data automatically.
> > All
> > you have to do then is load the resulting file in M.E.S.S. as a rom
> > pak and it loaded the Flight Simulator I instantly :)  I have a few
> > 27128 EPROM's so I'll be flashing this to one of those to confirm.  I
> > know from examining the .BIN data for FLTSIM.BIN that it was many
> > segments but it DOES work :)
> >
> > Anyone can use this to convert a 16k or less .BIN to a ROM Pak Image
> > (32K on CoCo 3????)  I'll put up the small .NET executable that makes
> > the process
> > simple if anyone wants it.   Here is the final Assembly listing, thanks
> > again!!  ....
> >
> >
> >         *.BIN single/multisegment bootloader for ROM Pak
> >
> >         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)
> >         LDU     ,X++            GET BLOCK LENGTH(U)
> >         LDY     ,X++            GET BLOCK START ADDRESS(Y)
> > XFER    LDA     ,X+             GET SOURCE BYTE(A) FROM X
> >         STA     ,Y+             PUT BYTE(A) AT Y
> >         LEAU    -1,U            MOVED BLOCK?
> >         CMPU    #0
> >         BNE     XFER            NO
> >         JMP     CHKBLK          CHECK NEXT BLOCK
> > ENDBIN  LDU     ,X++            GET BLOCK LENGTH (0000)
> >         LDU     ,X++            GET EXECUTION ADDRESS(U)
> >         JMP     [,U]
> > BINLOD  FCB     255
> >
> >
> > -----Original Message-----
> > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of William
> > Astle
> > Sent: Wednesday, September 03, 2014 7:21 PM
> > To: coco at maltedmedia.com
> > Subject: Re: [Coco] Assembly Help
> >
> > On 14-09-03 04:18 PM, Chad H wrote:
> > > DECD was in my 6809 manual and compiled in Rainbow IDE utilizing
> > > CCASM
> > without error.  DECU however failed and wasn't on the 6809 chart...I
> > will look at using the LEAU  and see what happens.  Thanks guys!
> >
> > DECD is most definitely NOT a 6809 opcode. (It's not listed in the
> > 6809 datasheet and none of the undefined operation codes has that
> > effect.) It is a 6309 opcode, though. If I recall correctly, CCASM
> > supports 6309 opcodes so that would be why it assembled. It won't run
> > as expected on a 6809, though.
> >
> > Of course, since you were already clobbering D with the use of A in
> > the loop, it wouldn't work on either processor.
> >
> >
> >
> >
> >
> > --
> > 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
> https://pairlist5.pair.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>