[net.micro.68k] More 68000 MMU's

jtr@lems.UUCP (09/02/86)

From: jtr (Jim Rayfield)

We are using a 68010 Memory Mangement scheme which is very similar to that
described by John Bass (bass@dmsd.UUCP).  I thought I would describe it in
case anyone is interested.

We designed and built our own 68010-based computer board.  It uses a 10 MHz
68010, 150ns dynamic RAMs, and 50ns (4kx4) static mapping RAM to achieve zero
wait-state operation.  The address multiplexing into the dynamic RAMs passes
the lower address bits (offset within page) first as the row address, and then
the higher (translated) address bits later (after translation) as the column
address.  Effectively, "zero" time is used for translation.  Our hardware
supports demand-paging with 'invalid', 'read-only', 'referenced', and 'dirty'
bits with 4096 4K-byte pages per user process.	As John said, it is easy to
generate BERR and inhibit CAS so that writes to invalid pages don't hurt
anything.  So far, we have built 26 of these boards, and they work fine.

This approach (for us) followed directly from using software refresh.  In
order to implement software refresh, the low-order address bits must be used
as the row address so that consecutive address accesses access different rows.
When we decided to add memory management to our design, it turned out that the
most obvious placement of a mapping RAM fitted in perfectly with the address
multiplexing.

An interesting side note:  Quoted from "Sun-3 Architecture:  A Sun Technical
Report", by Sun Microsystems, page 8:

	"The Sun-3 MMU overlaps virtual-to-physical address translation with
	main memory access.  This is done by using the (untranslated)
	page-address bits directly from the CPU for the row address of main
	memory and the translated address bits form the column address . . .
	THIS FEATURE IS A SUN PATENT . . ."

Does anybody know anything about this patent?  Can something that simple be
patented successfully?	Do you guys at DMS Design know anything about that?

Jim Rayfield, Brown University

UUCP:	...{decvax,allegra}!brunix!lems!jtr
ARPA:	jtr.lems.UUCP.brown@csnet-relay.arpa
BITNET: ST401137@BROWNVM (if desperate!)