Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Port Function
0x1F0 Data port -- read and write PIO <b>data</b> bytes on this port
0x1F1 Features / Error info -- mostly used with ATAPI
0x1F2 Sector Count -- number of sectors to read/write (0 = special value)
0x1F3 Partial Disk Sector address (CHS / LBA28 / LBA48 specific)
0x1F4 Partial Disk Sector address
0x1F5 Partial Disk Sector address
0x1F6 Drive Select bit, Flag bits, Extra address bits
0x1F7 Command port / Regular Status port -- write commands / read status
That's all fine & good, but how do these actually map to the tables in the "AT Attachment 8 ATA-ATAPI Command Set" document? (e.g. Table 90 on p 269 - see attachment). Each row is a 16 bit word. But when you access the aforementioned ports, you read/write bytes (except in the case of 0x1F0)
Word - Port
00h - 0x1F1
01h - 0x1F2
02h - 0x1F3
03h - 0x1F4
04h - 0x1F5
05h - 0x1F7 (gives the low 8 bits of word 5)??
Yet, specifically in the case of table 90 here (detecting an ATAPI device after an abort), the low 8 bits of word 4 appear to be readable on port 0x1F3, the low 8 bits of word 3 are read from 0x1f4 and the high 8 bits of word 4 are read from 0x175.... say.. what!?
I thought I explained that in the wiki entry. Maybe I need to go and clarify it a little more.
Your question only applies to LBA48 mode.
For that mode, those IO ports have been modified so that you set them to 16 bit values by writing to the same port TWICE. They toggle back and forth between expecting a high byte and a low byte. High byte first. (There is the additional issue that writing to the same port twice IN A ROW is super-extra slow, so it is best to mix the writes to the various ports up a little).
(You can read either a low byte or high byte back out of the port by setting the HOB bit in the Control Register.)
Well actually this is specific to detecting an ATAPI device after doing an IDENTIFY.
These devices will also write specific values to the IO ports.
and
on the Primary bus, IO port 0x1F4 will read as 0x14, and IO port 0x1F5 will read as 0xEB.
But 0x1f4 reads the 0x14 from the LOW 8 bits of word3, yet, 0x1f5 reads the HIGH 8 bits from word 4? Does it automatically read the high-byte first if it's set/used? Is the draft specification I got from t13.org just wrong in table 90?
I understood the wiki with respect to LBA48. Makes sense. There's just no clear mapping of these IO ports to the tables in the specification. It's nice to know how to do things, but it's even nicer to know how/why those things work internally...
OK, let me be much more specific to the table you attached. It is very confusing and misleading, I admit.
Look at the field labeled LBA. It shows as a 48bit value. Then it says that the top 3 bytes are unused. This leaves ONLY THE LOW BYTES with values. You do not need to read the high byte of "word 2, 3, or 4" -- they are unused.
You want to clear the HOB bit, so that you only read the low 3 bytes of the LBA from the 3 LBA IO ports -- 0x1f3, 1f4, 1f5 (for channel 0). That will give you bits 0 through 23 of the "LBA" value, which are supposed to be interpreted based on the table (special values 0x14/0xeb or 0xc3/0x3c). Please ignore the fact that these are called the "low, middle, and high bytes" of the LBA -- this is just more confusing and misleading terminology.
Port 0x175 is used for ATA channel 1 -- not for channel 0. That is a completely separate test.
To be as specific as I can be (for channel 0):
Port 1f3 handles LBA byte 0 and 3
Port 1f4 handles LBA byte 1 and 4
Port 1f5 handles LBA byte 2 and 5
-- and for some utterly stupid reason, these are labeled "words" in the T13 table. (You may also note that two 8bit values are also called "words".)
I must've been mis-interpreting the values in the table. Since the LBA row is labelled as word 02h-04h, I made the assumption that 04h must be bits 7:0 (low byte) and 15:8 (high byte). It's not very clear, and as far as I can tell the document doesn't go out of its way to explain the convention used.
The 0x175 was a typo, I meant 0x1f5 (my DVD drive is on channel 1, I was glancing at my output when I typed that, forgot to change the 7 to an f)
