Message-ID: <624@plus5.UUCP>
Date: Mon, 4-Mar-85 13:15:56 EST
Article-I.D.: plus5.624
Posted: Mon Mar  4 13:15:56 1985
Date-Received: Tue, 5-Mar-85 02:53:15 EST
Distribution: na
Organization: Plus Five Computer Services, St. Louis
Lines: 15

Why does the Mac not have memory protection?  It would seem that the
"computer for the rest of them" might be a bit more robust if it could 
detect addressing errors and recover from them, as opposed to stomping on
the screen handling routines and sending drivel to the debuging device
(read "printer").  If apple is listening, PLEASE include some type of
memory protection on future releases in the Mac line!!!!  It may be hard to
do, but it would be well worth it "for the rest of us."

eric

-- 
..!ihnp4!wucs!plus5!eric	
..!ihnp4!plus5!eric
(314) 725-9492

	

Message-ID: <167@dmsd.UUCP>
Date: Wed, 6-Mar-85 16:16:16 EST
Article-I.D.: dmsd.167
Posted: Wed Mar  6 16:16:16 1985
Date-Received: Fri, 8-Mar-85 05:22:56 EST
References: <624@plus5.UUCP>
Distribution: na
Lines: 75

I agree ... apple really messed the mac design up by not including a
simple mmu. There are several designs that can be done under $50
if you are willing to have a modest sized allocation granularity
in the range of 1k to 8k depending on memory requirements.

My two favorite designs are:

	1) ram lookup, static paging:

                        ________
                        |      |
        ---MMU REG R/W->|      |
                        |      |----
        <-Data Bus----->| XCVR |   |
                        |      |   |
                        --------   |
				   |
			--------   |    ------------------
			|      |   |    |                |
	-High Addrs---->|N x M |   |    | Memory System  |
			|Mapping<--|--->|		 |
	-ENA & R/W----->|Ram   |	|		 |
			|      |   ---->|		 |
			--------   |    ------------------
				   |
	-Low Addrs------------------


		Can generally be implemented with 3 to 5 parts using
	a 8X1024 static ram(s), 74LS245 XCVR(s), and a PAL16L8.
	With an 8bit map you can get 4k pages and a 512k process size
	with write protect. With address independant code (like mac
	programs have) and remapping support in the kernel, the program/data
	size can be much larger with application driven mapping.
	With a second ram and xcvr you can have 128byte pages and a
	2mb address space.

		With the two rams you can partition the map in 2/4 images
	by adding a partition number latch and increasing the segment size
	to 256/512 bytes. With a single ram you can divide the address
	space into banks. Either way you get memory protection.

	2) the second easy solution is to use base & bounds segmentation.
	This is slightly more complex using 8 to 12 parts. My single board
	unix kit uses 2-74AS870's, 1-74AS885, 2-74S283's, 2-74LS240's,
	and a PAL16L8. This gives you 16 base & bounds pairs that can
	be parititioned into the address space as needed. I choose 3 sets of
	3 user segments of text, data, and stack with kenel segments
	of text, data, stack, upage, and two general purpose.

Either design can add between 50ns and 100ns to the memory timing, but doesn't
need to add anything with careful design. You can use the low address lines
to drive memory row addresses, and when the mmu translation is complete
use the high addresses to drive the column addresses. This completely
overlaps the translation time with the RAS timing in many design using
200ns memories.

	Volume end user cost increase is likely much less than $100
with care. Stuffing it into a gate array can give more functionality
and lower cost. Not all systems need complex paging mmu's.

	When you evaluate on a cost of production and maintainance
standpoint including software design, debug, and support the mmu design
may have a much lower lifecycle cost. It would be  interesting to know
how much the LACK of an MMU has cost Apple and other software vendors
in building quality software.

	While we are on the beefs with the MAC hardware ... they could
have also added a serial number for software protection -- thus not
requiring much of the current disk format kludges which prevent using
a hard disk.
-- 
John Bass
DMS Design (System Performance and Arch Consultants)
{dual,fortune,idi,hpda}!dmsd!bass     (408) 996-0557

Message-ID: <1246@amdahl.UUCP>
Date: Fri, 8-Mar-85 02:21:00 EST
Article-I.D.: amdahl.1246
Posted: Fri Mar  8 02:21:00 1985
Date-Received: Fri, 8-Mar-85 20:20:38 EST
References: <624@plus5.UUCP>
Distribution: na
Organization: Amdahl Corp, Sunnyvale CA
Lines: 24

 >  Why does the Mac not have memory protection?  It would seem that the
 >  "computer for the rest of them" might be a bit more robust if it could 
 >  detect addressing errors and recover from them, as opposed to stomping on
 >  the screen handling routines and sending drivel to the debuging device
 >  (read "printer").  If apple is listening, PLEASE include some type of
 >  memory protection on future releases in the Mac line!!!!  It may be hard to
 >  do, but it would be well worth it "for the rest of us."
 >  
 >  eric
I heartily agree.  It amazes my wife and I, how some programs go waltzing
on in there and generate a sure fire bomb.  We haven't actually picked up
Inside Macintosh yet but must soon so we get an idea of what's going on in
there ( or maybe I should say wrong :-).   For now, I just chalk it up to
applications/DA's written without thought of interaction with other stuff.
Don't get me wrong, I love the freeware as much as anyone...

-- 
Do not walk in front of me,
   I may step on your heel.                                  Howard C. Simonson
     Do not walk behind me,          ...{dragon,hplabs,ihnp4,nsc}!amdahl!howard
        I may stop abruptly.
          Just walk beside me, and be wary of sharp turns.  --  HamuS

[ Opinion? What opinion.  I think you have the wrong guy... ]