[Coco] MMU testing utility

[Tormod Volden]

On Sat, Sep 23, 2017 at 8:29 AM, RETRO Innovations wrote:
> On 9/23/2017 12:04 AM, William Astle wrote:
>>
>> On 2017-09-22 09:22 PM, RETRO Innovations wrote:
>>>
>>> And, for others:
>>>
>>> what does the GIME do?  where does it map $fexx when I enable CRM bit?
>>
>>
>> From what I recall of when I tested it, FExx comes from the physical range
>> 7FExx (so block 3F). It has been a long time since I did test it, though.
>>
> Hmm, that is interesting.  So, it you mapped any other 8kB block to 3f, the
> next to last page would get overwritten by CRM activity...

Like the CoCo3, I store the CRM in the $3F block in my own MMU design.
Now here is where my MMU diverts a bit from the GIME/CoCo3. I
currently store it at the last page (upper 256 bytes). So if $3F is
mapped at $E000-$FEFF, you don't see the CRM bytes unless you actually
enable CRM. However, this logic is re-programmable, and I might
consider sacrificing those extra 256 bytes to be more GIME-like.
Further, you cannot map the $3F block anywhere else in my current
logic design. On the CoCo3, the ROMs and video RAM have their place in
the 512KB virtual space. In my cartridge design, the ROMs and internal
RAM including video RAM comes in addition to the external 512KB RAM.
So I use $3F as the magic "see-through" value to access the internal
RAM and ROMs. Since I use 6-bit task registers like the CoCo3 I make
double use of the $3F value, so this value means mapping block $3F for
the $E000-$FEFF task registers and "see-through" for the 7 other
address segments. I know that for instance OS-9/NitrOS-9 always map
the $3F block at $E000, maybe also because as William says, the CRM
sits in $3F so any operating system using CRM would want special
treatment of this block. With my scheme I can still map any other
block at $E000, but one block (in the external 512KB) is always mapped
there as long as the MMU is enabled. It also means that the CRM bytes
cannot be mapped in somewhere else and therefore stay out of trouble.
Additionally I map the last 16 bytes of the CRM to the vector space at
$FFF0 which makes the vectors directly writable and the redirection
otherwise dictated by the BASIC ROMs is not needed. On the CoCo3 the
ROM vectors point to the last 22 bytes in the CRM anyway. On the
Dragon/CoCo1/2 the ROM vectors point to $0100-$0109 which would be
quite unpractical for an operating system, so replacing the ROM
vectors is a big win.

I am still finishing small details so I am interested in your
comments. My goal is not to reproduce the GIME 100% for the sake of
the hardware itself, but to make it easy to port and run some software
made for the CoCo3. I develop both hardware and software so I try to
see how I can balance hardware compatibility and software adaption.

Regards,
Tormod