lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) (06/22/89)
I have a PAL, Jr. expansion chassis for my A1000. This unit has what is essentially a 2090 hard disk controller on a Zorro I form factor. I'm using it with an ST506 interface (a Seagate ST225 disk). Although I have been happy with the unit, after running DiskPerf I found that I was actually getting pretty slow transfer rates - about 50k/sec. My disk is formatted with the FFS and is running 1.3. I have read postings of much higer transfer rates using the 2090/2090A and am wondering why my set-up is so slow. I realize most of these postings were using SCSI disks rather than ST506, but I don't think the difference is that great. A reply from the manufacturer (who quit making the unit long ago) says that the ROM checksums were the same as the 2090A. I would be interested in hearing from any other PAL or PAL, Jr. owners who have run DiskPerf with ST506 disks. I'd be thrilled just to get 200k/sec or so transfer rates. Also... has anyone tried getting this controller to do SCSI?? Bernie Lofaso lofaso@titan.tsd.arlut.utexas.edu
andy@cbmvax.UUCP (Andy Finkel) (06/29/89)
In article <292@titan.tsd.arlut.utexas.edu> lofaso@titan.UUCP (Bernie Lofaso) writes: >I have a PAL, Jr. expansion chassis for my A1000. This unit has what is >essentially a 2090 hard disk controller on a Zorro I form factor. I'm using >it with an ST506 interface (a Seagate ST225 disk). Although I have been yes; its pretty much the same design. >happy with the unit, after running DiskPerf I found that I was actually >getting pretty slow transfer rates - about 50k/sec. My disk is formatted >with the FFS and is running 1.3. I have read postings of much higer transfer >rates using the 2090/2090A and am wondering why my set-up is so slow. I it doesn't sounds like you are really running FFS. Check it with the Workbench INFO menu item on your disk icon. FFS can be recognized by 512 bytes/block. (Also, check your mountlist to make sure your buffers are going into fast ram) >realize most of these postings were using SCSI disks rather than ST506, but >I don't think the difference is that great. A reply from the manufacturer >(who quit making the unit long ago) says that the ROM checksums were the >same as the 2090A. I would be interested in hearing from any other PAL or also make sure you are using the latest software for the 2090 (version 34.4) >PAL, Jr. owners who have run DiskPerf with ST506 disks. I'd be thrilled just >to get 200k/sec or so transfer rates. > >Also... has anyone tried getting this controller to do SCSI?? I don't think Byte By Byte always installed the Western Digital SCSI chip when they sold the PAL Jr as an ST506 controller. However, I've heard from some people who've added the chip (I don't know what else they did, whether or not they had to change jumpers or anything else) and it worked. >Bernie Lofaso -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "It's in there." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
baxt@pnet51.cts.com (Bill Backstrom) (07/01/89)
>In article <292@titan.tsd.arlut.utexas.edu> lofaso@titan.UUCP (Bernie Lofaso) writes: >>I have a PAL, Jr. expansion chassis for my A1000. This unit has what is >>essentially a 2090 hard disk controller on a Zorro I form factor. I'm using >>it with an ST506 interface (a Seagate ST225 disk). Although I have been > >yes; its pretty much the same design. > >>happy with the unit, after running DiskPerf I found that I was actually >>getting pretty slow transfer rates - about 50k/sec. My disk is formatted >>with the FFS and is running 1.3. I have read postings of much higer transfer >>rates using the 2090/2090A and am wondering why my set-up is so slow. I > >it doesn't sounds like you are really running FFS. Check it with > Yeah! I'm not alone... I have a B2000 with a 2090 and a ST296N (85 meg SCSI). I'm running 1.3, definitely using FFS (512 byte blocks) and version 34.4 of hddisk. Diskperf gives me a reads of about 80K bytes/sec and writes of 155K bytes/s for 32K blocks. I've also had an ST125 (20 meg ST-506) on the controller and got reads of 165K bytes/s and writes of 120K bytes/s. Nothing special is going on - no hi-res with overscan and interlace, etc. Following is a mountlist entry for the first FFS partition of the drive: u3p1: Device = hddisk.device FileSystem = l:FastFileSystem Unit = 3 Flags = 0 Surfaces = 6 BlocksPerTrack = 34 Reserved = 2 Interleave = 0 LowCyl = 4 ; HighCyl = 407 Buffers = 30 GlobVec = -1 BufMemType = 4 Mount = 1 DosType = 0x444F5301 StackSize = 4000 # I have tried different interleaves, another 2090 card, and various partition sizes. Nothing has improved the performance. The only unusual thing I've noticed apart from the low data transfer rates is that I could not prep the drive with my controller, I had to use my dealer's 2090A. I'm out of ideas and would appreciate any suggestions (of course sympathy is always welcome too). Thanks. Bill Backstrom >>Bernie Lofaso >-- >andy finkel {uunet|rutgers|amiga}!cbmvax!andy >Commodore-Amiga, Inc. > > "It's in there." > >Any expressed opinions are mine; but feel free to share. >I disclaim all responsibilities, all shapes, all sizes, all colors. UUCP: {rosevax, crash}!orbit!pnet51!baxt ARPA: crash!orbit!pnet51!baxt@nosc.mil INET: baxt@pnet51.cts.com
lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) (07/03/89)
Addendum to Pal Jr. problem:
Yes Andy, you are exactly right... I was not running the FFS. I guess
that's what happens when you use the machine daily and hurriedly try to
backup, reformat, and restore your hard disk. Anyway, I thought there might
be someone out there who might also learn from my experience. The key to my
problem was that when I did the original reformatting I didn't realize that
the first disk partition had to be AmigaDos. In my case, I had difficulty
setting up multiple partitions. This is partly due to the fact that Byte by
Byte did not distribute prep with their version of the 2090 controller.
Instead they distributed a program called hdtest. In some ways hdtest is
actually better than prep. For one thing prep does not seem to work (or maybe
works irratically) for disks that have had no low level formatting. Once your
disk has low level formatting then prep can be used easily to change
partitions. I found out (trial ... much trial, and error) that you can muck
with the mountlist entry all you want and if partition information is on the
disk, the mountlist will be ignored. In my case I had to tell hdtest to
rewrite disk parameters in order to properly set the end of the first
partition. On at least one attempt I created overlapping partitions - an
AmigaDos partition named dh0: which was the entire disk and an FFS partition
that was the disk less the first twenty cylinders. By the way, I didn't
realize that dh0: was a "majic" device name. I think it might be a
requirement that the first partition on the disk be called dh0: since
binddrivers will mount this automatically. I tried calling the FFS partition
dh0: in one trial and it didn't like that.
Also, any other Pal or Pal, Jr. owners who might use hdtest should
beware. If you decide to redo the low level formatting... hdtest does not
read the current bad block list from the disk. You MUST enter it in manually
and I recommend several read/write/compare scans to discover marginal blocks
that should also be entered in manually. To verify that the bad block list has
been correctly saved and recognized, you should notice additional seeks while
formatting at the dos level (sys:system/format) for those cylinders containing
bad blocks. If you can't hear this then your bad block list has probably
become corrupted or isn't there.
So what did I get from this exercise. Well, besides taking up two
evenings, I did get a lot of unused junk off my hard disk and performance as
measured by dperf (32K block reads) went from 50K/sec to 270K/sec. All in all
a very profitable exercise. Thanks for the help!visinfo@ethz.UUCP (VISINFO Moderators) (07/05/89)
In article <727@orbit.UUCP> baxt@pnet51.cts.com (Bill Backstrom) writes: >>In article <292@titan.tsd.arlut.utexas.edu> lofaso@titan.UUCP (Bernie Lofaso) >writes: >>>I have a PAL, Jr. expansion chassis for my A1000. This unit has what is >>>essentially a 2090 hard disk controller on a Zorro I form factor. I'm using >>>it with an ST506 interface (a Seagate ST225 disk). Although I have been >>>happy with the unit, after running DiskPerf I found that I was actually >>>getting pretty slow transfer rates - about 50k/sec. My disk is formatted >>>with the FFS and is running 1.3. I have read postings of much higer >>>transfer rates... I don't know if you could speed up ST506 drives. The ST506 standars is much slower than SCSI. So I my utilities will only work with SCSI drives. Sorry, but this IBM standard is really to bad to use it for professional usage on the AMIGA. >I have a B2000 with a 2090 and a ST296N (85 meg SCSI). I'm running >1.3, definitely using FFS (512 byte blocks) and version 34.4 of >hddisk. > >Diskperf gives me a reads of about 80K bytes/sec and writes of 155K >bytes/s for 32K blocks. I've also had an ST125 (20 meg ST-506) on the >controller and got reads of 165K bytes/s and writes of 120K bytes/s. >Nothing special is going on - no hi-res with overscan and interlace, >etc. That's probably because of the Low-level Interleave inside the SCSI drive. You cannot change this with Prep. >I have tried different interleaves, another 2090 card, and various >partition sizes. Nothing has improved the performance. The only >unusual thing I've noticed apart from the low data transfer rates is >that I could not prep the drive with my controller, I had to use my >dealer's 2090A. Different Interleaves in the mountlist don't affect the transfer between the SCSI device and the 2090. This interleave is only for DOS internal use. I have never seen any device that uses this Interleave. I always set it to zero. >I'm out of ideas and would appreciate any suggestions (of course >sympathy is always welcome too). Thanks. >Bill Backstrom Solution: Format the drive not with PREP. Prep always uses the built in Interlave which is usually 1. (Seagates are generally slow with Interleave 1). I hope I can release an early version of my SCSIformat this or next week. The problem currently is that I haven't written an SCSIprep yet which writes the cylinder 0 datas for automount/-boot after the low-level format. You could prep your hd and then save the infos from cyl 0 and 1, then format your hd with SCSIformat and restore the infos. /* -------------------------- SG (Simeon Graphics) ---------------------- */ /* Peter Simeon | // // */ /* UUCP: ...visinfo@bernina | // Long live the AMIGA! // */ /* BIX: hardwiz | \X/ \X/ */ /* ---------------------------------------------------------------------- */
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (07/07/89)
In <1492@ethz.UUCP>, visinfo@ethz.UUCP (VISINFO Moderators) writes: In <1492@ethz.UUCP>, visinfo@ethz.UUCP (VISINFO Moderators) writes: >In article <727@orbit.UUCP> baxt@pnet51.cts.com (Bill Backstrom) writes: >>>In article <292@titan.tsd.arlut.utexas.edu> lofaso@titan.UUCP (Bernie Lofaso) >>writes: >>>>I have a PAL, Jr. expansion chassis for my A1000. This unit has what is >>>>essentially a 2090 hard disk controller on a Zorro I form factor. I'm using >>>>it with an ST506 interface (a Seagate ST225 disk). Although I have been >>>>happy with the unit, after running DiskPerf I found that I was actually >>>>getting pretty slow transfer rates - about 50k/sec. My disk is formatted >>>>with the FFS and is running 1.3. I have read postings of much higer >>>>transfer rates... > >I don't know if you could speed up ST506 drives. The ST506 standars is much >slower than SCSI. So I my utilities will only work with SCSI drives. >Sorry, but this IBM standard is really to bad to use it for professional >usage on the AMIGA. A common misconception. An ST506 drive transfers data at a rate of 5 Mbits/second if it's MFM, and 7.5 Mbits/second if it's RLL. The final effective speed of data transfer into the computer is a function of the controller used, up to the maximum speed of the ST506 drive itself. The upper limit on an MFM ST506 drive (assuming 17 sectors/track), is about 510K bytes/second (522240 bytes/second) (60 revs/second * 17 sectors/revolution). Don't judge the speed/suitability of an interface solely on the implementations you have seen. -larry -- Van Roy's Law: An unbreakable toy is useful for breaking other toys. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+