Обсуждение: Локальная сеть корвет

Цитата:

---

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

NET-CP/M Version A - есть, работает по станартной сети, в доке написано что скорость 1К/c (в спец режиме копирования)

Значит, версия A работает так, как мы сейчас и делаем - подключается вся гирлянда корветов РМУ в компорт PC и все работает?

А где ее брать-то? Особенно серверную чатсть (клиентскую, я так думаю, сервер рассылает по сети сам при запуске).

---

всё в том архиве ;)

все перечисленные выше работают по обычной сети
самая простая из них явно cp/n-90

попробовал собрать все, но именно собирал из разных дисков
в эмуляторах вроде запускаются, но 100% гарантии работоспособности нет

порядок появления
с этими в свое время играл на живом классе

cp/n-90
kornet

а эти уже вообще не щупал
sfera
net cp/m a

p.s. Корнету для запуска нужно оба диска в дисководе, иначе он не стартует
и еще выглядит как на втором диске и сидит ос для РМУ (хотя не проверял)

Попробовал я версию IDA, выложенную ESL, под wine. Там базы нормально открываются. Правда, сама IDA практически не работает - видимо требует наличия в системе виндового питона, которого у меня, естественно, нет. В результате, например, переход ентером по адресу не получается. А консольная idaw под wineconsole вообще не запускается из-за отсутствия python27.dll. Ну да ладно.

Линуксовая версия ida5 лежит здесь - http://rutracker.org/forum/viewtopic.php?t=524500

Правда, в ней не будут открываться базы от 6 версии. И есть некоторые проблемы с поддержкой русского языка в unicode.

Цитата:

---

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

Попробовал я версию IDA, выложенную ESL, под wine. Там базы нормально открываются. Правда, сама IDA практически не работает - видимо требует наличия в системе виндового питона, которого у меня, естественно, нет. В результате, например, переход ентером по адресу не получается. А консольная idaw под wineconsole вообще не запускается из-за отсутствия python27.dll. Ну да ладно.

Линуксовая версия ida5 лежит здесь - http://rutracker.org/forum/viewtopic.php?t=524500

Правда, в ней не будут открываться базы от 6 версии. И есть некоторые проблемы с поддержкой русского языка в unicode.

---

python точно не виноват, это плагин, он не влияет, можно просто удалить из plugins/python*.*

у меня wine 1.7.19,
запустились обе,и консольная и нет.

---------- Post added at 13:15 ---------- Previous post was at 13:13 ----------

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

---------- Post added at 13:26 ---------- Previous post was at 13:15 ----------

чегойто сразу не нашел как побороть
./idal: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
:(

Итак, я закончил дизассемблирование и разбор библиотеки NETLIB.A. Хоть я и понимаю, что чудес на свете не бывает, но, как всегда, надеялся на маленькое чудо. Увы, получилось как всегда.

Код библиотеки написан весьма коряво, что, конечно, снижает производительность но облегчает разбор в IDA :) Кроме того, библиотека жестко привязана к функциям консольного драйвера МикроДос, и вызыает их прямым переходом. В результате, программы, использующие эту библиотеку, не будут работать в CP/M. Сама библиотека поддерживает кучу функций, описание которых лежит в файле C.TXT на том же диске, что и библиотека. Описание очень интересное, что и сподвигло меня на ее раскопку.

Насчет ответчика сети. В описании говорится, что это произвольно выбираемый РМУ, отвечающий серверу на команды передачи данных в режиме широковещательного адреса. Одна из функций библиотеки (15 - установка логической связи), должна возвращать адрес этого самого ответчика, и мне было интересно - где она его берет? Оказалось, что ответчик - это просто активный РМУ в сети с самым старшим адресом. И все. Не знаю как в мечтах автора библиотеки, но в реальной жизни РМУ отказывается отвечать на широковещательный адрес, даже если ему присвоить номер 15. Я еще раз прошел по коду ОПТС 2 - там однозначный запрет на передачу в сеть после приема широковещательного адреса и изменить это никак нельзя. Могу предположить, что эта возможность была в ОПТС 1. Что интересно - подпрограммы библиотеки действительно ждут ответа от сети при передаче, независимо от типа адресации. То есть ответчик в сети когда-то реально существовал.

Меня заинтересовала функция 9 библиотеки - из бейсика РМУ на экран РМП. Судя по описанию, она должна выгрузить из РМУ программу в токенах и показать ее на экран в текстовом виде, то есть распаковать. Я уже надеялся посмотреть фирменный распаковщик программ. Все оказалось проще. В РМУ посылается пакет S - запрос на получение данных типа 2 (бейсик-программа), а в поле +04 пакета S (которое копируется в ответный пакет R на то же место) указывается тип данных 0 - экран. И все. То есть сам РМУ должен распаковать программу и передать ее серверу уже в распакованном виде. Понятно, что этого не происходит - в коде ОПТС 2 просто нет такой возможности. Видимо, это тоже было заложено в ОПТС 1.

В библиотеке реализован автозапуск программ на бейсике, посылаемых по сети. Делается это так. После отсылки бейсик-программы, на РМУ пересылается коротенький самозапускаемый код:

Код:

---

basic_autostart_sub:                        ; DATA XREF: init_basic_autorun+Fo
                ld        hl, (word_63BF)
                jp        loc_362C

---

В ОПТС 2.0 это работать не будет - там по этим адресам нет ничего интересного. Общая идея этого кода - в HL загружается адрес начала программы, и управление передается интерпретатору. Похожий код имеется в конце обработчика команды LOAD - если в этой команде указан параметр R, то программа также автозапускается. И адреса там правильные. Но в бейсике ОПТС2 это работает не особо стабильно - иногда запускает программу, иногда нет. С причиной я разбираться не стал - придумал другой способ автозапуска.

Вообщем, библиотека оказалась не особо совместимой с сетью ОПТС2, и не особо полезной. Но все же, разобрав библиотеку, я почерпнул важную и полезную информацию.
Во-первых, прояснились поля +4 и +5 пакета S. Эти поля тупо копируются в ответный пакет R при передаче данных от РМУ к серверу, и никак не используются сетевым драйвером ОПТС. Оказалось, что поля эти используются самой сетевой библиотекой.
Поле +4 - это тип и назначение данных, принимаемых сервером от РМУ. Возможны такие значения:

Код:

---

0 - экран консоли РМУ.
2 - образ памяти с заранее определенной длиной
3 - образ памяти, ограниченный тремя нулями для данных или тремя байтами 1A (EOF) для бейсик-программы
4 - дисковый файл.

---

Таким образом, прояснилось назначение типа данных 4 (в ОПТС он не используется, начальный и конечный адрес установлены в 0). Это просто данные, подлежащие записи на диск.
Поле +5 пакета S - это адрес в памяти сервера, по которому загружаются принятые от РМУ данные. Используется в функции 14 (из ОЗУ РМУ в ОЗУ РМП) и ей подобными.

Также прояснилось, насчет мифических пакетов типа F и B, описания которых встречаются в документации по сети. На самом деле, такие пакеты по сети не передаются. Они существуют только внутри подпрограмм библиотеки, и используются для взаимодействия между отдельными процедурами, обозначая фазы сетевого протокола:

Код:

---

F - файловая фаза. Происходит открытие файла и подготовка к чтению-записи.
B - конец сетевого обмена при передаче данных
С - конец сетевого обмена при приеме данных
G - ошибка сетевого обмена

---

Похоже, код библиотеки и документацию к нему писали совсем разные люди. Иначе непонятно, зачем в документацию внесли информацию о кодах внутреннего взаимодействия библиотечных модулей. Пользователью снаружи это все равно недоступно.

Практической пользы от вышеописанного практически никакой - для реальной работы с сетью это не нужно. Разве только автостарт бейсика имеет реальную пользу. Но для раскопки сетевых программ все это может очень даже пригодиться. И еще - библиотека реализует протокол, немного несовместимый с ОПТС2. Видимо, под ОПТС2 была написана другая библиотека, но где ж ее искать...

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

есть sts 2.0 из комплекта кувт

Цитата:

---

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

есть sts 2.0 из комплекта кувт

---

Это версия STS для ОПТС2? Я эту STS в работе никогда не видел, и попробовать не на чем - требуется сеть из 2 корветов. Догадываюсь, что это программа приема-передачи данных по сети для классов КУВТ.

Ага, нашел. Диски DE_2_04 и DE_8_00. Будет время - посмотрю. Только боюсь что и там ничего интересного нет...

U

Цитата:

---

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

Это версия STS для ОПТС2? Я эту STS в работе никогда не видел, и попробовать не на чем - требуется сеть из 2 корветов. Догадываюсь, что это программа приема-передачи данных по сети для классов КУВТ.

Ага, нашел. Диски DE_2_04 и DE_8_00. Будет время - посмотрю. Только боюсь что и там ничего интересного нет...

---

В комплекте с кувт шла только sts
К оптс 1 шли точно оптс 1.x
По логике sts 2 от оптс 2
Они все есть в моих ida
Там кроме баз и есть и исходники из чего желал _ida

Кроме того там ещё есть сетевые программы
Сделанные по виду с похожей либой
Например postman

Доработал программу сетевого обмена. Выложил в соседнюю тему - http://zx.pk.ru/showpost.php?p=712788&postcount=9

Описание изменений там же.

Цитата:

---

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

Доработал программу сетевого обмена. Выложил в соседнюю тему - http://zx.pk.ru/showpost.php?p=712788&postcount=9

Описание изменений там же.

---

просто супер !
теперь точно надо свой Корвет оживлять ;)

Итак, можно считать, что сетевой протокол ОПТС2 мы раскопали практически полностью. Вроде как непоянтных и неопределенных моментов больше не осталось.
Сдедующим этапом надо бы ковырнуть сетевые ОС, ну и конечной целью сэмулировать их серверную часть на PC. Но тут есть проблема. Для исследования сетевого взаимодействия нужно иметь как минимум 2 корвета - сервер и клиент. У меня же есть только один, и то не совсем полноценный - без родной клавиатуры :) Второй мне, видимо, уже не добыть никогда - их теперь даже на помойке не найдешь.
Но я вижу еще один вариант. Существует несколько вариантов программных эмуляторов корвета. Если к одному из них прикрутить поддержку сетевого адаптера, то можно собрать сеть из реального корвета и эмулятора, и развлекаться с ней сколько угодно.

Я тут порылся в здешних корветовских темах и нашел ссылку на исходные тексты одного из эмуляторов - korvet-v092.src (изнутри они обзываются ETALON Korvet Emulator). Программа написана простым понятным языком, для сборки используется обыкновеннейший GCC, а для общения с внешним миром программа использует кроссплатформенную библиотеку Allegro. Сейчас попробую собрать ее в своей системе. Если соберется - можно сделать удобный инструмент для исследования сетевых программ.