Path: utzoo!attcan!uunet!samsung!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga.tech Subject: Re: Bus Latency Keywords: bus dma latency Message-ID: <128120@sun.Eng.Sun.COM> Date: 19 Nov 89 23:30:34 GMT References: <322@blenheim.nsc.com> <128061@sun.Eng.Sun.COM> <329@berlioz.nsc.com> Sender: news@sun.Eng.Sun.COM Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 60 In article <329@berlioz.nsc.com> waggoner@dtg.nsc.com (Mark Waggoner) writes: >I am not sure I understand all of this. Some questions: >(Perhaps I should RTFM) A good suggestion, the Hardware manual for the Amiga is excellent. > 1. Can the CPU be locked out of chip memory for long periods of > time? I thought it alternated cycles with the video dma. It works this way. There are several things that want bus cycles in the Amiga. The Custom chips, the CPU, and the peripherals. There is a great chart that shows what gets what, but basically the video gets the odd cycles and the CPU/CustomChips/Peripherals get the even cycles except during VBLANK and HBLANK when video doesn't need them. So yes, the CPU is on the alternate cycle but it shares those alternate cycles with other things. > If it DOES NOT alternate cycles and can be locked out of chip memory, > then "fast" memory is indeed fast only in that you can perform your > dma bursts faster. Also there is a problem where the CPU can grab the bus in an attempt to get to something in CHIP ram and block access to the expansion RAM so that in some cases you just loose period. I haven't looked real closely at the bus timing for the 500/2000 though so this may not be a problem any more. > 2. When a peripheral is dma'ing to/from chip memory, what > restrictions are placed on it in terms of burst size. Can it use > consecutive cycles? How is this handled? Peripherals get low DMA priority, when someone else wants the bus (like Agnus so she can stuff some bits into Denise) you lose it and have to wait. > 3. 14 mS of latency is a VERY long time. Doesn't this mean that > almost any peripheral will have to have local buffer ram? Take > Ethernet, for example (something I can talk about without getting > too confused). In 14ms, you could receive > 14mS / (800nS/byte) = 17500 bytes of data. > Of course, this is neglecting the fact that you shouldn't get packets > that big and packets can't come back to back. But still, there is no > way you could ever count on getting hold of the system bus in time to > buffer a packet unless you had either a FIFO or local memory big > enough to hold at least 20K. This makes peripherals much more > expensive. Could you even transfer 20K over to the system memory > in the time between video frames? (OK, so you aren't likely to > get a burst of packets like that, but it IS possible). A) You can get packets "back to back", and B) a 32K X 8 static RAM chips is only $10 and comes in a nice compact 28pin skinnydip. But that aside, you can do like 3Com did on their early boards and provide just enough ram for 1 packet (2K) and drop any that come in when you can't buffer them. This works because the protocols allow for lost packets but it does cut down on your efficiency. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"