[Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
S Klammer
sklammer at gmail.com
Fri Sep 5 19:13:08 EDT 2014
I wish every success and enjoyment with a project such as this.
As a product (IMHO), something like the CocoSDC (
http://cocosdc.blogspot.ca/) has more functionality. As a floppy
controller it functions like a charm and I'd certainly hope that more will
be produced and/or even more functionality is added into a new version.
It has eight 16K flash banks that could be used for alternate DOSes or ROM
carts... and as with SDC-DOS, a "Game Selector" ROM could be written into
one of those banks, accessing the SD card to load in ROM images 'on the
fly'. Or, just load your 7 favourite ROMs and use RUN@<banknumber>.
Shain
On Sep 5, 2014 6:23 PM, "Kandur" <k at qdv.pw> wrote:
> 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