[Coco] Coco 3 Memory Map Questions

Thu Feb 11 03:09:57 EST 2016

A stronger test would be to set all the values between $3FF0-3FFF to random
garbage values.  If William and Darren are right,and I believe they are,
all that should happen is that you'll find those values at $BFF0-BFFF when
you boot up the CoCo 3.  If they are wrong, the machine almost certainly
will fail to boot up at all as interrupt vectors and the reset vector would
be seriously kaput.

Or, if you really wanted to really sew things up 100%, you could do a
second burning attempt but put the garbage values at $7FF0-7FFF instead of
$3FF0-3FFF and verify that that really does prevent the machine from
booting up.  (I wonder if it would get even as far in the bootup sequence
as clearing the screen.  I doubt it.)

Art

On Wed, Feb 10, 2016 at 7:57 PM, Camillus <camillus.b.58 at gmail.com> wrote:

> That is not that bad to do, the worst pat is getting my coco back together
> after being in ICU for months now...LOL
>
> And I can do this also with a pin compatible static ram no ( with battery
> backup )?
>
> I see what I can do, and publish my findings...
>
> cb
>
> Sent from Mailbird [
> http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm_campaign=sent-from-mailbird
> ]
> On 2/10/2016 6:33:51 PM, Dave Philipsen <dave at davebiz.com> wrote:
> 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 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
> >
>
>
> --
> 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
>