Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ernie!bazyar From: bazyar@ernie (Jawaid Bazyar) Newsgroups: comp.sys.apple2 Subject: Re: Back to the GS MMU hack Keywords: multitasking, mmu, unix gs Message-ID: <1991Feb18.045719.22698@ux1.cso.uiuc.edu> Date: 18 Feb 91 04:57:19 GMT References: <27bef335.4e12@petunia.CalPoly.EDU> Sender: news@ux1.cso.uiuc.edu (News) Reply-To: bazyar@cs.uiuc.edu (Jawaid Bazyar) Organization: Mutation Testing Facility, University of Illinois Lines: 67 In article <27bef335.4e12@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu (Roy Bannon) writes: >The idea had been to implement a mmu on the GS using a motorola 68851 pmmu >chip. I finally got the data book on the thing a couple of weeks ago. I think >there is a big problem with using it on the gs. The 68000 series uses address >strobe and dack to get data from memory. The pmmu takes the as from the 68000 >does a lookup and the issues a as to memory with a new address. The problem I >see is that the 65816 wants to see data on the up edge of the clock. Even >using the fastest version of the pmmu, it would delay the time when the address >becomes valid til it was too late for the memory to respond in time for the >rising edge. The AS could be simulated, or just tied to one of the clocks and VPA/VDA (to be sure that a valid address is on the bus) I talked to some WDC engineers about the second thing. They said that by pulling the RDY line on the '816, you could effect a wait state, which would end before the next rising edge of the clock. >Also, the glue logic would have to convert all the 65816 signals >to 68000 like signals and the convert the 68000 back to 65816. This is because >the pmmu stores most of its translation tables in RAM. So when it tries to >look up an address that isn't in its cache, it finds it in RAM itself by >becoming bus master. This would drive the cost of this thing way up. I didn't see this problem- set it up so that the PMMU is ALWAYS the bus master- even in regular non-protected mode the '816. Also, the '816 has a bus enable (BE) so that it can easily be taken off the bus. >Secondly most of the pmmu features relate to address translations for virtual >memory. This means we wouldn't be using all the features of the chip we >bought. >So, As I see it, what we need is a more simple implementation of memory >protection. > >So, here goes. > >Break the memory up into 256 byte pages (the pmmu does this too). Then [...] This basically looks good, except that I would recommend a 32Kx16 setup. That allows for 8 megabytes of memory under 'protection'. Plus- and this is important- it would allow assigning an entire Memory Manager UserID per 256 bytes. If we assume that a process has the right to do whatever, whenever to its memory, then we don't need an access flag (it's implied). Your new plan also has another benefit, being that the modifications to the Toolbox/GSOS would be minimal, almost trivial. It simplifies things such as programs going straight to screen memory, etc. I just looked at my Toolbox ref, and actually only 11 bits of a UserID are necessary to unambiguously identify a process under GS/OS, so that leaves you 5 bits for whatever. About how to handle page faults- in the case of a fault, writes must be prevented from happening. Checking the hardware ref, we have 'round 250 ns to detect a fault and make sure R/W stays high (i.e. make sure write is turned off). >This should cost a lot less than using the 68851 pmmu, with the drawback of >virtual memory support. Anyway, lets here the flames people. True- I'm pushing for VM support because it would in the future allow for pre-emptive multitasking and clean up the '816s architecture software- wise (e.g. have as much stack space as needed). -- Jawaid Bazyar |"I'm sure K&R have never heard of Mike." Senior/Computer Engineering | bazyar@cs.uiuc.edu |"That's okay. I'm sure Mike's never heard of K&R". Apple II Forever! | (discussion about Orca/C)