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

[Kandur]

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