I have started writing my own ATA terminal software, I am trying to figure out an interesting issue.
I am returning each "block" of data as a 16 bit integer. When sending EC through the status register, the data returned has the bytes swapped. Command 20 returns data in order. Is there something I missed regarding the byte order? I tried returning as a single byte and the same thing happens. Any ideas?
Shawn




PS.
I have no intention of giving the software out. Some of the regulars maybe. I have learned from this project, that if you don't have the discipline to build this yourself you can only do more harm than good.

Hi,

Command 0xEC is supposed to work like that. This is normal. Just check ATA specs.

pepe

_________________
Adatmentés - Data recovery

That is what got me this far, I must have missed it. Are there others that you know of that work the same way?

I don't remember other ones.
But in this one only the ASCII fields are byte swapped too.

pepe

_________________
Adatmentés - Data recovery

Nice project

_________________
You don't have to backup all of your files, just the ones you want to keep.

Thanks DRC! I have been wanting to write an event driven logging class with exports and reporting for a while. I needed an ATA terminal for study, so I went for it. Quite fun actually. I am working on a few more MDI child forms. One for copy and jump on error, one for smart, one for partition tables, and one for graphing delay by sector.

Pepe, after going back and reading I did catch it. I was trying to figure out if I should have a switch to perform the swap after the data is read(if there was more than one) or if I should just process 0xEC differently.

Shawn

Oh, I forgot the number one reason for the project! Easy drive access through managed code. Pointers be gone!

Couple hints for you
You can try read and write data by dwords not just words
It will be faster
Most of the controllers and modern drives support this feature
But use it as an option, so it can be changed through user interface

Also it is good to have some kind of commands store, so you can load commands from this store and you don't need to type them again and again

Don't forget LBA48 support for sending commands and reading registers back

Good luck

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

DWords, From the spec I though I was stuck with words. I will make the change now. I have been debating the cammands store going more of a macro route. Haven't made that decision yet. Your HDDScan app and the bit about the Cypress USB controller is what is driving this.

Anyone care to elaborate on the Hi/Mid/Low cylinder registers? With LBA addressing how can I calculate these values?
Shawn

Doomer, it appears that Identify will only return words. Controller limitation?

U don't need them.
At least drives over some hundred megs will support LBA.
It is very rare that you need CHS addressing these days.
When u need it, just check ATA specs.

pepe

_________________
Adatmentés - Data recovery

So how are the LBA addresses entered through the H/M/L registers?

So the first byte of the lba goes in low, second in mid, last in high?

L <- LBA bits 0-7
M <- LBA bits 8-15
H <- LBA bits 16-23
Device reg lower nibble <-LBA bits 24-27

this is for 28bit LBA addressing.
But please, really, read that ATA spec, it will teach you a bunch of things.

pepe

_________________
Adatmentés - Data recovery

Pepe, I am reading trust me. I am just trying to apply as I read to further grasp the concepts.

Still trucking, put in the 48 bit support for the LBA registers. Now working on the DWORD read/write support. Thanks for everything guys!

1x1 and 1x2 are LBA48 related too

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

they are in my struct, just haven't used them yet so the textboxes aren't there. When using LBA values, x6 should should always have bit 6 set correct?

Almost correct

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.