[Coco] GFL football 2 on Cocoflash

[Arthur Flexser]

The ROM contents of $FFF0-FFFF can be read by moving the ROM segment to a
different memory location using the MMU.

POKE &HFFA1, &H3E ($3F will work, too) should move $E000-FFFF so that it
can be read at $2000-3FFF.

(You may also have to do a POKE &HFFDE,0 to go to ROM mode in order to see
the ROM data at $2000, not sure about that.)

As you say, those bytes make no practical difference as far as the game
goes.  Be a neat place for a game cartridge author to stash an Easter egg,
though.

Art

On Mon, Jan 15, 2018 at 1:14 AM, Barry Nelson <
barry.nelson at amobiledevice.com> wrote:

> > On Jan 14, 2018, at 5:12 AM, Barry Nelson <barry.nelson at amobiledevice.
> com> wrote:
> >
> > Update:
> >
> > First I saw 448 bytes different between my new dump and the file on the
> archive named "GFL Championship Football II (1988) (26-3172) (ZCT Systems
> [!].ccc" and 31733 bytes different between my new dump and the file on the
> archive named "GFL Championship Football II (1988) (26-3172) (ZCT Systems
> [b1].ccc”! So based on what I dumped from my cartridge, both are bad! One
> is close, only 448 bytes different out of 32768, but still different. The
> differences for the the one with 448 bytes different start at offset 15873
> or address $FE01 in the high bank so this could just be bytes that are
> never accessed in the rom that are hidden under the vector page. I read $FF
> for these bytes. My method of reading was to read it in the CoCo 3 by
> mapping the cartridge and reading the rom address.
> >
> > Secondly, I did not try either copy from the archive but I now know that
> mine works as I tried my dump.
> >
> > My dump is available right now at: https://drive.google.com/open?
> id=1DiwRvVeJY5s2il_9hPeSH2hi5iXMeoyO <https://drive.google.com/
> open?id=1DiwRvVeJY5s2il_9hPeSH2hi5iXMeoyO>
> >
> > Program ftball0.bin first, then ftball1.bin, in the menu data statement
> add an entry to start the bank where ftball1.bin was programmed with a type
> code of 2. Ftball0 will be mapped in after ftball0 starts. The file
> prgflash.dsk is a virtual disk file which contains the CoCo Flash
> utilities, ftball0.bin, ftball1.bin and the program I used to dump the rom
> which I just slapped together, dumprom.bas. Please forgive the way it
> displays a “garbage” screen while it is running, but it seems to work. It
> uses the USR4 routine from prgflash.bin which reads a byte from cartridge
> rom and returns it to BASIC.
>
>
>
> Further update:
>
> I updated the program and got a dump that is more similar to “GFL
> Championship Football II (1988) (26-3172) (ZCT Systems) [!].ccc”, it is now
> only 195 bytes different and all those bytes that are different are in the
> I/O page at $FF00-$FFFF. The change I did to the dumprom.bas program was to
> change the flags at $FF90 to disable the vector ram at $FE00-$FEFF. My
> previous program was read the vector ram instead of rom for those 256
> bytes. I don’t know any way to avoid reading the I/O page at $FF00-$FFFF
> though, so those bytes will be wrong, but it shouldn’t matter since the rom
> has no way of reading them either. The difference between “GFL Championship
> Football II (1988) (26-3172) (ZCT Systems) [!].ccc” and “GFL Championship
> Football II (1988) (26-3172) (ZCT Systems) [b1].ccc” is that “GFL
> Championship Football II (1988) (26-3172) (ZCT Systems) [!].ccc” has the
> two 16k banks reversed, and “GFL Championship Football II (1988) (26-3172)
> (ZCT Systems) [b1].ccc” does not, so it looks like those dumps are valid. I
> also fixed my dumprom.bas so the display is now correct and it has a
> progress bar you can watch. The updated files are in the link above. If you
> used my previous GFL Football files in a CoCo Flash, they should work and
> there is no reason to replace them. The dumprom program should be usable by
> anyone with a multipak and either a disk controller or DriveWire to dump
> other roms.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>