From: toddpw@cco.caltech.edu (Todd P. Whitesel)
Subject: Re: AE Flopticals...RamFAST & TAPE DRIVES
Organization: California Institute of Technology, Pasadena
Date: Wed, 9 Sep 1992 10:54:36 GMT

posty@socs.uts.edu.au (Andrew Roughan) writes:

>OR, these drives may have the "active termination" feature which caused
>Todd to blow his PLI drive up.

Actually it just got flakier as time went on. I sent that one back and bought
the Tulin drive a couple weeks later.

>Richard "SCSI Part, The Snail" Bennett has written a GS/OS SCSI driver for
>these drives. He is currently waiting on Insite to deliver the technical
>doco on the mechanism before he releases it.

Well Insite only took 5 days (including the weekend) to get them to me, and I'm
in the same state. If he has any specific questions have him mail me here on
punisher and I'll type in the specific bits he wants to know. They're quite
interesting reading, maybe I should just xerox the lot and ship it to CVT :)

>1)There are currently 3 known drivers for floptical drives.
>-Tulin sells one with thier drives.

Theirs is not available yet, it is in beta testing and should be available any
day now. I called Tulin last week and they said they would call me at work when
the driver was ready. I assume that all of these are for the DMA SCSI right?
I still need to track down my lead on a cheap one, which I am only getting so I
can use the floptical as it was meant to be used :( . This means I'll have a
RamFast for the quantum and a DMA SCSI for the floptical. bleagh.

>2)The current floptical drives only use MFM encoding. This means that 800k
>GS disks (GCR encoding) can not be read by these drives.

This is correct.

>3)The AE Floptical drive requires a "mode sense call" before either a "write"
>call or a "format" call.

The Insite mechanism itself requires this. I quote:
"The drive contains a write lock feature which prohibits write, reassign, or
format operations until an unlock sequence is executed. The purpose of this
feature is to prevent media modification until the initiator determines the
target drive type. The lock is set by a power-up or SCSI reset. The initiator
resets the lock by executing a Mode Sense command requesting Mode Page 2EH with
an allocation length exactly equal to the returned data length (including the
effect of the DBD bit)."
This DBD bit looks like part of the CCS standard and indicates the omission of
an 8 byte section that comes between the header and the 30 byte Page 2EH block.

>Richard has done this and expects to make his tape backup program "The Snail"
>work with the RamFAST. He "may" look into writing a GS/OS SCSI driver for
>tape drives on a RamFAST.

This would be nice. CVT has not made it particularly easy but it is possible.
My congratulations to Richard.

>BTW: According to Richard (so don't flame me) tape drives are actually
>block orientated devices. Apple's SCSITAPE is a character device driver only
>because it is more logical to think of a tape drive as a sequential medium.

Block orientated, yes, random access, usually not. GS/OS defines a 'block
device' to be random access, and a 'character device' to be sequential access.
This is the important distinction that I've been trying to get across, and you
have made me realize that GS/OS really should be using 'random-access device'
and 'sequential-access device' instead. My apologizes to anyone whose ego I
bruised because I expected them to not be fooled by the confusing terms.

>My feeling on this is that SCSITAPE will work with both character and block
>orientated tape drives (IF character orientated tape drives exist).

You might want to rephrase this in light of the previous paragraph but it's
no biggie -- I think we're on the same wavelength finally.

Todd Whitesel
toddpw @ cco.caltech.edu
Newsgroups: comp.sys.apple2