[Coco] Coco 3 Memory Map Questions

Arthur Flexser flexser at fiu.edu
Tue Feb 9 15:49:52 EST 2016


I'm not sure I understand the testing that led you to arrive at this
conclusion.

I'm a bit hazy on the order of the 2 halves of the 32K internal ROM.  Am I
correct that the half with Extended Basic and Color Basic is the lower
16K?  If so, is it then the case that the 32 bytes in the ROM from $FFE0 to
$FFFF (upper 16K) are duplicated at $BFE0-BFFF (lower 16K), the ending
bytes of Color Basic?  If these two 32-byte ranges are exact duplicates of
one another, how can you tell which is determining the hardware vectors,
without burning a replacement ROM that modifies some bytes at one address
or the other?  Or did you in fact do that?  (In your last sentence, you say
this "could be done" by someone, which seems to imply that you did not do
so.)

Art



On Tue, Feb 9, 2016 at 10:18 AM, William Astle <lost at l-w.ca> wrote:

> On 2016-02-09 04:06, Arthur Flexser wrote:
>
>> I believe the $FFFx vectors were in fact mapped to $BFFx in the earlier
>> CoCos. So this is apparently not true in the CoCo 3, then?  Does $BFFx in
>> a
>> CoCo 3 therefore contain unused leftover vectors?
>>
>
> That is correct. Additional confusion exists because the "leftover"
> vectors at BFFx have also been modified to match the real ones. However,
> examination of FFF0 and the contents of the actual ROM at BFF0 and FFF0
> shows the FFFx range comes from the actual upper bytes of the ROM. (FFEx
> also comes from the the high bytes of the internal ROM based on the same
> testing.)
>
> A completely definitive test could be done by someone who has the
> capability to burn a replacement ROM for the coco3. Simply change the bytes
> at BFFx in the new ROM and observe whether the bytes at FFFx change.
>
>
>
>> Art
>>
>> On Tue, Feb 9, 2016 at 12:22 AM, William Astle <lost at l-w.ca> wrote:
>>
>> On 2016-02-08 18:00, RETRO Innovations wrote:
>>>
>>> I can say there would be some value in someone who could combine GIME,
>>>> GIME2, LOMONT, Service Manual, Sock's GIME registers, etc. into a single
>>>> locaiton with a common layout.  As someone trying to get familiar with
>>>> the platform, it is difficult to sort through the various resources to
>>>> get to consistent and accurate data.  I see now where Darren picked up
>>>> his list from (it's listed on 2 lines on GIME.txt),
>>>>
>>>>
>>> That would be useful even for folks that already know the platform,
>>> actually. I find I have to look things up all the time myself.
>>>
>>> To cap it off, there are bits that are not listed in the "usual" places,
>>> like the "64 column 'VDG' screen" I wrote about some years ago on the
>>> list.
>>>
>>> There is also bad information on exactly where the FFFx vector area is
>>> mapped. As I recall, Lomont asserts that it is mapped to BFFx when, in
>>> actual fact, it maps to the upper 16 bytes of the internal ROM regardless
>>> of ROM or RAM mode, something I confirmed experimentally a while back
>>> when
>>> I was messing with ROM replacements.
>>>
>>> I'm sure there are other bits of information like that floating about in
>>> random places like Sockmaster's brain, comments in the Mame source, etc.
>>>
>>> --
>>> 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