-
Локальная сеть корвет
Наконец я осуществил свою давнюю мысль - изучил ОПТС 2.0 в дизассемблере IDA и, в частности, разобрал протокол работы локальной сети. Хочу поделиться результатами с общественностью.
Но вначале хотелось бы обсудить физический уровень сети. Я нигде не нашел никакой документации об этом, видимо, она прилагалась только в бумажном виде к комплексу КУВТ. Приходится строить предположения. Как видно из схемы корвета, передатчик сети выведен в виде транзистора с открытым эмиттером. Это позволяет соединять выходы нескольких корветов параллельно. В конце линии обязательно должен иметься нагрузочный резистор на землю. При бездействии передатчика транзистор закрыт и не влияет на работу сети, но в случае попытки одновременной передачи несколькими машинами произойдет коллизия. Приемник сети - обычный TTL-вход. Их также можно соединить параллельно.
Вырисовывается такая картина сети. Имеется комплекс из нескольких РМУ (клиентов) и одного РМП (сервера). По помещению проложен трехпроводной кабель. Все передатчики РМУ соединены с одной из жил, и туда же подключен приемник РМП. Приемники РМУ соединены с другой жилой, и к ней подключен передатчик РМП. Третья жил - земля. От обоих жил к земле подключены резисторы примерно 470 ом. В этом случае клиенты могут обмениваться данными только с сервером, передача от клиента к клиенту невозможна. Это вполне согласуется с протоколом сети. Согласно протоколу, клиент никогда не начинает передачу по своей инициативе. Передача разрешается только по команде от сервера после получения адресного пакета.
Но возникло одно затруднение. Имеющиеся у меня тестовые программы (KTDP и OLD) имеют режим проверки сети. Так вот они требуют, чтобы данные от передатчика сети попадали на вход приемника - то есть передатчик и приемник образуют петлю. В таком случае устройство сети получается немного другим. По помещению проложен двухпроводной кабель. К одной из жил подключены все передатчики и периемники сети, как клиентов, так и сервера. Вторая жила - земля, и между жилами включен нагрузочный резистор. Такая топология сети похожа на распространенный в свое время тонкий ethernet 10base2. Возникающее при передаче пакета паразитное эхо на входе своего же приемника подавляется тем, что на время передачи данных прерывания от приемника сети запрещаются (поначалу я не мог въехать, зачем так сделано в коде ОПТС). Поскольку протокол сети полудуплексный, и целиком контролируется сервером, коллизий в кабеле возникать не должно.
Какой из вариантов использовался на практике, трудно сказать. Работать должны оба.
Теперь насчет параметров последовательного канала. Скорость передачи здесь всегда 19200 baud. Параметры кадра - 8О1. То есть 8 бит данных, 1 стоп-бит и бит проверки на НЕЧЕТНОСТЬ. Обратите внимание - контроль четности в последовательных интерфейсах применяется крайне редко, тут он сделан, очевидно, из-за высоких помех на линии связи.
Ну и, наконец, как подключить корвет к последовательному порту PC. Сделать это можно двумя способами. Первый, самый простой, выглядит так:
http://zx.pk.ru/picture.php?albumid=135&pictureid=917
Повезло, что в корвете на входе и выходе ВВ51 уже стоят инверторы. Это позволяет соединить передатчик корвета прямо с компортом, а приемник - через простейший делитель. Такая схема работает, проверено, с современными набортными компортами и USB-Serial преобразователями. Со старыми компортами, на мультикартах, могут быть пробемы, поскольку логический 0 здесь именно 0, а не -12В, как положено по стандарту. В этом варианте поключения петля с выхода на вход не обеспечивается. К переходнику можно подключить и несколько корветов, соединив у них параллельно соответственно входы и выходы.
Второй вариант подключения:
http://zx.pk.ru/picture.php?albumid=135&pictureid=918
Здесь уже использована специализированная микросхема формирователя RS-232 уровней. Такая схема гарантированно будет работать с любым компортом. Также здесь имеется полноценная петля с выхода передатчика на вход приемника. Разумеется, к нему также можно подключить несколько корветов.
При любом варианте подключения, чтобы корвет стал РМУ (клиентом), надо назначить ему адрес сети, соединив с землей какие-либо из выводов A0-A3 на сетевом разъеме. На схемах я условно показал их как Ax. Если такого соединения не делать, то корвету назначается номер 0, и он становится сервером.
Теперь я немного систематизирую свои записи и в следующем письме опишу логический протокол сети.
---------- Post added at 11:52 ---------- Previous post was at 10:57 ----------
Логическая организация сети. Транспортный уровень.
Обмен в сети происходит всегда под управлением сервера. Только сервер может начать передачу данных в сеть по своей инициативе. Клиент производит передачу только если получает явную команду от сервера. Это исключает полностью коллизии на линии связи. Единицей обмена данными является пакет. Пакеты могут быть различной длины. Общая сруктура пакета такая:
Код:
Смещение длина описание
+00 1 Байт всегда равен 01 - признак начала пакета
+01 1 Длина пакета. Равен фактической длине + 1Dh
+02 1 Номер пакета. Пакеты нумеруются начиная с 20h и до FFh
+03 1 Буква, определяющая тип пакета
+04 nnn Тело пакета
+nnn+4 1 Контрольная сумма пакета
+nnn+5 1 Байт всегда равен 0D - признак конца пакета
Далее я опишу форматы отдельных пакетов.
Как видно, пакет всегда начинается с байта 01 и заканчивается 0D. Байт 01 не может встретиться в теле пакета. Фактически, когда клиент во время приема данных встречает 01 до конца пакета, он отбрасывает весь ранее принятый блок данных и начинает принимать пакет заново. Это позволяет избежать подвисаний в случае потери нескольких байт при приеме. Более того, прняты специальные меры, чтобы в пакете не встречалось байтов с кодами 00-1F (все управляющие). Таким образом всеь пакет состоит только из отображаемых байтов. Зачем так сделано - мне не совсем понятно. Похожие меры применяются, например, при передаче вложений по e-mail и сети фидо(MIME- и UUE-кодирование). Но там они оправданны, а здесь?
Длина пакета - это полная длина, включая префикс 01 и окончание 0D. К этой длине добавляется 1Dh для того, чтобы этот байт был не менее 20h. Таким образом, максимальная длина пакета не должна превышать 226 байт. На практике пакеты создаются меньшего размера - не более 100 байт. Это позволяет уменьшить объем перепосылаемой по сети информации в случае ошибки.
Номер пакета индивидуален для каждого пакета. Пакеты нумеруют начиная с 20h. При последовательной передаче данных номера постепенно увеличивают вплоть до FFh, а затем снова заворачивают на 20h. При приеме адресного пакета счетчик номеров сбрасывается на начальное значение. Номера позволяют проконтролировать потерю пакетов при приеме - в этом случае последовательность нумерации собъется.
Буква типа пакета определяет, какая информация содержится в пакете. Всего в ОПТС поддерживается 7 типов пакетов:
A - пакет адреса
R - запрос передачи данных, от сервера к клиенту
S - запрос приема данных, от клиента к серверу
D - пакет данных
Z - пакет конца данных
Y - пакет подтвержения приема
N - пакет ошибки приема
Возможно, что существуют и другие типы пакетов, но ОПТС 2.0 поддерживает только эти, и любой другой тип вызовет ошибку.
Контрольная сумма вычисляется по всему пакету начиная от байта длины и заканчивая собственно контрольной суммой. Префикс 01 в сумму не входит. Вычисляется она так. Вначале все складываются все байты пакета. Затем берется младший байт полученной суммы и с ним делается такое преобразование (sum - младший байт суммы):
Код:
cs=((sum>>6)+sum)&0x3f+0x20;
Результат CS и есть искомая сумма. Последние 2 преобразования (&0x3f+0x20) очевидно, сделаны для того, чтобы контрольная сумма не попала в диапазон 00-1F.
-
Формат пакетов Z, Y, N совершенно одинаков и примитивен.
Код:
Смещение длина описание
+00 1 01
+01 1 23h - длина пакета
+02 1 номер пакета
+03 1 'Z' или 'Y' или 'N'
+04 1 Контрольная сумма
+05 1 0Dh
Адресный пакет A имеет такой формат:
Код:
+00 1 01
+01 1 25h - длина пакета
+02 1 номер пакета
+03 1 'A'
+04 1 Тип адреса. 0 - широковещательный, 1 - для конкретного РМУ
+05 1 Номер РМУ (в широковещательном режиме не имеет смысла)
+06 1 Контрольная сумма
+07 1 0D
Таким образом, пакет может адресовать как конкретное РМУ, так и все сразу.
Пакет приема данных - тип R, инициирует прием данных клиентом от сервера. Пакет определяет, какие именно данные будут передаваться и что с ними потом делать. Формат пакета:
Код:
+00 1 01
+01 1 28h - длина пакета
+02 1 номер пакета
+03 1 'R'
+04 1 Цифра в ASCII от '0' до '9' - тип передаваемых данных
+05 4 Для данных типа 3 и 7 - стартовый адрес области в HEX
+09 1 Контрольная сумма
+0A 1 0D
Пакет передачи данных - тип S - запрос на передачу данных от клиента к серверу. С его помощью можно выгрузить из РМУ на сервер бейсик-программу или любую область памяти. Формат пакета:
Код:
+00 1 01
+01 1 31h - длина пакета
+02 1 номер пакета
+03 1 'S'
+04 1 копируется в ответный пакет R, назначение принимаемых сервером данных
+05 4 копируется в ответный пакет R, адрес размещения данных в памяти сервера
+09 1 Цифра в ASCII от '0' до '9' - тип данных, отсылаемых к серверу
+0A 4 Для блоков памяти - адрес начала области памяти в HEX
+0E 4 Для блоков памяти - адрес конца области памяти в HEX
+12 1 Контрольная сумма
+13 1 0D
Цифра типа данных по смещению 04 пакетов R и S может принимать следующие значения:
Код:
0 - текстовое сообщение с предварительной очисткой экрана,
для пакета S - запрос копии экрана РМУ
1 - область памяти с адреса 91D1, смысла я не понял.
2 - бейсик-программа
3 - образ области памяти (двоичный набор данных)
4 - в ОПТС не определено, используется сетевой библиотекой как признак файла на диске
5 - тело COM сообщения
6 - флаг наличия COM-сообщения
7 - образ блока памяти с передачей управления на начало блока
8 - предыдущий счетчик пакетов, видимо для проверки числа принятых пакетов.
9 - текстовое сообщение без очистки экрана
Понятно, что не все типы данных можно использовать в обоих - и S, и R пакетах. Например, передача в РМУ тела COM-сообщения бессмысленна. Начальный и конечный адреса в пакете записываются в виде 4 цифр или букв в HEX-коде со всеми незначащими нулями, например "001D".
Ну и, наконец, самый главный - пакет данных, тип D. В этот пакет упаковываются передаваемые данные.
Код:
+00 1 01
+01 1 длина пакета (+1Dh)
+02 1 номер пакета
+03 1 'D'
+04 LLL Данные пакета
LLL+4 1 Контрольная сумма
LLL+5 1 0D
Понятно, что здесь тоже принимаются меры по недопустимости управляющих кодов 00-1F в теле пакета. Для этого данные упаковываются с помощью специального кода 23h (знак #) следующим образом
23 xx - указывает, что к следующему байту надо добавить 40h, а старший бит передать как есть
23 23 - заменяется на одиночный знак #
23 00 - заменяется на 00
Упаковке подвергаются все байты с кодами 00-1F, 80-9F, а также байт 7F. При формировании пакета данных ОПТС следит, чтобы общий размер пакета не превышал 88 байт. Видимо, и при формировании передаваемых пакетов следует придерживаться такого же правила.
Ну вот вроде бы и все по форматам пакетов. Осталось описать сеансовый уровень сети - порядок передачи пакетов.
-
прелдагаю обсуждение вести в отельной теме
http://zx.pk.ru/showthread.php?t=23458
а тут оставить оригинальный текст и правки ?
p.s. если все будут сильно против - то вернем назад ...
-
Сеансовый уровень. Протокол обмена пакетами.
Как я уже говорил выше, обмен всегда начинает сервер. Широковещательный режим пока не рассматриваем, только адресный.
1. Фаза адреса. Сервером отсылается адресный пакет, выбирающий то РМУ, с которым сервер желает взаимодействовать. РМУ, адрес которого указан в пакете, отвечает серверу пакетом Y. Остальные РМУ переходят в пассивное состояние и ждут нового адресного пакета.
Следующие фазы зависят от того, в какую сторону планируется передача данных. Для отправки данных от сервера к клиенту протокол выглядит так:
2. Фаза типа данных. Сервером отсылается пакет R, содержащий тип данных и, если надо, адрес загрузки. Клиент отвечает пакетом Y.
3. Фаза передачи данных. Сервер начинает отсылать пакеты типа D с данными, клиент их принимает, распаковывает и размещает в своей памяти. После каждого принятого пакета D клиент отвечает пакетом Y, если пакет D принят успешно. В случае ошибок - неправильной КС, сбоя последовательности нумерации пакетов итд, клиент отвечает пакетом N. Тогда сервер перепосылает тот же самый пакет D с тем же номером.
4. Фаза конца данных. После передачи последнего пакета D сервер отправляет пакет Z. Клиент отвечает пакетом Y и приступает к обработке полученных данных (об этом далее).
При запросе сервером данных от клиента протокол будет немного другим:
2. Фаза типа данных. Сервером отсылается пакет S, содержащий тип данных и, если надо, адреса начала и конца области памяти. Клиент отвечает пакетом Y, затем, срзу же, пакетом R, содержащим в себе копию параметров (тип данных и адреса) из полученного пакета S. Сервер подтверждает прием пакетом Y.
3. Фаза передачи данных. Клиент начинает отсылать пакеты типа D с данными, сервер их принимает, распаковывает и делает с ними что ему нужно. После каждого принятого пакета D сервер отвечает пакетом Y, если пакет D принят успешно. При ошибке сервер отвечает пакетом N и клиент перепосылает тот же пакет D.
4. Фаза конца данных. После передачи последнего пакета D клиент отправляет пакет Z. Сервер отвечает пакетом Y, а клиент переходит в пассивное состояние с снова ждет адресного пакета.
В любой момент сервер может аварийно прервать процесс обмена, просто послав новый адресный пакет. При этом выбранный ранее клиент прекращает передачу данных по сети.
На всякий случай привожу диаграмы взаимодействия сервера и клиента
Код:
Загрузка данных в клиента от сервера:
Сервер Клиент (РМУ1)
A (1)
Y
R
Y
D
Y (N при ошибке)
D
Y
........................
Z
Y
Код:
Выгрузка данных на сервер из клиента:
Сервер Клиент (РМУ1)
A (1)
Y
S
Y
R
Y
D
Y (N при ошибке)
D
Y
........................
Z
Y
Теперь относительно обработки клиентом принятых данных. Для типов 0 и 9 принимается текстовая строка, которая тут же выводится на экран РМУ. Для типа 0 экран предварительно очищается. Для типа 2 принимается массив данных, содержащий упакованную в токены бейсик-программу. Массив размещается в памяти, начиная с адреса 91D1h, и может заполнять память вплоть до BF00h. Массив имеет такую структуру.
Код:
+00 1 FFh
------- программная строка -------
+01 2 адрес следующей программной строки
+03 2 номер данной строки
+05 nnn тело данной строки, заканчиватеся нулем.
Далее идет следующая программная строка, и так до конца всей программы.
После приема всей программы производится коррекция адресов следующих строк по всему массиву, и возврат в режим командной строки бейсика.
Для типа данных 3 и 7 происходит прием последовательности байтов и размещение их, начиная с указанного в пакете R адреса. При этом не прверяется, имеется ли в этом месте именно память. Так что можно писать по любому адресу - и в АЦЗУ, и в регистры периферии, и в область ROM (что приведет к записи в теневую память по тем же адресам). Для типа данных 3 после приема всех байтов управление возвращается в командную строку бейсика. Для типа данных 7 происходит передача управления по начальному адресу загрузки данных. Так можно передать в РМУ самозапускаемую программу в машинных кодах. Я пробовал TETRIS и GONKI - запускаются и работают. Кстати, если передать в РМУ данные типа 7 нулевой длины (то есть за пакетом R сразу передать пакет Z, не передавая данные), то можно просто передать управление по указанному в пакете R адресу. Так можно запустить предварительно загруженный в память код, ну или, например, перезагрузить корвет, передав управление по адресу 0.
Ну и, наконец, COM-сообщение - это сообщение, формируемое оператором бейсика COM. Его можно вызвать и из программы, и непосредственно из командного режима. После ввода сообщения формируется флаг наличия сообщения (становится равным 1), и его можно проверить, запросив данные типа 6. Текст сообщения можно получить, запросив данные типа 5, при этом флаг наличия сообщения автоматически сбрасывается в 0.
В коде ОПТС2 имеется одна особенность. После старта бейсика тело сообщения оказывается целиком заполнено кодом FF, и флаг наличия сообщения также устанавливается равным FF. Проще говоря, бейсик не подчищает эту область памяти, заполненную FF в процессе теста RAM при старте ОПТС. Это явный баг в коде, но его можно использовать для отлова по сети момента перезагрузки РМУ. После первого чтения строки байтов FF флаг наличия сообщения автоматически сбросится и дальше все будет работать как обычно.
COM-сообщения - очень полезный инструмент для взаимодействия с сервером. В своей серверной программе на PC я сделал режим, при котором прямо с РМУ можно запросить загрузку данных из файла на сервере, например COM "@L PROG.BAS" пересылает программу PROG.BAS с PC на РМУ. Так можно эмулировать возможности дискового бейсика на ПК8010, не имеющем дисковода.
Вот вроде пока и все, что я хотел рассказать по сети корвет.
-
Вдогонку - забыл описать широковещательный режим. В этом режиме возможна только передача данных от сервера к РМУ, зато сразу во все. Протокол при этом односторонний - передает только сервер, а клиенты молча собирают данные в буфер. Никаких пакетов подтверждения Y в этом случае, естественно, не посылается. Порядок передачи данных тут такой:
A(0) R D D D. .... Z
Клиенты молча принимают все данные и переходят в пассивный режим ожидания нового адресного пакета. Поскольку в этом режиме коррекция ошибок не выполняется, то использовать его не особо желательно.
-
Вложений: 1
Итак, выкладываю программу KL, выполняющую серверные функции в сети корвет-РМУ. По сути, обычный ПК превращается в сервер ПК8020. Сеть корветов подключается к любому последовательному порту ПК, можно даже в переходник USB-serial. Схемы подключения я ранее уже приводил, на всякий случай вложил их в тот же архив. Схемы проверены и на 100% рабочие.
Программа позволяет делать следующее:
- загружать в РМУ бейсик-программы и двоичные файлы с возможным автозапуском
- выгружать из РМУ бейсик-программы и любые области памяти
- просматривать бейсик-программы из РМУ в распакованном (символьном) виде, как по команде бейсика list
- посылать сообщения на консоль РМУ и принимать COM-сообщения
- наблюдать за трафиком в сети (функция сниффера, как tcpdump)
- использовать ПК как интерактивный сервер данных - посылать программы в РМУ по запросу с самих РМУ (COM-командами). Список команд есть в исходниках, на всякий случай привожу сюда:
Код:
@L file загрузка бейсик-программы
@S file сохранение бейсик-прогаммы
@LB file adr загрузка двоичного файла с адреса adr
@LBR file adr загрузка двоичного файла с адреса adr c автозапуском
@SB file adr len сохранение участка памяти с адреса adr длиной len
Как тут уже заметили, такая функциональность в свое время уже была реализована, но с другим форматом командной строки. Ну тут уж что получилось, то получилось. Переделывать уже неохота, да и привык я к таким командам.
Несколько слов о ключах настройки параметров. Адреса и размеры участков памяти всегда задаются в HEX-коде, например 3с00. Адрес РМУ и параметры времени задержки задаются в десятичном коде.
-t - устанавливает таймаут последовательного порта в 0.1с. По умолчанию 8 - 0.8c. Чем меньше параметр - тем быстрее идет опрос сети при поиске активных РМУ и меньше время подвисания при потере данных. С другой стороны, слишком маленький таймаут приводит к тому, что РМУ просто не успеет передать данные, и программа вывалится в бесконечный цикл перепосылки данных.
-u - устанавливает задержку перед посылкой адресного пакета. Дело в том, что по окончании обмена данными РМУ нужно определенное время для подготовки к приему нового адресного пакета. Если это время слишком маленькое - пакет уйдет раньше, чем РМУ подготовится к его приему, и программа вывалится по таймауту. Для одиночных операций (послать или принять файл) этот ключ практически не имеет значения - там адрес посылается всего один раз. Но при постоянном обмене, как например в режиме сервера, слишком большое значение этого параметра может серьезно замедлить работу.
На самом деле, программа не использует режим корректировки ошибок сети. Если пришел битый пакет, или РМУ ответило N, то просто файл перепосылается с самого начала. У меня еще ни разу не было ошибок передачи данных, а делать перепосылку отдельных пакетов на всякий случай без возможности отладки мне неохота.
Программа написана на С под Linux. Но особо на линукс не завязана (использует только termios для доступа к последовательному порту) и, по идее, может собраться и под другими ОС. Под FreeBSD точно работает. Собирается программа и в x86, и в x86_64 режиме. На всякий случай (вообще-то это очевидно) команда для сборки:
Надо бы, конечно, написать документацию, или хотя бы README к программе, но как-то неохота пока. Во времена, когда я копал винты, документацию писать я даже любил, но теперь постарел и обленился. Думаю, и сами разберетесь с программой, ничего сложного там нет и есть подсказка по ключу -h.
Вопросы, пожелания, замечания - оставляйте здесь, обсудим. Программа будет еще дорабатываться. Если кто-нибудь сам доработает программу - не поленитесь выложить сюда изменения, будьте людьми.
-
Прошу все обсуждения вести в соседней теме - http://zx.pk.ru/showthread.php?t=23458. Там я и ответил.
А эту и правда лучше использовать как наполняемую базу данных по сети.
-
Подключение к Корвету
Код:
РП15-9Г D-Sub-9M
OUTNL 4 2
INNL 2 4
GND 3 3
A0 9 6
A1 8 7
A2 7 8
A3 6 9
надо задать адресс РМУ, закоротить нужные A0-A3 на землю.
например A0 для номера РМУ #1
по схеме на 1первый вывод подано 5 вольт, но на платах вроде как не подключено, но на всякий случай проверить ;)
Спасибо DDp за консультацию
-
Вложений: 1
После изучения библиотеки NETLIB я доработал программу сетевого обмена. Выкладываю новую версию.
Что добавлено и изменено:
Приделан автозапуск программ на бейсике.В отличии от netlib, я использую более универсальный способ - в буфер командной строки РМУ записывается команда RUN, и затем буфер передается интерпретатору на выполнение. Соответственно, добавлен ключ -pr:
Код:
kl -pr test.bas - загрузка и запуск программы test.bas
Можно указывать этот ключ и без имени файла - тогда будет просто запущена ранее загруженаая программа:
Код:
kl -pu test.bas - загрузка программы
kl -pr - запуск программы
В продолжении предыдущей идеи - добавлен ключ -pi, позволяющий запустить на выполнение любую команду бейсика. Например
Код:
kl -pi "PRINT FRE(0)"
выпооняет команду print fre(0) на РМУ. Так можно и добавлять программные строки в программу, например
добавляет в программу строку 10 с текстом PRINT A.
Добавлена возможность просмотра копии тестового экрана РМУ. Для этого добавлен ключ -ms:
Код:
kl -ms
......................
---------------- Экран РМУ #2 ----------------------------
Бейсик КОРВЕТ в.2.0
Москва 1988
Ok
Ok
LIST
10 INPUT A
20 PRINT A,SQR(A)
30 END
Ok
RUN
? 5534
5534 74.3908
Ok
---------------- Экран РМУ #2 ----------------------------
Эту возможность можно использовать для снятия скриншотов бейсик-программ, и, кроме того, комбинация режимов -ms и -pi позволяет в некоторых, ограниченных пределах организовать общение с бейсик-системой корвета целиком с РС, не подключая к корвету монитор.
Добавлена возможность передачи управления по произвольному адресу без заливки двоичной программы в РМУ. Для этого используется ключ -br без имени файла, например:
Код:
kl -s 9000 -bu gonki.bin - загрузка файла gonki.bin в память с адреса 9000
kl -s 9000 -br - запуск с адреса 9000
Конечно, в данном случае проще обойтись одной командой:
Код:
kl -s 9000 -br gonki.bin
Ну и, наконец, добавлена возможность удаленного программного перезапуска корвета. Для этого введена группа ключей -r:
Код:
-rc - полный холодный перезапуск, как кнопкой RESET, со всеми тестами ОПТС
-rw - теплый перезапуск бейсика, происходит мгновенно.
-rb - принудительная загрузка операционной системы с диска
Режим -rb производит загрузку ОС, даже если сетевой адрес РМУ отличается от 0 - это дает возможность загрузить cp/m, не выдергивая сетевой разъем из корвета. Конечно, если в дисководе нет диска или дисковода вообще нет как такового, то будет запущен бейсик. А режим -rw запускает бейсик всегда, независимо от наличия дискеты в дисководе.
Вот пока вроде все. Вообще, с помощью сетевых средств можно попытаться организовать полноценный удаленный отладчик, с точками останова, просмотром-модификацией ячеек, заливкой программ, дизассемблером, блекджеком, шлюхами итд. Надо будет подумать. Он может очень пригодиться для отладки клиентской части сетевой ОС.
А вот и сама программа: Вложение 48103
-
Журнал "Радио #8 1989, стр 37"
Пользователяи о "Корвете"
Интерфейсы связи с внешними устройствами
"
...
Интерфейс локальной сети
Этот интерфейс фактически не отличается от последовательного интерфейса.
Он также реализован на микросхеме КР580ВВ51А.
Адреса ее регистров соответственно 20Н и 21Н.
Единственное отличие состоит в том,
что к этому интерфейсу подводятся четыре сигнала А0РС, А1РС, А2РС, АЗРС,
которые определяют номер устройства, подключенного к локальной сети.
Для присваивания компьютеру определенного номера в разъем нужно вставить перемычку,
соединяющую один из контактов с шиной +5 В.
Обмен происходит посредством двух сигналов OUTNL и INNL в TTL уровнях.
Сигналы АОРС—АЗРС подключены к битам 4—7 порта А ППА-1 (рис. 4).
"
http://www.pk-info.ru/infopk/doc/korvet_radio/doc4.htm
http://www.pk-info.ru/infopk/doc/kor...s/image004.jpg
может на ПК8020 просто не распаивали ?
---------- Post added at 23:29 ---------- Previous post was at 22:01 ----------
пересмотрел фото плат, таки нет
явно есть 8010 с незапаянными 1 и 5 контактами ...
