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

Chad H chadbh74 at hotmail.com
Sun Sep 7 22:15:06 EDT 2014 

Ummm .. de'ja'vu

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Kip Koon
Sent: Sunday, September 07, 2014 9:07 PM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!

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
Ultimate 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.
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 list' 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