dean@coplex.UUCP (Dean Brooks) (06/06/90)
A couple of weeks ago, I ran across a message that mentioned a bug
in GVP's GVPprepHD program that caused the Max Transfer Rate to be set much
too low, causing very bad performance on the ST296N (Seagate 80 MB SCSI) on
my Amiga 2000.
Could the author report/mail more detailed instructions on how to change
the Rigid Disk Block of the hard drive to reflect a new transfer rate?
Is this indeed a correct solution to the bad performance I am
getting out of this drive/controller combination? I know the ST296N is
a slow drive, but it is not THAT slow. Any help would be appreciated.
Thanks in advance...
--
dean@coplex.UUCP Dean A. Brooks
Copper Electronics, Inc.
Louisville, Ky
UUCP: !uunet!coplex!deanvisinfo@ethz.UUCP (VISINFO c/o Sascha Schnapka) (06/11/90)
In article <154@coplex.UUCP> dean@coplex.UUCP (Dean Brooks) writes: > A couple of weeks ago, I ran across a message that mentioned a bug >in GVP's GVPprepHD program that caused the Max Transfer Rate to be set much >too low, causing very bad performance on the ST296N (Seagate 80 MB SCSI) on >my Amiga 2000. > > Could the author report/mail more detailed instructions on how to change >the Rigid Disk Block of the hard drive to reflect a new transfer rate? You can use a Diskmonitor which allows Hard drive access, or a low-level read tool (like 'Read' by Chris Weber which reads bytes from a device into memory where you can edit them with a normal monitor). To be able to use a Diskmon you must write a mountlist entry for your drive with LowCyl = 0 and HighCyl = 1. Then you can read and modify the Rigid Disk Block. Each Block has an identifier in the first 4 bytes. You should look for the Blocks beginnig with PART. A PART Block contains a mountlist. The detailed description of the structure you can find in the include file 'hardblocks.h'. If you have entered all default values while installing the drive with the GVP install script, you can find $00002000 in each part block which is the maxtransfer. Change it to $00020000. Then write the block again to your drive. The Rigid disk blocks also have a checksum, but you don't have to correct it. I think GVP doesn't look at the checksum. It worked for me without recalculating the checksum. > Is this indeed a correct solution to the bad performance I am >getting out of this drive/controller combination? I know the ST296N is >a slow drive, but it is not THAT slow. Any help would be appreciated. It's not so slow. On a HardFrame we get a transfer rate of 620k/sec with the ST 296N-1 (28ms) formatted with Interleave 1. /* -------------------------- SG (Simeon Graphics) ---------------------- */ /* Peter Simeon, UUCP: | // // */ /* visinfo@bernina.ethz.ch | // Long live the AMIGA! // */ /* BIX: hardwiz | \X/ \X/ */ /* ---------------------------------------------------------------------- */
jesup@cbmvax.commodore.com (Randell Jesup) (06/12/90)
In article <4716@ethz.UUCP> visinfo@bernina.ethz.ch.UUCP (VISINFO c/o Peter Simeon) writes: >'hardblocks.h'. If you have entered all default values while installing the >drive with the GVP install script, you can find $00002000 in each part block >which is the maxtransfer. Change it to $00020000. Then write the block again >to your drive. The Rigid disk blocks also have a checksum, but you don't >have to correct it. I think GVP doesn't look at the checksum. It worked for me >without recalculating the checksum. Ack! It should check the checksum. If you do this, you won't be able to read the rigiddiskblock from any RDB editor I know of, nor will you be able to drop it onto another controller without losing your partitioning information. Doesn't GVP ship _some_ sort of RDB editor with their HD controller? Both Microbotics and Commodore do. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
visinfo@ethz.UUCP (VISINFO c/o Sascha Schnapka) (06/13/90)
In article <12552@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >>'hardblocks.h'. If you have entered all default values while installing the >>drive with the GVP install script, you can find $00002000 in each part block >>which is the maxtransfer. Change it to $00020000. Then write the block again >>to your drive. The Rigid disk blocks also have a checksum, but you don't >>have to correct it. I think GVP doesn't look at the checksum. It worked for >>me without recalculating the checksum. > > Ack! It should check the checksum. If you do this, you won't be >able to read the rigiddiskblock from any RDB editor I know of, nor will >you be able to drop it onto another controller without losing your >partitioning information. > > Doesn't GVP ship _some_ sort of RDB editor with their HD controller? >Both Microbotics and Commodore do. There are two completely different versions of the GVP scsidev.device which are completely incompatible. The Version 1.0 is supplied with all GVP hard cards and the Version 2.2 is supplied with SyQuest drives. Only the newer version 2.2 are compatible with the RDSK standards used by Commodore, Microbotics and others. This version also supports the SCSI direct access with HD_SCSICMD (command 28). Unfortunately all GVP's without SyQuests are delivered with the older 1.0 software and so nearly all people have the old device. The 1.0 device has two big disadvantadges: 1. Rigid Disk Blocks are not fully compatible with the standard. They use C-strings instead of B-strings for the Device name. So you can't take your drive to another controller without some troubles. 2. SCSI direct access is not compatible with HD_SCSICMD. I had to write different versions of my HD-Tools for GVP 1.0. I think they still deliver it, is because the version 1.0 is a bit faster and the boot sequence is much faster. Note that the scsidev.device came out before the RDSK standards were finished. So don't use a RDB editor like HD-ToolBox or RdPrep! You can't use the GVP RDB editor because they don't let you enter a maxtransfer > 8192. At the AmiEXPO in Basel GVP has told me that they will soon release a new scsi device which should be much faster. I hope all these problems will no longer exist. I have told them about and they didn't know these problems. May Be they think a Quantum with 300k/sec is fast enough. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup >Common phrase heard at Amiga Devcon '89: "It's in there!" /* -------------------------- SG (Simeon Graphics) ---------------------- */ /* Peter Simeon, UUCP: | // // */ /* visinfo@bernina.ethz.ch | // Long live the AMIGA! // */ /* BIX: hardwiz | \X/ \X/ */ /* ---------------------------------------------------------------------- */