GIGUERE@WATCSG.BITNET (Eric Giguere) (03/08/89)
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 and so he doesn't recommend it. *Sigh* Everyone I've talked to has recommended SCSI. So, how accurate is the dealer's assessment? Someone mentioned the contention problem on the net a couple of days ago, but how bad is it and when exactly does it occur? This is assuming we're using a SCSI drive with a 2090A controller. And I wonder why so few Amiga users have hard disks... Eric Giguere Computer Systems Group, University of Waterloo BITNET: GIGUERE@WATCSG Other: giguere@watcsg.UWaterloo.CA UUNET : watcsg!giguere@uunet.UU.NET
carpent@coltrane.SRC.Honeywell.COM (Todd Carpenter) (03/08/89)
"Bah!" I say. I have a spanking new 2000, with a A2090a screaming happily along, attached to a 206MB Rodime (experimental) 12msec, 12 MHz, SCSI hard disk. Yes, I'll admit that when I load in high res screens that life slows down somewhat. Big deal? There are so many workarounds to this, including loading it to a different screen, or having a lo-res screen in front, that complaining about it is worthless. Sure, it *would* be nice to see no slow down. But the 2090a is so incredibly fast the rest of the time, that it doesn't really matter. Perhaps if you were doing animation, and had to constantly display high res AND page/swap/load from disk, you may be annoyed. Aside from that, I don't understand the problem. Besides, what else would you do? I don't think you can use the bus by more than one device at a time, and I don't think the memory is dual ported, nor are there dual buses. (Sarcasm? No.) So (correct me if I'm wrong), you really can't get much better. Something has to degrade somewhere. I doubt the problem is inherent to SCSI, as your dealer seems to claim. The 2090a can support 7 SCSI, and 2 st506 drives. I found it trivial to install, and have had absolutely NO software problems. Looking around, I found the price ($330ish) competitive for the power I was getting. Tell your dealer he's full of hooey, and get the controller.
donw@zehntel.zehntel.com (Don White) (03/11/89)
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 >Eric Giguere The SCSI interface has NOTHING TO DO WITH THE GRAPHIC CHIPS!!!! Your local dealer is a bozo. (And I am being gentle. 1/2 ;-) ) 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. Don White Box 271177 Concord, CA. 94527-1177 zehntel!donw
c152-cb@cory.Berkeley.EDU (Vince Lee) (03/15/89)
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.
Bruce_Eric_Bowers@cup.portal.com (03/21/89)
I've read the discussion about the A2090A with interest, as I am planning to buy a A2500 or A2000HD soon. What are the symptoms of the contention problem? Is it just slower disk access time, slower disk *and* slower screen updates, glitchy screen :-(, hung machine :-( :-( ? What types of screen displays cause how much of a problem? (IE, does the problem get better and worse depending on the display mode, or is it no problem at all until its a big problem? (Is it every a *big* problem?)) I would consider an A2000 with a third party hardcard, but those package prices for the 2000HD and 2500 make it awfully tempting (especially the 2500). As always, thanks to everyone for any information offered!
drz@csri.toronto.edu (Jerry Zarycky) (03/24/89)
In article <16061@cup.portal.com> Bruce_Eric_Bowers@cup.portal.com writes: > > >I've read the discussion about the A2090A with interest, as I am planning >to buy a A2500 or A2000HD soon. What are the symptoms of the contention >problem? Is it just slower disk access time, slower disk *and* slower >screen updates, glitchy screen :-(, hung machine :-( :-( ? > The symptoms are VERY SLOW disk access time. I've only had these problems with static screens (not that animation would help :-)). >What types of screen displays cause how much of a problem? (IE, does I believe that any 640x200 or 640x400 display with 4 bit-planes is guaranteed to cause a problem. >the problem get better and worse depending on the display mode, or is >it no problem at all until its a big problem? (Is it every a *big* >problem?)) > There is no problem until there is a problem, and EVERY problem is a BIG problem. When one of these screens comes up, a picture that would take a few (< 5) seconds to load, now takes MINUTES to load, with the hard disk controller LED on SOLID, with the drive making a steady noise. (To be fair, I'm not sure how many minutes it takes to load, since I abort it before it has a chance to finish). >I would consider an A2000 with a third party hardcard, but those package >prices for the 2000HD and 2500 make it awfully tempting (especially the >2500). Flipping to a "normal" screen via the screen to back/to front gadgets will cause the transfer to complete quickly, but this is a pain to have to do all the time, and could be EXTREMELY frustrating if the screen you are on has no such gadgets. All in all, when you are demoing a program which uses this type of screen (Professional Page, I think) to some potential Amigaphile and he sees the contortions you have to go through to load a file, he may be sufficiently turned off. ("How come you have to flip to another screen to load/save a file????", he asks). Apparently, this problem can be minimized if you have real FAST RAM (i.e. non-CHIP RAM), but the standard computer won't come that way. > >As always, thanks to everyone for any information offered! You're welcome. ^ | spelled correctly! Jerry Zarycky Usenet: {uunet,watmath}!csri.toronto.edu!drz CSNET: drz@csri.toronto.edu EAN: drz@csri.toronto.cdn BITNET: drz@csri.utoronto
carpent@coltrane.SRC.Honeywell.COM (Todd Carpenter) (03/24/89)
[I have never seen evidence of this mythical line e In article <8903232240.AA05683@yorkville.csri.toronto.edu> drz@csri.toronto.edu (Jerry Zarycky) writes: | In article <16061@cup.portal.com> Bruce_Eric_Bowers@cup.portal.com writes: | > | [asks about 2090a slow down due to high res screens] | > | | >What types of screen displays cause how much of a problem? (IE, does | | I believe that any 640x200 or 640x400 display with 4 bit-planes | is guaranteed to cause a problem. | | [stuff] | | There is no problem until there is a problem, and EVERY problem | is a BIG problem. When one of these screens comes up, a picture | that would take a few (< 5) seconds to load, now takes MINUTES to load, | with the hard disk controller LED on SOLID, with the drive making a | steady noise. (To be fair, I'm not sure how many minutes it takes to | load, since I abort it before it has a chance to finish). | [stuff] Bull! Excuse me, but I've been viewing *lots* of 640x400 pictures, overscan, and others. NO WAY does this cause slowdown on the order of minutes. You have some screwy software, I think. Yes, I get slowdown. Probably about a factor of 2 to 5, at MAX. I never exactly timed it but, I get a load of a high res screen in less than one second. If there is already a high res picture up there, and I load in another, it is maybe 3 - 5 seconds. I have a *fast* disk. Other disks may not be able to handle the rate. But I would think that would make the problem *less* apparent. My A2090a is relatively new (about 3 months old? I forget). But I doubt it has the new ROMs in it. Perhaps your memory is fragmented, and you are seeing garbage collection effects? Or something? (Ouch! Geez, these keys get hot!)
dale@boing.UUCP (Dale Luck) (03/27/89)
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
poirier@giants.dg.com (Charles Poirier) (03/28/89)
In article <19314@srcsip.UUCP> carpent@coltrane.SRC.Honeywell.COM (Todd Carpenter) writes: >In article <8903232240.AA05683@yorkville.csri.toronto.edu> drz@csri.toronto.edu (Jerry Zarycky) writes: >| There is no problem until there is a problem, and EVERY problem >| is a BIG problem. When one of these screens comes up, a picture >| that would take a few (< 5) seconds to load, now takes MINUTES to load, >| with the hard disk controller LED on SOLID, with the drive making a >| steady noise. (To be fair, I'm not sure how many minutes it takes to >| load, since I abort it before it has a chance to finish). >| [stuff] > >Bull! Excuse me, but I've been viewing *lots* of 640x400 pictures, overscan, >and others. You haven't said if your pictures are 4 bitplanes or not. This is an essential ingredient. I'll grant, though, they probably are 4 planes. > NO WAY does this cause slowdown on the order of minutes. You have >some screwy software, I think. Yes, I get slowdown. Probably about a factor >of 2 to 5, at MAX. I never exactly timed it but, I get a load of a high >res screen in less than one second. If there is already a high res picture up >there, and I load in another, it is maybe 3 - 5 seconds. I timed it. A 27Kbyte, 640 x 400 x 4 image loads into DPaintII in 4.5 seconds with Workbench in front, or in 45 seconds with DPaintII in front. Extrapolate to a more complex (less compressed) image and that easily enters the "minutes" realm. >I have a *fast* disk. Other disks may not be able to handle the rate. But I >would think that would make the problem *less* apparent. Not so. The problem is that the disk overruns the 2090's tiny little buffer. The faster the disk, the more likely the overrun. Case in point, my older Miniscribe (68 ms) drive had no noticeable problem, but my Quantum Q280 (28 ms) has the abovementioned severe problem. BTW, I am using a 2090 not a 2090A, but I was assured the buffer sizes are equal. Given that some people with fast drives are having little trouble, it seems that the amount of slowdown depends on the detailed timing of the drive and not just its "average" speed. >Perhaps your memory is fragmented, and you are seeing garbage collection >effects? Or something? No. A) It works identically bad from a cold, unadorned boot. (^D as soon as disk is accessable) B) The Amiga (the sans MMU version anyway) does not page, swap, thrash, or garbage collect. C) If you meant the disk is fragmented, I think that's not it either. Cheers, Charles Poirier
poirier@giants.dg.com (Charles Poirier) (03/28/89)
In article <689@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > I hope they can correct this in the 3000 and have a separate bus >arbitration circuit for the expansion bus. Is there any chance of designing a retrofit of such a separate arbitration circuit for existing 2000's? Cheers, Charles Poirier
poirier@giants.dg.com (Charles Poirier) (03/28/89)
In article <689@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >The problem lies in the way the Zorro bus is designed. ... > I hope they can correct this in the 3000 and have a separate bus >arbitration circuit for the expansion bus. Is there any chance of retrofitting existing 2000's with such a separate circuit? Charles Poirier
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (03/28/89)
> Not so. The problem is that the disk overruns the 2090's tiny little buffer. > The faster the disk, the more likely the overrun. Case in point, my older > Miniscribe (68 ms) drive had no noticeable problem, but my Quantum Q280 > (28 ms) has the abovementioned severe problem. BTW, I am using a 2090 not Ahhh, this make sense. With a 2090 and the latest drive software and my CDC Wren III, I never could get a 4-bitplane DPaint picture to load, no matter how long I waited---even if I pulled the DPaint screen 90% of the way down. Thanks for clearing that up! -tom
dougp@sbphy.ucsb.edu (03/28/89)
>In article <689@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:
[stuff about how bus contention is handled in fast ram deleted]
Wouldn't things be improved if you had real fast ram at 0xC00000
instead of slowfast ram like the 2000 currently has? This would
put most of the OS structures and code in real "fast" ram, then
the 68000 would be less likely to be tring to access ram which
the bus arbitrator thinks is chip ram, and less likely to get
stuck waiting for the chips to finish.
So if, when the new chips come out and the slowfast 0xC00000 ram
becomes chip ram, you buy a 1 meg 0xC00000 fast ram board, will
disk reads while displaying 640 wide 16 color screens be closer
to normal speed?dleigh@hplabsz.HPL.HP.COM (Darren Leigh) (03/30/89)
In article <4573@xyzzy.UUCP> poirier@dg-rtp.dg.com (Charles Poirier) writes: >In article <19314@srcsip.UUCP> carpent@coltrane.SRC.Honeywell.COM (Todd Carpenter) writes: >>In article <8903232240.AA05683@yorkville.csri.toronto.edu> drz@csri.toronto.edu (Jerry Zarycky) comments on hd slowness while displaying graphics screens: >>Bull! Excuse me, but I've been viewing *lots* of 640x400 pictures, overscan, >>and others. > >You haven't said if your pictures are 4 bitplanes or not. This is an essential >ingredient. I'll grant, though, they probably are 4 planes. > >> NO WAY does this cause slowdown on the order of minutes. You have >>some screwy software, I think. Yes, I get slowdown. Probably about a factor >>of 2 to 5, at MAX. I never exactly timed it but, I get a load of a high >>res screen in less than one second. If there is already a high res picture up >>there, and I load in another, it is maybe 3 - 5 seconds. > >I timed it. A 27Kbyte, 640 x 400 x 4 image loads into DPaintII in 4.5 seconds >with Workbench in front, or in 45 seconds with DPaintII in front. Extrapolate >to a more complex (less compressed) image and that easily enters the "minutes" >realm. My system, for reference: B2000, 2090A, 1.3, Quantum Pro 80s I just did some timings with Butcher. I consistently load a 640x400x4 image (while displaying one) in about twelve seconds. Writing one takes substantially longer (about 90 seconds). The file is 102078 bytes long. What's really weird is that things didn't used to go this fast. I had some hard disk problems a while ago and ended up reformatting my entire drive and changing some things. Before then, image loads used to take forever so I was quite pleased when they went faster after the reformat (etc.). If anyone's really interested in exactly what I changed, send me mail. Diskperfa w/ workbench in front: File create/delete: create 16 files/sec, delete 52 files/sec Directory scan: 102 entries/sec Seek/read test: 119 seek/reads per second r/w speed: buf 512 bytes, rd 84562 byte/sec, wr 29127 byte/sec r/w speed: buf 4096 bytes, rd 238312 byte/sec, wr 163840 byte/sec r/w speed: buf 8192 bytes, rd 327680 byte/sec, wr 218453 byte/sec r/w speed: buf 32768 bytes, rd 524288 byte/sec, wr 291271 byte/sec Diskperfa w/ 640x400x4 image in front: File create/delete: 1 create files/sec, 6 delete files/sec Directory scan: 44 entries/sec Seek/read test: 28 seek/reads per second r/w speed: buf 512 bytes, rd 18460 byte/sec, wr 9637 byte/sec r/w speed: buf 4096 bytes, rd 22995 byte/sec, wr 12542 byte/sec r/w speed: buf 8192 bytes, rd 2449 byte/sec, wr 1105 byte/sec r/w speed: buf 32768 bytes, rd 2085 byte/sec, wr 2007 byte/sec So we do take a substantial hit when displaying hi-res 4 bit deep images, especially with large buffer sizes. Since the buffer size is so critical, apparent disk speeds will be application dependent. >>I have a *fast* disk. Other disks may not be able to handle the rate. But I >>would think that would make the problem *less* apparent. > >Not so. The problem is that the disk overruns the 2090's tiny little buffer. >The faster the disk, the more likely the overrun. Case in point, my older >Miniscribe (68 ms) drive had no noticeable problem, but my Quantum Q280 >(28 ms) has the abovementioned severe problem. BTW, I am using a 2090 not >a 2090A, but I was assured the buffer sizes are equal. Given that some people >with fast drives are having little trouble, it seems that the amount of >slowdown depends on the detailed timing of the drive and not just its >"average" speed. The 80s is a fast disk (19ms access, even better) and still doesn't take very long to load images. ======== Darren Leigh Internet: dleigh@hplabs.hp.com UUCP: hplabs!dleigh