8-bit micro MMU's

[Bob Bradlee]

I think you will find that 13k is not enough common memory. You will find working with a 16k common and 
a 48k user segments will give you much more flexability when building your XIOS. Even with 16k bios 
space is tight if you include much in the way of drivers for the I/O, On several ocasions I have bumped the 
16k boundery with HD, Floppy, and multi console I/O devices. FYI, a morrow HD controler, floppy 
controler, memory mapped video controler for console, a 4 port buffered serial controller for terminals, 
and 2 printer drivers using Prn and Aux just fit in 16k with less than 200 bytes free.
16k common system and 5 48k user segments fit nicely in 256k of memory by mapping the 3 extra 16k 
top segments into the 5th 48k user segment. I made a living writing XIOS's in the early 80's and saw a 
wide range of bank switching systems in the day.

later
Bob


Dont forget the base 100 bytes or so at the base of each user space is reserved as XIOS work space and 
jump table.

On Mon, 28 Jan 2008 15:02:45 +1030, Alexis wrote:

>Hi,

>I'm working on an Z80 MP/M II server for my 8080 CP/M computer and I
>have been designing a MMU for it. I thought I'd post it here because it
>could be useful to other builders or better still to talk about any
>flaws or improvements.

>The circuit diagram is here:
>http://kaput.homeunix.org/~thrashbarg/MMU.png

>Configured like that it is capable of accessing 256kB of RAM with write
>protection, or 512kB without write protection by using the 'Mem WE'
>output as an address line. The logical address range is divided up into
>2kB pages, where those pages can be of any 2kB page in the physical
>address range. It's more of a Memory Mapping Unit than a Memory
>Management Unit.

>MP/M II needs to remain resident in the highest 13kB of RAM so having
>the write protection will prevent any runaway processes from crashing
>the system. 50kB of RAM can be made available to the running program.

>Pages can be duplicated in the logical address range, so if a process
>only uses say 4kB of RAM only three pages need to be allocated to it,
>two for the program itself and one to fill the rest of memory. There may
>be a need to have a table on disk to tell the OS how many pages to
>allocate, because a program may use less space on disk than what it
>requires in memory.

>The Process ID is determined by the 74174 to the left of the SRAM. When
>the process changes the 2kB bank making the switch must not change or
>the program will be moved and probably crash. In MP/M II this wont be an
>issue because the system bank isn't supposed to move.

>In this configuration there is a total of 64 processes, 63 if you don't
>include the system as a process. When an interrupt occurs it clears the
>PID register to zero so the system can be called to service the
>interrupt request.

>The 74175 to the far left controls the MMU and ROM. The ROM is enabled
>after a reset and the MMU is disabled. This is done by deactivating the
>left CS of the RAM and connecting the upper address bits of the CPU
>directly to memory. The remaining two or three address lines should be
>tied high with resistors, or even connected to the 74LS244 with those
>inputs tied to +5 or Ground.

>The tricky element is the 2kB dual port SRAM. I found two of them on an
>old arcade game board. This lets the CPU program the mapping of memory
>without having to implement a messy multiplexing system.

>To program a bank an 11-bit address is loaded into ports F9h and FAh,
>then the desired bank is programmed to port F8h. The lowest 5 bits of
>the address selects the desired 2kB page the CPU will access and the
>remaining 6 digits determine the PID. Maybe they should be split up so
>one port selects the page and the other selects the PID.

>Maybe someone can use this? I haven't looked deeply into the MP/M II
>XIOS requirements so I may have left something out that it needs so is
>anyone familiar with the XIOS?

>Cheers,

>Alexis.