Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amiga!boing!dale From: dale@boing.UUCP (Dale Luck) Newsgroups: comp.sys.amiga Subject: Re: Hard drive & chip contention Message-ID: <689@boing.UUCP> Date: 26 Mar 89 18:57:43 GMT References: <8903071906.AA01731@jade.berkeley.edu> <796@zehntel.UUCP> <11072@pasteur.Berkeley.EDU> Reply-To: dale@boing.UUCP (Dale Luck) Organization: Boing, Milpitas, Ca. Lines: 54 In article <11072@pasteur.Berkeley.EDU> c152-cb@cory.Berkeley.EDU.UUCP (Vince Lee) writes: >In article <796@zehntel.UUCP> donw@zehntel.UUCP (Don White) writes: >>In article <8903071906.AA01731@jade.berkeley.edu> GIGUERE@WATCSG.BITNET (Eric Giguere) writes: >>>The local Amiga dealer here is very reluctant about selling me a SCSI >>>drive for my 2000 because he claims that anything more than 2 bitplanes >>>causes mucho contention between the drive and the Amiga's graphics chips >> >> The SCSI interface has NOTHING TO DO WITH THE GRAPHIC CHIPS!!!! >> >> I don't know where your dealer heard this, but is false. There may have >> been something wrong with the SCSI (broken, misjumpered, whatever). But >> there is NO INHERENT problem with using one in an amiga. > >Well, your dealer is wrong, but I think i know where he is coming from. the >problem lies not in scsi itself, but in commodore's 4090a scsi controller. >The 4090a is dma. In a hires 4-plane screen, or other graphically intense >display, there aren't enough dma slots left for the controller to do decent >dma. I believe (correct me if i am wrong) that there is a flaw in the current >driver software which causes the data to queue up incorrectly b/c of this. > >Anyway, there is no problem with scsi using other 3-rd party non-dma >controllers such as gvp. They're also cheaper, but most will not handle >st506 drives. If you don't need st506 drives, i would go ahead with one of >them. The problem lies in the way the Zorro bus is designed. One would think that as long as you are only dma'ing into real fast memory, (not the 512k of fake stuff in a 2000) one would never have bandwidth problems since the graphics chips are restricted to access the 512k of chip memory and the two kinds of memory are on separate buses. Well this is true in theory, however the expansion bus arbitration logic is a little state machine inside the 68000. This is where the problem lies. If the the 68000 itself tries to access chip memory, or needs to get on the chip bus and is held off because graphics chips are doing there thing, then that bus arbitration logic gets locked up to. Along comes a dma request to the expansion bus from some dma board that wants to write a byte or a word to some memory on the expansion bus. But what happens? The 68000 state machine is what grants the request to get on/off the expansion bus but it is busy screwing around with a wait trying to get a chip memory! The result? If the 68000 needs to access the chip bus, the expansion bus ends up being help up when ever the 68000 is wait stated. So when you have dma cycles soaked up by the display refresh or the blitter running full bore you cause the expansion bus to lose cycles whenever the 68000 or 68020 stops while waiting for chip memory cycles. I hope they can correct this in the 3000 and have a separate bus arbitration circuit for the expansion bus. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale