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

Kandur k at qdv.pw
Fri Sep 5 23:33:30 EDT 2014


What a great piece of hard and software!
Presumably it is available, the software version being
a very recent SDC_Setup_July_2014.zip
Where can I buy one, and how much does it cost?
Another question, the prototype photo shows a 40 pin
header on a ribbon cable. Where could I buy one of those?

Kandur

Friday, September 5, 2014, 4:13:08 PM, you wrote:
> 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