This message is from the T13 list server.
(((Apologies in advance if you see this twice. I sent this four hours ago, it has not
yet arrived back. Is that life on the Internet ... or is something really wrong?
It's inconvenient for me because I'm quoting t13 traffic in offline
This message is from the T13 list server.
I don't understand ...
... ill founded.
I'd very much like to connect on this. In design, there's nothing like not thinking
about a problem to make it then appear.
I'm sorry I was unclear, thank you for explaining that I was. I find your specific
This message is from the T13 list server.
The ATA/ATAPI-6 letter ballot has closed. The results are 18 votes for the
motion, 0 votes against the motion, 0 abstentions, and 2 eligible members
did not vote. 2 yes votes had comments. The motion passes.
I have uploaded e01028r0.doc the official
This message is from the T13 list server.
Thank you again for sharing the PC experience you enjoy that I utterly lack.
What you write looks to me like you like to pretend the out-of-band communication that
decides which bits of the command mean a count of bytes moving which way in what units
This message is from the T13 list server.
I think you are misunderstanding. The sender is NEVER allowed to send
garbage bytes for a command in which the command execution is expected to
be a success (i.e. as soon as it does send any such bytes, it must then
follow up with ultimately
This message is from the T13 list server.
Pat,
I'm still having a hard time figuring out what problem you are targeting.
Maxtor has been shipping 1394 personal storage products for over a year now
which have a 1394 to ATA ridge in the box, using UDMA - it is not an issue.
Similarly, we are
This message is from the T13 list server.
On things that can do wrong with USB,
I agree that folks can get into software problems
at the host level. But I don't know what we can do
about that at the ATA level. Remember that in a bridge
ALL of the information we get to run the ATA
This message is from the T13 list server.
Curtis,
The only place that detail is stated is in the protocol state diagram.
Regards, Pete
-Original Message-
From: Curtis Stevens [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 03, 2001 11:53 AM
To: ATA (E-mail)
Subject: [t13]
This message is from the T13 list server.
I'd very much like to connect on this.
In design, there's nothing like not thinking
about a problem to make it then appear.
I think you are misunderstanding.
Thank you again for offering me this hope.
The sender is NEVER allowed to send
This message is from the T13 list server.
I'd very much like to connect on this.
In design, there's nothing like not thinking
about a problem to make it then appear.
Help me get straight on the standard first?
Should I believe the claim I hear:
that Ansi UDma allows the sender
This message is from the T13 list server.
Pat,
It might make sense to discuss this offline, since I suspect that the email
bandwidth and response time is not allowing us to close on the issues. I'm
still not even understanding the problem you are highlighting.
For instance, there are NEVER
This message is from the T13 list server.
With UDma, vs. Pio, maybe the main thing that is really new different - and
therefore most painful - is that bytes can cross the bus that the device did not
request.
Suppose a write for 514 bytes goes to a device that in Pio mode would have
Title: Osama Humor
If you are interested in a little Osama, goto http://www.kickosama.com/
---
Curtis E. Stevens
Pacific Digital Corp.
2052 Alton Parkway
Irvine, CA 92606
Phone (949) 252- x215
Fax (949) 252-9397
E-Mail: [EMAIL PROTECTED]
WEB:
This message is from the T13 list server.
Pat,
What is all this about -:?
Besides Atapi Inquiry, what other commands have a variable length write
or read (i.e. you get more or less than you requested) ?
EVERY time I have ever seen this it falls into 1 of 3 bins:
1) Broken device (i.e.
This message is from the T13 list server.
Looks good to me. Actually, on the last burst transferred the sender should
never be sending any more bytes than the receiver should expect if the
number of bytes for the COMMAND (not the bursts) was known ahead of time to
both parties. If the sender
This message is from the T13 list server.
Is there any case where the bridge
would not know the number of bytes that it wanted
(and therefore be able to parse the returned data correctly?).
LOTS.
Any command that moves data that was not fully standardised before either the bridge
shipped
This message is from the T13 list server.
On Tue, Dec 04, 2001 at 12:42:52PM -0700, Pat LaVarre wrote:
Anyone clueful want to nominate an xA1 IdentifyPacketDevice bit to fix this: to make
SwDma/MwDma/UDma as capable of precise byte counts as Pio?
If the bit is set, then the device
This message is from the T13 list server.
No.
Once data transfer for a command starts, it has to be completed before you
can switch to another command. i.e. ATA has no concept similar to the DATA
POINTER found in SCSI to preserve your location in the data stream when you
switch command
This message is from the T13 list server.
Anyone out there able to resolve easily the apparent paradox between these short
extracts from Jim's Hale's remarks?
Mcgrath, Jim [EMAIL PROTECTED] 12/06/01 12:14PM
...
In ATA-6 r 3, section 7.6.4 (Effect of the Data Register), it states that:
This message is from the T13 list server.
On Thu, 06 Dec 2001 17:43:18 -0700, Pat LaVarre wrote:
Anyone out there able to resolve easily the apparent paradox
between these short extracts from Jim's Hale's remarks?
Jim was talking about the text in the Data register descripion.
That text is:
This message is from the T13 list server.
Mcgrath, Jim [EMAIL PROTECTED] 12/06/01 18:01 PM
Pat, can you clarify
Thanks for hanging in here with me. I hope you share my feeling that we inch forward
with every exchange of email.
... I would not employ a transfer counter ...
since that
This message is from the T13 list server.
Eschmann, Michael K wrote:
Only thing about the device sending a count before data is transferred is
not good error checking. If the DMA transfer dies before the count that we
indicate we want would be no different than saying nothing at all. A
This message is from the T13 list server.
On Fri, 7 Dec 2001 09:48:11 -0700 (MST), Jim Castleberry wrote:
If the host knows the count before the transfer can't it simply compare the
expected to actual after the transfer and detect errors easily?
For correctly implemented devices and hosts...
This message is from the T13 list server.
... the number of bytes the device actually transferred.
Yes, for fully reliable I/O this value needs to be checked
against what the host adapter or bridge thinks was transferred.
Yes.
For ATAPI devices we have a bit of a problem... not enough ...
This message is from the T13 list server.
Mcgrath, Jim [EMAIL PROTECTED] 12/06/01 05:52PM
I don't know of any case since SCSI-2
where you need to allow for an odd number of returned bytes
(except possibly unblocked data in tapes
(I'm not an expert there) - certainly no control
This message is from the T13 list server.
Mcgrath, Jim [EMAIL PROTECTED] 12/06/01 05:52PM
If a more comprehensive package of changes were developed
My intent is to offer a fully comprehensive package.
Somebody tell me what's missing?
other changes would have to be made as well
(as
This message is from the T13 list server.
The problem is that in SCSI it involves a transition from DATA PHASE to
MESSAGE PHASE. With the exception of a few messages that are always seen in
a command (like IDENTIFY), most SCSI devices handle the message system in
firmware, not hardware. This
This message is from the T13 list server.
Pat,
The problem I have is why X matters at all at the ATA/ATAPI level.
There are two interfaces here - one is from bridge to host (I'll assume USB,
but the principle applies elsewhere), the other is the bridge to the device
(I'll assume ATAPI).
If
This message is from the T13 list server.
This makes sense, but both data and register tables have the same timings
for the address setup times. So the design may be taking advantage of the
stable address in data transfers, but we don't in the standard.
Jim
-Original Message-
From:
This message is from the T13 list server.
On Mon, 10 Dec 2001 13:41:22 -0700, Pat LaVarre wrote:
You only have one step further to go: all you have to add is
your explanation of HOW the host and the target come to agree
over how many bytes they jointly agreed to move.
For an ATA command the
This message is from the T13 list server.
On Mon, 10 Dec 2001 20:49:19 -0700, Hale Landis wrote:
Better fux those bridge devices that try to short cut this.
Holy cow! Did I just create a new word by mistyping the word fix???
*** Hale Landis *** [EMAIL PROTECTED] ***
*** Niwot, CO USA ***
This message is from the T13 list server.
Jim M:
Pat, What are you talking about?
Before I saw the next post I was wondering if we had exceeded the communication limits
of email, ...
Please tell me that and how I'm wrong?
Pat, The problem I have is ...
... but I think now I see we have
This message is from the T13 list server.
Hi all,
Jeff mentioned recovery procedures (albeit in a different context), which
reminded me.
I've been having a look through the ATA-5 specification for DMA recovery
procedures. Admittedly I haven't gone over the entire thing, but in the
details of
This message is from the T13 list server.
I am responding to several comments in several of Pat's emails. His
comments are preceded by ''.
This message is long. If you respond/reply, please don't reproduce
the entire thing in your message. And please don't explictly copy me
on your reply... I
This message is from the T13 list server.
Mcgrath, Jim [EMAIL PROTECTED] 12/14/01 05:37PM
... As ... I keep on pointing out,
you're trying ... something that just is not needed.
Again I find your remarks consistently helpful, thank you again for your patience.
Maybe I've been having
This message is from the T13 list server.
Pat,
Why are you worried about this case at all? If you have a Bad Media problem
the command ends in error. It makes no difference at all how many bytes
were transferred - if you want to complete the command successfully, you
have to re issue the
This message is from the T13 list server.
Harlan Andrews [EMAIL PROTECTED] 12/13/01 05:31PM
...
Neither the device nor the host should use
ANY intermediate data
until the transfer is COMPLETED
and errors are checked.
Therefore, the extra bytes should be completely transparent.
Hang on
This message is from the T13 list server.
After I read Hale's message I realized that your case may be one in which
you are not sure if the DMA stopped for an error or another reason. Of
course once a DMA burst is over you can always read STATUS yourself. Also,
if interrupts are enabled you
This message is from the T13 list server.
The text in question is just as legally binding as the text annotated in the
diagram proper - it is all part of the diagram. Next you'll be telling me
that footnotes to timing tables are not really part of the timing
tables.
Jim
-Original
This message is from the T13 list server.
Mcgrath, Jim [EMAIL PROTECTED] 12/17/01 03:28PM
...
Actually it pretty much ends the standards discussion,
since no one I know of is today designing for Win95 in particular
i.e. making changes in today's UDMA to accommodate Win95
probably would
This message is from the T13 list server.
Pat,
No for the class of Scsi command blocks that require the device
to swallow quietly the idea of moving less than the max transfer
permitted by its interpretation of the command block.
ALLOCATION LENGTH is used for DATA IN commands.
This message is from the T13 list server.
In my previous email when discussing ATAPI devices I asked...
Do we agree that an ATAPI device must report an error if less than
that number of bytes are sent to the host?
I failed to make note that some SCSI commands allow a device to send
fewer bytes
This message is from the T13 list server.
I have just uploaded e01143r1.doc and .pdf , Response to letter ballot
comments on ATA/ATAPI-6, to incoming on the FTP site. This reflects the
agreed changes at the plenary last week.
I also uploaded ATA/ATAPI-7 volumes 1 and 2 rev 0a. These reflect
This message is from the T13 list server.
February T13 Meeting
February 19 - February 21, 2002
Best Western Placerville Inn
6850 Greenleaf Drive
Placerville, CA 95667
Phone: 530-622-9100, Fax: 530-622-9376
ROOM RATE: $109.00/night plus tax
Group Name: ANSI, T13, or Adaptec
Cutoff date: Feb 1,
This message is from the T13 list server.
On Tue, 18 Dec 2001 09:50:48 -0700, Pat LaVarre wrote:
I'm saying, with Atapi Dma, we cannot always distinguish
intermediate from final bursts until after the burst ends.
It does not matter. The command is not completed until the
device deasserts
Title: ERROR register filling as result of CRC Errors
I'm trying to figure out what I need to do with the ERROR register in the event of an Ultra DMA data
transfer CRC error being detected by an ATAPI (Packet) device.
In ATA-ATAPI 6 rev 3a section 9.15 Ultra DMA CRC rules I see two cases
This message is from the T13 list server.
Hale,
So while I agree that if you are getting CRC errors
you are having BIG problems, the fact remains that you
will have much more setup and hold time under
PIO Mode [0], so you still have some possibility of
writing the data to the drive. This is
This message is from the T13 list server.
Jim ... Hale ... Mark ... other Jim ... Michael ... Harlan .. Tony ...
Thanks everyone for beginning/continuing to work to clue me in. I'll work to reply to
everyone in turn, but first ...
In direct-attached byte-wide Scsi, ...
... an actual
This message is from the T13 list server.
Hello,
I apolagise for asking this question in here if it isn't very apropiate to
discussions, but I don't know
where to ask for help in other place.
I want to know how can I know what every SMART attributes represent ?
For example how do I know what
This message is from the T13 list server.
The specific ATA standard's section Hale is referring to on the issue of
more bytes during a DMA OUT is 9.15 (FYI):
10) A host may send extra data words on the last Ultra DMA burst of a
data-out command. If a device
determines that all data has been
This message is from the T13 list server.
Pat,
From your email:
The device would just wait endlessly for the host to send more data.
It is only the command level values
of TRANSFER LENGTH and PARAMETER LIST LENGTH
that allow the device to determine,
when compared to
This message is from the T13 list server.
On Fri, 21 Dec 2001 05:42:36 -0700, Pat LaVarre wrote:
Given that now we say here we don't like this analogy, I'm ok
drawing a sharp Three way distinction:
1) host NOT wanting to move data in,
In ATA/ATAPI the host has limited options. If the
This message is from the T13 list server.
Why not do the obvious inside the error handler?
Inc. the icrc_error counter regardless and retry. Then once you have
reached your icrc_error max threshold count, jump and do an immediate
operation to down grade the transfer rate via set-features
This message is from the T13 list server.
On Fri, 21 Dec 2001 12:46:46 -0600, Wolford, Jeff wrote:
So until ANY content protection comprehends the following
we will be highly UNMOTIVATED to use ANY product that contains it:
But you may have no choice if the entertainment industry gets
Congress
Title: ERROR register filling as result of CRC Errors
Hi,
Is
there anyone who can help me with my questions posted 19 Dec
2001?
Thanks
in advance
John
Sherry
-Original Message-From: Sherry, John
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, December 19, 2001
15:26To: '[EMAIL
This message is from the T13 list server.
-Original Message-
From: Sherry, John [mailto:[EMAIL PROTECTED]]
First case:
For the Request Sense Packet Command, I see that if a CRC error
is detected by the device during the transmission of sense data
that it should complete the command
This message is from the T13 list server.
Mcgrath, Jim [EMAIL PROTECTED] 01/02/02 11:53AM
Thanks again for being so willing to talk.
D = H ... for SCSI DATA OUTcommands.
It has to be this way ... a host that tried to change this
after the command is issued would violate the standard
This message is from the T13 list server.
The key design principle of UDMA is to have the signals be in the exactly
same state after the DMA burst as it was before the DMA burst. Remember
that outside of the burst you have to play be old PIO rules, which do not
allow for double transitions
This message is from the T13 list server.
Pat,
You have to keep this conversation straight. You asked me what 8 bit
asynchronous SCSI requires independent of Windows or other implementation
issues - and I've told you (in several messages). All DATA OUT commands
send data out as a TRANSFER
This message is from the T13 list server.
On Thu, 03 Jan 2002 16:07:31 -0700, Pat LaVarre wrote:
One byte count that matters
is the count of bytes written or read that the OS reports to the app.
And I hope the device drivers in your favorite OS report the correct
value. This has nothing to
This message is from the T13 list server.
Pat,
I think the problem here is that you keep on saying that when using PIO the
ATAPI interface is transferring an odd number of bytes under certain
circumstances. Hale, Harlan, and myself keep repeating that this is
physically impossible at the
This message is from the T13 list server.
It does (i.e. see figures 57 and 58). The deassertion of DMACK- is always
the last thing done, since it clocks the CRC data from the host to the
device and defines the end of the DMA burst (after which all the signals
revert to their earlier meaning).
This message is from the T13 list server.
Well given that recent discussion with a few people and finding out the
EFF may be coming to their senses about the silliness of their position.
Where as during the Austin T13 February 2001 meeting, where my memember
ship was invalided for just cause,
This message is from the T13 list server.
From: Hale Landis [EMAIL PROTECTED]
On Wed, 02 Jan 2002 10:31:10 -0700, Pat LaVarre wrote:
I have a question about how much data a single CRC-32 should be
made to cover. I have heard rumors that if a single CRC-32 is
This message is from the T13 list server.
FYI
-Original Message-
From: McMillan, Kate [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 08, 2002 10:48 AM
To: 'NCITS members'; 'NCITS TC/TG/SG Chairs'
Subject: NCITS Changes its Name to INCITS
Importance: High
Please be advised that
This message is from the T13 list server.
Initio Debuts 1394 Single-Chip Bridge Controller
Initio has unveiled the first of its ATA-to-1394a FireWire bridge
controllers, which integrates low-power IEEE 1394 physical interface
(PHY) technology from NEC. Delivering data transfer speeds of up to
This message is from the T13 list server.
http://www.boston.com/dailyglobe2/014/business/Striving_to_push_storage_capacity_beyond_its_limit+.shtml
--andre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
This message is from the T13 list server.
I have uploaded e02101r0 Proposal to obsolete the SEEK command in
ATA/ATAPI-7 to incoming on the FTP site. It will be added to the agenda for
the February meeting.
Dan, please put it on the web site.
Regards, Pete
Subscribe/Unsubscribe instructions
This message is from the T13 list server.
On Wed, 16 Jan 2002 08:41:40 -0700, Mclean, Pete wrote:
I have uploaded e02101r0 Proposal to obsolete the SEEK command in
ATA/ATAPI-7 to incoming on the FTP site. It will be added to the agenda for
the February meeting.
Yes! Yippie! Party Time!
Why
This message is from the T13 list server.
Obsoleting not-useful-in-the-field stuff like Ata op x70 Seek isn't necessarily
helpful.
Summer of 2001 I saw people surprised to discover an Oem in question there wanted Ata
ops x23/33 ReadLong/WriteLong to work. They were ok learning those new ops
This message is from the T13 list server.
The greatest problem I've run into with getting rid of old functionality is
with customer testing and manufacturing software. Frequently this is old
stuff that is not even maintained anymore, so having them update it to avoid
the old command is not
This message is from the T13 list server.
Hale,
So what are we going to do about this??? YES, I am making this your
problem too!!! I am tired of this crap and the lack of tech support
that seems to come with ATAPI devices from retailers and from the
device manufacturers.
while I understand
This message is from the T13 list server.
If you are a manufacturer or retailer of ATAPI CD/DVD devices you may
want to read this...
www.ata-atapi.com/cddvd.htm
...I hope you are getting the idea and that you will start supporting
your customers.
*** Hale Landis *** www.ata-atapi.com ***
This message is from the T13 list server.
Dear T13:
Does anyone know where I can get more info on the use of the interrupt? The
question I have is whether the INTRQ pin is optional or not. I have a design
using a chip with ATA/ATAPI interface. The INTRQ pin was left open. I wonder
if this is
This message is from the T13 list server.
Curtis said...
The interrupt is truely not a requirement for UDMA.
Just to expand on this... INTRQ is not required by any ATA or ATAPI
reset or command protocol. A host can chose to ignore INTRQ anytime.
But I think the point of the original
This message is from the T13 list server.
Folks,
I have been notified by INCITS that ATA-3 is up for maintenance this year.
T13 must recommend whether we want ATA-3 reaffirmed, revised, or withdrawn
by June 18th so we need to make our decision by the April meeting.
Please think about this so
This message is from the T13 list server.
I have a question that I am hoping someone on this list can help me find an
answer to ... I apologize in advance if this question is inappropriate for
this forum ...
I am involved with the development of a hardware driver which interfaces to
several
This message is from the T13 list server.
The key thing to remember is that UDMA works perfectly find for all Hard
disk drives (and their host connections) up to 133 MB/s. For CD-ROM and DVD
drives there are shipping products using it up to 33 MB/s (or faster).
The odd byte problem. is very
This message is from the T13 list server.
On Thu, 24 Jan 2002 17:13:44 -0500, Mark Sawyer wrote:
I apologize in advance if this question is inappropriate for
this forum ...
This is probably as good a place as any (to get a bunch of
conflicting answers).
I am involved with the development of a
This message is from the T13 list server.
Mcgrath, Jim [EMAIL PROTECTED] 01/24/02 06:03PM
The key thing to remember is that
UDMA works perfectly fine
for all Hard disk drives (and their host connections)
up to 133 MB/s. For CD-ROM and DVD drives
there are shipping products using it up to
This message is from the T13 list server.
On Thu, 24 Jan 2002 17:59:06 -0700, Pat LaVarre wrote:
This message is from the T13 list server.
But some of us think in the lab we see the byte counts for UDma
Out gets off by more and more as the UDma burst rate increases.
Pat, I really don't want to
This message is from the T13 list server.
On Fri, 25 Jan 2002 08:25:12 -0700, Pat LaVarre wrote:
This message is from the T13 list server.
I'm not clear myself on why Windows UDma connections to
actual Cd-rw drives appear to work mostly ...
My guess is they work because (good grief,
This message is from the T13 list server.
But even the pad bytes are exact and known to both sides before the xfer takes
place, correct?
1/25/02 8:49:43 AM, Hale Landis [EMAIL PROTECTED] wrote:
This message is from the T13 list server.
On Fri, 25 Jan 2002 08:25:12 -0700, Pat LaVarre wrote:
This message is from the T13 list server.
[EMAIL PROTECTED] 01/25/02 08:43AM
Just use PIO ...
In passing I happened to notice Hale is here restating a part of Jan 1996 Sff8020i rev
2.6 paragraph 5.4 that I think I remember never made its way into Ansi texts.
Long time listeners to this
This message is from the T13 list server.
Pat,
I still think you're still a bit confused on how devices actually work:
What I think I'm seeing is that AtapiPio (like parallel Scsi,
printer port Scsi, and UsbMass) give us a protocol for the host
and the device to negotiate an
This message is from the T13 list server.
Pat,
I think you're asking for something that just really does not make any sense
in this context:
This gets interesting only when the host and the
device do not agree perfectly out of band in
advance which byte should be the last byte,
This message is from the T13 list server.
With DMA the HOST DOES NOT NEED to know the amount of data to transfer
before the device starts transferring data. In all cases the device can
halt the transfer of data when it runs out by terminating the DMA burst.
The device indicates that all of
This message is from the T13 list server.
Mark,
Why do you think you need to know the number of bytes to transfer? That is
the device's responsibility, not the host's. You just have to send the
device the CDB, use the buffer the caller gave you (he did give you a
buffer?) and let the device
This message is from the T13 list server.
On Fri, 25 Jan 2002 13:56:02 -0500, Mark Sawyer wrote:
That said, I am working at the device driver level, a lower layer
sufficiently removed from the upper host layer such that I am not privy to
the details of the underlying device filesystem or media
This message is from the T13 list server.
Ooops...
In my example I said: When the sender of the data is ready to
transfer data it asserts
DMARQ and the receiver responds with DMACK and the first DMA data
burst starts.
I should have said: The sender of the data could be the host or the
device.
This message is from the T13 list server.
[EMAIL PROTECTED]
Helpful as always, thank you again.
You appear to want ... just insane.
With another person, I begin to believe I'm communicating only when I hear that person
echo back to me in their own words what I meant to say. I can still
This message is from the T13 list server.
Why do you think [the host]
need to know the number of bytes to transfer?
That is the device's responsibility,
not the host's.
H.
[The host] just have
to send the device the CDB,
use the buffer the caller gave you
... and let the device
This message is from the T13 list server.
Sorry... I confused host, device, sender and receiver in my
example. Here is the entire email again with the corrected
example.
On Fri, 25 Jan 2002 12:08:35 -0700, Pat LaVarre wrote:
Ah, fun. As many saw here, I spent much time over Christmas
This message is from the T13 list server.
What I find very interesting is the diverse perspectives that everyone
brings to the table, all strongly colored by the requirements of their
various implementations and their experiences with same ...
Jim said (Friday, January 25, 2002 20:53):
With
This message is from the T13 list server.
This thread has been followed for some time. If you are designing an X to ATA-x
bridge, the following is true on the ATA side.
1. The device has to be told exactly how many sectors to transfer via the
Sector Number register whether it be read or
This message is from the T13 list server.
On Sat, 26 Jan 2002 10:04:05 -0700, don clay wrote:
This message is from the T13 list server.
3. The device will pause data transfer only between sectors by waiting to post
the interrupt and raise DRQ in PIO mode or by de-activating DMAREQ in any
Dear T13,
Can you help me with the following questions:
Bus Master IDE rev 1.0
- When the start bit is cleared and ACTIVE bit in the Bus Master IDE
status register is set -
What is the correct behavior of the DMA? Let's assume
that a command using UDMA protocol is ongoing:
Abort the ATA
This message is from the T13 list server.
Don C:
Glad to hear you still listening, glad to see you posting a third perspective.
Speaking now to that third perspective, yes the Atapi details matter:
AtapiDma needs an analogue to what you point out Ata 0.5KiB block read/write already
has for
This message is from the T13 list server.
On Mon, 28 Jan 2002 01:52:58 -0700, Pat LaVarre wrote:
This message is from the T13 list server.
A less clearly intuitive example is the extreme of UDma Data
Out, where a host can inadvertently overestimate the count of
bytes a device agrees to move by
Yaniv,
Typically the"Active" bit (in the status
register) will follow the "Start" bit (in the Bus Master command
register). Using Intel ATA controllers, you have the following definitions
for each bit:
Start/Stop
Bus Master (SSBM). 1=Start;
0=Stop. When this bit is set to 1, bus master
1 - 100 of 1830 matches
Mail list logo
