[Coco] Conversion utility for Program Pak Images

[Ron Klein]

Hi Ed,

Thanks for the clarification.  I may have jumped the gun and apologize.


On Tue, Feb 14, 2017 at 10:03 AM, Zippster <zippster278 at gmail.com> wrote:

> I think so Ron.
>
> - Ed
>
>
> > On Feb 14, 2017, at 10:02 AM, Ron Klein <ron at kdomain.org> wrote:
> >
> > Perhaps this is only related to 32K ROMs?
> >
> > On Tue, Feb 14, 2017 at 9:59 AM, Ron Klein <ron at kdomain.org> 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...
> >>
> >> 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
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>