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.
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.