Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!amdahl!dmsd!bass
From: bass@dmsd.UUCP (John Bass)
Newsgroups: net.micro.atari16,net.micro.amiga,net.micro.68k
Subject: Re: 68000 Memory Managment
Message-ID: <271@dmsd.UUCP>
Date: Thu, 28-Aug-86 09:36:11 EDT
Article-I.D.: dmsd.271
Posted: Thu Aug 28 09:36:11 1986
Date-Received: Thu, 28-Aug-86 22:17:48 EDT
References: <508@elmgate.UUCP> <64@mit-prep.ARPA> <510@elmgate.UUCP> <417@atari.UUcp>
Organization: DMS Design, San Luis Obispo Office, CA
Lines: 88
Keywords: 68000 atari amiga 68k mmu
Summary: MMU's need not affect Ram RAS/CAS timings
Xref: mnetor net.micro.atari16:1738 net.micro.amiga:4416 net.micro.68k:1169

In article <417@atari.UUcp>, dyer@atari.UUcp (Landon Dyer) writes:
> In article <4374@gatech.CSNET>, jeff@gatech.CSNET (Jeff Lee) writes:
> >                                                 You could do
> > the same with a 68000. With a couple of 35ns rams and some address
> > decoding (to map them into memory) you can implement a similar type of
> > .......
> 
> It's a nice idea in general . . . but not on the ST.  Address
> timing is *so* critical that running the address lines through a
> 35ns RAM would result in missing RAS and/or CAS windows on the
> DRAMs.  Bad things happen.

By design, this can be a non-problem. Drams have three parts to each cycle:

   1) RAS/CAS precharge   -- Overlapped with end/begining of M68k cycle
   2) RAS/Row address     -- taken from M68k address lines after AS asserted
   3) CAS/Col address     -- taken from MMU result after delay from AS asserted

The delay from RAS to CAS required/accepted by most DRAMS is about the same
is running the address lines thru a mapping ram or adder/comparator based mmu.
Addresses and function codes precede AS by half a clock giving a little more
head room.  RAS can be started without knowing if the translation will be
valid, since witholding CAS is a refresh cycle.

> 
> The other gotcha is that by the time the lookup RAM can indicate
> if a location should generate a bus error, the memory controller
> is already comitted to the read or write cycle.  You'd have to
> map every unused page to some piece of scratch RAM.

Using a mapping ram, two of the outputs are valid and write-protect allowing:

RAS  := AS2RAS_DELAY  * AS

DTACK:= AS2RAS_DELAY  * AS * MEM_ACCESS                          +
        ROM_DELAY     * AS * ROM_ACCESS                          +
        IO_DELAY      * AS * IO_DTACK

CAS  := RAS2CAS_DELAY * AS * MEM_ACCESS *  VALID *  RW           +
        RAS2CAS_DELAY * AS * MEM_ACCESS *  VALID * /RW *  WPROT

BERR := RAS2CAS_DELAY * AS * MEM_ACCESS * /VALID                 +
        RAS2CAS_DELAY * AS * MEM_ACCESS *        *  RW * /WPROT

NOTE: the delay terms can be external (delay lines??) or state terms from
on-chip counter/sequencer outputs.

Since you can determine a fault at CAS time, CAS is withheld to prevent
writing. DTACK is given early, and BERR asserted on a fault. Target data is
protected during the fault for both reads and writes.

It can't be done that way???? We currently run 16mhz 4-CLK memory cycles using
120ns DRAMS and a $15.00 mapping ram based mmu (4-CLK cycles are zero wait
state for the M68000, and 1 wait state for the M68020 which uses 3-CLK memory
cycles).  Stop by next month and we will show you our M68020 UNIX SBC running
3-CLK memory cycles at 16mhz with our mapping ram mmu and 80ns DRAMS. Still not
convinced, order now and we will save one from the October build for you to
try yourself (starting from $1,800 + tax and shipping).

For a 8mhz M68000 the above the timings are all a piece of cake, including
cycle-stealing arbitration for display accesses.

> 
> We looked at this many months ago, and went a different route....

MMU's are left out of toy computers because toy engineers don't know how
to design real computers -- NOT because they take to much time (the above
solves that problem) or because they cost too much (two mapping rams cost
less than $10 in volume, and the rest of the circuit could have been dumped
into the custom parts or pals already on the board -- an adder/comparator
design could have been placed in the custom parts for nearly zero additional
production cost).  Ditto for memory parity.

MMU's are also left out of toy computers because toy programmers don't know
how to use an mmu, because toy marketing/sales don't care, and many toy buyers
don't care. If you want a toy computer buy one, I like my toy Mac, I can even
do some real work on it ... the cost of ownership could have been lower though
if less development time had been spent by it's programmers fighting the
memory manager and lack of process/os protection from software faults. With
an mmu, certain failures can be identified much earlier, allowing the product
to mature faster and reach market sooner and possibly stay on the market longer
by supporting CLEAN multiuser/multitasking ... thus being more profitable in
the LONG RUN. MMU's are left out of systems due to short term thinking.
-- 

John Bass (DBA:DMS Design)
DMS Design (System Design, Performance and Arch Consultants)
{amdahl,fortune,polyslo}!dmsd!bass