Там настолько все просто, что хватит даже примера из сингеровской книжки. На bitsavers впрочем полно инфы про RK11 (см в разделе UNIBUS - RK05 только там бывает в оригинале).
- - - Добавлено - - -
Вторая глава в мануале - programming.
Вид для печати
Там настолько все просто, что хватит даже примера из сингеровской книжки. На bitsavers впрочем полно инфы про RK11 (см в разделе UNIBUS - RK05 только там бывает в оригинале).
- - - Добавлено - - -
Вторая глава в мануале - programming.
Это самое хорошее описание, но я не просто так дал ссылку на попытку реализации этого описания в ПЛИС, результат которой описан так: "RK11: hardware poll not working. The RK11/RK05 hardware poll logic is probably no reflecting the behaviour of the real drive."
Суть проблемы в том, что у каждого из приводов есть свой регистр состояния ( DS ), который может проецироваться по адресу 177400 ( RKDS ). В обычной ситуации по адресу 177400 виден DS того привода, который выбран старшими битами RKDA ( 177412 ), но в состоянии POLL - по адресу 177400 может быть виден DS любого из приводов и то, в какой последовательности и по каким причинам DS одного привода сменяется в RKDS регистром другого привода - понять по описанию едва ли возможно ( в всяком случае пока этого никто сделать не смог ).
Никогда подобного не встречалось. Впрочем все это давно было и теперь сложно что-то говорить. Но нужно ли об этом думать? Контроллер не предусматривает параллельную работу разных дисков, соответственно что выбрано то и должно быть. Не понимаю сути проблемы. Или хочется реализовать какой-то конкретный глючный контроллер который есть у конкретного человека со всеми его глюками?
Центральный контроллер RK предусматривает параллельную работу локальных контроллеров всех 8 приводов, но чтобы передать задание локальному контроллеру - центральный контроллер должен быть свободен. Поэтому, пока выполняются операции с данными - начать другие операции невозможно, но пока выполняются операции без данных ( сброс, позиционирование и включение защиты записи ) - все 8 приводов могут быть озадачены одновременно.
Не очень представляю себе это. Если не ошибаюсь, регистры адреса, буфера и счетчика относятся ко всему контроллеру и он напрямую с ними в процессе I/O манипулирует (можно наблюдать на пульте как они меняются). К чему приведет попытка поменять на ходу регистр адреса (чтобы выбрать другой привод) - загадка. Также ни один драйвер не предусматривает такого - запуск нескольких операций на одном контроллере одновременно (на любом контроллере). Так что по-моему просто не греть голову.
Пока идёт I/O и центральный контроллер занят - отработавшие локальные контроллеры ждут освобождения центрального. Поэтому, самое интересное начинается, когда центральный контроллер закончил I/O. Если прерывания включены, то после каждого прерывания - в RKDS находится DS очередного локального контроллера, завершившего операцию. В какой последовательности эти DS появляются в RKDS - документация явно не говорит. Если прерывания выключены - авторы эмуляторов идут вешаться, потому что такая ситуация в документации не описана вообще.
И породить очередное убогое подобие. Зачем, если единственный в мире идеально точный эмулятор контроллера RK можно сделать за один день - надо только иметь адекватную информацию.
Кстати - эмуляторы DX и SM5631 уже без ошибок проходят все тесты XXDP.
Пока что мне никто не объяснил как вообще можно их загрузить параллельно (и откуда вообще такая информация [страницу выше не показывать - нужна официальная инфа]).
Для этого придется допустить, что регистры адреса, буфера и счетчик слов также для каждого привода свои (это легко проверить если упросить Andrey_Ak включить свою Э100-25). Допустим (я честно не задумывался никогда ибо параллельных операций не предусмотрено ни одним драйвером ни в одной системе ни для одного контроллера). Но и тут криминала не вижу. В упор.
Допустим так и есть. Слово прерывание мы сразу отбросим как несущественное - прерывание всего лишь следствие установки бита 7 в CSR и значит никакой разницы нет разрешено оно или нет. То есть при завершении I/O все регистры заведомо показывают правильную инфу для нужного привода независимо от того есть прерывания или нету. Остается решить в какой момент контроллеру разрешено переключиться на следующий привод. При чтении RKDS? При этом получается что если есть еще что обрабатывать - бит 7 в CSR тутже должен сброситься, а все регистры (адреса, буфера, счетчика) должны загрузиться новыми значениями и пуститься вскачь.
- - - Добавлено - - -
...и вешаться может любой драйвер (в принципе от самой идеи очереди операций) ибо он отработал I/O и дал сигнал, что готов к следующему, система ему сует новый пакет, и драйвер начинает загрузку регистров контроллера сразу - он считает, что тот безусловно готов.
В каждой доке по RK первым делом написано, что каждый из 8 приводов RK может двигать головку сам, поэтому бит RDY в RKCS устанавливается сразу после НАЧАЛА выполнения приводом команды SEEK. Чтобы выполнять операции БЕЗ ДАННЫХ никакие регистры приводам не нужны, поэтому все 8 приводов RK могут одновременно выполнять команды SEEK, DRIVE RESET и WRITE LOCK.
Иными словами по-моему просто не надо греть голову и пытаться изобрести то для чего все-равно нет никакого софта :)
- - - Добавлено - - -
Никакие? А регистр адреса в котором выбирается привод? А он между прочем динамический - в момент выполнения I/O он меняется.
- - - Добавлено - - -
Но суть не в этом. Простой вопрос - зачем думать о том для чего софта нет в принципе. Даже тестового?