[Coco] Assembly .BIN -> .CCC/.ROM = SOLVED!
Kandur
k at qdv.pw
Fri Sep 5 23:33:30 EDT 2014
What a great piece of hard and software!
Presumably it is available, the software version being
a very recent SDC_Setup_July_2014.zip
Where can I buy one, and how much does it cost?
Another question, the prototype photo shows a 40 pin
header on a ribbon cable. Where could I buy one of those?
Kandur
Friday, September 5, 2014, 4:13:08 PM, you wrote:
> 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