Path: utzoo!attcan!uunet!tektronix!tekig5!wayneck From: wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory / doable 1.4 request / Hot links Message-ID: <4193@tekig5.PEN.TEK.COM> Date: 17 May 89 16:04:58 GMT References: <8905132203.AA27784@postgres.Berkeley.EDU> <17209@usc.edu> <24470@agate.BERKELEY.EDU> Organization: Tektronix Inc., Beaverton, Or. Lines: 36 In article <24470@agate.BERKELEY.EDU>, c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) writes: > In article <4182@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: > >So why not build a system like this: > > > >Amiga 3000 +===#################### > >---------- + # Page control RAM # > > + #################### > > ########### ####### ###################### ####### > > # CUSTOM #====# MMU #====# # ####### # # > > # CHIPS # ####### # Single Pool of RAM #=====# MMU #===# CPU # > > ########### # # ####### # # > > ###################### ####### > ^ > | > Wait States... ^^^^^^^^^^^^^ However if built right wait states could be avoided since: 1. Copper only accesses 1 out of 4 memory cycles at best 2. Blitter only accesses 1 out 2 memory cycles at best and it isn't real time anyway. 3. The Playfield DMA can run every cycle in high res. 16 color, but the memory it accesses is in order. 4. Sound and spirtes accesses are needed that often. So you did catch me, but maybe a "smart" MMU could do the job. I was thinking more on the idea of using the MMU as a page controller, controlling which pages of RAM the custom chips could use and wait staing the main CPU when using the same page as a custom chip is working on. The two MMU's would have to have a master/slave relationship where the CPU MMU is the slave. I'm glad to see that someone out there is awake! Wayne Knapp