Программная поддержка двух IDE-устройств на одном шлейфе (?)

[Vadim]

про обязательство полного вычитывания всего сектора в оф.доке ничего нет (возможно, я не нашёл, читал в оригинальном английском варианте), об этом я уже сам догадался.

Как же нет? Там везде написано, что, к примеру, запросили мы один сектор. Винт его считает во внутренний буфер, и мы обязаны его прочитать целиком. Как мы вычитали 512 байт винт понимает, что сектор нами взят и он из буфера его удаляет.

А вот тут возвращаю Ваше "вижу фигу". Про это есть в доках, чётко и ясно (п. 7.2.13, NOTE 6). И у меня это сразу корректно заработало.

прошу прямо по шагам алгоритм расписать, т.к. даже в эмуляторах ZX на этот счёт были грубые ошибки. Т.е. в реале 2 винта ведут себя не так, как было в эмулях.

[Denn]

Denn, именно те же проблемы и с IBM PC и MS-DOS. И что?

А вот с этого места поподробнее, плз.

- - - Добавлено - - -

...и мы обязаны его прочитать целиком. Как мы вычитали 512 байт винт понимает, что сектор нами взят и он из буфера его удаляет.

Где конкретно такое написано?

прошу прямо по шагам алгоритм расписать, т.к. даже в эмуляторах ZX на этот счёт были грубые ошибки. Т.е. в реале 2 винта ведут себя не так, как было в эмулях.

Про эмуляторы ничего не знаю, и мне это не интересно. По факту поведение реального железа соответствует тому, что написано в оф. документации.
Важный момент: если у привода есть перемычка "Slave Present", то её обязательно нужно использовать. Выше я про это упоминал.
Детект ведомого накопителя делается в три хода:
1) установка бита DRV=1;
2) выдача какой-либо команды (например, NOP);
3) Анализ регистра состояния (согласно п. 7.2.13, NOTE 6).
Всё.

[HardWareMan]

А вот с этого места поподробнее, плз.

Я об этом:

ram_scan, например копируем "100500" файлов размером 3 байта. Ситуация утрированная, но тем не менее. На практике размеры файлов не кратны 512, и хвосты как раз представляют собой эти "три" байта. 100500 по 3 или по 512, есть разница?
В случае записи, разумеется, без вариантов - приходится честно добивать "мусором" до 512.

Т.е., твоя утрированная ситуация это типичная установка Windows NT без SmartDrive'а, т.к. загрузочная дискетка побилась.

[Denn]

Я об этом:

Т.е., твоя утрированная ситуация это типичная установка Windows NT без SmartDrive'а, т.к. загрузочная дискетка побилась.

И что мне с этого? На писи свои заморочки, а у меня 8-битка и спортивный интерес выжать максимум производительности. Даже просто вхолостую вычитывать из порта лишние сотни байт нет никакого желания. На писи, имхо, это не так заметно, как на ВМ80@2,5МГц

[Denn]

Тема с не полностью вычитанным сектором из буфера HDD возымела небольшое продолжение. На тест-драйве, при копировании кучи файлов, посреди процесса случился затык - типа ошибка чтения очередного файла. Повтор считывания прошёл успешно. Далее ещё несколько таких затыков (первый раз ошибка, повтор успешно). Далее замечаю, что эффект 100% стабилен, т.е. в одних и тех же местах. Более того, в другом подкаталоге на том же наборе файлов ровно то же самое. Причём, что характерно, эффект проявляется только на конкретной модели винчестера: Фуджик МПЕ3102АТ с микропрограммой версии 0028. На Фуджике МПЕ3084АЕ высечь эффект не удалось.
Расследование показало, что после чтения "проблемного" файла, первым сектором на следующем запросе читается "мусор", причём этот мусор представляет собой содержимое сектора, следующего за последним "проблемного" файла. Хотя команды чтения этого сектора в принципе не поступает. Вероятно, это механизм look-ahead чтения "на всякий пожарный". А вот почему его результат "винт" отдаёт по следующему запросу - х/з, видать особенность (или бага?) конкретной микропрограммы.
Фиг с ним, начал думать как побороть. Первая мысля была - после неполного чтения последнего сектора выдать не NOP, а команду рекалибровки (переход на 0-ю дорожку), она-то уж точно должна всё сбросить. Не прокатило! Головки щёлкают в начало, но предиктивный мусор "винт" по-прежнему отдаёт на следующем запросе.
Как ни странно, помогла прерванная команда "Чтение буфера". Хотя странно, ведь по факту я ничего не читаю, разумеется. Тем не менее, факт: ReadBuffer + NOP решили вопрос. По скорости это быстрее холостого вычитывания ненужного остатка сектора, и по объёму кода меньше.
Вот такие костыли

[HardWareMan]

... и по объёму кода меньше.

Т.е., выдавать +2 команды АТА это меньше простого увеличения счетчика чтения байтов данных?

[Vadim]

Детект ведомого накопителя делается в три хода:
1) установка бита DRV=1;
2) выдача какой-либо команды (например, NOP);
3) Анализ регистра состояния (согласно п. 7.2.13, NOTE 6).
Всё.

Что анализируем в регистре состояния? Про вычитку буфера - как найду так процитирую доку, у меня по этому вопросу вообще не было сомнений, а доки я читал и делал ещё в 1996-1998гг.

[Denn]

Т.е., выдавать +2 команды АТА это меньше простого увеличения счетчика чтения байтов данных?

Мне нужно закончить полезный цикл переноса данных из хдд в ОЗУ и начать отдельный бесполезный цикл холостого вычитывания. При этом ещё добавится код вычисления значения счётчика этих бесполезных байтов, т.к. у меня есть только счётчик полезных, который получен ранее исходя из длины файла. Понятное дело, что это будет 512 минус хвостик, но это вычитание двухбайтовых чисел, т.е. далеко не одна команда. Ещё же нужно обработать ситуацию, когда хвостик равен полному размеру сектора. Можно наоборот увеличивать хвостик и ждать равенства значению 512, но это тоже дофига кода.
А так всего 9 байт на костыли - дёшево и, главное, быстро

[HardWareMan]

Denn, т.е. вариант с отсечением сохранения данных при выходе за пределы размера в том же цикле не учитывается? Ну да ладно, не мой проект, не мне и решать, как писать код.

[Denn]

Denn, т.е. вариант с отсечением сохранения данных при выходе за пределы размера в том же цикле не учитывается?

Это получается, что в цикле нужно делать две проверки (работать будет медленнее). А по фатку проверки будет четыре, т.к. байты вычитываются из двух разных портов по очереди (тобишь объём кода ощутимо возрастёт). Одни минусы.

Вот причинный участок кода:

LDHDAT6:
IN PT_IDE_DATL
MOV C,A
MOV A,B
CALL SVBYTE
INX H
DCX D
MOV A,D
ORA E
JZ LDHDAT7
IN PT_IDE_DATH
MOV C,A
MOV A,B
CALL SVBYTE
INX H
DCX D
MOV A,D
ORA E
JNZ LDHDAT6

LDHDAT7:
; ПРИНУДИТЕЛЬНОЕ ЗАВЕРШЕНИЕ ОПЕРАЦИИ
MVI A,0E4h
CALL SetCMD
XRA A
CALL SetCMD
XRA A
RET

В [HL] адрес в ОЗУ куда складываем байты, в [B] номер страницы ОЗУ, в [DE] длина хвоста, регистр [C] используется для передачи записываемого байта процедуре записи в произвольную банку.