[Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
computerdoc at sc.rr.com
computerdoc at sc.rr.com
Fri Sep 5 16:56:18 EDT 2014
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
More information about the Coco
mailing list