[Coco] CoCo3 MMU Register question...

[Zippster]

Hi Tormod,

Ok, good to know!  This is exactly the kind of info I needed.  :)

Implementing a second set of registers is no problem, just more latches and
a control bit to switch them.  Following the CoCo3 MMU scheme that will mean an
8-bit latch at each memory location ($FFA0 - $FFAF).  So 16 latches + 2 more to capture
the memory address presented by the SAM.  

So, 18 (8-bit) latches, 128 buffers to load default latch values on system reset or startup
(unless a routine is added to the system ROM to handle it, probably the best way, but is there room?), 
and all associated address decoding logic.  Getting interesting.  :)  

Which N8VEM project?  The Griffon board?

- Ed


> On Mar 30, 2015, at 4:04 PM, Tormod Volden <lists.tormod at gmail.com> wrote:
> 
> Hi Ed,
> 
> Bringing OS9 Level 2 to CoCo2 and Dragon makes all sense in the world
> to me! We are many who dream of such an MMU, and of designing one. A
> recent discussion:
> http://archive.worldofdragon.org/phpBB3/viewtopic.php?f=5&t=5234
> 
> For OS9 (or any real OS) you should absolutely have at least two
> tasks. And a way to read out the current task would be nice. I don't
> think reading out the MMU bank registers is needed.
> 
> If this is an internal MMU board it should monitor BS and BA to trap
> interrupt fetches and switch to system mode. The GIME keeps a RAM page
> at FE00 write protected while in user mode (and MMU enabled), and all
> interrupt vectors go here. I suppose also the bank registers are
> locked in user mode.
> 
> It should be possible to make a NItrOS-9 port that runs this MMU and
> otherwise keeps to CoCo2 peripherals. Of course you would not be able
> to run Level 2 programs that depend on the CoCo3's graphics modes.
> 
> In any case, it would be a fantastic platform for FUZIX!
> 
> Take also a look at what the N8VEM guys are cooking. They made their
> own MMU solution, with a different page size IIRC (4 KB instead of
> GIME's 8 KB).
> 
> Best regards,
> Tormod