[Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
Chad H
chadbh74 at hotmail.com
Fri Sep 5 19:26:29 EDT 2014
That sounds uber-awesome dude. I've seen 'hack-paks' for Game Gear in the
past and a few other console systems where someone has packed multiple games
in with a menu system. I already am working on making a custom rom pack
that replaces a EPROM with non-volatile SRAM and is 'loaded' by a Atmega
microcontroller. The user will be able to scroll through a list of .CCC/ROM
files on a MicroSD card plugged into the rom pak and it will load the rom
into the SRAM and you can boot from it at next power cycle. This will all
be self contained within the pak.
As for your idea, I know you can load up to 64K in a 27512 EPROM and use it
with the CoCo. The EPROM boards I've been building do this and allow the
user to 'select' a 8K/16K rom within the chip by moving jumpers. A user can
store up to 8 x 8K ROM's this way. I don't know how to programmatically
have the computer access more than 16K of the ROM at a time though. That
would be AWESEOME!!.. You could then extend the size of your .BIN files.
But is it even possible to do without the hardware banking on the EPROM
board?
-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Kandur
Sent: Friday, September 05, 2014 5:11 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
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