Subject: Large SCSI drive on Apollo
From: [email-masked] (Paul Walker)
Date: Wed, 2 Dec 1998 05:47:48 GMT

I recently purchased a 4.57GB drive for my DN5500.  When I first
invol'd it, the reported capacity was about 270MB.  This also happened
on a DN4500 as well.
    After some investigation, I was able to get the drive to invol just
fine, and get the full capacity on either machine (of course, the 4500
had to see the drive as two 2GB drives).
    I solicited the help of another Domain/OS user (thank you very much
for being an "alpha" test site).  He was successful in using the same
technique to put a 9.09GB drive on a 425t.
    Here are the details on why it doesn't work with the standard
kernel, and how the problem was fixed ...

    Invol gets drive capacity information from the disk_$pv_assign_n
kernel call.  Here are disk_$pv_assign_n results with 'stock' kernels:

Drive   System  Type    Reported Blocks
-----   ------  ----    ---------------
8760    4500    608      a0f8c
4.5G    4500    71b      417a3
4.5G    5500    71b      105e8
2.1G    3500    7d6     1ff0c0
4.5G    4500    701     4417A3  (patched kernel)
4.5G    5500    701     1105e8  (patched kernel)

The read capacity command of the mts tool shows that the 4.5G drive
reports a capacity of 8924999 (0x882f47) blocks, with a block size of
512 bytes.

The problem is that the kernel code that determines the capacity of a
physical volume is not written for capacities that exceed 2^32 bytes. 
In the case of the 4.5G drive, the capacity is 8,924,999*512 bytes,
which comes to 4,569,599,488, or 0x1105e8e00.  This number exceeds 32
bits, and becomes 0x105e8e00, which divides by the page size of the node
to become either 0x105e8 or 0x417a3 blocks.  Note that the DN4500 has a
1K page size, and the DN5500 has a 4K page size.

The simplest fix for the problem is to reorder the code that does the
multiply/divide.  The compiler generates two LSR instructions for the
division.  If one of these is moved to operate on the blocksize, then
the multiply won't overflow.

*********************************************************************************
Kernel code that determines number of blocks ...  Note that it will overflow
 for a large drive.  Can we reorder the operations?
7A423CD0: MOVE.l      (a2),d0                       * d0 = numblocks
7A423CD2: MULS.l      ($4,a2),d0                    * d0 *= blocksize
7A423CD8: MOVE.l      d0,d1                         * d1=d0
7A423CDA: LSR.l       #$8,d1                        * d1 /= 4096 (page size)
7A423CDC: LSR.l       #$4,d1                        *
7A423CDE: MOVE.l      d1,($FFFFFFE0,a6)             * local_b_per_pvol = d1

Here is a proposed reordering that will support drives up to 1000G, assuming that
 the blocksize is 512 bytes:
 MOVE.l      ($4,a2),d0                    * d0 = blocksize
 LSR.l       #$8,d0                        * d0 /= 256  (assumes blocksize is multiple of 256)
 MULS.l      (a2),d0                       * d0 *= numblocks
 MOVE.l      d0,d1                         * d1=d0
 LSR.l       #$4,d1                        * d1 /= 16
 MOVE.l      d1,($FFFFFFE0,a6)             * local_b_per_pvol = d1

*********************************************************************************

    The d_type is still returned incorrectly.  It appears that for SCSI
drives, Domain/OS uses the lower byte of this field to indicate the
capacity, in 1E7 byte blocks.  For example, 0x7d6 is the proper d_type
for a 2.1GB drive, and 0xd6 comes to 214.  Netstat reports this drive as
a 2140MB drive.  This scheme allows a capacity of 255E7 bytes (about
2.5GB).  This would be reported by netstat as a 2550MB SCSI disk.
    The code-reordering I've done results in the low byte of the d_type
field being divided by an additional 256.  So a drive with a 2.56GB
capacity will be reported as 10MB.  So will a 5.11GB drive.  However, a
5.12GB drive will be reported as 20MB, and a 9.09GB drive will be
reported as 30MB.
    If the division results in a zero, then 1 is substituted.  If the
result is too large, then 0x700 is substituted.  This won't happen until
the capacity exceeds 255*256*1E7 bytes (approx. 652.8GB).
    There doesn't seem to be an easy way to correct the kernel in this
respect, but the error doesn't seem to cause a problem, so I'll let it
be.  Even if it could be fixed, there is a range problem (2.56GB
limit) in the current representation that HPollo chose.  A complete
fix of this could extend to many areas in Domain/OS, besides the kernel
and netstat.
    Using the patched kernel all of the time will cause "standard"
drives to be mis-reported by netstat, as well as the large drives.  So
far, this is the only downside I've seen to using the patched kernel all
of the time.

*********************************************************************************

    I have written a program that makes the kernel patch that is
described above.  It operates directly on the kernel image in
/sau?*/domain_os.  It searches for the specific code segment that is
listed, and changes it.  If the code segment is found more than once, no
patch is made, because I don't know which segment is the appropriate one
to change.  The algorithm is described in the program's source code.
    If you are interested in trying the program, send me an Email.  I
would like to have a few more people try this out before I make a
general release of the code.
    I also welcome any discussion on this subject.

[ Ed note: The program is called kbs_patch and is available from the UM
Apollo Archive. - Jim Rees ]

Paul Walker
-- 
Paul Walker <[email-masked]>
Note:  I hate spam - if you want to send mail to me, remove the alphabetic
 letter sequence that has been interleaved into my address, starting with the
 first 'a', to the 'r'.

From: "Joe Avila" <[email-masked]>
Subject: Re: High Capacity Drives
Date: Sun, 09 Aug 1998 08:13:03 GMT

Hello Everyone,

I have an update to my high capacity drive adventure that I orginally
inquired about a couple of weeks ago. I was finally successfull in
formatting and using a 4.3G drive on my 433t running SR10.3.5.15 (this is no
joke). I thought some of you would like to hear about the details of my
experience.

On SR10.3.5.15 fully patched with patch kit PD97_MBP09 I was able to format
a 4.3Gig drive on my 433t. This drive was a Seagate ST15150N. The format was
done with online invol and I had to make no special changes to the drive
firmware whatsoever. It worked right out of the box (except for setting the
SCSI id). Here is the drive description as reported by scsi_info:

Target 5:
Device Type: Disk
Vendor: SEAGATE
Product: ST15150N
Rev Level: 0023
ANSI version compliance: SCSI-2
Features supported: Synchronous Data Xfer; Linked Commands; Cacheing;
Command Queueing;
0 bytes of vendor unique data

After running option 7 of invol (initialize bad spot list) and formatting
the drive, I initialized the virgin physical volume with the '-f' option and
it reported 4166892 kbytes free. After the logical volume was created (1
full partition of 4Gig), I was able to mount the drive and begin using it
with no problems. I have yet to run into any as well. The entire process
from install to mount took 4 hours.

From: [email-masked] (Tom Brock)
Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb.
Date: 1 Dec 1996 13:51:33 GMT

WArning. This is quite long and boring.

Many thanks to those who responded to my 'dead' Micropolis 170 post.
FYI, DEX reported no errors of any kind when 'RUN WIN -ENTIRE -WRITE'
was run on on one example. It took the devil of a time, but convinced
me to persevere. A special thanks go to Paul Szabo for pointing out a
basic flaw in my knowledge of 'jumper'. My WD7000 was jumpered
incorrectly: W4 was in, but that should have had no effect on disks. All
the experiments below were done with W4 out.

In article <[email-masked]>, [email-masked] (Tim
Hunkler) writes:

|> 
mega-snip
|> Thanks Tom!  The only problem I see is that the 11858-6 / 12191-7
|> combination that I tried failed and the one that you tried worked!!!
|>

I enjoyed it :^). I've been doing a lot more playing around with this.
I really must get a life.

The following applies to attempts to use a WD7000-ASE with a disk
formatted by an SMS/OMTI controller.

As I mentioned, the first time I tried a WD7000 in a 11858-6/12191-7,
I thought it had failed, but it was simply that, for the first self-test
only, winchester controller test 0 takes for ever. My log says
'freezes in test 0'. I did not record the elapsed time, but it was 
many minutes. The same happened with a 11858-10/12191-7 combination.
This time I was not prepared to believe it and waited. This persuaded
me to try the 11858-6/12191-7 combo again, this time with time taken
out to make, a nice chilli.

The controller test 0 time is not quite so long in 15652 motherboards.

On 11858-6 and up, 15652-1 and up, with 12191-5 and up, the business of
involling a disk previously formatted with an SMS/OMTI controller seems
to *require* the use of FBS. This is not what I remember from years ago,
but this time I've been round the loop several times and recorded the
results.

Note that in all cases, the *drive* test gives 'read test fails'.
Furthermore, invol option 7 (or any other option, for that matter) will
give status code 80003 (controller timeout).

If one uses FBS, with or without telling it to use existing badspots, it
claims that that the badspot list is corrupt, but proceeds nevertheless
to format the disk and find all the badspots. The physical addresses
differ from those reported by the SMS/OMTI controller, and there are
only approximately half as many. My experiments with a Micoprolis 170
showed 45(d) badspots with a WD7000 and 98(d) with the SMS/OMTI.
Examples:-

WD7000    SMS/OMTI
BB0       BB5 BB6
CD0       CD5 CD6

After FBS has done its work, invol works perfectly, But I skipped option
7 for obvious reasons.

Also, contrary to my recollection, it was necessary to uss FBS when
moving the disk back to SMS/OMTI. Plainly, the physical badspot list
(even when empty) is completely incompatible, at least on the
Micropolis 170 and 380-FA. I have not tried a MAXTOR 380-FA.

I also had some fun with one particular disk. It was Micropolis 380-FA
that I bought at a rally for 15 UK pounds. Getting that one to go was wierd.
Even FBS refused to work. What did work, though, was invol option 7, but
giving it an entirely spurious manually added badspot. I would never have
'thought' of trying this, but I was in exhaustive search mode. Invol option 7
with no manually added badspot had failed completely. Then I could run
FBS and find the real badspots. Turns out there are none at all. It's
also the quietest Micropolis 380-FA I've come across.

I now have all my disks fully functioning. After all that work making
the 170s work with WD7000, they are now paired up with SMS/OMTI
controllers. As I said, I really must get a life.

Tom Brock.

-- 
Home:    [email-masked]
Work:    [email-masked]

From: [email-masked] (Tom Brock)
Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb.
Date: 24 Nov 1996 10:57:04 GMT

Maybe you weren't convinced, especially after the post from
Harry Selfridge <[email-masked]>, quoting the
authoritative WD7000 word from HP. I began to doubt myself, 
and went back and tried again.

I am speaking to you from a 11858-6 12191-5 with WD7000, 760-FA,
8 Mbytes of RAM, token ring, and 4-plane graphics, running
10.4, December 1992 (no patches).

Don't try this with 4 Mbytes of RAM: it takes 10 minutes to boot up.
As you can see, it gives a remarkably good impression of a
functioning node: not quite up there with a 32 Mbyte DN4500, but
nonetheless servicable.

As promised, here is the table for the 15652-1

Motherboard Boot        WD7000
            PROM        supported
 
15652-01    12191-2     No (fails winchester disk self-test 1, just like 11858)
15652-01    12191-5     Yes (boots off 760-FA)
15652-01    12191-7     Yes (boots off 760-FA)

Tom Brock.

From: "Harry E. Selfridge" <[email-masked]>
Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb.
Date: Fri, 22 Nov 1996 10:53:23 -0800

...
The minimum cpu revisions for the wd7000 3 function scsi disk controller
are as follows:

	series 4000		rev 25 or later
	series 3500/3550	Part #11858 rev 9, or part #15862 rev 1 or later
	series 4500		rev 5 or later
	series 5500		All

From: Tim Hunkler <[email-masked]>
Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb.
Date: Fri, 22 Nov 1996 01:22:54 -0700

Andrew Kerr wrote:
> 
> I purchased a 760mb apollo hard drive for my 3500 and was awfully
> disapointed when I looked at the rev level and noticed a 6.  So now I'm
> left with a 760mb hard drive and a wd7000.  I have the 10.4 and 10.4.1
> tapes, and I can set up the Authorized Area onto the hard drive with my
> friends 5500, or maybe an old 3500 that can take this drive if I can
> find someone that has one.  Is anyone interested?
>         While I am taking the time to post, I'm looking for a 3500 or better
> (preferably a 4500 and up) that can take this hard drive.  I've got this
> little non-existant budget, so selling the drive would be better, but
> I'd sure like to have a new apollo to keep my 3500 company.
>         Thanks for taking the time to read this, and I'll look forward to any
> reply to this post.

Don't give up hope yet.  It could be that if you upgrade the boot EPROM that
you will have better success.  I have been trying to figure out exactly what
combinations of DN3500/3550 motherboard and boot EPROM it takes to be able
to successfully use a WD7000 and here's what I know so far:

config  motherboard   boot      WD7000      760MB
        rev           PROM      supported   disk
------  -----------   -------   ---------   -----
#1      015652-4      12191-7   *WORKS*     *WORKS*
#2      011858-6      12191-2    fails
#3      011858-6      12191-7    fails
#4      011858-4      12191-2    fails
#5      011858-4      12191-7    fails
---reported by Tom Brock, [email-masked] ---
#6      015652-1      12191-5   *WORKS*     unknown, but 380 works
#7      015653-00     12191-7   unknown, but should work
#8      011858-6      12191-5    ?
#9      011858-10     12191-6    ?

It seems that the 015652 and above seem to support the WD7000.  Once the
WD7000 is supported then both 380MB and 760MB drives should work, as well as
SCSI drives with the right patches.

Some comments I have received indicate that a motherboard rev of 9 is needed
for the WD7000, I can only assume that this refers to the 011858-9 as the
0115642 and above support the WD7000 at a lower rev.

Please supply your motherboard part num/rev and boot prom rev and I'll have
yet another piece of data.

I have reprogrammed the boot EPROM on config #2 and #4 above from rev 2 to
rev 7 without any improvement.  However, if your motherboard rev is not
listed above as a failing one then you might have some luck by upgrading the
boot EPROM.  I have made HEX file images of the various boot EPROMS that I
have that can be used in most popular EPROM programmers and I can upload
them for access if the demand is high enough.  You'll need a machine that
can handle a AM29C512 or AM29512.

I also have one DN4000 that was parted-out and so I salvaged the EPROM from
that and turned it into a spare 12191-7.  I may be persuaded to part with
it.

Perhaps we can gather yet more input and solve this puzzle completely?
If we can get Tom Brock to try 12191-7 boot EPROM in the 011858-10
motherboards along with the WD7000 that would flush out some more data.

Anyone else out there with working WD7000 configurations that would not
mind popping the cover and reporting motherboard and EPROM rev's????

-- 
         \////
        ( o o )                 http://www.goodnet.com/~hunkler
======oOO-(.)-OOo==============================================
Tim Hunkler                 (602) 814-4511, [email-masked]

From: Christian Anzenberger <[email-masked]>
Subject: Re: does DN3500 support 760MB using WD7000
Date: Thu, 31 Oct 1996 12:03:30 +0100

Tim Hunkler wrote:
> Has anyone out there successfully used a 760MB drive with a WD7000
> controller on a DN3500?

Hello World.

YES. The DN3500 was available from factory in this configuration.

For upgrading you need the following revisions:

DN3500    CPU 011858    Rev. 09
DN4000    CPU 009992    Rev. 25
DN4500    CPU 013031    Rev. 05
DN5500    all

DN3000 is not supported. Jumper settings see UM Apollo Archive.

Have fun. Have success.

Chris.

From: [email-masked] (Paul Szabo)
Subject: Re: does DN3500 support 760MB using WD7000
Date: 31 Oct 1996 20:39:36 GMT

I think those CPU part numbers and revision numbers are slightly out. My
view of them (which may in fact be mistaken):

DN3500    CPU 011858    Rev. 09
DN3500    CPU 015652    all
DN4000    CPU 009992    Rev. 22
DN4500    CPU 013031    all
DN5500    A1631-66001   all
DN3000 is not supported.
For jumper settings see the /systest/ssr_util/jumper program.

Hope this helps.

From: [email-masked] ((jt) John Thompson)
Newsgroups: comp.sys.apollo
Subject: re: SCSI disks on 5500?
Date: Thu, 27 Aug 92 17:18:59 EDT
Organization: The Internet

> I've read the faq, but it doesn't make the answer to this question entirely
> clear.  Can I connect an external SCSI disk to a DN5500 with a WD7000
> controller?  If so, is there any limitation on the size (eg 1.2GB)?  Is the
> process for involing etc.. the same as for a 425t?

OK -- let's make it clear then.

You can not hook up any SCSI disk drives to a WD7000 controller.  In fact, you 
can't use SCSI drives on any Apollo machine except the DN2500 (the 9000/4xx is
an HP/Apollo box).

You CAN hook up up to 2 ESDI drives to a WD7000 controller.  There are only 
three (?) drives that are supported, though -- the Maxtor 8760E (697MB), the
Maxtor 4380E (329MB FastActuator) and the Micropolis(?) 170MB drive.  The 
controller can apparently figure out what's on the other end, and act 
appropriately, so there aren't jumpers for the drive type itself.  I think I've
heard that you can add different drive types as your two drives (e.g. a 697MB and
a 329MB drive).  

You CAN install up to 2 WD7000 controllers in your system (DN3500/DN4500/DN5500).
The SCSI bus _must_ be disabled on the second controller.

You CAN install a SCSI cartridge drive or floppy, but only if you do not have a
non-SCSI one in place.  If you have a non-SCSI tape/floppy, you must disable the 
SCSI bus.

If the SCSI bus is enabled, you CAN add up to 7 SCSI devices total of CD-ROMS,
4mm drives, 8mm drives, and 9-track drives.  I'm not sure whether the 4mm drives
are explicitly supported, but I'm almost certain that I read somewhere that they 
work.  I've read that SCSI device 0 is reserved for the cartridge/floppy drive, 
but that might have changed.

The 8mm tape drives must be SCSI ids 1,2,3, or 4.  These correspond to devices
rmts8, 9, 10, and 11 (12-14 for non-rewinding devices).  Although wbak is not
officially supported on 8mm drives, it works fine at 10.3+ (and at 10.2?).  Use
m0 for SCSI id 1, m1 for SCSI id 2, etc.  There is a long pause before it starts
writing the tape with wbak.  The tar and omniback packages work just fine (as do
lots of other vendors' backup packages, I'm sure).

Clearer?

-- jt --
John Thompson
Design Services Engineer / Sys-Admin
Honeywell, SSEC
Plymouth, MN  55441
[email-masked]

From: [email-masked] (Michael A. Thomas)
Newsgroups: comp.sys.apollo
Subject: Re: Connecting two disks to an Apo
Date: 19 Jan 1995 20:46:00 -0700
Organization: Evergreen Communications  Phoenix, AZ

---Deleted text regarding 380MB FA disk on OMTI controller

> 
>I'd really like to make this disk work, and get a definitive statement
>as to whether an OMTI controller supports two-disk configurations...
> 
>Thanks in advance for any help !
> 
>Naoto Horii  /   [email-masked]
> 

   I can tell you that the OMTI controller will definitely support
a 2nd disk drive.  The secret is to install jumper W5 on the controller,
this will enable the drive to talk to a 2nd ESDI disk.

   The 11914 controller works well with a 2nd disk and my documentation
indicates that the 10119 and the 10741 (DN4000) should also work.  It
is also possible to mix drive types, i.e. a 170MB and 380MB.  Disk
to disk copies using the cpt command will also produce bootable
disks, though I haven't tried this with different sizes of disk drives.

   If you examine the drive select jumpers on your first drive you will
discover that it is set to DS1.  The Apollo system expects the boot
device to be strapped as disk #1, although all of the software will
refer to it as drive #0.  Your second disk must be strapped as disk #2
and of course the software and diagnostics will see it as drive #1.
The previous statements only apply to the 'straight-through' style
of daisy chain cable.  If you've stolen a PC style of daisy chain
which will usually have a 'twist' in the cable near the 2nd drive
connector, you will need to strap both drives as DS2.  The PC style
cable will convert one of the DS2 settings to a DS1, via the twist,
for the controller.  Confusing, eh?

   Terminating doesn't seem to be a big issue.  I've had the first
drive terminated, the second, both and neither.  Usually doesn't
seem to cause any problems, but in reality it is probably best
to terminate the last physical drive on the cable.

   If you install your second drive in an external case instead of
simply laying it on it's side on top of the power supply, you will
need to power it up before applying power to the system.  Seems to
work just like SCSI, the controller likes to find the *all* of the
drives when it finishes it's own post (power-on self test).  BTW,
watch the little red led on the controller, if it doesn't go out
after a few seconds it has failed it's own post and is defective.

   I've only played around with a couple of 'non-apollo' drives,
but the biggest problem was jumper 31 on the drive logic board.
This jumper is for hard or soft sectoring and should be out for
the OMTI controller.  I believe it is in for the WD7000.  The
jumpers 16-29 are for setting up the number of bytes per sector,
16 being a binary 1, 17 a 2, 18 a 4, and so on.  BTW this doesn't
seem to bother the Apollo's that much, I once set up a drive for
only 512 bytes per sector and it formatted and ran just fine!
Confused the heck out of the users who would interpret the block
count as the amount of free space left.  Surprised me that it
even worked.  

   If you have access to another Apollo there is a utility with
some of the jumper information required.  Just set your working
directory to /systest/ssr_util and invoke jumper.

Hope this helps some,

Mike

From: [email-masked] (James S. Vera)
Newsgroups: comp.periphs,comp.sys.apollo
Subject: Priam 7050 Hard Drives and Apollo DN300 shoeboxes
Date: Fri, 29 Mar 91 23:27:10 EST

I recently began a search for facts about the hard drives in our
Apollo DN300 shoeboxes.  After much search I am reporting back on
what (little) I have learned.

First off the hard drive in my shoebox is a Priam 7050-41.  As many of
you know Priam is not quite what it used to be and it turns out that a
company called Sequel (sp?) +1.408.987.1533 now handles the drives.
Joe Grove in technical support told me the following:

	Drive		Interface
        -----		---------
	7050-11		Priam Proprietary 
	7050-21		SMD
	7050-41		ANSI X3.101

Kathy in Sales said she would sell me the interface board to change my
7050-41 to a 7050-21 for $500 and she seemed willing to deal (maybe
$250). [if for some reason I was dieing for a small SMD drive the
Minicomputer exchange sells an unused 84MB drive for $125].

Closure:
1) Unless it turns out that ANSI X3.101 to anything-useful converters
these drives are probably boat anchors.
2) The rumor that the drives are ST-506 compatable is unfortunately
almost certainly wrong.
3) Someone on the net sent me a list of the pin outs for the drive
which he obtained from some Apollo literature.  The pin outs did not
exactly match the pin outs in the ANSI X3.101 literature. (Why? I dont
know).

Thats all I know.

-- 
James S. Vera      |         Internet	        |Standard Disclaimers
Stanford [email-masked]|Blah Blah Blah Blah
Bellcore           [email-masked] |vvv My WARNING vvv
I am an ASSU Graduate Senator, Engineering & Earth Sci.  Be Suspicious!

Date: Sat, 30 Mar 91 12:26:29 -0800
From: James S. Vera <[email-masked]>
To: [email-masked] (Jim Rees)
Subject: Re: Priam 7050 Hard Drives and Apollo DN300 shoeboxes 
In-Reply-To: Your message of Sat, 30 Mar 91 12:16:00 -0500.
             <[email-masked]> 

Here's the pin outs I have:

James
-------------
	Table 1, Pin Assignments from ANSI X3.101
Signal	Ground	
Pin	Pin	Signal Name				Signal Source
----------------------------------------------------------------------
1		Ground					---
		CONTROL BUS
2	10	  Bit 0, Select Attn Device 0		Host/Device
3	10	  Bit 1, Select Attn Device 1		Host/Device
4	10	  Bit 2, Select Attn Device 2		Host/Device
5	10	  Bit 3, Select Attn Device 3		Host/Device
6	10	  Bit 4, Select Attn Device 4		Host/Device
7	10	  Bit 5, Select Attn Device 5		Host/Device
8	10	  Bit 6, Select Attn Device 6		Host/Device
9	10	  Bit 7, Select Attn Device 7		Host/Device
11	12	  Parity (optional)			Host/Device

13	14	SELECT OUT/ATTN IN STROBE		Host
15	16	COMMAND REQUEST				Host
17	18	PARAMETER REQUEST			Host
19	20	BUS DIRECTION OUT			Host
21	22	PORT NABLE				Host
23	24	ADDRESS MARK CONTROL (optional)		Host
25	26	READ GATE				Host
27	28	WRITE GATE				Host
29	30	BUS ACKNOWLEDGE				Device
31	32	INDEX					Device
33	34	SECTOR/ADDRESS MARK DETECTED		Device
35	36	ATTENTION				Device
37	36	BUSY					Device

39	38	READ DATA +				Device
40	38	READ DATA -				Device
42	41	READ/REFERENCE CLOCK +			Device
43	41	READ/REFERENCE CLOCK -			Device
45	44	WRITE CLOCK +				Host
46	44	WRITE CLOCK -				Host
48	47	WRITE DATA +				Host
49	47	WRITE DATA -				Host
	50	Ground					---