[Coco] Conversion utility for Program Pak Images

John W. Linville linville at tuxdriver.com
Tue Feb 14 11:08:23 EST 2017


On Tue, Feb 14, 2017 at 09:59:58AM -0600, Ron Klein wrote:
> Hi John,
> 
> I may have misunderstood an older email comment from Robert Gault.  You can
> see his comments toward the bottom of the post.  I was looking for
> information prior to my posting and came across this...

Are you dealing with a 32K CCC file? If so, then Robert's information
suggests that you would have to split the file in half and then
swap them...

	dd if=input.ccc of=tophalf.rom bs=1024 count=16

	dd if=input.ccc of=bottomhalf.rom bs=1024 skip=16

	cat bottomhalf.rom tophalf.rom > output.rom

Assuming that Robert's info is correct and assuming that I understand
it correctly, then the above sequence should get you a 32K burnable
EPROM image on a Linux (or other Unix-ish) environment. YMMV...

If your CCC file is 16K or smaller then just burn it to an EPROM.

John
 
> Robert Gault <robert.gault at att.net>
> 1/26/16
> to CoCoList
> OK, after writing an ml routine to print data to the screen I can report
> what a Coco3 sees in the external ROM with 16k / 16k internal external and
> 32k external.
> 
> The most reasonable way to present this is that the 32k ROM always exists
> from $8000-$FF00 and when the Coco3 is in standard 16k internal 16k
> external mode, it sees the second half of the external ROM.
> So my program when using 16k/16k saw the Extended Basic ROM at $8000 and
> the second half of the cart ROM at $C000. When the program set 32k
> external, then it saw the first half of the external ROM at $8000 and the
> same data (second half ROM) at $C000.
> Can I prove that a ROM reader would see the same thing? No I can't, but I
> expect it would. It makes sense because it is the only way a 32k ROM would
> not get lost when switching from 16k/16k to 32k external.
> 
> And then how does this relate to .ccc files? These files do NOT present the
> ROM as seen by a Coco3. The halves are reversed with the second half
> preceding the first!
> This makes no sense to me but someone must have decided that one of the
> emulators JVC, MESS, or VCC could handle a 32k ROM cart more easily in this
> fashion. That format then became the standard for .ccc files regardless if
> it was reasonable.
> 
> On Tue, Feb 14, 2017 at 9:36 AM, John W. Linville <linville at tuxdriver.com>
> wrote:
> 
> > On Tue, Feb 14, 2017 at 07:01:48AM -0600, Ron Klein wrote:
> > > Hello,
> > >
> > > Does anyone know of a way to convert Program Pak images (*.ccc) to a
> > > standard ROM file?  I heard the *.ccc format is mainly designed for
> > > emulator use and not something that can be burned (or flashed).
> > >
> > > Thanks!
> > >
> > > -Ron
> >
> > AFAIK, the *.ccc format is just a flat binary -- the same as what
> > you would burn into an EPROM.
> >
> > If you have other documentation, I would love to see it!
> >
> > John
> > --
> > John W. Linville                Someday the world will need a hero, and you
> > linville at tuxdriver.com                  might be all we have.  Be ready.
> >
> > --
> > 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

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


More information about the Coco mailing list