Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: 3.5" disk hardware questions
Message-ID: <1990Dec3.040725.15807@nntp-server.caltech.edu>
Date: 3 Dec 90 04:07:25 GMT
References: <901201122740.204030b1@VENUS.TAMU.EDU>
Organization: California Institute of Technology, Pasadena
Lines: 55

JDB8042@VENUS.TAMU.EDU (John D. Baker) writes:

>What exactly makes the UniDisk 3.5 so different from the other
>Apple-compatible 3.5" drives.  Why can't one sector-edit a
>UniDisk 3.5 while other 3.5"drives _can_ be sector-edited?

Correction: UniDisk's can't be NIBBLE-edited and the other drives can.

All 3.5's can be block edited (5.25 is 2 sectors per block, 3.5 is just blocks)
since they are treated as prodos block devices. Any prodos block device can be
block edited.

>If the UniDisk 3.5s are so different from the others, how can
>AMR and AE make a 3.5" drive that can be used on both Apple
>][s, ][+s, and //es with the 3.5" disk controller AND the //c,
>//c+ and ][gs Smartport?

Another correction: the 'compatible' drives can be used in place of Apple 3.5's
which means //gs and //c+ or older machines with the third party controller
card. Apple's 3.5 card is Unidisk only and is an exteremely lame option.

The Unidisk is special because it is to the other drives what SCSI drives are
to bare drives (i.e. most IBM drives). The Unidisk uses a communications
protocol over the smartport that does essentially what SCSI does -- except this
protocol (the smartport packet protocol) uses the same data transfer method as
the original 5.25 drive -- hence you are lucky if you can get 14K/sec data
transfers with it. The problem with the unidisk is that you have to send a
command to it over the smartport daisy chain (including data if it's a write)
and wait for the drive's controller to handle the request (and then send the
data back if it was a read). The problem with this is that the controller only
has enough RAM in it to handle 1 block's worth of data at a time, so the
process is extremely bottlenecked. Had Apple done things properly (running the
protocol faster would have helped a lot too) then the unidisk could have been
a fairly nice 'smart' 3.5 with diversi-cache performance built into its
controller. As things have turned out, however, there's no point in using a
Unidisk if you can get a bare 3.5 to work because you will be able to get
maximum performance in host software rather than being stuck with the neutered
controller the unidisk is stuck with.

>Way back when the Chinook CT20c and CT40c had just come out, I read
>that they could also be attached to a //e via the UniDisk 3.5
>controller card.  How is this possible?  In fact, it was in a
>copy of inCider (arrgh!) at the time (in their review, in fact!).

Those drives used the smartport packet protocol also. Hopefully they have
better controllers so they are as fast as the smartport protocol allows --
however the packet protocol puts a practical limit of something like 27K/sec
which is about as fast as the bare 3.5's can get with good software (i.e.
diversi-cache, AppleDisk3.5 driver for 5.0, Photonix, etc.).

Some of these details might be off a bit (I don't deal with unidisks directly)
so anybody feel free to correct the above.

Todd Whitesel
toddpw @ tybalt.caltech.edu