Ну хорошо. Здесь лишь подтверждается что прерывание - результат конкретных условий. То есть снова прерывание отбрасываем. Оставляем завершение операции при котором выставляем RKDS. Чтение RKDS дает возможноть выставить следующий. Все. Укладывается в схему? Укладывается.
- - - Добавлено - - -
И кстати это опять таки легко проверить у Andrey_Ak.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Именно так я и планирую это эмулировать. Вопрос лишь в том, в какой последовательности DS отработавших приводов попадают в RKDS.Сообщение от form
Ходят слухи, что для POLL-команд DS выставляются в порядке положения приводов в цепочке, а для единственной I/O-команды DS всегда выставляется первым, вне зависимости от положения привода в цепочке.
По идее в порядке выполнения физически операции. Для эмулятора если хочется достоверности - можно соответственно разности между текущей и выбираемой дорожкой выбирать порядок.
Я думаю, что все это несущественно ибо как не крути, а таки нету софта которому есть разница. В XXDP 5 тестов касаемых RK11/RK05, basic logic test #1 даже не требует самих дисков. Прогнать их для проверки.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Может статься, что проблемы с написанием софта для использования продвинутых фич RK11 возникли из-за того, что контроллеры разных версий по-разному "сортировали" DS. Так как самое простое - выдавать все DS в порядке положения приводов в цепочке, то при такой реализации - после прерывания по завершению I/O в RKDS будет DS завершившего I/O привода только в том случае, если это первый привод в цепочке из всех, завершивших операции.
Вполне вероятно. Вероятно также, что документация писалась впрок (как у DEC обычно и было). Так или иначе, но факт остается фактом: overlapped seek (если конечно это вообще о том) сам DEC не использовал для RK05, хотя судя по написанному он возможен (причем в данном случае прерывания имеют место быть).
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Приводы RK ( если не ошибаюсь ) подключаются к контроллеру последовательно ( как сигналы IRQ от плат - к процессору ), поэтому более близкий к контроллеру привод ( насколько я понимаю ) может полностью заблокировать обмен для более дальних.
Тут я просто не в курсе - никогда не лез в такие дебри. С RK05 имел дело только на Э100/25, и все, что о них знал - это куда ткнуть пальцами если вдруг привод не заводится, как форматнуть диск не загружая системы и тому подобную дребедень
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Последнее предложение заставляет думать, что при выключенных прерываниях номер привода в RKDS всегда совпадает с RKDA, поэтому для просмотра состояния приводов - надо сначала заносить их номера в RKDA.
- - - Добавлено - - -
Подробное описание интересующего вопроса:
Понятно, что контроллер учитывает все приводы, начавшие двигать головку, и опрашивает их по очереди, пока последний из приводов не закончит работу.
Ой ли? Как минимум, нелогично: пускаем SEEK сразу на трех накопителях, на двух из них - сдвиг на одну дорожку (идет перезапись большого файла с диска на диск) на третьем - на все 199 (другая задача чего-то захотела). И что, первой задаче ждать, пока на третьем накопителе головки пролетят все 199 дорожек?
- - - Добавлено - - -
Угу.
Вряд ли - обмен запускается только контроллером, а программа, которая им рулит (ОСь) такого не должна допустить.
А вообще, надо бы поразглядывать список сигналов в шине от контроллера к накопителям. Может что удастся сообразить.
2All: у кого есть, выложите, плз, означенный список из описания накопителя.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
.
Похоже, что POLL-система контроллера RK работает примерно так:
1. Когда привод начинает выполнять команду SEEK или DRIVE_RESET ( т.е. SEEK на минимальной скорости на нулевую дорожку ) - в слове MASK устанавливается бит, соответствующий номеру привода.
2. Когда привод начинает выполнять любую команду, кроме SEEK или DRIVE_RESET - в слове MASK очищается бит, соответствующий номеру привода.
3. При переходе в состояние IDLE ( когда контроллер больше ничем не занят ) - контроллер проверяет слово MASK и если оно не нулевое и прерывания разрешены битом 6 в RKCS - запускает POLL-систему.
4. POLL-система поочерёдно сравнивает биты слова MASK с признаком готовности соответствующего привода и если оба бита установлены - отключает POLL и выставляет запрос прерывания.
5. Если прерывание принято процессором - POLL-система очищает бит MASK, устанавливает в RKCS бит 13 и подменяет номер привода в RKDS номером из счётчика POLL, после чего немедленно продолжает POLL, если в слове MASK ещё есть установленные биты.
Осталось понять, что произойдёт, если процессор не принял прерывание от POLL, но передал новую команду на другой привод. Логично предположить, что при очередном переходе контроллера в состояние IDLE - произойдёт перезапуск POLL-системы и повторное выставление прерывания для передачи сообщения о состоянии "нашего" привода.
- - - Добавлено - - -
Надо думать, что подмена номера в RKDS должна держаться до одного из следующих событий: 1) INIT; 2) запись в RKCS; 3) запись в RKDA. Но как с этим обстоит на самом деле - ещё предстоит выяснить.
Последний раз редактировалось Patron; 12.03.2016 в 12:37.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
