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

[Chad H]

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