roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (05/30/89)
In article <20149@winchester.mips.COM> mash@mips.COM (John Mashey) writes: > And while I'm at it, there are rumors on the > street of Chapter-11 time for Edgecore(?) (used to be Edge). Anybody > have any data on that one? My info is that Edgcore (formerly Edge until it ran afoul of Leading Edge) has cut back on its own complete system activities and will concentrate on supplying OEMers with high-performance 68k cpu subsystems. There's an interesting architectural > connection: Edge's business is selling very-high-end > 68K-compatible boxes built from (I think) CMOS gate arrays, i.e., > boxes OEMed to cover the high end of your line, if you're 68K-based. > (i.e., this is a strategy somewhat similar to NexGen's for the 386, > I think). Any postings of data might be useful. The high end of our P9000 series motorola based line (the P9600) uses the E2000 cpu. This machine is currently in the (final) alpha testing phase. Although we're the first large European company to bring an E2000 based system to market we will not be the only large European company to do this. In other words, rumours of Edgcores demise are - at the very least - premature/overly optimistic (depending on your point of view). Now for some data: The E2000 CPU runs at around 15-16 VAX mips sustained. We get about 4x performance improvement over our 25 Mhz 68030 model. The machine can currently support 96Mb physical memory (4 triple Euro 32 Mbyte boards) but can be configured to 1 Gbyte physical memory when the (4M) chips become available. The cpu is 68010 compatible but has a number of the more frequently used 68020 instructions on board e.g long divide and multiply, scaled index addressing. Binaries on our lower end models (compiled in 68010 mode) run unchanged on the P9600. Although we don't support it instruction emulation can be used to run full 68020 code. The cpu is dual-pipelined (4-stage instruction fetch pipeline/5-stage operand execution pipeline) which permits a risc-like average instruction time of about 1.4 cycles per instruction. Cycle time is 45 ns. Virtual addressing space is 4Gbyte per process. The system is scalable with up to 4 processors (although we currently support only 1). Each cpu has a 32K 2 set associative virtual instruction cache with 16 byte line, a 448K direct mapped physical operand cache (meant for process stacks) and a 64K 4 set associative physical operand cache. The operand caches use a copy-back strategy. The distributed hardware cache coherency protocol is totally hardware controlled. It also has a branch prediction unit which contains a branch cache for 4K entries and a 16 entry lifo return stack, which together support correct branch prediction over 90% of the time. The subsystem has two busses: a proprietary 64 bit bus with a bandwidth of 128 Mb/s and a 20 Mb/s VMEbus which supports a 68020 support processor (used for boot and debug activities). It can support up to 5 secondary i/o busses. This is how we use the system: basically we pull out the processor card out of one of our lower model computers drop in the secondary bus card which attaches to the E2000 subsystem (in a separate cabinet). The lower model computer now becomes a io cabinet. Using this technique we can field upgrade a system in under 30 minutes - hardware and software. The cpu is implemented using five 1.5 micron 50000 CMOS gate arrays on a triple euro board, the data caches are on a separate triple euro board together with the mmu which supports a subset of the 68030 mmu functionality. Most of this info can be found in an article in Electronics, September 3 1987. Disclaimer 1: Opinions are mine, for my employers you pay extra. Disclaimer 2: I am _not_ an (ex-)80386 designer and my name does _not_ appear on Rev 1.0 ;-). -- Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof
mash@mips.COM (John Mashey) (05/31/89)
In article <125@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes: >In article <20149@winchester.mips.COM> mash@mips.COM (John Mashey) writes: ... >There's an interesting architectural >> connection: Edge's business is selling very-high-end >> 68K-compatible boxes built from (I think) CMOS gate arrays, i.e., >> boxes OEMed to cover the high end of your line, if you're 68K-based. >> (i.e., this is a strategy somewhat similar to NexGen's for the 386, >> I think). Any postings of data might be useful. >In other words, rumours of Edgcores demise are - at the very least - >premature/overly optimistic (depending on your point of view). Good: one never knows about rumors, which is why I posted it... (It's hard for me to tell, since we don't really run into them, what's going on.) >Now for some data: Thanx! >The E2000 CPU runs at around 15-16 VAX mips sustained. Any chance you (or anybody) could post any benchmarks? This is of architectural interest, as I note, because it makes an interesting comparison of different implementation approaches of the same architecture. >We get about 4x performance improvement over our 25 Mhz 68030 model. >The machine can currently support 96Mb physical memory (4 triple Euro Must be 128MB! >32 Mbyte boards) but can be configured to 1 Gbyte physical memory when >the (4M) chips become available. ......more data..... Note that this is one of the first extant examples of building a more powerful top end beyond a widespread VLSI micro architecture. Others include the NexGen, the DG ECL 88K (both of which have articles in the Spring COMPCON, I think: maybe somebody would cite the articles, and maybe authors would care to summarize them?), the Prime ECL 486, and the PRISMA GaAs SPARC. This is in interesting trend, which is just the opposite of earlier efforts, i.e., people have often done VLSI CMOS versions of earlier supermini & mainframe architectures. [Maybe some citations from VAX-land, and, if possible, there's that new Unisys chip that fits into a PC/AT box, but runs their mainframe software.] -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (05/31/89)
In article <20752@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <125@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes: > >>The E2000 CPU runs at around 15-16 VAX mips sustained. >Any chance you (or anybody) could post any benchmarks? This is of architectural >interest, as I note, because it makes an interesting comparison of >different implementation approaches of the same architecture. > We're still twiddling around with one or two things in the OS to notch up performance so it'll be a while yet before we've got really proper benchmark results. Even then we don't expect to stray too much outside of the given range. Anyway some (but not all) of the marketing people breathing down our necks consider "faster than the previous model" to be a perfectly adequate performance description :-). >>The machine can currently support 96Mb physical memory (4 triple Euro >Must be 128MB! >>32 Mbyte boards) but can be configured to 1 Gbyte physical memory when >>the (4M) chips become available. Yes. My desk calculator confirms 4x32=128 and my doctor confirms slight brain damage. >Note that this is one of the first extant examples of building a more >powerful top end beyond a widespread VLSI micro architecture. > >This is in interesting trend, which is just the opposite of earlier efforts, >i.e., people have often done VLSI CMOS versions of earlier >supermini & mainframe architectures. But perhaps not a surprising trend. Even though an existing (cisc) architecture may not be able to offer the same performance as a newer (risc) architecture (using same real estate and process technology etc) it obviously can still be economically viable providing the existing (cisc) architecture represents compatibility (with previous models). With a little back-of-the-enveloping we might even be able to roughly quantify this. We estimate that in order to satisfy customer needs we should be looking at a perfomance doubling every 2 years or a factor of about 1.4 every year. This is like inflation. In other words, a 10 Mips machine available now offers the "same" performance (value form money) as a 14 Mips machine available over 1 year or a 12 Mips machine available over 6 months. In order to switch to a new processor in an existing environment, new tools (compilers,assemblers) and possibly a few new techniques (understanding code rearrangement for delay slot filling for example) must be mastered. Also various assembly files need to be rewritten. I estimate this (one time) extra developement effort and learning curve at 6 months extra lead time. Now what this means in the above calculation is that in our current development environment a 10 Mips compatible processor is equivalent to a 12 Mips incompatible one due to the extra lead time. There are of course other factors which stack in the favour of the existing architecture: - easier customer field upgradability, often as not the customer is willing to spend the money but not the time to upgrade. If s/he needs to recompile the motivation is that much less. Which means the existing machine will be replaced later rather than earlier. - the learning curve in the organization costs time. These costs are generally hidden however. - the availability of the machine is later possibly resulting in fewer total sales and thus a smaller recoup on investment. I'm talking intuitively but I'ld say that these effects at least double the effect of the longer lead time. In other words, an incompatible processor would have to offer at least 40-50% more performance for the same price before you even to start to think about a change over (in an environment like ours). Before I get flamed this is my estimate for our environment in which we have knowledge/hardware invested in an existing processor. Other environments may differ radically obviously if little existing knowledge/hardware is available. However I do think our environment is not atypical for those environments with existing models. Put another way if the existing (backwards compatible) cisc architecture implemenations can offer 60-70% of the performance of the newer risc architecture implementations for the same price they may be around for a while. Disclaimer: Opinions are my own, for my employers you pay extra. -- Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (06/01/89)
In article <20752@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >Note that this is one of the first extant examples of building a more >powerful top end beyond a widespread VLSI micro architecture. >This is in interesting trend, which is just the opposite of earlier efforts, I agree. I would like to make a request here- I think the time has come for micro people to consider mainframe architectural requirements. Some nice micros have come out in recent years which could have been extended to mainframe architectures except for various flaws which, if remedied, would have had little or no effect on the performance or usability as micros. Next time, while designing a new architecture, ask if anything will stop you from building a high performance implementation with: a clearly and completely defined instruction set architecture support for a large number of processors in a symmetric arrangement separate caches for each processor a high bandwidth multi-port multi-bank central memory high bandwidth I/O provable encapsulation/virtualization It is my belief that adding the above would cost little, but would buy potential customers a great deal. I note that some recent micros my indeed be capable of all of the above, but not all of them do. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
mash@mips.COM (John Mashey) (06/01/89)
In article <126@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes: .... >I'm talking intuitively but I'ld say that these effects at least double >the effect of the longer lead time. In other words, an incompatible processor >would have to offer at least 40-50% more performance for the same price before >you even to start to think about a change over (in an environment like ours). Our general rule-of-thumb is that: 10% is uninteresting 50% is interesting to lots of people, although not others 100% is interesting enough to make people take serious risks 1000% is uninteresting to some people (really!), i.e. compatibility is everything. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
aglew@mcdurb.Urbana.Gould.COM (06/01/89)
>>> connection: Edge's business is selling very-high-end >>> 68K-compatible boxes built from (I think) CMOS gate arrays, i.e., >>> boxes OEMed to cover the high end of your line, if you're 68K-based. >>> (i.e., this is a strategy somewhat similar to NexGen's for the 386, >>> I think). Any postings of data might be useful. > >>32 Mbyte boards) but can be configured to 1 Gbyte physical memory when >>the (4M) chips become available. >......more data..... > >Note that this is one of the first extant examples of building a more >powerful top end beyond a widespread VLSI micro architecture. >Others include the NexGen, the DG ECL 88K (both of which have articles >in the Spring COMPCON, I think: maybe somebody would cite the articles, >and maybe authors would care to summarize them?), the Prime ECL 486, >and the PRISMA GaAs SPARC. > >This is in interesting trend, which is just the opposite of earlier efforts, >i.e., people have often done VLSI CMOS versions of earlier >supermini & mainframe architectures. [Maybe some citations from VAX-land, >and, if possible, there's that new Unisys chip that fits into a PC/AT box, >but runs their mainframe software.] Actually, isn't the Alliant non-vector instruction set a Motorola 68K take-off? Or am I giving still more evidence of my faulty memory?
jmoore@Solbourne.COM (Jim Moore) (06/01/89)
In article <20804@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: > In article <126@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes: > .... > >I'm talking intuitively but I'ld say that these effects at least double > >the effect of the longer lead time. In other words, an incompatible processor > >would have to offer at least 40-50% more performance for the same price before > >you even to start to think about a change over (in an environment like ours). > > Our general rule-of-thumb is that: > 10% is uninteresting > 50% is interesting to lots of people, although not others > 100% is interesting enough to make people take serious risks > 1000% is uninteresting to some people (really!), i.e. > compatibility is everything. > -- Sounds like it has gotten a bit easier to sell performance in the last few years. I remember when I first went to work for MIPS in 1985, trying to sell a 250% performance improvement (and that was just integer, FP was even better) was a difficult chore. The 5 VUP MIPS product was being sold against the 2 VUP 68020. But in 1985, we not only had to sell performance, we had to sell the idea that a RISC architecture was a good thing. Fortunately, *every* microprocessor introduced since 1985 is based on RISC*, so that is not a missionary sell any longer. * just ask the marketing folks Jim Moore Solbourne Computer, Inc. {sun,boulder,nbires}!stan!jmoore OR jmoore@solbourne.com
mat@uts.amdahl.com (Mike Taylor) (06/01/89)
In article <26207@ames.arc.nasa.gov>, lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: > I agree. I would like to make a request here- I think the time has come > for micro people to consider mainframe architectural requirements. Some > nice micros have come out in recent years which could have been extended > to mainframe architectures except for various flaws which, if remedied, would > have had little or no effect on the performance or usability as micros. > > Next time, while designing a new architecture, ask if anything will stop you > from building a high performance implementation with: > > a clearly and completely defined instruction set architecture > support for a large number of processors in a symmetric arrangement > separate caches for each processor > a high bandwidth multi-port multi-bank central memory > high bandwidth I/O And support for high availability - error detection and recovery. yes, much of that is implementation but it must be supported by the proper architectural definition. And support for high multiprogramming levels - without getting into the wars about how long it takes to save registers (not very) - the effect on caches, TLBs, etc. is far more relevant. And support for continuous operation - dynamic change to system configuration. And support for multilevel memory hierarchies - possibly processors cache, global cache, main storage, bulk RAM. And support for performance measurement and system management. We could start a whole new debate - what is a mainframe? We make them but I'm not sure that there is a well-understood definition. -- Mike Taylor ...!{hplabs,amdcad,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]
peter@ficc.uu.net (Peter da Silva) (06/01/89)
The problem was that in 1985 people didn't believe your 250% improvement, and now they do. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
rec@dg.dg.com (Robert Cousins) (06/02/89)
In article <26207@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >I would like to make a request here- I think the time has come >for micro people to consider mainframe architectural requirements. Some >nice micros have come out in recent years which could have been extended >to mainframe architectures except for various flaws which, if remedied, would >have had little or no effect on the performance or usability as micros. THis is true. It is amazing the number of "state of the art" processors with migration difficulties on the market today. The lack of scoreboarding has been discussed here. Other important features include: Multiprocessor support The ability to use 4 gigabytes of virtual memory (without cludging the software around) The ability to use 4 gigs of physical memory (without cludging the software around) >Next time, while designing a new architecture, ask if anything will stop you >from building a high performance implementation with: >a clearly and completely defined instruction set architecture >support for a large number of processors in a symmetric arrangement >separate caches for each processor >a high bandwidth multi-port multi-bank central memory >high bandwidth I/O >provable encapsulation/virtualization >It is my belief that adding the above would cost little, but would buy >potential customers a great deal. I note that some recent micros my >indeed be capable of all of the above, but not all of them do. True there are many guilty here. THis is why DG chose the 88K. It supports these issues directly. However, not many others do. > Hugh LaMaster, m/s 233-9, UUCP ames!lamaster > NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov > Moffett Field, CA 94035 > Phone: (415)694-6117 Robert Cousins Dept. Mgr, Workstation Dev't. Data General Corp. Speaking for myself alone.
slackey@bbn.com (Stan Lackey) (06/02/89)
In article <28200326@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes: >>Note that this is one of the first extant examples of building a more >>powerful top end beyond a widespread VLSI micro architecture. >>This is in interesting trend, which is just the opposite of earlier efforts, >>i.e., people have often done VLSI CMOS versions of earlier >>supermini & mainframe architectures. [Maybe some citations from VAX-land, >Actually, isn't the Alliant non-vector instruction set a Motorola 68K take-off? It sure is! 68020 except for callm-rtm. We set out to do 68881 compatibility as well, but ended up doing a proprietary scalar FP architecture for implementation reasons. Memory management is a subset of the 68420 (sp?) MMGT chip. -Stan
les@unicads.UUCP (Les Milash) (06/02/89)
Roelof Vuurboom wrote: >With a little back-of-the-enveloping we might even be able to roughly >quantify this. ^^^^^^^^ raising it from an art to a science! > >We estimate that [...] to satisfy customer needs we [need] >at a perfomance doubling every 2 years or a factor of about 1.4 every >year. This is like inflation. In other words, a 10 Mips machine available >now offers the "same" performance (value form money) as a 14 Mips machine >available over 1 year or a 12 Mips machine available over 6 months. >[etc] >[...] a 10 Mips compatible processor is equivalent to >a 12 Mips incompatible one due to the extra lead time. Mr. Mashey wrote: Our general rule-of-thumb is that: 10% is uninteresting 50% is interesting to lots of people, although not others 100% is interesting enough to make people take serious risks 1000% is uninteresting to some people (really!), i.e. compatibility is everything. (never get tired of hearing what that guy has to say) I write: although this is probably label-able as "marketing", i must confess that this kind of stuff is exciting for me to read. it kind of reminds me of Daniel (connection machine) Hillis's approach to multiprocessing: "forget the 4 processor model. forget the .5u CMOS model. examine the limit as N->infinity, and as processor size goes towards 0. conway&mead's book worked like this, somewhat; extracting the overall patterns from the physics. i've been tagged as ivory-tower-ish cause i "can't tell what's good enough". well it's great to have that finally quantizable, not that i take your numbers as the gospel, but approximately. i mean, aint' it true that lots of arch decisions--well maybe not "arch" but "computer design"--are like "do we wait for the -30 or build in the -20 now?". i generally "hate marketing stuff" too, but if/when market acceptance is key to whether or not you're copmpany will be around till generation 2 is done, or if i'm gonna predict whether joe businessman will put up with a water-cooled lotus123 accelerator under his mahogany desk, i have to know these things. it seems that engineering is "meeting needs with max !/$. if i'm tryna decide to include part X vs part Y then relative !/$ is ok but if i have a new idea then absolute benefit vs. hassle is what counts. so maybe we can grade fabrication lines or semi houses in terms of their bang-per-buck time constant. if they can't keep up with "inflation", don't go with their gate arrays, cause then your product will get buried, as t->infinity. just joking, but concievably not. i never thought i'd argue FOR keeping marketing stuff in comp.arch (that sure wasn't what motivated me to press the "F" key, just excitement at the data). ---------------------------------------------------------- Spelling brought to you by Tanqueray. R. Stein was right. ----------------------------------------------------------
pechter@scr1.UUCP (Bill Pechter) (06/02/89)
In article <28200326@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes: > >Actually, isn't the Alliant non-vector instruction set a Motorola 68K take-off? >Or am I giving still more evidence of my faulty memory? No ECC error there -- the Alliant uses the 68020 instructions in their Computational Elements. They also use 68012 and 68020's as their IP's (front end processors). This is based on my time at Alliant 2 years ago. Things may have changed since then but the FX/1 and FX/8 were 68020-ish. -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Usenet . . . rutgers!pedsga!tsdiag!scr1!pechter ** MS-DOS is CP/M on steroids, bigger bulkier and not much better **
bcase@cup.portal.com (Brian bcase Case) (06/05/89)
> Multiprocessor support > > The ability to use 4 gigabytes of virtual memory (without > cludging the software around) > > The ability to use 4 gigs of physical memory (without > cludging the software around) Robert (and anyone else), could you post something short that gives examples of the software kludges needed? >>Next time, while designing a new architecture, ask if anything will stop you >>from building a high performance implementation with: > >>a clearly and completely defined instruction set architecture >>support for a large number of processors in a symmetric arrangement >>separate caches for each processor >>a high bandwidth multi-port multi-bank central memory >>high bandwidth I/O >>provable encapsulation/virtualization >>It is my belief that adding the above would cost little, but would buy >>potential customers a great deal. I note that some recent micros my >>indeed be capable of all of the above, but not all of them do. Hugh (and anyone else), could you post a short summary of architectures that don't have the above? E.g., what is (and isn't) a clearly- and completely-defined ISA?
mlord@bnr-rsc.UUCP (Mark Lord) (06/06/89)
In article <184@dg.dg.com> uunet!dg!rec (Robert Cousins) writes: >In article <26207@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: > >>a clearly and completely defined instruction set architecture > >True there are many guilty here. THis is why DG chose the 88K. It >supports these issues directly. However, not many others do. > Alright.. enough gloating. Not even the latest hot-rod from Moto meets this requirement. There are a large number of instructions which can be encoded differently by varying the numerous "don't care" bits in the instruction words. This isn't exactly the most "clearly and completely defined instruction set" around (mind you, it really looks okay on several other points). -Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: Aliens from Mars made me post this! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wcs) (06/07/89)
In article <125@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes:
]My info is that Edgcore (formerly Edge until it ran afoul of Leading Edge)
Sigh. The names aren't really that close that Dell should
go rip off somebody's good name.
]Now for some data:
]The E2000 CPU runs at around 15-16 VAX mips sustained.
]We get about 4x performance improvement over our 25 Mhz 68030 model.
]The machine can currently support 96Mb physical memory (4 triple Euro
]32 Mbyte boards) but can be configured to 1 Gbyte physical memory when
]the (4M) chips become available.
My Motorola sales rep has been claiming 5 MIPS for a 25 MHz
68030 VME board, and predicts 15 MIPS for the 68040 in the fall
(presumably at 33 MHz?) Will Edge be doing a performance
upgrade similar to that? Or will the 68040 kill them?
] [nifty & large cache stuff ]
]The subsystem has two busses: a proprietary 64 bit bus with a bandwidth of
]128 Mb/s and a 20 Mb/s VMEbus which supports a 68020 support processor (used
Moto's 68030 boards use VSB or one of the other VME-offloader
memory busses, with VME for generic I/O. Doesn't need a 68020 helper.
The higher-performance boards have cache and memory on the
card, but have had to push SCSI and Ethernet off-board
because they need the real estate.
]The cpu is implemented using five 1.5 micron 50000 CMOS gate arrays on a
]triple euro board, the data caches are on a separate triple euro board
]together with the mmu which supports a subset of the 68030 mmu functionality.
--
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
# also cloned at 201-271-4712 tarpon.att.com!wcs
# ... counting stars by candle light ....