[Coco] Coco 3 Memory Map Questions

[Camillus]

OK Dave, 

The coco sees  the rom  contents with address bit 15 low
while outside    the same contents with address bit 15 High

effectively a 32k shift
correct? 


               msb            lsb
64 K binair =   10000000000000000
32 K binair =    1000000000000000
BFFF binair =    1011111111111111
3FFF binair =    0011111111111111
ROM/EPROM
addres I/O Range AAAAAAAAAAAAAAAA
                 1111110000000000
                 5432109876543210 

   So what is that mean then for programming the Eprom?
cb                             

On 2/9/2016 11:07:34 PM, Dave Philipsen <dave at davebiz.com> wrote:
Camillus, just remember that the ROM is only 32k. The CoCo has a 64k
address space of which the ROM sits in the top half. That means your
EPROM programmer, if it has an editing function, will probably see it as
$0000 - 7FFF. When the ROM is not in your computer you'll usually refer
to the addresses in an absolute way starting at 0000. In the CoCo, it
maps to $8000 - FFFF. So BFFx in the CoCo becomes 3FFx on the EPROM
programmer.

Dave


On 2/9/2016 10:45 PM, Camillus wrote:
> Hi arthur,
>
> Can you explain the ROM test forcoco3 a bit more in detail?
> I do have an eprom programmer and can take out the ROM from my coco3.
> I want it in a socket anyway.
> Do I take a dump from this prom and then change the bytes at BFFx ?
> What byte value should then come in the place?
> Do I then make a memory dump from the eprom space to see if those bytes are reset to the original value?
> Or am I seeing this completely wrong?
>
> Explain to me what exactly you want to know, and I would like to do this experiment.
>
> cb
>
> Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm_campaign=sent-from-mailbird]
> On 2/9/2016 2:50:39 PM, 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.)
>
> Art
>
>
>
> On Tue, Feb 9, 2016 at 10:18 AM, William Astle 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 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
>>
> --
> 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