8-bit micro MMU's

Chuck Guzis cclist at sydex.com
Mon Jan 28 14:02:06 CST 2008


> From: Alexis
> Subject: 8-bit micro MMU's

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

(Raises hand)

For MP/M and CP/M Plus, this is probably far too elaborate.  It's my 
experience that MP/M appears to be designed around the idea of a 16K 
bank size.

So, for 256K, you need only to be able to select 16 banks of 16K.  A 
fairly common 74LS670 should do the trick.

A 74LS610 or 612 should be more than adequate for most large-scale 
MP/M applications, but I understand that they're getting hard to come 
by. They can sometimes be found on early 286 motherboards as the DMA 
bank select register.  (PC XTs and ATs have to perform bank-selection 
for DMA, as they use an 8237 DMA controller model, which is limited 
to 64K addressability).

I made the mistake of (just before the '610 came out) designing a 
bank-select circuit for an 8085 product.  It used a Fairchild 64x9 
bipolar RAM (power-hungry and expensive) to give granularity of 1K 
pages.  With MP/M, this was overkill.  16K would have done just fine 
and saved time and money.

With the slow memory chips back then, making things work with the 
wretched 8202 DRAM controller was a real chore.  I seem to recall 
that if you  ran worst-case numbers, you could wind up with the 
requirement of a negative access time for the DRAM for a 5MHz 8085.  
Adding bank-mapping hardware in the address path didn't improve 
things any.

The comment about separating data and address space is worth 
considering, but be aware that, because of deficiencies in the 
instruction set and for performance and space needs, 8080 self-
modifying code is not uncommon.  For example, consider the problem of 
I/O to a variable port number.  SHLD-ing into the operand field of an 
LXI instruction to save a few cycles and bytes is also common in my 
experience.

For what it's worth.

Cheers,
Chuck




More information about the cctech mailing list