NET-CP/M Version A - есть, работает по станартной сети, в доке написано что скорость 1К/c (в спец режиме копирования)
сервер - IBM/PC
[/QUOTE]
Значит, версия A работает так, как мы сейчас и делаем - подключается вся гирлянда корветов РМУ в компорт PC и все работает?
А где ее брать-то? Особенно серверную чатсть (клиентскую, я так думаю, сервер рассылает по сети сам при запуске).
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
ой, переделывать точно смысла нет !Сообщение от forth32
я привел SWM как пример реализации той-же идеи, не более !
тем более этот синтаксис явно приятнее!
хотя по схеме на разъеме
вход, выход, земля ...
" Топологически сеть представляет собой двунаправленную
магистраль, соединяющую все рабочие места комплекса. Линия
связи выполнена в виде витой пары и прокладывается стационарно.
При работе с адаптером локальной сети необходимо установить
перемычку между контактами 04 и 02 соединителя адаптера.
"
Последний раз редактировалось esl; 20.05.2014 в 20:45.
На ПК80х0 19600 было, а не 19200?Теперь насчет параметров последовательного канала. Скорость передачи здесь всегда 19200 baud.
Во времена, когда не было дисковода, я пытался передавать на пк8010 с PC данные, но максимум что получалось - завесить пк8010. Мне тогда показалось, что проблема в разнице скоростей 19200 на PC и 19600 на ПК80х0. Была идея в ближайшее время вернуться к этому вопросу. Теперь благодаря вам уже не придется
Развязка была оптрон PC817.
Последний раз редактировалось marinovsoft; 20.05.2014 в 22:11.
ПК8010 "Корвет"+ExtRom+AY, Atari 65XE+SDrive, Дельта-С(52ИС)+AY, Scorpion ZS 1024+SMUC
OFF
ESL, пробовал открыть несколько ида-баз из вашего архива, ничего не вышло. К слову сказать idb от forth32 тоже не поддянулся(3.7, 4.15, 5.5, 6.1)
Канонiчная ида гуглится так all_rdw_releases.rar, а эта кажется китайская со старым hexrays
Последний раз редактировалось marinovsoft; 22.05.2014 в 17:14.
ПК8010 "Корвет"+ExtRom+AY, Atari 65XE+SDrive, Дельта-С(52ИС)+AY, Scorpion ZS 1024+SMUC
Попробовал я версию 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.
В библиотеке реализован автозапуск программ на бейсике, посылаемых по сети. Делается это так. После отсылки бейсик-программы, на РМУ пересылается коротенький самозапускаемый код:
В ОПТС 2.0 это работать не будет - там по этим адресам нет ничего интересного. Общая идея этого кода - в HL загружается адрес начала программы, и управление передается интерпретатору. Похожий код имеется в конце обработчика команды LOAD - если в этой команде указан параметр R, то программа также автозапускается. И адреса там правильные. Но в бейсике ОПТС2 это работает не особо стабильно - иногда запускает программу, иногда нет. С причиной я разбираться не стал - придумал другой способ автозапуска.Код:basic_autostart_sub: ; DATA XREF: init_basic_autorun+Fo ld hl, (word_63BF) jp loc_362C
Вообщем, библиотека оказалась не особо совместимой с сетью ОПТС2, и не особо полезной. Но все же, разобрав библиотеку, я почерпнул важную и полезную информацию.
Во-первых, прояснились поля +4 и +5 пакета S. Эти поля тупо копируются в ответный пакет R при передаче данных от РМУ к серверу, и никак не используются сетевым драйвером ОПТС. Оказалось, что поля эти используются самой сетевой библиотекой.
Поле +4 - это тип и назначение данных, принимаемых сервером от РМУ. Возможны такие значения:
Таким образом, прояснилось назначение типа данных 4 (в ОПТС он не используется, начальный и конечный адрес установлены в 0). Это просто данные, подлежащие записи на диск.Код:0 - экран консоли РМУ. 2 - образ памяти с заранее определенной длиной 3 - образ памяти, ограниченный тремя нулями для данных или тремя байтами 1A (EOF) для бейсик-программы 4 - дисковый файл.
Поле +5 пакета S - это адрес в памяти сервера, по которому загружаются принятые от РМУ данные. Используется в функции 14 (из ОЗУ РМУ в ОЗУ РМП) и ей подобными.
Также прояснилось, насчет мифических пакетов типа F и B, описания которых встречаются в документации по сети. На самом деле, такие пакеты по сети не передаются. Они существуют только внутри подпрограмм библиотеки, и используются для взаимодействия между отдельными процедурами, обозначая фазы сетевого протокола:
Похоже, код библиотеки и документацию к нему писали совсем разные люди. Иначе непонятно, зачем в документацию внесли информацию о кодах внутреннего взаимодействия библиотечных модулей. Пользователью снаружи это все равно недоступно.Код:F - файловая фаза. Происходит открытие файла и подготовка к чтению-записи. B - конец сетевого обмена при передаче данных С - конец сетевого обмена при приеме данных G - ошибка сетевого обмена
Практической пользы от вышеописанного практически никакой - для реальной работы с сетью это не нужно. Разве только автостарт бейсика имеет реальную пользу. Но для раскопки сетевых программ все это может очень даже пригодиться. И еще - библиотека реализует протокол, немного несовместимый с ОПТС2. Видимо, под ОПТС2 была написана другая библиотека, но где ж ее искать...
Сейчас пойду править описание протокола в соседней ветке. Кроме того, получив кое-какие идеи из библиотеки, я доработал свою программу сетевого обмена. Сейчас дотестирую и тоже выложу в ту ветку.
есть sts 2.0 из комплекта кувт
Это версия STS для ОПТС2? Я эту STS в работе никогда не видел, и попробовать не на чем - требуется сеть из 2 корветов. Догадываюсь, что это программа приема-передачи данных по сети для классов КУВТ.
Ага, нашел. Диски DE_2_04 и DE_8_00. Будет время - посмотрю. Только боюсь что и там ничего интересного нет...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
