Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: New Stuff...
Message-ID: <17292@cbmvax.commodore.com>
Date: 9 Jan 91 19:04:02 GMT
References: <2442@lpami.wimsey.bc.ca> <2253@shodha.enet.dec.com>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 32

In article <2253@shodha.enet.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes:
>In article <2442@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>>In <1038.277C32DA@weyr.FIDONET.ORG>, David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) writes:
>>>And another... why doesn't the A590 provide a pass through?

>>Adding a pass through would violate the spec that CBM mandates for the 
>>expansion connector.

>Just to clarify the point about violating specs.  I'm pretty sure that
>passing the bus through wouldn't necessarily be violating the spec.

Well, you can ask for trouble one way or another.  If you buffer the pass-
through, you have a good chance at voilating the timing parameters expected
by the next SOTS box.  If you don't buffer the passthrough, you'll definitely
violate the bus loading.  There's no proper way to support passthrough.  If
you want more than one add-on, get a machine with a backplane (or add one
to your SOTS edge machine).

>Buffers and associated logic, plus connector and FCC problems make it a 
>fairly expensive proposition.

FCC problems do, certainly, increase with any passthrough.

>>-larry

>  Hans-Gabriel Ridder			Digital Equipment Corporation

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"Don't worry, 'bout a thing. 'Cause every little thing, 
	 gonna be alright"		-Bob Marley