-
Немного разборок с программами с перекрытиями в образе RSX - на примере SAV :)
Результат копания - ячейки могут искаться не только вниз по дереву перекрытий (это было сделано давно), но в вверх. Не уверен, что пригодится для обычных файлов TSK (программа то ещё не в памяти и не успела поработать), но для задч в образе RSX - очень даже - программа уже успела поработать и даже что-то из оверлеев загрузить.
На очереди, скорее всего - загруженные драйверы. Но свободное время.. Так что - что-то реально успею сделать только в выходные
-
Перекрытия в RSX - это звиздец, а программа с перекрытиями в образе системы - отдельный звиздец.
Разбирался. И ещё много осталось.
-
С перекрытиями дошёл до некоей логической точки, пока вроде бы всё отрабатывается и на просто задачах и на образе системы - классической RSX+ с поддержкой Data Space и на образе P/OS (собственно, она и инициировала копания в перекрытиях)
Взялся за драйвера - тоже буду смотреть на варианты самостоятельных файлов и в образе систем.
- - - Добавлено - - -
Текущее состояние - микроскоп для RSX+ на примере P/Os 3.2
-
Первое впечатление - после всех доработок под образы RSX - DisAsm на удивление неплохо стал (по сравнению с тем, что можно было видеть до) справлятся с драйверами. По сути, надо было сделать одну небольшую правку (которая, кстати, давно задумывалась). Ну и то, что для образов была добавлена поддержка работы с STB файлами (а для драйверов они тоже ДОЛЖНЫ быть) - сразу визуализировало имена :) По крайне мере - для векторизованных драйверов :) Надо будет проверить на невекторизованных :)
Дальше - парсинг стандартных блоков данных драйверов. Благо определить их местоположения (благодаря stb файлам) можно, осталось только описать структуру классами C#
- - - Добавлено - - -
Кстати, для драйверов в образе - последнее будет несколько сложней - ибо их файлов stb нетууу.. Но есть другие методы
-
-
Так, с возможностью "вырезать" ячейки из ядра ОС и оформлять их как отдельный "оверлей-модуль" (началось всё с блоков данных для драйверов) вроде разобрался (хотя может какие нюансы и всплывут - тогда по мере возникновения), можно двигаться дальше - парсить не только DCB, но UCB, SCB и KRB (и кто там ещё есть) в таблицах для драйвера :) Если память мне не изменяет, UCB самый проблемный, остальные вроде попроще...
-
Разборку "сырых" данных в что-то понятное (экземпляры классов) для C# давно делаю через класс-посредник Mapper. То есть на вход подаётся описание класса, массив с "сырыми" данными, смещение, а на выходе экземпляр класса. Причём в нём могут быть как привычные для .NET объекты, так и объекты классов, которые так же создаются из "сырых" данных.
Парсинг таблиц-описателей драйверов RSX строится так же на этой схеме. То есть на вход подаётся ссылка на DCB (device control block) - с него всё начинается, а на выходе хочется получить все структуры - DCB, UCBs (unit control block-и), SCBs (status control block-и) и KRBs (controller request block-и). Пока парсится только DCB. На очереди - UCBs. И тут первые засады. Во первых, структура UСB имеет варианты - есть постоянная часть (и тут с парсингом особых проблем нет), есть переменная часть. Плюс - есть отрицательны смещения (и их структура тоже имеет варианты). Плюс - из DCB ведёт ссылка на первый UCB, плюс из UCB есть ссылки на родительский DCB (остальные CB и RB так же имеет ссылки). И до сих пор с такой организацией данных ещё не сталкивался (ранее всё было проще и площее). Так же - с доработкой DisAsm-11 вожусь уже очень долго и несколько.. подустал :) Так что - таймаут на какое-то время. Дальше, скорее всего, займусь PDP-11X
-
Закопался в приведение в порядок файло-помойки, но попутно...
Страничные ПЗУ - первый подход к снаряду
-
Появилась возможность создавать и указывать макросы вручную, то есть они не цепляются автоматом по кнопке Макро?, а выбираются из списка и применяются к выбранной ячейки.
Но иногда встречаются случаи, которые сложно запихать в макросы - слева два страничных обращений, для которых удалось написать макрос, а вот справа.. только руками. Что возвращает к вопросу о ручном указании - куда ссылается операнд, в какой оверлей...
На и из прикольного - изменения файла макросов отслеживается и автоматом подтягиваются :)
-
Dilog MQ-100 FirmWare - первые шаги, первые части
По результатам есть некоторое понимание того, как оно ДОЛЖНО быть. Одно из будущих изменений - будет генерироваться не такое большое количество файлов, в идеале должен получаться один, но... надо пробовать
Ну и как обычно - будет свободное время - буду пробовать...
