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

S Klammer sklammer at gmail.com
Fri Sep 5 19:13:08 EDT 2014


I wish every success and enjoyment with a project such as this.

As a product (IMHO), something like the CocoSDC (
http://cocosdc.blogspot.ca/) has more functionality.  As a floppy
controller it functions like a charm and I'd certainly hope that more will
be produced and/or even more functionality is added into a new version.

It has eight 16K flash banks that could be used for alternate DOSes or ROM
carts... and as with SDC-DOS, a "Game Selector" ROM could be written into
one of those banks, accessing the SD card to load in ROM images 'on the
fly'.  Or, just load your 7 favourite ROMs and use RUN@<banknumber>.

Shain
On Sep 5, 2014 6:23 PM, "Kandur" <k at qdv.pw> wrote:

> Hi Kip,
>
> Friday, September 5, 2014, 1:56:18 PM, among other thing, you wrote:
> I've been thinking of making an eprom board with the capability of
> 'dialing up'
> the portion of the eprom the user would like to run to give the user the
> capability
> of having multiple DOSes available to the user just by poking one byte to
> a register
> in the eprom pak.
>
> A tremendous idea, I remember a few month back you were
> very much interested in my multiple socket eprom-pak.
> Would it help you to implement the Ultimate Game Pack?
> http://qdv.pw/eng/_photos/Computers/Coco/cartridges/E-PROM/index.html
>
> > Hi Chad!
> > This is a very interesting idea you have come up with!  This process
> you've
> > outlined now gives the capability of storing a wealth of binary (.bin)
> files
> > in a massive eprom along with .rom game files to ultimately have the
> Ulimate
> > Diskless Game console with a massive rom storage!
> > I've been thinking of making an eprom board with the capability of
> 'dialing
> > up' the portion of the eprom the user would like to run to give the user
> the
> > capability of having multiple DOSes available to the user just by poking
> one
> > byte to a register in the eprom pak.  This would also work beautifully
> as an
> > Ultimate Game Pak also or maybe both together in the same eprom/flash
> memory pak.
> > I'm also thinking of creating a menu program that would boot first
> giving the
> > user the capability of choosing which .rom/.bin image they wish to run.
> As
> > this menu would be in the first 16KB portion of the large eprom,  The
> > 'directory listing' of .bin/.rom images available would have to be custom
> > assembled for each user's purposes.  Then too I could try to collect up
> all
> > the possible .bin/.rom image files people might like to have, create the
> > master menu program and preburn a massive eprom or flash memory chip.
> The
> > on-board register would of course address the extra address lines of the
> > eprom(s) available on this Ultimate Game pak.  Would anyone be
> interested in
> > this?  Any further thoughts on this idea?  Now to get busy on the
> schematic!  :)  Take care my friends!
>
> > Kip Koon
> > computerdoc at sc.rr.com
> > http://www.cocopedia.com/wiki/index.php/Kip_Koon
> > http://computerpcdoc.com/
>
> > -----Original Message-----
> > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Chad H
> > Sent: Thursday, September 04, 2014 11:27 PM
> > To: 'CoCoList for Color Computer Enthusiasts'
> > Subject: Re: [Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
>
> > Johann,
> >         You're optimized code saved 8 bytes! Thanks!  Now its only 25
> bytes
> > + the .BIN file in the rom pak :)
>
> > I did test this in a 27128 EPROM and about 2 seconds after I turned on
> the
> > CoCo 2 I was looking at the Flight Simulator!
> > I've also tested this on CHESS.BIN (<8K) and it worked great too.
>
> > If anyone wants to sample this, I've put up the source .ASM, the
> FLTSIM.CCC
> > for EPROM's, and the Windows .EXE that will take a .BIN file and make a
> > auto-boot .CCC/.ROM file out of it.  The .EXE requires .NET 3.5, which
> is built into Windows 7 and above.
>
> > https://www.mediafire.com/folder/14dbb743vvvsp/BIN_TO_ROM
>
> > -----Original Message-----
> > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Johann
> Klasek
> > Sent: Thursday, September 04, 2014 9:31 AM
> > To: CoCoList for Color Computer Enthusiasts
> > Subject: Re: [Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
>
> > On Wed, Sep 03, 2014 at 09:47:36PM -0500, Chad H 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.
>
>
> > Just for elegance (efficiency also), if someone bother  ... ;) I would
> change
> > Y <-> U as William pointed out already:
>
> >>       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)
>
> > -       LDU     ,X++            GET BLOCK LENGTH(U)
> > +       LDY     ,X++            GET BLOCK LENGTH(U)
>
> >>       LDY     ,X++            GET BLOCK START ADDRESS(Y)
>
> > -       LDY     ,X++            GET BLOCK START ADDRESS(Y)
> > +       LDU     ,X++            GET BLOCK START ADDRESS(Y)
>
> >> XFER  LDA     ,X+             GET SOURCE BYTE(A) FROM X
> >>       STA     ,Y+             PUT BYTE(A) AT Y
>
> > -       STA     ,Y+             PUT BYTE(A) AT Y
> > +       STA     ,U+             PUT BYTE(A) AT Y
>
> >>       LEAU    -1,U            MOVED BLOCK?
> >>       CMPU    #0
>
> > -       LEAU    -1,U            MOVED BLOCK?
> > -       CMPU    #0
> > +       LEAY    -1,Y            MOVED BLOCK?
>
> >>       BNE     XFER            NO
> >>       JMP     CHKBLK          CHECK NEXT BLOCK
> >> ENDBIN        LDU     ,X++            GET BLOCK LENGTH (0000)
> >>       LDU     ,X++            GET EXECUTION ADDRESS(U)
>
> > Without the skipping read (if X is not expected to point after the
> execution
> > address) ...
>
> > - ENDBIN        LDU     ,X++            GET BLOCK LENGTH (0000)
> > -       LDU     ,X++            GET EXECUTION ADDRESS(U)
> > + ENDBIN        LDU     2,X     GET EXECUTION ADDRESS(U)
>
>
> >>       JMP     [,U]
>
> > Is this really meant in this way? Register U contains already the address
> > where the execution should proceed, isn't it?
> > This would fetch the 2 bytes U is pointing at, which is the effective
> address
> > here (which is already the code itself).
> > If U already contains the address, simply jump there with
>
> >         JMP     ,U
>
> > Same as the original implemention does:
>
> >         LDY     ,X++            GET EXECUTION ADRESS(Y)
> >         STY     EXECJP
> >         JMP     [EXECJP]
> > or
> >         LDY     ,X++
> >         JMP     ,Y
> > or
> >         JMP     [,X]
>
> > Back to the version above:
> > This could be shorten further (without reading the block length) with
>
> > ENDBIN  JMP     [2,X]
>
> > (replacing both LDUs and the JMP)
>
> > In addition I prefer BRA instead of JMP (to keep it relocatable, just in
> case).
>
> > 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?
>
>
> > Johann
>
>
> > --
> > 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
>


More information about the Coco mailing list