[Coco] MMU testing utility

[Tormod Volden]

On Fri, Sep 22, 2017 at 7:24 PM, RETRO Innovations wrote:
>
> Many thanks.
>
> Since you're here, I wanted to ask:
>
> On your MMU design, since you're on the cart port, how do you prevent a
> write to your cart from "bleeding through" to the internal RAM?  I see how
> SLENB can be used to move the RAM off the bus for reads, but I don't how it
> will prevent a write from happening. Of course, by redirecting all reads to
> your cart, the only issue is graphics, correct?  How do you handle that?

You can't fully prevent it from the cartridge port (without internal
surgery on the machine). However if you have 64K internally, the upper
32K are safe since the bleed-through won't happen in SAM map type 0.
So you have the internal $8000-$FDFF for video RAM (and other use).
Then you can ignore what's going on below $8000, in most cases the
remaining 512KB + 32KB will be enough anyway. On a Dragon 32 or 16KB
CoCo it is necessary to reserve some CPU space for video memory,
across all mappings. Not much of a problem on FUZIX, where you usually
reserve some statically mapped common memory anyway. Should also be
pretty doable on NitrOS-9, by reserving the memory when the new
process is created. Much the same way as the CRM area is off-limits to
processes.

It would have cost one little gate on the main board (/WE) to make the
SLENB work properly also on writes. However it was not there on the
reference design in the 6883 datasheet, and the CoCo and Dragon
designers were not really looking for anything that could incur extra
cost. I think the SLENB line (ENDC in the datasheet) was thrown in to
allow finer partitioning of the FFxx I/O addresses, and in particular
the sloppy decoding of the PIAs.

Tormod