[Coco] Coco 3 Memory Map Questions

[Dave Philipsen]

Well, I could be wrong on how I'm interpreting this but:

Remove the ROM from your CoCo.  Read it in using an EPROM burner. Save 
the ROM contents as a binary file.  Using a binary editor changes the 
contents of $3FF0 and $3FF1 to something other than what's already 
there.  Use the edited binary file to burn a new EPROM.  Put the new 
EPROM in your CoCo and boot it up.  Do a PEEK (&HFFF0) and a PEEK 
(&HFFF1).  Do the values there match the values you edited?

Dave


On 2/10/2016 6:08 PM, Camillus wrote:
> 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
>