[Coco] CoCo3 MMU Register question...

[Tormod Volden]

On Mon, Mar 30, 2015 at 8:53 PM, Zippster wrote:
> I have a scheme in mind, using a CPLD for address decoding, and high speed latches
> for the MMU bank registers, that would operate similarly to one set of CoCo3 MMU banks.
>
> With 8 banks (0-7), the same register locations in memory as the first instance in the CoCo3 (TR 0).
> Using each memory location ($FFA0 - $FFA7) to hold an 8-bit value for the memory block to map to (in a latch).
>
> Perhaps someone who knows about OS9 can tell me if a simplified MMU scheme like this would be
> suitable to compile OS9 to use.  This is without a second task register, and no ability to read the MMU registers.
> Those things could be implemented if necessary, but trying to keep it simple.
>
> Any thoughts or suggestions?  Unfortunately I don’t know squat about OS9’s memory usage.

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