ДВК (и всё, что с ними связано)

Вид для печати

Показывать 40 сообщений этой темы на одной странице

19.02.2012, 19:46
Patron

Цитата:

Сообщение от form

Так может проще сделать временной мерой загрузку простой программки без операционки которая все сделает?
Или как вариант - загрузка RAFOS/RM который весь находится в памяти и может быть вообще без терминала.

Без стандарта мультиплексирования пакетного и неоформленного обменов через порт терминала - это всё равно не сделать. А имея стандарт - можно делать что угодно.

Принцип такой: Когда происходит вызов мультиплексора (например, драйвер псевдодиска хочет записать блок и через аргумент вызова передаёт мультиплексору адрес блока памяти с пакетом для передачи) - мультиплексор перестаёт транслировать прерывания порта в RMON, производит отправку/получение пакетов, после чего восстанавливает то состояние терминального обмена, которое имелось на начальный момент.
19.02.2012, 19:47
form

Цитата:

Сообщение от Patron

Без стандарта мультиплексирования пакетного и неоформленного обменов через порт терминала - это всё равно не сделать. А имея стандарт - можно делать что угодно.

Зачем мультиплексирование если обмен ведется только для одной функции, а терминала нет? :)
19.02.2012, 19:50
Patron

Цитата:

Сообщение от form

заливаем @мониторскими командами врапер для MX или еще чего

В этом случае мультиплексирование не требуется.
19.02.2012, 19:51
form

Цитата:

Сообщение от Patron

В этом случае мультиплексирование не требуется.

Мне кажется это будет самый незатратный вариант - залить на ту сторону прогу с драйвером, драйверу создать видимость системы и далее передавать ему запросы удаленно.
19.02.2012, 19:52
Patron

Написать абсолютно-загружаемые драйверы с терминальными врапперами для всех устройств ДВК - это очень круто и не очень сложно :)
19.02.2012, 19:55
form

Цитата:

Сообщение от Patron

Написать абсолютно-загружаемые драйверы с терминальными врапперами для всех устройств ДВК - это очень круто и не очень сложно :)

Да чего мелочиться - сразу qbus over serial ;)
19.02.2012, 20:02
Patron

Цитата:

Сообщение от form

Да чего мелочиться - сразу qbus over serial

Но есть одна сложность - нужно переписывать драйверы (а в случае конкретно с MX - исходник довольно кривой).

Тогда как написав простейший терминальный мультиплексор и встроив его в простейший псевдо-дисковый драйвер - можно грузить на целевой ДВК родную операционку и использовать родные программы и драйверы.

Так что я всё же счтитаю, что мультиплексор - более простое, универсальное и выгодное решение.
19.02.2012, 20:05
form

Цитата:

Сообщение от Patron

Но есть одна сложность - нужно переписывать драйверы (а в случае конкретно с MX - исходник довольно кривой).

Тогда как написав простейший терминальный мультиплексор и встроив его в простейший псевдо-дисковый драйвер - можно грузить на целевой ДВК родную операционку и использовать родные программы и драйверы.

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

Потому я и предложил простой вариант где ни переписывать драйвер не надо ни мультиплескирования :)
Просто грузим на ту сотрону прогу которая делает ноповсский форк процессор для драйвера и эмулит подпрограмму завершения. Для полного счастья ноповский EMT чтобы инсталяционные проги советских драйверов счастливы были. А потом просто удаленно подсоввываем родному драйверу запросы :)
19.02.2012, 20:14
Patron

Цитата:

Сообщение от form

Потому я и предложил простой вариант где ни переписывать драйвер не надо ни мультиплескирования :)
Просто грузим на ту сотрону прогу которая делает ноповсский форк процессор для драйвера и эмулит подпрограмму завершения. Для полного счастья ноповский EMT чтобы инсталяционные проги советских драйверов счастливы были. А потом просто удаленно подсоввываем родному драйверу запросы

Т.е. создаём для ДВК "вынесенный филиал RMON" с терминальным враппером, позволяющий грузить родные драйвера. А на стороне PC запускаем эмулятор ДВК с "ответными частями" драйверов, которые по сути - один и тот же "фронт-энд" ( только в файлах с разными именами ) настроенный на передачу запросов I/O через COM-порт в "вынесенный филиал RMON".
19.02.2012, 20:20
form

Цитата:

Сообщение от Patron

Т.е. создаём для ДВК "вынесенный филиал RMON" с терминальным враппером, позволяющий грузить родные драйвера. А на стороне PC запускаем эмулятор ДВК с "ответными частями" драйверов, которые по сути - один и тот же "фронт-энд" ( только в файлах с разными именами ) настроенный на передачу запросов I/O через COM-порт в "вынесенный филиал RMON".

Именно так.
При желании можно даже полный рмон послать на ту сторону, но не думаю, что это нужно :)

---------- Post added at 23:20 ---------- Previous post was at 23:14 ----------

Причем вместо байта с кодом 100 передавать его заменитель двухбайтный, а появление такого байта со стороны ДВК будет означать, что все пропало :)
19.02.2012, 20:24
Patron

Идея мультиплексора привлекает меня тем, что не нужно хорошо знать устройство RMON и принципы загрузки и работы драйверов. Написать для RT-11 драйвер системного псевдо-диска со встроенным мультиплексором, который позволит загружать RT-11 через порт её системного терминала - я могу довольно легко. А вот написать "вынесенный филиал RMON" - мне не по силам.
19.02.2012, 20:28
form

Цитата:

Сообщение от Patron

Идея мультиплексора привлекает меня тем, что не нужно хорошо знать устройство RMON и принципы загрузки и работы драйверов. Написать для RT-11 драйвер системного псевдо-диска со встроенным мультиплексором, который позволит загружать RT-11 через порт её системного терминала - я могу довольно легко. А вот написать "вынесенный филиал RMON" - мне не по силам.

Так и здесь не нужно. Нужно из рмона отработать только одно смещение которое вызывается из .DRFIN :)
Ну а принципы загрузки легко в SYSMAC посмотреть.
Причем у нас нет цели поддерживать вообще все - к примеру драйвера с кучей векторов нам не особо нужны.

---------- Post added at 23:27 ---------- Previous post was at 23:25 ----------

Но вобщем любой вариант какой бы он не был не повредит :)

---------- Post added at 23:28 ---------- Previous post was at 23:27 ----------

А насчет одновременной работы терминала - предусмотреть в пакете через каждые х байт, байт для терминального обмена который в случае NUL считается неиспользуемым :)
19.02.2012, 20:42
Patron

Цитата:

Сообщение от form

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

Смысла нет.

Порт передаёт 960 байтов в секунду. Пакет имеет максимальную длину 512+заголовок.

Мультиплексор "встревает" в терминальный обмен ( переставая транслировать прерывания порта в RMON ) только когда псевдодрайвер хочет прочитать или записать блок.

---------- Post added at 19:42 ---------- Previous post was at 19:39 ----------

Причём, когда мультиплексор принимает пакет из TTKB - он не мешает монитору выводить символы в TTPB.
19.02.2012, 20:46
form

Кстати попутно о пройденом уже - насчет всех устройств ДВК - это по сути любые устройства :)
Я себе заказал 5 макеток для QBUS и если понадобится, из одной сделаю втыкалку для советских плат. Можно по идее сделать обратную процедуру :)
19.02.2012, 21:09
Patron

Общий контур стандарта мультиплексирования форматного и неформатного обменов через порт терминала может выглядеть так:

1. По умолчанию осуществляется неформатный ввод-вывод. На стороне ДВК мультиплексор транслирует все прерывания TTO в RMON, а перед трансляцией в RMON прерываний TTI - проверяет, нет ли в порту TTKB признака начала пакета - байта 0377. На стороне PC мультиплексор отправляет нажатия клавиш в порт и проверяет поступающие из порта байты на признак начала пакета ( байт 0377 ) выводя все "честные байты" на экран консоли.

2. При получении во входном порту признака начала пакета - мультиплексор принимает пакет ( байты 0377 в пакете не нужно дублировать, поскольку структура пакета жёстко задана стандартом и байт 0377 имеет особый смысл только в одном месте пакета - в самом начале ).

3. Если принятый пакет требует посылки ответного пакета, либо если мультиплексор получает API-вызов с требованием передачи пакета - мультиплексор блокирует внешний вывод ( со стороны ДВК перестаёт транслировать в RMON прерывания TTO, а со стороны PC отправляет нажатые клавиши в свой временный буфер ввода ) и передаёт пакет.

Вот и всё. Этот несложный подход позволяет совместить в одном последовательном порту любое количество форматированных каналов с одним неформатированным.
20.02.2012, 00:10
Andrey_Ak

Нашел интересный драйвер MY, который позволяет читать и писать так-же
дискеты от Электроника-85 и МС0515 на ДВК.

Так-же написал две статьи по MY и MX контроллерам, обновил версии DW, MX, MY

Подробнее тут:

http://www.tis.kz/forum/topic.php?forum=1&topic=4
20.02.2012, 01:07
form

Под утро идейки разные в голову иной раз приходят...
Никакого DD, никакого мультиплексирования, никаких филиалов рмона.
Имеем незагрузочный MX с файлами, грузим его. Все. :)

Кто нам в сущности мешает послать VTCOMом код загрузчика MX и мини программку которая пользуясь его подпрограммой чтения найдет на диске файл монитора и прочитает блоки 1-4 :)

---------- Post added at 04:07 ---------- Previous post was at 04:06 ----------

этакий мини-DUP
20.02.2012, 11:38
Patron

Цитата:

Сообщение от form

Имеем незагрузочный MX с файлами, грузим его. Все.

Но это годится только для тех, кто научился писать MX на PC.

Сделать такое (насколько я понимаю) на порядок сложнее, чем просто подключить порт терминала ДВК к порту COM или telnet.
20.02.2012, 12:02
form

Цитата:

Сообщение от Patron

Но это годится только для тех, кто научился писать MX на PC.

Сделать такое (насколько я понимаю) на порядок сложнее, чем просто подключить порт терминала ДВК к порту COM или telnet.

Да, но это и была исходная задача.
Все остальное - развитие темы :)

К MX к слову не привязано - любой диск годится.
Опробовал на примере DM, попутно обнаружив ошибку в E11 которая проявится если пытаться грузиться своим загрузчиком, а не родной e11 командой с DM.

---------- Post added at 14:47 ---------- Previous post was at 14:46 ----------

А сложности вообще никакой.

---------- Post added at 14:47 ---------- Previous post was at 14:47 ----------

Особенно в сравнении с соданием протокола для связи по сериал :)

---------- Post added at 15:02 ---------- Previous post was at 14:47 ----------

Собственно... :)

Код:

.SH TT (Resident) DM (Resident) DM1 = DK DM2 = SY MQ (Resident) LD ZY SD SL (Loaded) VM SP NL DO 7 free slots .BO SY:/FO ?BOOT-U-No boot on volume ─
20.02.2012, 12:26
Patron

Цитата:

Сообщение от form

К MX к слову не привязано - любой диск годится.

Если есть любой другой рабочий привод, кроме MX - просто грузимся с него и форматируем MX.

Для того и нужен Bytestream/DSK Multiplexer, чтобы без лишних усилий превратить PC в рабочий дисковый привод ДВК.

Цитата:

Сообщение от form

А сложности вообще никакой. Особенно в сравнении с соданием протокола для связи по сериал

Мне протокол написать проще, чем как-то иначе создать системный диск MX на связке МС1201+MX при наличии только одного порта терминала.
20.02.2012, 12:39
form

Цитата:

Сообщение от Patron

Мне протокол написать проще, чем как-то иначе создать системный диск MX на связке МС1201+MX при наличии только одного порта терминала.

А я не создаю системного диска. Я просто гружу несистемный без долгих проблем и делается это тупо отправкой небольшого кода в @ монитор VTCOMом :)

---------- Post added at 15:39 ---------- Previous post was at 15:37 ----------

Без всякого второго терминала разумеется.
20.02.2012, 12:40
Patron

Цитата:

Сообщение от form

Я просто гружу несистемный без долгих проблем и делается это тупо отправкой небольшого кода в @ монитор VTCOMом

Но этот диск должен быть. И весьма желательно, чтобы этот диск был записан на том же приводе, на котором он будет читаться. Если так - то да.

Иначе - просто грузимся через терминальный порт и форматируем MX.
20.02.2012, 12:44
form

Цитата:

Сообщение от Patron

Но этот диск должен быть. И весьма желательно, чтобы этот диск был записан на том же приводе, на котором он будет читаться. Если так - то да.

Иначе - просто грузимся через терминальный порт и форматируем MX.

Это уже детали.
Я ставил задачу для решения исходного вопроса, а на развитие - у тебя есть достаточно хорошие идеи к которым могу только добавить, что в случае потери протокола его легко восстановить с любой точки если соединение прямое (а не через телнет) :)
20.02.2012, 13:19
Patron

Цитата:

Сообщение от form

Это уже детали.

Вряд ли так думают те, кто хоть раз пробовал записать MX на PC.

Цитата:

Сообщение от form

в случае потери протокола его легко восстановить с любой точки если соединение прямое (а не через телнет)

Длина каждого пакета известна в момент получения заголовка. Если идентификатор заголовка был испорчен - пакет целиком пойдёт в терминальный обмен, ответа не будет и дисковый обмен зависнет. Увидев это на экране - оператор захочет выйти в пульт и повторить загрузку. Выход в пульт осуществляется мультиплексором при приёме двух байтов 0377 подряд. Если контрольная сумма пакета данных не совпала - пакет будет перезапрошен ( если это чтение ) или послан повторно ( если это запись ). Пакеты команд и подтверждений передаются без контрольной суммы.
20.02.2012, 13:35
form

Цитата:

Сообщение от Patron

Вряд ли так думают те, кто хоть раз пробовал записать MX на PC.

А ты спроси не тех, а того, что тему открыл ;)

Цитата:

Сообщение от Patron

Длина каждого пакета известна в момент получения заголовка. Если идентификатор заголовка был испорчен - пакет целиком пойдёт в терминальный обмен, ответа не будет и дисковый обмен зависнет. Увидев это на экране - оператор захочет выйти в пульт и повторить загрузку. Выход в пульт осуществляется мультиплексором при приёме двух байтов 0377 подряд. Если контрольная сумма пакета данных не совпала - пакет будет перезапрошен ( если это чтение ) или послан повторно ( если это запись ). Пакеты команд и подтверждений передаются без контрольной суммы.

При прямом коннекте восстановление протокола делается автоматически без всякого участия оператора. У TU81 так - в каком бы состоянии он не оказался, его можно мгновенно вернуть в начальное :)
20.02.2012, 13:43
Patron

Цитата:

Сообщение от form

При прямом коннекте восстановление протокола делается автоматически без всякого участия оператора. У TU81 так - в каком бы состоянии он не оказался, его можно мгновенно вернуть в начальное

Мы пойдём другим путём :)

Асинхронный протокол без таймаутов восcтановить невозможно. Если ввести таймауты - подключение по telnet станет затруднительным.
20.02.2012, 13:44
form

Вложений: 1
Пре-RC пре-альфы ;)

Загрузчик для незагрузочного MX и вообще любого устройства - например носителя одинакового формата вставленного в другой тип дисковода.

Формат команды:

Код:

*DD[X][.SYS],MONNAM[.SYS][/N][/U:N]

Перед выполнением команды локально включается лог терминала. После выполнения лог отключается, последнее сообщение убирается из лога и получается готовый скрипт для отправки VTCOMом на загрузку в память. Более навороченный вариант лень делать - прога делалась просто для общего развития ;)

Драйвер не обязан быть тем же самым который на диске, не обязан соответствовать параметрам SYSGEN и/или MMUшности системы.

Опции:
- /N - не писать команды для записи нулей
- /U:N - использовать устойство N вместо 0 для загрузки
Код:

.RU RBOOT SY:DMX,RT11XM/U:2/N 0/240 2/415 32/41420 34/116020 ... 5324/72157 5326/63040 5330/72557 5332/62156 ?RBOOT-I-Use "005020G" command to boot DM2:RT11XM.SYS
20.02.2012, 13:45
form

Цитата:

Сообщение от Patron

Мы пойдём другим путём :)

Асинхронный протокол без таймаутов восcтановить невозможно.

Никаких таймаутов не нужно.
Стандартные serial порты как на PC так и на PDP-11, ДВК, УКНЦ (С2) кроме передачи символов еще и BREAK умеют слать. Ну за исключением УКНЦшной консоли которая нам и не пригодится :)
20.02.2012, 13:50
Patron

Цитата:

Сообщение от form

Никаких таймаутов не нужно.

Для автоматической работы - нужно. Никакой сигнал не поможет, если стандарт полагает нормальный промежуток времени ожидания ответа бесконечным.
20.02.2012, 14:07
form

Цитата:

Сообщение от Patron

Для автоматической работы - нужно. Никакой сигнал не поможет, если стандарт полагает нормальный промежуток времени ожидания ответа бесконечным.

В каком смысле не поможет?
Закладываешь стандартом, что BREAK - признак сброса в начальное состоение. BREAK однозначно идентифицируется в любое время и мгновенно. Проблема решена. Нет?
20.02.2012, 14:21
Patron

Цитата:

Сообщение от form

Проблема решена. Нет?

Решение о посылке сигнала должен принимать оператор. Таймаутов ведь нет.
20.02.2012, 14:22
form

Цитата:

Сообщение от Patron

Решение о посылке сигнала должен принимать оператор. Таймаутов ведь нет.

А ты не собираешься закладывать в протокол контрольные суммы и тому подобное?
20.02.2012, 14:27
Patron

Цитата:

Сообщение от form

А ты не собираешься закладывать в протокол контрольные суммы и тому подобное?

Контрольные суммы - пространственные сущности. Время им неподвластно. Если мультиплексор отправил пакет и ждёт ответа - без таймаутов он будет ждать вечно ( пока не придёт ответ или пока не вмешается оператор ).
20.02.2012, 14:29
form

Цитата:

Сообщение от Patron

Контрольные суммы - пространственные сущности. Время им неподвластно. Если мультиплексор отправил пакет и ждёт ответа - без таймаутов он будет ждать вечно ( пока не придёт ответ или пока не вмешается оператор ).

А причем тут время? Если ты отправил пакет и он не битый, ответ будет. Если пакет битый - мы слетели с протокола. Шлем BREAK и другая сторона мгновенно знает, что проблема есть.
Конечно это не решит всех вопросов - вроде падения программы на обратной стороне, но "штатные" нештатные ситуации поможет решить.
20.02.2012, 14:36
Patron

Цитата:

Сообщение от form

Если ты отправил пакет и он не битый, ответ будет.

Не факт. Потеря любого пакета равновероятна. Досточно исказиться любому биту в байте-идентификаторе заголовка пакета 0377 - и весь пакет не будет распознан как пакет, а отправится в терминальный обмен.
20.02.2012, 14:39
form

Цитата:

Сообщение от Patron

Не факт. Потеря любого пакета равновероятна. Досточно исказиться любому биту в байте-идентификаторе заголовка пакета 0377 - и весь пакет не будет распознан как пакет, а отправится в терминальный обмен.

Ну на подтверждение можно заложить определенное число циклов готовности опять таки без таймаута. Вобщем на любой вкус.
В том числе и по решению оператора можно опять таки послать BREAK который гарантированно дойдет на ту сторону как BREAK, а не потеряется/исказится как символ :)
20.02.2012, 14:46
Patron

Цитата:

Сообщение от form

Вобщем на любой вкус. В том числе и по решению оператора

Поскольку все потерянные пакеты попадают в терминальный обмен (и выводятся на экран), то именно оператору проще всего или принудительно отправить команду "пакет потерян" ( которую отправляет приёмник при несовпадении контрольной суммы ), или команду "выход в пульт" ( для последующей перезагрузки системы ).
20.02.2012, 15:42
form

Вложений: 2

Загрузчик незагрузочного MX.

Загрузчик для отправки через VTCOM.
Грузит RT11SJ.SYS с MX0.

Можно править:

Код:

5000-5002 время суток в тиках 5004 дата в формате RT-11 5006-5010 имя файла монитора в RADIX-50 (без SYS) 5014 название драйвера в RADIX-50 (на случай если MX но не MX) ;) 5016 номер дисковода 0-3

Запускается командой:

Код:

@5020G

UPD: добавлен сокращенный вариант MXBNZ.TXT - то же самое, но не передает нули. Слегка сокращает время передачи. Перед тем как передавать для надежности стоит зачистить память:

Код:

@R6/XXXXXX 160000 @0/XXXXXX 4747 @0G 000002 @
20.02.2012, 21:16
Patron

Написал для байтового потока эмуляторную утилиту ODT_Loader для загрузки любых кодов в память компьютера через терминальный интерфейс ODT.

Утилита начинает загрузку скрипта при совпадении двух условий:

1. Всё готово для загрузки скрипта и на экране приглашение ODT: @
2. Состояние утилиты "Load" активировано.

Скрипты - это наборы обычных текстовых команд ODT с одним дополнением: конец строки преобразуется в <CR>, символ "¬" - в <LF>.

В результате такой скрипт:

Код:

R0/¬ ¬ ¬ ¬ ¬ ¬ ¬ RS/

Даёт такой результат:

Код:

@R0/000113 R1/130422 R2/000000 R3/146772 R4/000000 R5/000036 R6/130402 R7/150214 @RS/000004 @

А такой скрипт:

Код:

10000/5000¬ 12701¬ 177720¬ 12702¬ 177722¬ 10012¬ 12711¬ 1¬ 5012¬ 12711¬ 2¬ 5012¬ 12711¬ 3¬ 12712¬ 400¬ 12711¬ 4¬ 12711¬ 5¬ 106427¬ 340¬ 137¬ 0 10000G

Даёт такой результат:

Код:

@10000/177777 5000 010002/000000 12701 010004/177777 177720 010006/000000 12702 010010/177777 177722 010012/000000 10012 010014/177777 12711 010016/000000 1 010020/177777 5012 010022/000000 12711 010024/177777 2 010026/000000 5012 010030/177777 12711 010032/000000 3 010034/177777 12712 010036/000000 400 010040/177777 12711 010042/000000 4 010044/177777 12711 010046/000000 5 010050/177777 106427 010052/000000 340 010054/177777 137 010056/000000 0 @10000GHD Boot-I-Cold boot.. HD (177720) disk driver v1.0b 2011 SL V08.00 [SW] Сторожевых С.В. 1988 RT-11SJ (S) V05.04
22.02.2012, 13:59
Andrey_Ak

Цитата:

Сообщение от Patron

Но это годится только для тех, кто научился писать MX на PC.

Сделать такое (насколько я понимаю) на порядок сложнее, чем просто подключить порт терминала ДВК к порту COM или telnet.

- Ничего сложно... Практически любой 286 может это... И не надо определенных контроллеров...

Это читать оригинальные дискеты MX сложно, а форматировать и писать спец дискеты просто... Это не совсем дискеты MX, они отличаются от обычных MX, отформатированных на ДВК... Но ДВК понимает эти дискеты без проблем...

Показывать 40 сообщений этой темы на одной странице

Текущее время: 08:33. Часовой пояс GMT +3.