Инмос
http://s014.radikal.ru/i329/1603/39/6a10d9e5ff01.jpg
Скачать.
Вид для печати
Насколько помню, нет кабеля НМД?
Это не он случайно:
http://tis.kz/temp/20160310_190801.jpg
http://tis.kz/temp/20160310_190808.jpg
http://tis.kz/temp/20160310_190902.jpg
На обоих концах РГ7КП-10Г3Т-В 0587 3290 мамы.
И еще кабель:
http://tis.kz/temp/20160310_191009.jpg
http://tis.kz/temp/20160310_191027.jpg
http://tis.kz/temp/20160310_191037.jpg
http://tis.kz/temp/20160310_191104.jpg
http://tis.kz/temp/20160310_191112.jpg
Ага, первый "шланг" между дисководами есть. Второй, который уходит непосредственно на контроллер, эта вот здоровая вилка есть, выходит шлейф и СНПшка отрезана.
От чего второй шланг не знаю...
Получается кабель тот? Нужен?Цитата:
Сообщение от BYTEMAN
К сожалению, не тот... :( Междисководник у меня есть (на этой фотке виден https://goo.gl/photos/MWQTet8GLansYnRJ6), а вот откуда уходят белые шлейфы - ответка СНПшная отрезана. Заюрал уже его домой, книжки по 5400 и 1420.5410 - буду спа(р)ивать :)Цитата:
Сообщение от Andrey_Ak
.
Есть где-нибудь книжка, полноценно описывающая работу контроллера 5400 ?
А то по контроллеру RK только видимость наличия информации - попытка эмуляции RK на основе имеющейся информации закончилась неудачно.
Да вроде не было там отличий от RK05. Так что все просто.Цитата:
Сообщение от Patron
Потому и нужна адекватная информация по 5400 - адекватной информации по RK в природе не существует.Цитата:
Сообщение от form
Есть книга по СМ1420.5410 подробная.
- - - Добавлено - - -
Диагностический пульт к контроллеру имеется. Правда хвост обрезан, но тоже можно припаять.
Там настолько все просто, что хватит даже примера из сингеровской книжки. На bitsavers впрочем полно инфы про RK11 (см в разделе UNIBUS - RK05 только там бывает в оригинале).Цитата:
Сообщение от Patron
- - - Добавлено - - -
Вторая глава в мануале - programming.
Это самое хорошее описание, но я не просто так дал ссылку на попытку реализации этого описания в ПЛИС, результат которой описан так: "RK11: hardware poll not working. The RK11/RK05 hardware poll logic is probably no reflecting the behaviour of the real drive."Цитата:
Сообщение от form
Суть проблемы в том, что у каждого из приводов есть свой регистр состояния ( DS ), который может проецироваться по адресу 177400 ( RKDS ). В обычной ситуации по адресу 177400 виден DS того привода, который выбран старшими битами RKDA ( 177412 ), но в состоянии POLL - по адресу 177400 может быть виден DS любого из приводов и то, в какой последовательности и по каким причинам DS одного привода сменяется в RKDS регистром другого привода - понять по описанию едва ли возможно ( в всяком случае пока этого никто сделать не смог ).
Никогда подобного не встречалось. Впрочем все это давно было и теперь сложно что-то говорить. Но нужно ли об этом думать? Контроллер не предусматривает параллельную работу разных дисков, соответственно что выбрано то и должно быть. Не понимаю сути проблемы. Или хочется реализовать какой-то конкретный глючный контроллер который есть у конкретного человека со всеми его глюками?Цитата:
Сообщение от Patron
Центральный контроллер RK предусматривает параллельную работу локальных контроллеров всех 8 приводов, но чтобы передать задание локальному контроллеру - центральный контроллер должен быть свободен. Поэтому, пока выполняются операции с данными - начать другие операции невозможно, но пока выполняются операции без данных ( сброс, позиционирование и включение защиты записи ) - все 8 приводов могут быть озадачены одновременно.Цитата:
Сообщение от form
Не очень представляю себе это. Если не ошибаюсь, регистры адреса, буфера и счетчика относятся ко всему контроллеру и он напрямую с ними в процессе I/O манипулирует (можно наблюдать на пульте как они меняются). К чему приведет попытка поменять на ходу регистр адреса (чтобы выбрать другой привод) - загадка. Также ни один драйвер не предусматривает такого - запуск нескольких операций на одном контроллере одновременно (на любом контроллере). Так что по-моему просто не греть голову.Цитата:
Сообщение от Patron
Пока идёт I/O и центральный контроллер занят - отработавшие локальные контроллеры ждут освобождения центрального. Поэтому, самое интересное начинается, когда центральный контроллер закончил I/O. Если прерывания включены, то после каждого прерывания - в RKDS находится DS очередного локального контроллера, завершившего операцию. В какой последовательности эти DS появляются в RKDS - документация явно не говорит. Если прерывания выключены - авторы эмуляторов идут вешаться, потому что такая ситуация в документации не описана вообще.Цитата:
Сообщение от form
И породить очередное убогое подобие. Зачем, если единственный в мире идеально точный эмулятор контроллера RK можно сделать за один день - надо только иметь адекватную информацию.Цитата:
Сообщение от form
Кстати - эмуляторы DX и SM5631 уже без ошибок проходят все тесты XXDP.
Пока что мне никто не объяснил как вообще можно их загрузить параллельно (и откуда вообще такая информация [страницу выше не показывать - нужна официальная инфа]).Цитата:
Сообщение от Patron
Для этого придется допустить, что регистры адреса, буфера и счетчик слов также для каждого привода свои (это легко проверить если упросить 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.Цитата:
Сообщение от form
Иными словами по-моему просто не надо греть голову и пытаться изобрести то для чего все-равно нет никакого софта :)
- - - Добавлено - - -
Никакие? А регистр адреса в котором выбирается привод? А он между прочем динамический - в момент выполнения I/O он меняется.Цитата:
Сообщение от Patron
- - - Добавлено - - -
Но суть не в этом. Простой вопрос - зачем думать о том для чего софта нет в принципе. Даже тестового?
Это регистр центрального контроллера. Приводами он не используется, а после установки бита RDY в RKCS - не используется и центральным контроллером.Цитата:
Сообщение от form
А может это и есть ответ на вопрос? В RKDS никогда не появится в принципе ничего пока не будет выставлен RKDA. Все. Условие выполнено согласно написанному :)Цитата:
Сообщение от Patron
- - - Добавлено - - -
Приводами-то он не используется, да используется контроллером. И что будет если его на полном ходу поменять (для выбора устройства) непонятно. Контроллер-то его меняет постоянно во время выполнения I/O и использует как адрес диска с которым он работает (полный - включая unit).Цитата:
Сообщение от Patron
Тестовый софт точно есть, иначе эмуляторщики не лили бы слёзы из-за неудачных прогонов тестов XXDP, а что касается оптимизации использования RK в старших версиях UNIX для PDP-11, то отвергать возможность её наличия тоже не стоит.Цитата:
Сообщение от form
Написанный ими самими? Официального такого софта точно нет.Цитата:
Сообщение от Patron
Контроллер не использует RKDA после установки бита RDY в RKCS.Цитата:
Сообщение от form
Для DM/DB/DR в RSX-11M+ есть overlapped seek (для DK нету). Я так понимаю это и имеется в виду когда диск может делать seek в то время пока выполняется что-то другое. Но как я написал выше - условие когда RKDS всегда соответствует RKDA (который может быть изменен только програмно) соовтествует требуемому.Цитата:
Сообщение от Patron
- - - Добавлено - - -
А после установки он нас и не интересует - раз RDY, значит мы имеем полное право его менять по определению.Цитата:
Сообщение от Patron
- - - Добавлено - - -
А речь точно идет про RK05, а не про RK06/RK07? - это другой контроллер. Собственно говоря исходники всех старший UNIX (включая backport с 32bit) есть.Цитата:
Сообщение от Patron
В документации прямо сказано, что в ситуации POLL - содержимое RKDS никак не связано с RKDA.Цитата:
Сообщение от form
Об том и речь - бит RDY устанавливается в RKCS после начала выполнения приводом команды SEEK, а не после завершения.Цитата:
Сообщение от form
В какой? Ссылка на документацию есть?Цитата:
Сообщение от Patron
Ну и что? В упор не вижу препятствия какого-либо. Вплоть до того, что даже не вижу разницы работаем мы с одним приводом все время или запустили seek на одном и тут же I/O на другом. То есть абсолютно не вижу разницы.Цитата:
Сообщение от Patron
Да, RK05 - довольно крутой контроллер, который пока никто в мире не смог точно сэмулировать.Цитата:
Сообщение от form
И наконец мы имеем работающие исходники эмулятора где все тесты проходят насколько я понимаю :)
- - - Добавлено - - -
А может весь секрет в том, что и DEC всего что написал в доке не реализовал в виду устаревания контроллера раньше чем все было сделано (а что DEC писал доки до того как реализовано - вроде бы все знают - далеко за примерами ходит не нужно - доки по RT-11, RSX-11M/M+)? Не случайно ведь наверное для DK нету overlapped seek в DECовских же системах...Цитата:
Сообщение от Patron
http://pic.pdp-11.ru/images/rk05poll.pngЦитата:
Сообщение от form
Ну хорошо. Здесь лишь подтверждается что прерывание - результат конкретных условий. То есть снова прерывание отбрасываем. Оставляем завершение операции при котором выставляем RKDS. Чтение RKDS дает возможноть выставить следующий. Все. Укладывается в схему? Укладывается.
- - - Добавлено - - -
И кстати это опять таки легко проверить у Andrey_Ak.
Именно так я и планирую это эмулировать. Вопрос лишь в том, в какой последовательности DS отработавших приводов попадают в RKDS.Цитата:
Сообщение от form
Ходят слухи, что для POLL-команд DS выставляются в порядке положения приводов в цепочке, а для единственной I/O-команды DS всегда выставляется первым, вне зависимости от положения привода в цепочке.
По идее в порядке выполнения физически операции. Для эмулятора если хочется достоверности - можно соответственно разности между текущей и выбираемой дорожкой выбирать порядок.Цитата:
Сообщение от Patron
Я думаю, что все это несущественно ибо как не крути, а таки нету софта которому есть разница. В XXDP 5 тестов касаемых RK11/RK05, basic logic test #1 даже не требует самих дисков. Прогнать их для проверки.Цитата:
Сообщение от Patron
Может статься, что проблемы с написанием софта для использования продвинутых фич RK11 возникли из-за того, что контроллеры разных версий по-разному "сортировали" DS. Так как самое простое - выдавать все DS в порядке положения приводов в цепочке, то при такой реализации - после прерывания по завершению I/O в RKDS будет DS завершившего I/O привода только в том случае, если это первый привод в цепочке из всех, завершивших операции.
Вполне вероятно. Вероятно также, что документация писалась впрок (как у DEC обычно и было). Так или иначе, но факт остается фактом: overlapped seek (если конечно это вообще о том) сам DEC не использовал для RK05, хотя судя по написанному он возможен (причем в данном случае прерывания имеют место быть).Цитата:
Сообщение от Patron
Приводы RK ( если не ошибаюсь ) подключаются к контроллеру последовательно ( как сигналы IRQ от плат - к процессору ), поэтому более близкий к контроллеру привод ( насколько я понимаю ) может полностью заблокировать обмен для более дальних.Цитата:
Сообщение от form
Тут я просто не в курсе - никогда не лез в такие дебри. С RK05 имел дело только на Э100/25, и все, что о них знал - это куда ткнуть пальцами если вдруг привод не заводится, как форматнуть диск не загружая системы и тому подобную дребедень :)Цитата:
Сообщение от Patron
http://pic.pdp-11.ru/images/rk05poll2.png
Последнее предложение заставляет думать, что при выключенных прерываниях номер привода в RKDS всегда совпадает с RKDA, поэтому для просмотра состояния приводов - надо сначала заносить их номера в RKDA.
- - - Добавлено - - -
Подробное описание интересующего вопроса:
http://pic.pdp-11.ru/images/rk05poll3.png
Понятно, что контроллер учитывает все приводы, начавшие двигать головку, и опрашивает их по очереди, пока последний из приводов не закончит работу.
Ой ли? Как минимум, нелогично: пускаем SEEK сразу на трех накопителях, на двух из них - сдвиг на одну дорожку (идет перезапись большого файла с диска на диск) на третьем - на все 199 (другая задача чего-то захотела). И что, первой задаче ждать, пока на третьем накопителе головки пролетят все 199 дорожек?Цитата:
Сообщение от Patron
- - - Добавлено - - -
Угу.Цитата:
Сообщение от Patron
Вряд ли - обмен запускается только контроллером, а программа, которая им рулит (ОСь) такого не должна допустить.Цитата:
Сообщение от Patron
А вообще, надо бы поразглядывать список сигналов в шине от контроллера к накопителям. Может что удастся сообразить.
2All: у кого есть, выложите, плз, означенный список из описания накопителя.
.
Похоже, что 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. Но как с этим обстоит на самом деле - ещё предстоит выяснить.