Эта версия сканера была задумана как простой и дешевый инструмент в помощь ремонтнику или дигеру по отлову команд из утилей. Он прост до предела, не требует ни прерываний, ни дополнительных портов или других ресурсов. Подключать его можно прямо на шлейф к любому винту (можно на горячую) и на любом порту, кабель до 2,5 метров, электронная защелка сканера держит данные даже при отключении разьема принтера или выхода из программы сканирования. Что еще надо ремонтникам не имеющим (пока) грошей для мощного инструмента ипользующих MHDD, HDD, HDDL, и другой полезный софт, часто требующий знание Vendor комманд.

... Кстати, наконец то я узнал, что делает Fujirec (Fujitsu Recovery) при восстановлении битых модулей. Сама утиль загружается под Linux и работает в защищенном режиме, использует кучу Linux-библиотек и драйверов по железу, да еще все это записано единым массивом на дискету - так-что практически нет никакой возможности дизассемблировать или влезть отладчиком, а теперь все проще. На что ушли бы месяцы (или годы) стало известно за 3 минуты. И еще - при отладке граббера обнаружил, что состояние CS0-CS1 и SA0...SA2 не сбрасываются портом как шина данных и адреса, а винт после каждого IOW посылает (читает???) кучу импульсов которые находятся в верхней области 1 (единицы) диапозоне примерно +2,7 - +3,3V. В ATA про это вроде ничего нет, хотя может пропустил?

Что касается версии IDEGRAB+FIX, то он задумывается как универсальный инструмент умеющий и грабить и лечить и тестировать. В принципе для этого все есть:
Порт ECP до 2Mb/s - это, в среднем, 500000 блоков команд в секунду, если дать винту команду читать по 256 секторов, то для того что-бы он успевал за сканером (синхронно) ему пришлось бы развить скорость чтения минимум 64 Mb/s, а если учесть что команды последовательного чтения/записи не требуют обновления многих портов регистров, то до 100 Mb/s. При работе с одним сектором винт тратит еще больше времени, как вы знаете. Кроме того, ECP имеет FIFO буфер для команд и может сжимать данные увеличивая их поток, да и никто не запрещает на "законных" ATA-основаниях притормозить (IOR) процесс на некоторое время.
На шине в 100Mhz на обоих компах (проверено) при тестовом коде:

mov dx,170
outprt: out dx,al
jmp outprt

т.е. при максимально-возможной скорости отправки даннах в порт и включенном сканере (без защелки), осциллограмма показала что частота IOW и сканера практически одинакова. У сканера примерно на 1% меньше. Это обусловливается тем что запись в порт всегда медленнее чем чтение из него.

IDEGRAB+FIX будет считывать 8 и 16 битовые данные записываемые в 1X0 (IDEGRAB только 8), принимать данные из буфера, вкл/выкл питание винта, посылать команды на винт и контроллировать состояние всех его регистров и.т.д.
Кроме того:
В нем будет использованная моя фирменная фишка, основанная на обнаруженном свойстве IDE-порта, который не сбрасывает состояние CS0-CS1 и SA0...SA2, что позволяет - не инициализировать регистры винта повторно (в операциях чтения/записи - при анализе поверхности), а только повторить код команды на шине данных !!!

IDEGRAB+FIX будет иметь программируемый, логический фильтр состояния регистра статуса винта и буферную защелку посланной команды, которая, по мере необходимости и в зависимости от состояния логического фильтра, может послылаться в цикле, самим сканером, без участия программы, а вслучае обнаружения ошибки - фильтр вызовет программу для анализа случившегося. Это позволит тестировать поверности блинов на скорости которую имеет винт.

Анализ в (DMA)UDMA режиме:
Мои скудные познания говорят о том что прямой обмен данными (именно данными) устройства с памятью.
К примеру:
Для того что-бы проанализировать время чтения одного сектора, на скорости хотя-бы 10Mb/s (т.е. 20000000 секторов в секуду), минимальная частота дескретизации анализа должна быть не менее: (20000000 = 20Mhz) умноженное на 100. (100 это минимальное количество тактов процессора адаптера затраченное на выполнение кода программы.) Получается что процессор адаптера должен иметь тактовую частоту от 2 до 6 гигагец !!! HRT и PC3 работают на шине максимум 33-66Mhz, а частота процессора (не знаю) наверное 20-40 Mhz так что данные, без задержек, они принимать не могут. Если поток данных (к примеру) от винта шел со скоростью 133Mhz и вдруг скорость упала в 2-3 раза (скажем нестабильная зона), то ни один сканер, HRT или PC3K этого не заметит. ...Видел я на каком-то сайте оборудование для тестирвания блинов - так там стоит мотор (как от стиральной машины), сверху блины, сбоку автоподатчик голов, все под прозрачным колпаком а рядом - шкафы с электронным оборудованием, немалого размера...

Отсюда вывод:
Окромя самого винта, скорость чтения/эаписи отдельного сектора, нормально анализировать никто не может и даже сам он делает это довольно медленно хотя и имеет на борту несколько разных units анализирующих отдельно сервометки CRC и.т.д.- И лечить себя, по возможности, он должен сам, командами из прошивки или лодыря. Недаром частенько народ спрашивает: Почему в MHDD блок один раз красный, другой раз - нормальный? Пролечил, а он опять!

IMHO:
Невозможно физически, заставить винт прочитать только один сектор. Встав на цилиндр он прочитает его весь пока не найдет нужный сектор, после чего, до упора будет загружен кэш этим и последующими секторами. Если на этом цилинре, есть скажем candidate, то в зависимости от того, на каком секторе окажется головка встав на цилиндр, candidate может попасть или не попасть в зону чтения определяемую размером кэша. А ругаются проги именно на запрашиваемый сектор, потому-что им и невдомек, что сбой произошел по дороге (в прямом смысле) к нему, а винт никогда не сообщит о том что "при чтении 19 сектора произошол облом на 195 :))" Запись по секторам в этом случае лучше, потому что в регистрах останется номер последнего удачно записанного сектора.

А вообще, я мало что знаю про винты, наврал тут наверное много, хотя свято в это верю.
Кто-б помог с инфой по этим делам - в пятку бы поцеловал.