From owner-freebsd-hackers  Sun Aug 27 23:39:32 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA04868
          for hackers-outgoing; Sun, 27 Aug 1995 23:39:32 -0700
Received: (from sos@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA04859
          ; Sun, 27 Aug 1995 23:39:32 -0700
Message-Id: <199508280639.XAA04859@freefall.FreeBSD.org>
Subject: Re: ATAPI
To: jdl@chrome.onramp.net (Jon Loeliger)
Date: Sun, 27 Aug 1995 23:39:31 -0700 (PDT)
Cc: freebsd-hackers@freebsd.org
In-Reply-To: <199508280543.AAA00248@chrome.onramp.net> from "Jon Loeliger" at Aug 28, 95 00:43:28 am
From: sos@freebsd.org
Reply-to: sos@freebsd.org
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1825      
Sender: hackers-owner@freebsd.org
Precedence: bulk

In reply to Jon Loeliger who wrote:
> 
> OK, So where can I get a copy of the ATAPI spec?  Does anyone
> on this list have (or know where to find) one on line?
> (Any vague chance of finding one specifically for the NEC 260?)

The SFF specification (SFF8022 I think) floated around on the
net long ago in its final draft version.
I don't know about the NEC, but I pretty sure it is one of
those drives that was made BEFORE the specification was
made :( (why else would NEC make a nonstd drive?)

> Specifically, I guess I'd like to be able to interpret the
> command buffers, and know what the handshakes and protocols
> are supposed to be.
> 
> As Joerg pointed out, the entire buffer from the probe attempt
> does appear to need to be byte-swapped.  This fixes both the
> ident string problem and the devtype == AT_TYPE_CDROM problem.

Hmm, the specification says that the indendification string
is byteswapped, and so are some of the "vendor specific" fields.
There should be no differences in the entries for actual
drive data. 
A solution may be that if the drive fails on the normal
ATA probe (ie its no old IDE disk), then it is some kind
of ATAPI device, if it fails the "standard" ATAPI probe
it is a device that needs special treatment in one or
more cases. Then look up the sucker in a tabel, and see
if we know how to deal with it, or else notify the user...

I think you can find some info in the linux(tm) driver
on the NEC drive, I seem to remember some crude hacks
in there to cope with this model.

Hope this helps you further, I might have a few ideas
left, just not much time to do anything with them :(

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Soren Schmidt  (sos@FreeBSD.org | sos@login.dknet.dk)  FreeBSD Core Team
               So much code to hack -- so little time