[Coco] Coco 3 Memory Map Questions

[Camillus]

How then would Arthur's experiment would be done practically?


Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm_campaign=sent-from-mailbird]
On 2/10/2016 12:41:02 PM, Dave Philipsen <dave at davebiz.com> wrote:
All I'm saying is that when you make reference to $BFFx that address
does not exist within the ROM/EPROM because it is outside of the 32k
address range of the device. There is no A15 line on the device. When
the device is installed in the CoCo it is selected, effectively, when
the A15 line of the CoCo is hi putting it in the upper 32k bank of the
64k address range of the 6809.

When you speak of addresses in the ROM/EPROM from the standpoint of the
CoCo they are at $8000 - FFFF. When you speak of addresses in the same
device as a standalone device or in an EPROM programmer the addresses
are in the range of $0000 - 7FFF.

Your illustration of "64 K binair" below can never happen on the address
lines of a 6809 since it is using 17 bits to create that address. While
it's true that that binary number does represent 64K you must remember
that the CPU starts with the first address as zero so the highest
address possible on the 6809 address bus is actually FFFF (which can be
expressed using 16 bits). Since we started with 0000 that makes a full
64K range. It's just like saying the range of 0-9 is actually showing
ten different possibilities but we've never used the number 10.

Dave


On 2/10/2016 7:47 AM, Camillus wrote:
> 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 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
>


--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco