Контроллер псевдо КМД+дисковод для УКНЦ (на SD карте)

[ZPilot]

А ошибка 102 свидетельствует о том, что за энное количество попыток (около 30) не удалось найти сектор с заданным номером. Т.е. попадался либо адресный маркер заголовка данных, либо сектор не с тем номером.

А как такое возможно, да еще и в случайных местах-то?! Получается, что я где-то пропускаю команды, но чтоб 30 раз подряд.. Если брать реальный диск, то читаем сектор, считать не получилось, ждем пока диск сделает оборот или как?

[Alex_K]

А как такое возможно, да еще и в случайных местах-то?! Получается, что я где-то пропускаю команды, но чтоб 30 раз подряд.. Если брать реальный диск, то читаем сектор, считать не получилось, ждем пока диск сделает оборот или как?

Процедура поиска сектора довольно сложная. Почитайте мой труд "Контроллер дисковода УКНЦ", там расписано как работает драйвер дисковода в ПЗУ УКНЦ. Хотя, к сожалению, он у меня не дописан до конца.

Если найден адресный маркер заголовка данных, то драйвер УКНЦ программирует программируемый таймер на время прохождения головки над зоной данных плюс часть межсекторного промежутка. Через данное время произойдёт прерывание программируемого таймера, головка расположена уже за зоной данных, перед адресным маркером заголовка следующего сектора. Ищется синхрозона, это значит, что читаются нули. Поиск идёт не постоянно, а за заданное число прочитанных слов. Если нулевое слово не обнаружено, то поиск сначала. А если обнаружили, то даётся команда на поиск синхроимпульса.
Соответственно вопрос: через ваш эмулятор драйвер УКНЦ прочёл адресный маркер заголовка. В этом случае драйвер программирует таймер на время пропуска зоны данных. Какое слово в данном случае выдаст ваш эмулятор при следующем запросе - уже из зоны данных или дискета у вас всё-таки вращается?

[ZPilot]

Почитайте мой труд "Контроллер дисковода УКНЦ"

Вы не поверите, но это основной источник моих данных!

акое слово в данном случае выдаст ваш эмулятор при следующем запросе - уже из зоны данных или дискета у вас всё-таки вращается?

Весь вопрос какой запрос, если 2423 (для 0 дисковода), то выдаст: если был маркер сектора, то маркер данных, ну или если был маркер данных, то маркер заголовка следующего сектора.
Вращение я не делал. Хотя индексный импульс у меня эмулируется.

Вот картина testmz: https://pic.maxiol.com/?v=1592165831...31610.jpg&dp=2
Ошибка всегда 102, других нет.

[Alex_K]

Весь вопрос какой запрос, если 2423 (для 0 дисковода), то выдаст: если был маркер сектора, то маркер данных, ну или если был маркер данных, то маркер заголовка следующего сектора.
Вращение я не делал. Хотя индексный импульс у меня эмулируется.

Вся соль ситуации состоит в том, что в ситуации по моему вопросу никакой записи в регистр 0177130 не делается. Регистр 0177130 анализируется только на предмет установки бита готовности, ну и читаются данные с регистра 0177132.
А раз вращения не делается, то следующими данными будут данные сектора. При таком раскладе синхрозоны не будет найдено, т.к. с большой долей вероятности будут читаться ненулевые данные. Ну а далее поиск сначала, с первого цикла. Есть ещё тонкий момент - при поиске в первом, втором и третьем циклах не анализируется бит готовности, а значит за примерно четыре чтения будет читаться одно и тоже слово, т.к. при реальном вращении дискеты новое слово ещё не успеет сформироваться. В вашем варианте скорее всего будут читаться новые слова, а значит легко проскочится синхрозона и по запросу поиска синхроимпульса весьма вероятно не будет найден маркер за этой синхрозоной, т.к. он мог быть прочитан простым чтением.
Да и регистр 0177130 не является регистром команд. Там дисковод управляется отдельными битами. Для поиска играет роль только бит 8. А так записываемые значения для нулевого привода могут быть не только 2423, но и 2463 для верхней стороны. Может остаться установлен бит направления шага, а это 2523 для низа, или 2563 для верха.

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

Хотя индексный импульс у меня эмулируется.

Индекс реально используется для форматирования. Для записи и чтения реально не применяется, он анализируется только при чтении секторов размером 1024 байта.

[ZPilot]

Да и регистр 0177130 не является регистром команд. Там дисковод управляется отдельными битами. Для поиска играет роль только бит 8. А так записываемые значения для нулевого привода могут быть не только 2423, но и 2463 для верхней стороны. Может остаться установлен бит направления шага, а это 2523 для низа, или 2563 для верха.

0177130 для записи - регистр команд (понятно, что команды там - биты), на чтение регистр - статуса, так?

то следующими данными будут данные сектора. При таком раскладе синхрозоны не будет найдено, т.к. с большой долей вероятности будут читаться ненулевые данные.

но реальный же дисковод ведет себя так же? Или ВП1-128 ведет себя как-то иначе?

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

при реальном вращении дискеты новое слово ещё не успеет сформироваться. В вашем варианте скорее всего будут читаться новые слова

Да, 100% будут, тк при обращении к 177132 снимется флаг готовности данных и контроллер сформирует новое слово, но если флаг не установлен, то формироваться слова не будут.
Я не понимаю, как тогда реальная вп1-128 такое обрабатывает? Те она всегда выставляет то слово, что у нее есть? УКНЦ сама переваривает что ей надо?

[Alex_K]

но реальный же дисковод ведет себя так же? Или ВП1-128 ведет себя как-то иначе?

Реальный дисковод является устройством реального времени и вращается, данные с него на контроллер поступают со скоростью 250 кБит/сек. Из этих данных контроллер аккуратно нарезает слова каждые 64 мкс. Если слово за этот промежуток прочитано не будет, то оно в контроллере замещается уже следующим прочитанным словом. А вот если с регистра 0177132 будут бесконечно читать, то в течении 64 мкс будет читаться одно и тоже слово, а в следующие 64 мкс уже другое.
Хотя реально чтение идёт байтами и каждые 32 мкс будут замещаться то младший, то старший байт.

[ZPilot]

А вот если с регистра 0177132 будут бесконечно читать, то в течении 64 мкс будет читаться одно и тоже слово, а в следующие 64 мкс уже другое.

Так зачем было делать чтение без проверки бита готовности?

В общем.. Мир мой рухнул, я не представляю как это можно эмулировать! Единственное привязать к таймеру и изменять значения в регистре 177132 только по истечении 64 микросекунд после чтения предыдущего, а за одно и бит готовности тогда же менять.

Остается только один вопрос, как обрабатывать команду GOR, у меня реакция на нее моментальная, сразу маркер.

[Alex_K]

0177130 для записи - регистр команд (понятно, что команды там - биты), на чтение регистр - статуса, так?

По записи 0177130 это не регистр команд. Это регистр управления отдельными линиями дисковода. К самому контроллеру по записи имеют отношения только бит 8 (GOR), и в некоторой степени бит шага ST, который контроллер автоматически сбрасывает через примерно одну мкс. Все остальные выводы являются параллельным портом и выводятся прямо на дисковод.
1801ВП1-128 не является интеллектуальным контроллером, в отличии от Intel 8271.

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

Так зачем было делать чтение без проверки бита готовности?

А потому что неизвестно в каком режиме находится контроллер - уже в режиме чтения или ещё в режиме поиска маркера. В режиме поиска маркера бит готовности не устанавливается до тех пор, пока не будут найден маркер. И если бы драйвер дисковода перед чтением регистра данных всё время анализировал бы бит готовности, то в некоторых ситуациях он мог подвиснуть в режиме опроса регистра состояния. А после нахождения маркера контроллер переходит в режим чтения и аккуратно, каждые 64 мкс, нарезает слова.

[ZPilot]

то в некоторых ситуациях он мог подвиснуть в режиме опроса регистра состояния. А после нахождения маркера

так он бы мог повиснуть и в режиме чтения из 177132, какая разница-то какой регистр анализировать?

[AFZ]

Я просто стараюсь максимально быстро отпустить RPLY, если его можно задержать на по-дольше, то можно впихнуть разбор команды от УКНЦ и подготовку данных..
Это вообще допустимо?

Когда процессор посылает DIN или DOUT, одновременно он запускает счетчик тайм-аута и ждет низкого уровня на линии RPLY. Если тайм-аут (около 10 мкс) прошел, а RPLY не прибежал, процессор считает, что адресованного абонента на шине нет и возбуждает Trap to 4. Получив же RPLY, процессор выполняет требуемые действия с данными и шиной (в частности, снимает DIN/DOUT) и ждет окончания RPLY, то есть, высокого уровня на нем. Ждет бесконечно, тайм-аут здесь не предусмотрен, это реальный способ завесить МПИ намертво.

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

Естественно, все эти задержки - это тормоза для процессора.

В общем.. Мир мой рухнул, я не представляю как это можно эмулировать! Единственное привязать к таймеру и изменять значения в регистре 177132 только по истечении 64 микросекунд после чтения предыдущего, а за одно и бит готовности тогда же менять.

Во-первых, Никита (nzeemin) предлагал посмотреть, как он реализовал это дело в своём эмуляторе УКНЦ. И, во-вторых, при таком раскладе действительно, надо будет во время "шагов" (минимум - 3 мс) вычитать дорожку в оперативку, а потом в фоне проигрывать ее через эмулируемые регистры, а на обмен с ПП УКНЦ отвлекаться по прерываниям (EXTI по DIN или DOUT), SYNC же придется ловить аппаратно. ИМХО. А жаль, я надеялся, что можно будет ускорить это дело. Тупая все-таки железка, этот ВП1-128...

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

То есть,вычитывать надо обе дорожки цилиндра, на котором стоит головка. 20 секторов по 0.5 К = 10К, вполне терпимо.