Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!unisoft!mtxinu!taniwha!paul From: paul@taniwha.UUCP (Paul Campbell) Newsgroups: comp.arch Subject: Re: ACE (Was Re: Will NeXT survive? Grow with the times?) Message-ID: <865@taniwha.UUCP> Date: 8 Jun 91 07:33:49 GMT References: <11399@uwm.edu> <32580026@hpcuhe.cup.hp.com> <4638@batman.moravian.EDU> <22152@cbmvax.commodore.com> <863@taniwha.UUCP> <22236@cbmvax.commodore.com> Reply-To: paul@taniwha.UUCP (Paul Campbell) Organization: Taniwha Systems Design, Oakland Lines: 55 In article <22236@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <863@taniwha.UUCP> I wrote: >>Yeah, they do both, the basic bus is a 12.5MHz NuBus (12.5/25 is a 'nice' >>number if you have a 25MHz CPU - everything is synchronous) - they have a >>special burst mode which is clocked at 25MHz - the bus has 2 clocks 12.5/25. >OIC. So this is a special mode over and above the NuBus "block transfer". I think from memory that NextBus just doubles it's burst rates, I don't think it supports 'normal' NuBus burst transfers >>NuBus 90 has picked up the Next clocking/burst scheme (it is a nice design) >>and added it to existing NuBuses at 10/20MHz (for compatability). > >I had read something about an enhanced NuBus being supported by Apple some time >in the future, but I had no idea where it came from. So this clocking scheme >is fully upward compatible and all? Sounds like a pretty cool solution. And I don't think Apple have announced any NuBus 90 Macs - but they were heavily involved in the NuBus 90 effort. Yes they stole some of the -5v (ie ECL) power lines that no one ever used and turned them into a new clock (20MHz) and some controll lines - it supports all the current transfers as well as the new double speed burst transfers (and a way to drop back to the slow modes if the remote board doesn't speak the new ones) and a few other things such as an optional cache coherency protocol, a serial bus etc etc - they also did some minor bug fixes to the original spec. >>Next solve this by driving everything with the CMOS driver ICs, having short >>backplanes and requiring the driver/controller chips to be physically right >>next to the bus. The also terminate it so that it gets exactly one reflection >>within the bus settling time. > >Sounds about right. I stayed away from CMOS buffers on the Amiga 3000 bus >(though some of the signals are driven by a CMOS ASIC), mainly for speed >concerns, though I was also worried about noise. We had to stay with TTL >levels for compatibility reasons, but the buffer drive, speed, and backplane >termination was chosen for support of the 32 bit bus. Nowadays, with FCT >and ACTQ parts being pretty common, even in the relatively weird types like >74x646, I'll probably use TTL-level CMOS buffers in the future. Though I >just got some samples of these new "FR" parts.... Well Next went CMOS, NuBus 90 of course has to stay with the same old drivers so that all the existing cards still work OK - besides we have bigger backplanes etc etc. Paul Campbell -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Tom Metzger's White Ayrian Resistance has been enjoined to stop selling Nazi Bart Simpson t-shirts - Tom of course got it wrong, Bart is yellow, not white.