[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

1890.0. "New Device Driver for Pacific Peripherals Controller" by TLE::RMEYERS (Randy Meyers) Sun Nov 20 1988 03:46

As I stated in a reply to a pervious note, I've had many problems using
the fast file system and the Pacific Peripherals Overdrive disk controller.
PP has updated their software, and I've found that I now experience only
an occasional problem.

The new software is available in:

	TLE""::UPORT$:[RMEYERS.TRADE.AMIGA]OVER.ZOO

I now encounter infrequent random Gurus from using the Fast File System
and my overdrive controller.  One of the reasons that I am posting these files
is to see if anyone else encounters problems.  (There is a small chance
that the problem could be hardware problems with my system.)

Interestingly enough, I encounter the most problems when warm booting
my system.  I believe that the device driver may use uninitialized
variables and random trash in memory may cause it to guru.

I don't encounter any problems using the old file system.  That is the
reason I don't believe it's a hardware problem, but it could be a
hardware problem that only surfaces when doing multiblock transfers.

Please report any experiences you have as replies to this note.

The following is the readme file that I wrote up and included in the zoo
archive:

The files in this archive are the latest version of the device driver
for the Pacific Peripherals Overdrive controller.

The files from Pacific Peripherals are:

ODutils                    46740 ----rwed 24-Oct-88 16:39:37
ODutils.info                1188 ----rwed 24-Oct-88 16:40:06
OverDrive.device            5340 ----rwed 24-Oct-88 16:37:50
overdrive.drives            9076 ----rwed 03-Nov-88 14:25:37

I have been given permission from Lee Adams of Pacific Peripherals to
distribute these files.

To install these files, copy ODutils and ODutils.info to your boot
up disk.  Copy OverDrive.device and overdrive.drives to your devs:
directory.

I have also included a mountlist suitable for using an ST157N disk
as a Fast File System device.  The mountlist divides the ST157N into
two equal partitions.  To use this mountlist, edit your mountlist
and replace your definitions for your hard disk with mine.

To use the Fast File System with your hard disk, do the following:
(I am assuming that you are using 1.3, have your disk divided into
two partitions using my mountlist, and you have an ST157N hard disk.
Read your overdrive documentation for information if you differ.  Note
that if you have ODUtils generate a mountlist entry for you, it will
generate a mountlist entry that contains Fast File System parameters
inside a comment.  You may then edit the entry to get a Fast File System
entry.)

1. Backup your hard disk using a good backup program.  The process of
   switching from the old file system to the new 1.3 Fast File System
   will erase all the data on your disk.  Also, doing a low level
   format using the new ODUtils program will erase all files on the
   hard disk.

2. Boot your system using a 1.3 floppy on which the new Pacific Peripherals
   files are installed.

3. Double Click on the ODUtils icon.  Select "Device 0" from the device
   id menu.

4. Select "Format" from the command menu.  In order for the Fast File
   System to be really fast, the "interleave" of the disk must be set
   properly.  The new ODUtils program does this when you do a format.
   The previous version of the ODUtils program used an interleave matched
   to the old file system, not the Fast File System.

5. After the format finishes, click on the close box to exit the ODUtils
   program.

6. In the CLI, type the following commands:

	mount dh0:
	mount dh1:
	format drive dh0: name "Fast" QUICK FFS
	format drive dh1: name "Fast" QUICK FFS

7. Restore the files to your hard disk using the backup program.

Warning:

I have encountered occasional Gurus using the FFS on my hard disk.  These
problems seem to be due to bugs in the overdrive device driver
"overdrive.device".  I have talked to Pacific Peripherals about these
problems.  However, few people seem to be encountering them (or at least
few people have been calling them to complain).  PP plans to investigate
the problem, but has problems reproducing the problem.

If you encounter any crashes, call PP at 415-651-1905, ask for Lee Adams
and complain.

ST157N owners should note.  Seagate has reduced the number of cylinders
on the ST157N from 609 to 608.  If you have an older ST157N, you probably
have 609 cylinders on your drive.  The new Pacific Peripherals software
matches assumes that if you have an ST157N that it is a new, smaller
ST157N.  If you have an older drive, you may want to edit the overdrive.drives
file to change the .Cylinders and .CAPACITY entries for your drive.  See
the comment at the start of overdrive.drives for details.

Note that I have edited the mountlist entries in my sample Mountlist
to remove the Mask= entry.  This entry is unneeded unless you have a
68020 or 68030 processor accelerator that contains memory that can not
be DMA'ed to.  I also set the MaxTransfer= to 8192.  (Pacific Peripherals
recommends on the phone much larger values.)  The ODUtils program generates
mountlists that have a value that is smaller than one block.  The MaxTransfer
parameter is the number of bytes that can be transferred in one operation.
The 1.3 Enhancer documentation erroneously states that this is the
number of block transferred.
T.RTitleUserPersonal
Name
DateLines
1890.1STC::HEFFELFINGERSun Nov 20 1988 23:26100
Re .0
    
    I have been running under FFS for the past 4 or 5 days and have
    seen no guru that I can attribute to the drive or device driver.
    
    My configuration is:
    
    B2000 rev 4.4 
    no true FAST RAM
    2 floppies
    1 PP Overdrive with ST157N drive affixed
    The Overdrive.device file that I have is dated 24-Mar-88 so it's
        not likely to be the one optimised for FFS.
    
    The important parts of my MountList follow:
    Note that I have 3 partitions (2 equal at ~20M and 1 for the remainder)
      and that my maxtransfer parm is set to 4096.
         
/* MountList for V1.3 */


/* An example mount entry using the fast file system with a partition
   of the hard disk using the 2090 disk controller.  PREP has been
   used to create the first partition (up to cylinder 20).  The second
   partition is MOUNTed, using the following entry:
   NOTE: Some hard disk drivers require more stack than specified here.
   Some may required less.
   (The hard disk is not included; this is only an example.)
*/

DH0:
    Device = overdrive.device
    FileSystem = l:FastFileSystem
    Unit   = 1
    Flags  = 0
    Surfaces  = 6
    BlocksPerTrack = 26
    Reserved = 2
    Interleave = 0
    LowCyl = 1  ;  HighCyl = 260
    Buffers = 5
    GlobVec = -1
    BufMemType = 2
    MaxTransfer = 4096
    Mount = 1
    DosType = 0x444F5301
    Mask = 0x7FFFF
#
DH1:
    Device = overdrive.device
    FileSystem = l:FastFileSystem
    Unit   = 1
    Flags  = 0
    Surfaces  = 6
    BlocksPerTrack = 26
    Reserved = 2
    Interleave = 0
    LowCyl = 261  ;  HighCyl = 520
    Buffers = 5
    GlobVec = -1
    BufMemType = 2
    MaxTransfer = 4096
    Mount = 1
    DosType = 0x444F5301
    Mask = 0x7FFFF
#
DH2:
    Device = overdrive.device
    FileSystem = l:FastFileSystem
    Unit   = 1
    Flags  = 0
    Surfaces  = 6
    BlocksPerTrack = 26
    Reserved = 2
    Interleave = 0
    LowCyl = 521  ;  HighCyl = 607
    Buffers = 5
    GlobVec = -1
    BufMemType = 2
    MaxTransfer = 4096
    Mount = 1
    DosType = 0x444F5301
    Mask = 0x7FFFF
#
    

    
    Thanks for making the new driver available.  I won't be able to
    rerun the low level format until Monday night, but I'll report again
    here as soon as I do.  I was wondering how I was going to be able
    to change the interleave factor, now I know.  I'm glad that PP has
    taken it into account.  I was a little disappointed when I ran
    diskperfa against my newly formatted FFS device and it did not compare
    favorably to some of the timings I saw on usenet. 
    
    Anyway, in short, I've been running just fine for days now, but I
    have been running using the software optimised for 1.2.

    
    Gary
1890.2It's a HARDWARE problemTLE::RMEYERSRandy MeyersMon Nov 21 1988 17:0836
Re: .0

Further investigation over the weekend seems to indicate that the problems
I am having with the Overdrive controller are hardware, not software.

I had though that the device driver might have used uninitialized variables
since crashes seemed to occur under a warm boot.  Switching the Amiga
off and then back on (to clear memory) seemed to always fix the problem.
Since this could also be the symptom of a heat problem, I once turned
on the Amiga, waited what seemed to be a long time, and then booted it.
I booted fine.

Well, this weekend, turning the machine off temporarily (for the minimum
5 seconds mandated by the manual) didn't solve the problem.  Turning
the machine off for several minutes did solve the problem.

Sunday, I turned the machine on and didn't feed it a boot disk for two hours.
When I finally gave it a boot disk, it crashed doing hard disk I/O.

Turning the machine off for a few minutes fixed the problem.

Thus, it sounds like a heat related hardware problem.

The problem might be in my 8 meg memory board.  I've pulled the memory
board to see if I can get a crash without it.

The memory board and the disk controller card are in adjacent slots.
Since the space between slots is narrow, the reduced airflow might
be the culprit.

I am a little worried that removing either card from the machine
increases the air flow enough around the other card that the
heat related bug will not be able to be pinned down.

Both the memory board and the disk controller are under warranty, so
I am set if I can pin it on either.
1890.3So far, so goodTLE::RMEYERSRandy MeyersTue Nov 22 1988 04:4326
I haven't been able to crash my Pacific Peripherals controller all day.
I removed my 8 Meg memory board from the system, and tried to crash the
dish controller.

I couldn't.

I put the board back and tried to crash the system.

I couldn't.

I ran extensive diagnostics on the memory board.  It checked out ok.

I've been running the system seven hours without a crash.

What changed?  I don't know.  Did the system get better because I
reseated the memory board?  Did vacuuming the large dust bunnies
off the configuration jumpers on the memory board solve the problem?

Beats me.

After my two hours of testing failed to crash the system, I moved
the memory board to the last expansion slot.  I left the disk controller
in the first expansion slot.  I figure that configuration will minimize
heat transferred for board to board, maximize the airflow between
the boards, and minimize the dust build up on the components on the
memory board.
1890.4STC::HEFFELFINGERTue Nov 22 1988 22:2815
    Re .3
    
    Glad things are going better.
    
    How about another topic.  I've been working to get my drive formatted
    under FFS to provide me with the best possible performance.  I've
    been using DISKPERFA as a guideline.  I'm being driven to distraction
    trying to get the block read/write times as good as those seen on
    the usenet.  I tweaked the interleave parm in the overdrive.drives
    entry for the ST157 from 2 to 3.  I've got maxtransfer set to 64K.
    And I've gotten roughly the same performance no matter what I do.
    
    Anyone have any suggestions?
    
    Gary
1890.5LEDS::ACCIARDIInsert witty anti-Dukakis slogan here - Wed Nov 23 1988 05:146
    
    Don't know about your specific controller, but with the C Ltd system,
    interleave can only be set by deep formatting.  The mounlist entry
    is always set to zero.
    
    Ed.
1890.6Looks Solid HereFSDEV1::JBERNARDMon Nov 28 1988 12:4643
    Byte 04 in the format field sets the interleave format of the drive.  Ed is
    correct, as with the C-Ltd controller, you need to low level format
    the drive to change the interleave.
    
    As a side note, you can run two different controllers simultaneously.
     I ran the C-Ltd controller and the Overdrive controller, (as well
    as the GVP Controller) all at the same time, but you have to be
    veeerrry careful!
    
    I did this to make rebuilding drives on different controllers easier,
    since each controller formats the drive differently.  The DMA
    controllers, as recent postings have shown, seem to fare better
    on larger transfers.  The other controllers seem to do better with
    small to medium transfers.  All can be optimized to be very comparable
    in speed to each other.  It seems to boil down, at least to me,
    on personal preference.
    
    The only crash I had with the OverDrive was my own fault.  If you
    have two controllers in your system, you MUST bring up the non-DMA
    controller FIRST, i.e. mount a drive connected to the non-DMA
    controller first, then mount a drive from the DMA controller.  Doing
    the reverse will hang the system big time (doesn't hurt the disk
    thankfully!).
    
    By the way, At one time I had almost all the slots in the 2000 full,
    2 internal floppies, internal hard drive in 5 1/4 bay, two 2 meg
    expansion mems, two disk controllers,  a CMI accelerator board,
    a borrowed flickerFixer, and a very warm workshop.  All this was
    run round the clock for over a week without any over heating or
    power problems.
    
    This should be a separate topic, but if you try and run some V1.3
    ROMS at 14 Mhz using the CMI processor Accelerator, you may have
    problems ranging from intermittent crashes to full lockup of the
    system when you switch from 7mhz to 14 mhz. The fix is to get another
    V1.3 ROM and hope (expensive) or swap back to the V1.2 ROM.  I verified
    this with the folks at CMI, and they are aware of the problem. 
    The ROMS used may or may not be marginal at 14 mhz, depending on
    the batch, vendor, phase of the moon, etc..  The fix is to simply
    disable the fast ROM option on the CMI board.
    
    John
    
1890.7Remove MaskTLE::RMEYERSRandy MeyersMon Nov 28 1988 15:21134
Re: .5

You are entirely correct, Ed.  The Interleave parameter in the Mountlist
is useless for SCSI drives.  The interleave on SCSI drives is set by the
low-level format program that is run before doing the AmigaDOS format.

However, the author of .4 is doing the right thing.  He is setting the
interleave parameter of his disk by editing the overdrive.drives file.
The Overdrive controller's low level format utility reads this file
when it runs to discover what the characteristics are of the drive
attached to the controller.  When the Overdrive utility program runs,
it asks the drive what model it is, looks up the model in the
overdrive.drives file, and then the utility knows the geometry of
the drive and what interleave factor to use when doing a low level
format.

Re: .4

For an ST-157N and Overdrive controller, the best interleave to use is
2.  Using an interleave of 3 just decreases performance by a little.
(Actually, I believe write times speed up a little, but read times
suffer.)  At an interleave of 2, one block transfers are slow (about
20K/sec), but any multiple buffer transfer screams (I believe the
next larger buffer size used by diskperfa results in 120K/sec.  A
32K buffer results in 300K/sec transfer.)  Since programs that use
single block buffers are rare, that statistic isn't worth worrying about.

I believe your problem is your mountlist entry (as given in .1)

>DH0:
>    Device = overdrive.device
>    FileSystem = l:FastFileSystem
>    Unit   = 1
>    Flags  = 0
>    Surfaces  = 6
>    BlocksPerTrack = 26
>    Reserved = 2
>    Interleave = 0
>    LowCyl = 1  ;  HighCyl = 260
>    Buffers = 5
>    GlobVec = -1
>    BufMemType = 2
>    MaxTransfer = 4096
>    Mount = 1
>    DosType = 0x444F5301
>    Mask = 0x7FFFF
>#

Remove the Mask parameter.  The Mask parameter allows the Mountlist
to inform the Fast File System that there exists memory in your
Amiga that the disk controller can not access.  This situation
is rare: about the only time is occurs is when you have a 68020
or 68030 board in your Amiga with private memory.  (Note that
the Commodore 68020 board has memory on it, but it isn't private.
A device can DMA to it.)

The overdrive controller is perfectly happy doing DMA to Chip memory,
half-fast memory (the other 512K in a 2000 or 500), or expansion
memory.

Removing the Mask parameter will cause the system to use the default
value which is "do DMA to anything with a 24 bit address" (this is
the entire addressing range of a 68000).

With your Mask, the controller will refuse to do DMA to any user
buffers located in your half-fast memory.  Effectively, you have
turned the Fast File System into the old file system.  Whenever
the file system sees a request for a read into a non-DMA'able
buffer, the file system does single block DMA into one of its
private buffers (set up by Buffers = in the Mountlist), and then
uses the CPU to copy the data into the user buffer.

As an experiment, you can keep the Mask parameter, but run NoFastMem
before running diskperfa.  Since NoFastMem will force diskperfa's
buffers to be allocated into chip ram (which is DMA'able according
to your mountlist), you should see a tremendous speed up.

Of course, the correct, permanent solution is to delete the Mask
parameter from the mountlist.

I have a few criticisms of your other Mountlist entries:

BufMemType should always be odd.  This parameter is the "type of memory"
argument passed to the AllocMem function when the system sets up the
file system's private buffers.  The low order bit says that the memory
should be "public" memory that can be shared between tasks.  Setting
this bit isn't important right now since AmigaDOS doesn't do memory
management, but it doesn't hurt to look to the future.  (Ok, I'm
being a bit silly here: you'd need a hardware and software upgrade
before this became an issue.)

Good values for BufMemType are:
	1	Allocate fast memory if available, otherwise use chip
	3	Allocate only chip memory
	5	Allocate only fast

I recommend a value of 1.  Unless you run tons of memory in your
startup sequence, it will result in the buffers being in fast memory.
If you do manage to use up all of your "fast" memory before mounting
the partition, it will allow the mount to succeed (but use chip memory).

Your mountlist uses 2.  This sets the chip-memory-only flag.  Since
this gains you nothing and limits your ability to open screens and
windows, it isn't a good idea.

You have LowCyl = 1.  You can gain a bit of extra room by setting
LowCyl = 0.  You will have to reformat (using the AmigaDOS format)
in order to use that partition after making this change.

You may want to bump up your MaxTransfer parameter.  Since my system
started working, I've been using MaxTransfer = 65536.  Larger values
would probably work (yes I've tested this by using a program with super
large buffers), but programs with such large buffers are rare.  The
value you are using will put a performance cap on programs that more
than 4K of buffer).

You may want to bump up your Buffers =  parameter.  The Fast File System
works well with large number of buffers because it is more intelligent
that the old file system about what is worth buffering and what isn't.
Additional buffers help when working with large directories.  This is
a trade off against I/O speed versus memory size, and thus is difficult
to make.   Since you only have a one meg system, you definitely don't
want a large number here, but "burning" an extra 50K of memory for
buffers may make things seem smoother.  (Each buffer is half a K.)
So try and see if you see any difference with Buffers = 20 for each of
your three partitions.

By the way, another night of beating on my system turn up no Gurus.
Reseating my memory board (or vacuuming it) seems to have fixed
my problems.

P.S., the sample Mountlist included in the ARC I uploaded isn't
necessarily a great one.   I made minimal changes to the one
generated by the overdrive utilities program.
1890.8LEDS::ACCIARDIInsert witty anti-Dukakis slogan here - Mon Nov 28 1988 15:2211
    
    Re:  CMI Accelerator reading the ROMS at 14 MHz...
    
    John, the last time I spoke with Bill at CMI, he indicated that
    he was considering allowing a wait state in the CMI board to deal
    with slower ROMS.  Alternately, he was considering reading them
    at 12 MHz, which all ROMS seem to be capable of.
    
    Until this is resolved, I'm staying with my 1.2 ROMS.
    
    Ed.
1890.9STC::HEFFELFINGERMon Nov 28 1988 23:5419
    Re: .7
    
    Thanks for your input.  After trying a myriad of combinations of
    mountlist parms last weekend I tried removing the MASK parm, as you suggest.
    Unfortunately, I was rewarded with a number of gurus.  It behaved
    beautifully, for awhile, but oddly enough, when I loaded up my copy
    of DME.  Task held.  It was repeatable.  Now I'd be willing to give
    up DME if it were the only thing choking on the truly fast FFS.
    However, on occasion I'd get gurus on startup.  It seemed to happen
    when DMouse spawns its process.  Now one thing that I *didn't* do,
    was Format the partition after changing the mountlist.  It didn't
    seem necessary in this case.
    
    Anyway, it was fast while it lasted but I have set the numbers back
    until I have more time to experiment.  (And reseat my Overdrive
    card.)
    
    
    Gary
1890.10Using new software?TLE::RMEYERSRandy MeyersTue Nov 29 1988 00:5073
Re: .9

Are you using the latest version of the driver software that I uploaded?
If not, that could be your problem.

You should need to do a reformat unless you change the low or high
cylinder number or do a low level format.

The Mountlist entries that I use are:

/* OverDrive Drive definition */

/* SEAGATE  ST157N */

DH0:	Device = overdrive.device
	Unit = 1
	Flags = 9
	Surfaces = 6
	BlocksPerTrack = 26
	Reserved = 2
	Interleave = 0
	LowCyl = 0  ;  HighCyl = 304
	Buffers = 256
	BufMemType = 1
	GlobVec = -1
	FileSystem = l:FastFileSystem
	Mount = 1
	Stacksize = 0x800
	MaxTransfer = 65536
	DosType = 0x444F5301
#


DH1:	Device = overdrive.device
	Unit = 1
	Flags = 9
	Surfaces = 6
	BlocksPerTrack = 26
	Reserved = 2
	Interleave = 0
	LowCyl = 305  ;  HighCyl = 608
	Buffers = 256
	BufMemType = 1
	GlobVec = -1
	FileSystem = l:FastFileSystem
	Mount = 1
	Stacksize = 0x800
	MaxTransfer = 65536
	DosType = 0x444F5301
#


You should reduce the value of Buffers = to something more reasonable
for your 1 meg system.

Also, be aware that not all ST-157n drives have a cylinder number 608.
You may only be able to have a HighCyl = 607.

>    Unfortunately, I was rewarded with a number of gurus.  It behaved
>    beautifully, for awhile, but oddly enough, when I loaded up my copy
>    of DME.  Task held.  It was repeatable.

My most usual Guru occurred when loading a large program in from disk.
My usual Guru numbers were 3 (most common) and 4.

>And reseat my Overdrive card.

It was reseating (or vacuuming) my memory card that fixed my problem.
I never removed the overdrive card.  However, reseating your board
can't hurt.

By the way, I wrote .7 last Wednesday just before the machine hosting
this notesfile went down.  It's been about a week now with no crashes!
1890.11Using new software.STC::HEFFELFINGERTue Nov 29 1988 22:4619
    Re .10
    
    I am using the new software that you uploaded.  Thanks.  
    
    My mountlist now looks very much like yours, except that I'm using
    30 buffers instead of 256.
    
    I reseated the board last night, to no avail.
    
    The gurus I'm seeing are typically 3's and 4's as well.  I don't
    think that I would say that it gurus when I load large files.  DME
    is not particularly large, and I am able to load some that are larger.
    
    I'll do some more experimenting later.
    
    
    Thanks,
    
    Gary
1890.12Things are betterSTC::HEFFELFINGERThu Dec 01 1988 23:2020
    I'm continuing this here rather than via mail because it might be
    of interest to others...
    
    Randy,
    
    Are you a workbench user?  
    
    I have determined that my problem with
    the Overdrive stems from the fact that I set my MaxTransfer value
    too high.  Andy Finkel of CBM suggested that I lower it to 1024
    and when I did things went much better.
    
    Anyway, I find that I can load some of my problem programs via CLI with
    the MaxTransfer rate set over 16K, but it seems that as soon as
    I try to start some of these from WB, the guru's return.  As a
    consequence, I've lowered the rate to 1K.  
    
    Am I nuts, or is this possible?
    
    Gary
1890.13TLE::RMEYERSRandy MeyersSat Dec 03 1988 06:368
Re: .12

Yes, I use the Workbench quite a lot.  And my system has not crashed
since I reseated the memory board.

Are you sure you installed the software properly?  Try putting the driver
in both the devs directory of your boot floppy and your hard disk's
devs directory.
1890.14STC::HEFFELFINGERSat Dec 03 1988 21:1818
    Re: .13
    
    Yes, I've got the .device in both places.  I've also got the same
    mountlist in both places.  I tried moving the Overdrive card away from
    the power supply last night to see if I could lessen any heat buildup.
    I noticed, or thought I noticed, that the # of gurus increased the
    longer I had the machine turned on.  So I thought that moving it away
    from the biggest source of heat might make a difference.  Could
    be.  But I still get gurus if I set the MaxTransfer rate much above
    512.  Not ideal, but I can live with it.  Besides, I've gotten my
    fill of tweaking.  I want to actually *use* the machine for a change.
    
    Perhaps I'll call Pacific Periph again next week and see if they
    have anything new to tell me.
    
    Thanks for your help,
    
    Gary 
1890.15new OverDrive.drives fileFSDEV1::JBERNARDWed Dec 14 1988 12:06681
The following is an updated OverDrive.drives file for those of you with
    an OverDrive controller.  This file provides support for all the
    RD series drives.
    
    John
    
    
    __________________________  CUT HERE ___________________________________
    
Overdrive.Drives                                   Version 1.3b       12-DEC--88
================================================================================
11/88 

This file contains information necessary to operate a variety of SCSI drives.
Any drive name followed by the letters NT means that the file was submitted by
one of our customers and has NOT BEEN TESTED  by Pacific Peripherals.  While we
believe these to be correct, there may be some errors.   Should you 
successfully install a drive not on our list, please let us know.

!NOTE!  DRIVE MANUFACTURERS OCCASIONALLY CHANGE THE PARAMETERS ON THEIR DRIVES.
IF, DURING THE BAD BLOCK SCAN, YOU FIND A BLOCK NEAR THE END OF THE DRIVE THAT 
CANNOT BE REASSIGNED, THE DRIVE PARAMETERS MAY HAVE BEEN CHANGED. 
PRINTED DOCUMENTATION MAY CONTAIN OLD SPECS, SO LOOK FOR TEST SHEETS FOR TOTAL
CAPACITY.  CASE IN POINT:  THE SEAGATE ST157N AND ST138N HAVE CHANGED AT LEAST
TWICE SINCE THEIR INTRODUCTION.

================================================================================

UPDATE - 20-NOV-88      John D. Bernard

Under ADAPTEC, added ST225 drive
Under Seagate, corrected cyl count for ST-277N from 612 to 812

================================================================================

UPDATE - 26-NOV-88      John D. Bernard

Under ADAPTEC, added RD31, RD52, RD53 Drives

================================================================================

UPDATE - 12-DEC-88      John D. Bernard

Under ADAPTEC, added RD32, RD51 Drives

================================================================================

                          FILE DESCRIPTION

       * Denotes Manufacture
       - Denotes Product
       . Specifies each Data Field
       # Denotes end of drive spec


  This file contains the drive specs.
  The 2 digit numbers after each command is in Hex and is the SCSI command
  or data sequence needed by the drive for that operation.

  When references to a particular byte in the field, we will number them
  starting at 0.

  example

  { .Format 04 00 00 00 01 00 }
     byte #  0  1  2  3  4  5

Format      This is the Low Level Format Command. Byte 4 contains the
      interleave value

FSetupCmd   Format Setup Cmd
FSetupData   Format Setup Data
      These are sent to the Drive before the Format Operation
      they are used to configure the drive. For example the rodime
      RO632 drive is not shipped with 512 bytes per block. so this
      command will change that.  In Most drives this will be the
      MODE SELECT command.  On Most SCSI drives this will not
      be nessasary. 

SetupCmd   Setup Command
SetupData   Setup Data
      This is the same as above except that it is sent during
      the Setup Drive menu Selection.  This is used to configure
      a drive that may need to be configured during every power on.
      For this release of the driver you will need to add a 
      command in the startup sequence for these type of drives.
      the command is already documented in the startup-sequence
      files on the floppy.
      For most drives this will not be nessasary.

RequestSenseCmd Request Sense Command
      Byte 4 contains the length of data returned by the drive.
      This command is rather standard for most drives except that
      the length must match what the drive will return.  This
      is used to return error codes to you if something fails in
      the ODutils programs.

ParkCmd      1st Park Command
ParkData   1st Park Data
Park2Cmd   2nd Park Command
Park2Data   2nd Park Data
      This is used to Park the heads on your drive.
      Most Drives will use the SCSI Start/Stop command for this
      funtion. If this is so you can use the examples below for
      the Rodime. Two commands are supplied for those who
      need them. EX. some HOST adaptor boards do not provide
      a Start/Stop command. So on these you may need to use
      the first command to send new configuration data to the drive
      to trick it into having more cylinders then normal then
      do a SEEK past the end.

CertifyCmd   Certify Command
CertifyData   Certify Data
      Most drives won't use this feature. (TOO BAD)
      On the Rodime drives this feature will automaticly
      search the drive for Bad Areas and reassign them so that
      a bad block scan will not be nessasary.

Capacity   Capacity of the drive in blocks (Decimal)
      Currently this is only used for the bad block scan


Cylinders   # of Cylinders of drive in  Decimal. 
      This is used basicly to build you MountList

BlocksPerTrack   # of Blocks contained on each track (Decimal)
      For Mountlist

Heads      # of Heads on Drive (Decimal)   
            For Mountlist

   Cylinders, Blockspertrack, Heads  are used by Amiga Dos
   to use the drive.  All that is is really important is that if
   you mulitpy them together that you don't excede the number of
   blocks available on the drive.
*(NT)=not tested
#

*CDC
-94211
.Format 04 00 00 00 0E 00
.RequestSenseCmd 03 00 00 00 0D 00
.Cylinders 1022
.BlocksPerTrack 35
.Heads 5
.Capacity 178850
.BlockSize 512
.BBScanType 1
#
*Maxtor
-Maxtor3380
.Format 04 00 00 00 01 00
.RequestSenseCmd 03 00 00 00 1B 00
.Cylinders 1220
.BlocksPerTrack 33
.Heads 15
.Capacity 603900
.BlockSize 512
.BBScanType 1
#
*Micropolis
-Micropolis 1375
.Format 04 00 00 00 01 00
.RequestSenseCmd 03 00 00 00 1B 00
.Cylinders 1016
.BlocksPerTrack 36
.Heads 8
.Capacity 603900
.BlockSize 512
.BBScanType 1
#
*Conner
-CP340(NT)
.Format 04 00 00 00 01 00
.RequestSenceCmd 03 00 00 00 01 00
.Cylinders 752
.BlocksPerTrack 26
.Heads 4
.Capacity 78208
.BlockSize 512
.BBScanType 1
#

-CP3100(NT)
.Format 04 00 00 00 01 00
.RequestSenceCmd 03 00 00 00 01 00
.Cylinders 748
.BlocksPerTrack 33
.Heads 8
.Capacity 197472
.BlockSize 512
.BBScanType 1
#
*Fuji
-FK308S-39R
.FSetupCmd 15 00 00 00 14 00
.FSetupData 00 00 00 08 00 00 00 00 00 00 02 00 01 06 00 08 00 00 00 00
.Format 04 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 11 00
.Cylinders 615
.BlocksPerTrack 26
.Heads 4
.Capacity 63960
.BlockSize 512
.BBScanType 1
#

-FK308S-58R
.FSetupCmd 15 00 00 00 14 00
.FSetupData 00 00 00 08 00 00 00 00 00 00 02 00 01 06 00 08 00 00 00 00
.Format 04 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 0A 00
.Cylinders 615
.BlocksPerTrack 26
.Heads 6
.Capacity 95940
.BlockSize 512
.BBScanType 1
# 

*KONICA
-KT-510 FDD
.Format 04 00 00 00 00 00
.RequestSenseCmd 03 00 00 00 00 00
.Cylinders 350
.BlocksPerTrack 30
.Heads 2
.Capacity 21000
.BlockSize 512
.BBScanType 1
#

*RODIME
-RO632
.Format 04 00 00 00 16 00
.FSETUPCMD 15 01 00�00 0C 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 12 00
.Cylinders 306
.BlocksPerTrack 34
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.CertifyCmd E2 00 00 00 00 00
.Capacity 41616
.BlockSize 512
.BBScanType 1
#

-RO3057S
.Format 04 00 00 00 02 00
.FSETUPCMD 15 01 00�00 0C 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 12 00
.Cylinders 680
.BlocksPerTrack 26
.Heads 5
.ParkCmd 1B 00 00 00 00 00
.CertifyCmd E2 00 00 00 00 00
.Capacity 88400
.BlockSize 512
.BBScanType 1
#

-RO3080S
.Format 04 00 00 00 02 00
.FSETUPCMD 15 01 00�00 0C 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 12 00
.Cylinders 680
.BlocksPerTrack 26
.Heads 7
.ParkCmd 1B 00 00 00 00 00
.CertifyCmd E2 00 00 00 00 00
.Capacity 123760
.BlockSize 512
.BBScanType 1
#

*SEAGATE
-ST225N
.Format 04 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 1B 00
.ParkCmd 1B 00 00 00 00 00
.CAPACITY 41720
.Cylinders 613
.Heads 4
.BlocksPerTrack 17
.BlockSize 512
.BBScanType 1
#

-ST138N
.Format 04 00 00 00 02 00
.RequestSenceCmd 03 00 00 00 1B 00
.CAPACITY 63128
.Cylinders 607
.Heads 4
.BlocksPerTrack 26
.BlockSize 512
.BBScanType 1
#

-ST157N
.Format 04 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 1B 00
.CAPACITY 94848
.Cylinders 608
.Heads 6
.BlocksPerTrack 26
.BlockSize 512
.BBScanType 1
#

-ST277N
.Format 04 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 1B 00
.CAPACITY 126790
.Cylinders 812
.Heads 6
.BlocksPerTrack 26
.BlockSize 512
.BBScanType 1
#

-ST296N
.Format 04 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 1B 00
.CAPACITY 165850
.Cylinders 812
.Heads 6
.BlocksPerTrack 34
.BlockSize 512
.BBScanType 1
#

-ST251N
.Format 04 00 00 00 02 00
.RequestSenseCmd 03 00 00 00 1B 00
.ParkCmd 1B 00 00 00 00 00
.Capacity 84254
.Cylinders 810
.Heads 4
.BlocksPerTrack 26
.BlockSize 512
.BBScanType 1
#

*NuData
-20 Meg
.Format 04 00 00 00 0E 00
.FSetupCmd C2 00 00 00 00 00
.FSetupData 04 01 00 03 02 63 80 00 10 00
.SetupCmd C2 00 00 00 00 00
.SetupData 04 01 00 03 02 63 80 00 10 00
#

*LaPineLT4000(NT)
.Format 04 00 00 00 0e 00
.RequestSenceCmd 03 00 00 00 1B 00
.ParkCmd 1B 00 00 00 00 00
.Cylinders 730
.Heads 4
.BlocksPerTrack 26
.Capacity75920
.BlockSize 512
.BBScanType 1
#

*MINSCRIB
-M8425 - SCSI
.Format 04 00 00 00 0A 00
.RequestSenseCmd 03 00 00 00 0D 00
.Cylinders 602
.BlocksPerTrack 17
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 40936
.BlockSize 512
.BBScanType 1
#
-M8051(NT)
.Format 04 00 00 00 0A 00
.RequestSenceCmd 03 00 00 00 0D 00
.Cylinders 732
.BlocksPerTrack 28
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 81984
.BlockSize 512
.BBScanType 1
#

*Adaptec w/ DEC Drives
-Seagate ST225
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00�00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 01 32 04 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 612
.BlocksPerTrack 17
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 41616
.BlockSize 512
.BBScanType 1
#

-RD31
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00�00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 01 32 04 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 612
.BlocksPerTrack 17
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 41615
.BlockSize 512
.BBScanType 1
#

-RD32
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00�00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 03 34 06 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 820
.BlocksPerTrack 17
.Heads 6
.ParkCmd 1B 00 00 00 00 00
.Capacity 83639
.BlockSize 512
.BBScanType 1
#

-RD51
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00�00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 01 38 04 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 312
.BlocksPerTrack 18
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 22463
.BlockSize 512
.BBScanType 1
#

-RD52
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00�00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 01 E6 08 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 502
.BlocksPerTrack 18
.Heads 8
.ParkCmd 1B 00 00 00 00 00
.Capacity 72287
.BlockSize 512
.BBScanType 1
#

-RD53
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00�00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 04 00 08 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 1024
.BlocksPerTrack 17
.Heads 8
.ParkCmd 1B 00 00 00 00 00
.Capacity 139263
.BlockSize 512
.BBScanType 1
#


*Adaptec 4000A Controller
-Nippon RD-4255 MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 01 32 08 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 306
.BlocksPerTrack 17
.Heads 8
.ParkCmd 1B 00 00 00 00 00
.Capacity 41615
#

-Rodime RO632 MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 01 32 04 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 306
.BlocksPerTrack 17
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 20807
#

-Rodime RO3057S MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 01 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 A8 05 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 680
.BlocksPerTrack 17
.Heads 5
.ParkCmd 1B 00 00 00 00 00
.Capacity 57799
#

-Rodime RO3080S MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 A8 07 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 680
.BlocksPerTrack 17
.Heads 7
.ParkCmd 1B 00 00 00 00 00
.Capacity 80919
#

-Seagate ST225N MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 65 04 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 613
.BlocksPerTrack 17
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 41683
#

-Seagate ST157N MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 61 06 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 609
.BlocksPerTrack 17
.Heads 6
.ParkCmd 1B 00 00 00 00 00
.CAPACITY 62117
#

-Seagate ST277N MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 5F 08 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 607
.BlocksPerTrack 17
.Heads 8
.ParkCmd 1B 00 00 00 00 00
.CAPACITY 82551
#


-Tulin 30 Meg MFM
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 8A 06 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 650
.BlocksPerTrack 17
.Heads 6
.ParkCmd 1B 00 00 00 00 00
.Capacity 66299
#

     This is the same drive as directly above, but using the RLL controller

*Adaptec 4070A Controller
-Tulin 50 Meg RLL
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 8A 06 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 650
.BlocksPerTrack 26
.Heads 6
.ParkCmd 1B 00 00 00 00 00
.Capacity 101399
#

-NEC 30 Meg RLL
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 76 04 00 00 00 00 00 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 630
.BlocksPerTrack 26
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 65519
#

       Same as above but using only 615 data cylinders and the
       other cylinders used for parking. This is probably the
       most common configuration (4 heads/615 cylinders) for 20 meg mfm
       or 30 meg rll drives.

-NEC 30 Meg RLL Park
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 67 04 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 615
.BlocksPerTrack 26
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 63959
#

-Rodime RO632 RLL
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 01 32 04 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 306
.BlocksPerTrack 26
.Heads 4
.ParkCmd 1B 00 00 00 00 00
.Capacity 31823
#

-Rodime RO3057S RLL
.Format 04 00 00 00 02 00
.FSETUPCMD 15 01 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 A8 05 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 680
.BlocksPerTrack 26
.Heads 5
.ParkCmd 1B 00 00 00 00 00
.Capacity 88399
#

-Rodime RO3080S RLL
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 A8 07 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 680
.BlocksPerTrack 26
.Heads 7
.ParkCmd 1B 00 00 00 00 00
.Capacity 123759
#

-Segate ST157N RLL
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 61 06 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 609
.BlocksPerTrack 26
.Heads 6
.ParkCmd 1B 00 00 00 00 00
.Capacity 95003
#

-Segate ST277N RLL
.Format 04 00 00 00 02 00
.FSETUPCMD 15 00 00 00 16 00
.FSETUPDATA 00 00 00 08 00 00 00 00 00 00 02 00 01 02 5F 08 00 00 00 00 0A 02
.RequestSenseCmd 03 00 00 00 04 00
.Cylinders 607
.BlocksPerTrack 26
.Heads 8
.ParkCmd 1B 00 00 00 00 00
.Capacity 126255
#