[Coco] Coco 3 Memory Map Questions

[Arthur Flexser]

Incidentally, the bytes from $BFE6 to $BFEF are an encoded version of
"MICROSOFT!" spelled backwards (decode with XOR $87), according to
http://www.pagetable.com/?p=43.  (The Unravelled disassembly labels these
as "Unused Garbage Bytes.)

Art

On Tue, Feb 9, 2016 at 4:07 PM, William Astle <lost at l-w.ca> wrote:

> On 2016-02-09 13:49, Arthur Flexser wrote:
>
>> 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.)
>>
>
> Yes, the internal 32K ROM is organized as you'd expect with ECB and CB in
> the lower half.
>
> Only the 14 bytes from BFF2...BFFF and FFF2...FFFF are identical. FFE0
> through FFF1 do not match BFE0 through BFF1. It's extremely unlikely they
> would have specially mapped only 14 bytes. (You get 0000 at FFF0 but at
> BFF0 is a couple of junk bytes.)
>
> You're right that I haven't done the ROM experiement. At the time, I
> didn't have a machine with a socketed ROM and I don't have the skills to
> desolder chips and install sockets even if I did have EPROMs and a
> programmer.
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>