QIC NEWS and Notes vol. 1 no. 7

[Jesus Monroy Jr]

Released
+----------------------------------------+
QQQQQQ II CCCCCC
QQ QQ II CC N E W S and N O T E S
QQ QQ II CC for 386bsd-Linux-Mach-OS/2
QQ QQ II CC (and sometimes minix & coherent)
QQQQQQ II CCCCCC Vol.1 no.7
QQ (r)
Quarter Inch Cartridge (Tape Drives)
+----------------------------------------+
News about QIC-40/80

(Disclaimers move to bottom.. getting to big.) (crowd:YEAH!!)

*=======================================*
| Tabloid Contents |
*=======================================*
| <1>__ Hey! What happened? |
| <2>__ Question, Questions |
| <O>__ One OS at a Time |
| <M>__ Meaningless dribble. |
| <F>__ FLAMES to the editor |
| <N>__ NEXT ISSUE |
*=======================================*
hint: search for "<?>__"

<1>__ Hey! What happened?

OK, OK.... QIC NEWS and NOTES is still in
reorganizing.. so whats's new! This issue is much more
technical than the usual. The next issue will more inline
with the usual format.

Also I should note, at this time, the standard for the
QIC-40/80 and planned predecessors is moving in different
directions. Namely, away for the FDC one day. The QIC
committee meets in September and I hope to be there.
Send me comments for them if any.


<2>__ Question, Questions.

Is there mailing list for QIC NEWS and NOTES?
---------------------------------------------

I've been asked this more than once, and by people
that think less of QNN than those that like it. The answer is
no, not at this time, but I am looking for an FTP or archive
site as well as a wide-area list server. In any case, I will
do what I can and report back.

--------------oOo---------------

Is there a FAQ for the tape drives?
------------------------------------

Yes, cause their such nice guys and all, here is the
list of "who to who". Keep in mind, that except for 386bsd,
everyones' tape drive list is mixed in with the rest of the
FAQ(Frequently Asked Questions). So finding your tape drive
may not be a picnic. As such, if every OS group mails me a
list of "working or under-development" drives, I will make a
"Tape drive FAQ for *nix type OSs". (I promise, I do.)

FOR 386bsd ask:
---------------
Working tape drives and specifics:
and...@oti.on.ca (Andrew Cornwall)
r...@ecs.soton.ac.uk (Bob Kemp)
EXECELLENT work by the way.

Drivers underdevelopment:
men...@fnal.fnal.gov

General FAQ:
is available via FTP from hrd769.brooks.af.mil in the
"~/pub/FAQ" directory.

FOR LINUX ask:
-------------
m...@theory.TC.Cornell.EDU (Matt Welsh)

FOR MINIX e-mail:
-----------------
ove...@plains.nodak.edu (Glen Overby)

FOR Coherent e-mail:
--------------------
mi...@array.com (Mike Willett)

FOR MACH
--------
fg...@cardinal.ncsc.org. (Frederick E Gray)

FOR OS/2 & MACH
---------------
I have not been able to locate the FAQ's at this time.
But I'm sure someone will tell me for next time.

--------------oOo---------------

Questions specifically asked by jeme...@trumpet.calpoly.edu
------------------------------------------------------------

1) Specifically I want to know whether there is a hope
that I will be able to use the Mountain Fail-Safe
tape drive with the Linux operating system, and if
so, can it be done with the standard two floppy
controller (with two floppies already attached) or
will a four floppy controller be required?

To answer your first question, Yes, you should be able
to one day use your Mountain Fail-Safe tape drive. To the
second part of your question, a "standard" two floppy
controller can be use, as well as a four floppy controller,
but there are some small restriction.

The first restriction depends on the actual writer
(implementer) of the device driver, and the OS (Operating
System) in use. If the OS does not allow access to multiple
devices on one controller at a time then, it can not be done.
If the writer does not wish to add this level of complexity
to his/her driver, it will not be done. Lotsa "ifs" as to why
this won't be done, but ask for a specific and it might be
done (at least I will do it, if possible).

If your question is "can it be done and can it be done
so that all devices(QIC & FDC) are accessible -on the fly- ?",
then the answer is YES, it can be done. However, if your
question is "WILL it be done", I can not say. That question
is dependent on the writer and the OS, explicitly. My driver
will allow both QIC & FD access on the fly.


2) Will I be able to exchange tapes with other
minicartrige tape drives, such as those made by
Archive, Irwin, Colorado Memory Systems, Alloy or
Wangtek?

Yes, provided the the tape(s) follows the QIC-40/80
tape standard. Thought this is straight forward there is the
problem of "standard interpretation". For this a testing
organization exists, and the last reports had some companies
not following the standard close enough to call it "by the
book". Also, note that QIC-80 drives can read, but cannot
write to QIC-40 drives. This follows the old "lets not make
it 100% backwards compatible so we can sell more of the new
units" marketing ploy. This "non-write" feature (sabotage)
can not be bypassed because the drive is an independent
device. That is, it has it's own microprocessor on board so
it does all the "really" low-level logic on it's own.

3) As I understand it, the QIC-40 and QIC-80 standard
specify how data is stored on the tape. Perhaps there
are other standards that specify the interface between
the floppy controller and the tape drive. Do you know?

The answer to your question is YES. There are
multiple standards that facilitate the the QIC operation for
the FDC (Floppy Disk Controller) based units. The one that
concerns us the most is QIC-117, the common command set.
For more information on QIC standards in general ask me for
QIC NEWS and NOTES vol.1 no.1. e-mail me as:

jmo...@netcom.com
subject: [BACK ISSUE REQUEST]


4) Are there timing constraints on communication between
the tape controller and tape drive which make it
difficult or impossible to do on a *nix style operating
system?

Yes, there are quite a few timing issues which make it
difficult to operate the QIC -tape driver- in a "correct
manner". By a "correct manner" I mean, having it work as a
streaming "like" tape system, not necessarily one that just
"bumps along".

One of the main problems is a "miss" on a tape
read/write. What happens is that since the "miss" occurred,
the software driver MUST rewind the tape to before you
"missed", about 2 or 3 segments that is. From there, there
is a avalanche of issues that will be shown in the "RTC
NOTES", which I mentioned in the previous issue of QNN.

--------------oOo---------------

Thanks to jeme...@trumpet.calpoly.edu for his questions, and
making my life difficult. :)

--------------oOo---------------

Questions specifically asked by Someone who's name I lost
---------------------------------------------------------
> For example, have an article on actually dealing with QIC devices
> on the port/IRQ level.

I will note your request.

> Have another dicussing the problems with writing
> a QIC driver for OS/2 or something.
>
Noted.

> Hell, you might even want to have a
> section devoted to keeping track of what companies are
> writing (or have written) drivers for their hardware...
> and for which operating systems.
>

Looks like I got my work cut our for me.


--------------oOo---------------


IF you have specific questions, don't be afraid to send them
to me:
jmo...@netcom.com
subject: [QIC NEWS and NOTES: question]



<O>__ One OS at a Time

What follows is from a conversation between Mr. David Brown of
UCSD and myself about his work on the MACH 386, QIC-40/80 driver.
David Brown has one of the earliest (if not the first) known
working driver for the QIC-40/80.
===============================================================
> Date: Wed, 5 May 93 06:38:56 -0700 (PDT)
>
> Please forward this information on to whoever needs it.
>
>Jesus Monroy Jr writes:
>> Yes, the timing factor to a read/write must be precise.
>> The spec says 2.5us (I think) and I talked to the
>> designer. He said it was a bear to do in DOS.
>
> I think there might be a little bit more paranioa
> with the timing issue than necessary. There is a
> very small number of places where timing is critical.
> In every other place you can take however long you
> feel like.
>
> Here's the critical places I can remember:
>
> - Most crucial.
>
> Between each sector of a read or write, you have
> 2.5us to issue another read or write command to the
> FDC. I implemented this in two ways. Originally, I
> allocated a physically contiguous 32k buffer in the
> kernel. This way my read segment routine could just
> issue a multiple sector read command to the FDC.
> Whenever there is an error sector to be skipped and
> not read or written, a new command is used. The
> length of the skipped sector is more than enough
> time to write the required data.
>
> After I got this working, I tried issuing individual
> FDC commands after each sector. On my 16 Mhz 386SX
> (about the slowest thing I can imagine this running
> on) it works most of the time. Once in a while the
> driver takes too long to get to the data and it has
> to back up the tape (it's not fatal, it's just slow,
> and wears the tape out faster).
>
Every thing you say follows all the information I have
and the situations are as I imagined in my design.
Also I talked to Maynard; I have never had had luck with CMS.

> - Next crucial.
>
> After starting the tape you have a couple hundred
> usecs to get the FDC reading or writing. On some
> drives this can be on the order of seconds. Getting
> the command to the FDC is not a problem here (this can
> usually be done in a few usecs), however, the FDC just
> did a seek and it is going to wait the mandatory head
> settle time. After implementing this, I discovered
> that it isn't a problem at all. There is a rather
> enormous amount of time that the drive takes to get
> the tape up to speed so it has to be seeked well into
> the previous segment anyway.
>
Yes, these things are mentioned in QIC-117, although the
document is a bit verbose and terse in places.
I plan to explain the QIC-117 from notes I made with
a friend (over ago year now).

> - More notes.
>
> Unless there's something I've forgot about, these are
> the only important timing issues. _ALL_ other timing
> is completely irrelevant. The driver can take however
> long it wants for operations. Most of the things it
> will be doing (such as seeks) take so long to perform
> that there isn't even a performance problem with the
> driver being too slow. Many of the timeouts are done
> by the FDC because the drive sends out index pulses
> regularly. These catch reading past the end of tape
> and such things.
>
Yes, my exact reason for working on a FDC driver. The work
involved gave me many of the experience you now relate.
I have more notes on the FDC, but I am hoping to publish
these in sept. or so.

>
> [[stuff deleted]]
>
> There is one aspect of the drives that the spec doesn't
> describe. Most drives can coexist with a drive B. The
> drive is normally dormant. It is enabled by issuing
> some particular sequence of seek operations to wake it
> up. Another sequence puts it to sleep. Both Colorado
> and Mountain have very different sequences. Neither
> of these are documented. When I tried talking to
> Colorado, they wouldn't tell me the information. After
> an evening with a logic analyzer, I figured out how to
> wake up the drive. This information is in my driver,
> or I can send it to you.
>
This is actually new information and is the first time
I have heard this. I think may users will be happy about
this.

>> However, versions run in SCO and ICS(Interactive?)
>> this tells us it can be done.
>
> Remember, my driver works. When people complain that
> timing is too critical or that something works a
> certain way, ask them if they have working code.
>
> Right now I can say:
>
> qic -r5 > filename
>
> and read the contents of file 5 on the tape into file.
> For the most part, the tape streams during the whole
> operation. This is on my 16Mhz 386SX.
>
> I can say:
>
> qic -a 'Description' < filename
>
>
> And write a new file on the tape. Again the operation
> streams most of the time. The streaming breaks down
> when uucp tries to use the modem, or something else
> takes too much time. The problem is in the data path
> from the driver to the user program. Also, computing
> ECC codes on this machine takes up about 75% of my cpu
> so if something else is running (say compress) it can't
> stream. I have a reasonable workaround with a reblock
> program that reads in large blocks and writes them.
> With a small amount of work, I could improve performance
> by changing this reblock program to read and write on
> demand (with select).
>
> Where my driver breaks down isn't because of timing.
> The code isn't organized right and I didn't have time
> to fix it. The seek algorithm is in the wrong place
> and works poorer than necessary. My seek algorithm
> doesn't work very well on drives other than my own
> because I haven't had the time to work on the other
> drives. A friend with a mountain drive has read and
> written tapes with my driver, though.
>
> I'm pretty sure I can speak authoratatively about
> using the drive and its interface. Before believing
> someone about some timing issue (I have no idea why
> timing would be difficult under dos, unless someone
> was trying to do it without interrupts) make sure
> they've tried it.
>
> Sorry for being a bit harsh, I've just had too many
> other people telling me that the driver I have running
> is impossible to write.
>
I found none of your comments harsh at all.
Experience talks with knowledge; Ignorance talks with rhetoric.


<M>__ Meaningless dribble.

"It was so annoying I didn't even notice."

-Jeff Dehard

"A market is not held for the sake of one person."

-African Proverb

"Communications among the prisoners of war were recognized
early by the North Vietnamese as being a vital support to
prisoner resistance and morale. Thus, they struck at the
communications system constantly."

-"When Hell was in Session"; preface
-Senator Jeremiah A. Denton
Chairman of the Board
United Families of America


<F>__ FLAMES to the editor

====================================================
From: le...@microsoft.com
Subject: re: QIC NEWS and NOTES vol.1 no.6
Date: Tue, 29 Jun 93 03:23:05 PDT

Windows NT includes support of QIC-40/QIC-80 media formats
via the QIC-117 floppy/tape interface. in case you are looking
for QIC information, outside of these random 386bsd comments
included in this online newsletter.


====================================================
mail pe...@nmti.com
Re: Subject: Re: Subject: Re: Ramblings about the ...

> OK, I've tried tact. I've tried humor.
> Let's get down to brass tacks.
>
OK.

> You are not communicating. Not with me. Not with anyone.
>
I speak to peole daily....
I don't know what you are referring to.

> Some people are humoring you in the hope you've
> actually got something technical to contribute.
> That's the *best* you've got going for you.
>
Was that a compliment?

> Quit writing in parables.
>
Why?

> Quit writing chatty little newsletters that have
> nothing to do with the net.
>
I think this is only your opinion.

> Start communicating.
>
Aren't we talking?

====================================================
From: Risto Widenius <wide...@cc.helsinki.fi>
Subject: ramble
Date: Thu, 29 Apr 1993 05:46:31 +0300

you shine much too bright for their little sky.
my sincerest support.

-rw-------

___________________________________________________________________

<N>__ NEXT ISSUE

o.... "Documentation. Us and Them."
o.... QIC devices on the port/IRQ level.
o.... "Update on the tape drives that work!"

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

"QIC" is a registered trademark of the
Quarter-Inch Cartridge Drive Standards, Inc. (QIC).

This publication is not affiliated with "QIC" or "QIC DATA NEWS".

All comments, issues, and errors are only attributable
to the quasi-editor-in-chief.

Back issues of QIC NEWS and NOTES are available via e-mail
to jmo...@netcom.com subject: [BACK ISSUE REQUEST]

IF you have specific questions, don't be afraid to send them
to jmo...@netcom.com subject: [QIC NEWS and NOTES: question]
___________________________________________________________________________
Jesus Monroy Jr jmo...@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________

[Peter da Silva]

I notice that you've started communicating. Thanks. I wish you'd been
doing that all along.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Hefur thu fadhmadh ulfinn i dag?
'U`
"Det er min ledsager, det er ikke drikkepenge."

[Jordan K. Hubbard]

int
main(int argc, char **argv)
{
float f;

for (f < 0.0; f < FLT_MAX; f += 1.0)
printf("Where's the fucking code then?\n");
}
--
Jordan Hubbard j...@violet.berkeley.edu, j...@al.org, j...@whisker.lotus.ie

[KP KP]

Good read!