JDB8042@VENUS.TAMU.EDU (John D. Baker) (12/02/90)
I have a few questions regarding Apple 3.5" disk equipment. 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? 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? In other news: 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!). Please elaborate, as it sounds like a quick and sneaky way to add a hard disk to a //e (3.5 controllers are easily obtainable and much less expensive than a EssSeeEssEye card). Thanks for the help. John D. Baker ->An Apple 5.25", 3.5", 8" ZCPR3 nut //
MQUINN%UTCVM@PUCC.PRINCETON.EDU (12/02/90)
On Sat, 1 Dec 90 12:27:40 CST John D. Baker said: >I have a few questions regarding Apple 3.5" disk equipment. > >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? > >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? Well, I don't know if you were aware of this, but Apple makes -two- 3.5" 800k drves (the Apple 3.5" Unidisk drive and the Apple 3.5" drive). They're virtually identical in operation, except, the Unidisk is a little 'smarter'. The Unidisk has firmware IN the drive that reads one 'block' at a time. The Apple 3.5" drive doesn't have this, so the computer has to tell the drive EXACTLY -HOW- to read each block, which, supposively, takes a little more time. The Unidisk already 'knows' how to read a block, so all the computer has to tell it to do is -WHICH- block to read. Because of this, the computer can't take complete control of the Unidisk drive to do sector editing, track examination, nibble editing, etc. All the computer can do to a Unidisk is tell it which block to read or write and the drive does the rest. Since the Apple 3.5" drive doesn't have this 'capability', the computer has to tell it -everything- to do. Which track to move to, how far to move the drive arm, which head to access, and what bytes need to be written or read to the blocks, sectors, tracks, sync bytes, address fields..... So, with the Apple 3.5" drive, there's nothing preventing you from doing a sector edit. The AMR & AE drives are, basically, Apple 3.5" drive clones (I think). Both the Unidisk 3.5" and the Apple 3.5" drives were designed to use the smartport. (here's some speculation, can someone confirm or 'un'confirm this?)... ProDOS probably looks to see which kind of drive is connected. If it's the Unidisk, then ProDOS only says, "read or write block #xxxx". If it's the Apple 3.5" drive, ProDOS goes ahead with all the technicle details of finding the track, head, & sectors, then actually does the writing. >In other news: > >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!). > >Please elaborate, as it sounds like a quick and sneaky way to add a >hard disk to a //e (3.5 controllers are easily obtainable and much >less expensive than a EssSeeEssEye card). The Hard drive probably makes ProDOS think that it's a Unidisk. All ProDOS is concerned with is block information, so the smartport device (the HD in this case) can have just about any number of blocks available for prodos to access. >Thanks for the help. > >John D. Baker ->An Apple 5.25", 3.5", 8" ZCPR3 nut // ---------------------------------------- Michael J. Quinn University of Tennessee at Chattanooga BITNET-- mquinn@utcvm pro-line-- mquinn@pro-gsplus.cts.com
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (12/03/90)
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
kimbrennan@gnh-starport.cts.com (Kim Brennan) (12/10/90)
Tood, the Unidisk 3.5 >CAN< do nibble editing, but nobody has bothered to go to
the difficulty of programming it so it can do it. Basically what has to be done
is for a program to be written (in 6502 assembly) downloaded INTO the Unidisk
3.5 (so that the internal 6502 of the Unidisk 3.5 can run it) and then
executed. Obviously the market has determined that this is more trouble than it
is worth and hence it has never really been done.
Someplace I had the tech note that said how much memory was inside the
Unidisk 3.5 (1k or something) but it is probaly unavailable to ME at the
moment. Hey, what's the good of a drive being 'smart' if nobody ever instructs
it.
INET: /\_/\ kimbrennan@gnh-starport.cts.com
/ o o \ America Online: KimBrennan
( v ) ______
/// \\\ \\
( / /\\
| || |\___/ / ))
/// /// /// ((
))
~