[Coco] CoCo 3 MMU test for all

[Roger Taylor]

At 08:31 PM 1/20/2008, you wrote:
>Roger,
>
>To be compatible with a 512k system when/if the end user ever updated.
>
>Just as if you poke in values in to the MMU that would move you out 
>of 512k. They are just pages of repeat lower address that 2^y as you 
>go up in the address space.
>
>Going up in memory space that logic works, going decreasing it does 
>not because the upper address space is always present.
>
>Binary thing.....hex thing. Decimal thing....I'll hit the 
>delete/trash icon. Last warning. :)
>
>Stick with hex and you will understand how it works, remember it and 
>possibly see how the hardware is functioning.
>
>Regards,
>
>Mark
>Cloud-9


Since LOADM does read what you poke in any address, including the MMU 
registers, I can take advantage of a few things if I know more than I 
knew before.  ;)

For the record, most of what you guys are assuming I don't know, I've 
known for years.  I'm not a hardware guy like you so I wouldn't care 
why Tandy only used 6 of the 8 MMU bits so we would be having these 
conversations 20+ years later about ghosting and how other designers 
handled adding another 1.5 megs.

I realize 128k on a memory board is $0-$F and my question about Why 
Tandy uses MMU blocks $30-$3F was not asking how ghosting works, it 
was me making a point that the software point of view is all I'm 
interested in here.  If PEEKing 65441 yields $79 because %01000000 
shows up on an undesired/illegal PEEK, my initial idea was that Tandy 
did this on purpose.  It really doesn't matter to me now.  The topic 
is blown far away from my original post, as this happens from people 
only reading the first sentence and then jumping back with tutorials 
and stuff.  All of my stuff works great and I'm about to load huge 
games into both 128k/512k CoCo's from a single .bin file.  On a 1 or 
2 meg CoCo 3, I'm sure I'll have different copies of the .bin file 
that will LOADM without producing an error.