DEC и я

[Alex_K]

Там весь код - 32 кб страница - 512 байт Но первоначальная причёска достаточно муторное и однообразное дело, так что - не быстро. Цель - получить что то более менее читабельно и разобранное на код-данные, собираемое обратно в образ и дающее на выходе идентичное исходному

32 кБ, почти как на УКНЦ. Его ПЗУ я тоже вручную разбирал. Действительно долго, но когда сам вручную дизассемблируешь, то одновременно начинаешь понимать код.

[Advertiser]

[Hunta]

Не совсем вручную (использую две программы и результат беру из одной или другой кусками), но пока подходящего инструмента (IDA не предлагать ) нет. Начал потихоньку писать, но ещё самое начало.
На первом проходе я на логику смотрю только если надо поточнее понять - код или данные. Ну, иногда глаз цепляет вышеприведённое. Особенно учитывая, что имеем своеобразный вариант оверлеев, резидентных в памяти

Разобрал (логика не до конца) ПЗУ от MXV11-B (использовал для нашей М8), там тоже страничная организация, но вызов кода из других страниц сделан малость по другому - в конца страницы две процедуры (страничный вызов, возрат из страничного вызова) и типа дальнего (на другую страницу) JMP-а.

У KDJ11-B вроде как нет - прямая запись в регистр отображения страниц и переход-вызов.

На первый взгляд - в случае MXV11-B легче анализировать код, но.. посмотри, как пойдёт..

[yu.zxpk]

Если не секрет, то в чем проблема с IDA?

[Hunta]

За текущую версию не скажу, но та, которую в своё время пробовал - не позволяла задать (или я не нашёл) базовый адрес для кусков кода. Например - ПЗУ от KDJ11-B - это файл размером 32 кб, но принцип его работы - отображение 512-байтных страниц через два окошка с фиксированными адресами. То есть то, что с точки зрения IDA находится с адреса 1000 (2000, 3000) - на самом деле работает с адреса 165000 или 173000, причём понять - с какого адреса оно работает, можно только после логического анализа.

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

[S_V_B]

Хунта.. ты же самый умный в этой конторе Вот скажи какую арифметику с фиксированной точкой лучше использовать для 2D для физики 640х264?
Чего-то я маханул по моему с s15x16?

[Hunta]

какую арифметику с фиксированной точкой

Что ты имеешь ввиду под - какую? Вроде как на УКНЦ особого выбора нет.
Или ты имеешь ввиду - диапзон?

[S_V_B]

Да.. диапазон.. можно же s7x8..
Я не сталкивался, ты то же?

[Hunta]

640 на 264 больше тянет на 10 бит на 9, так что для хранения всё равно будет 15 бит
Вычисления можно слегка оптимизировать, так как 640 - это 512+128, а 264 - это 256+8, то есть вместо умножения можно использовать сдвиги
Дальше пока не понял суть вопроса

- - - Добавлено - - -

Ну и результат умножения в общем случае вылезет за 16 бит

[S_V_B]

Суть вопроса про разрядность арифметики.
Про 512 я тоже думал..
Ты в курсе что Джон Кармак написал Doom на такой арифметике? Только проц у него был 32бит.

- - - Добавлено - - -

Два слова дофига..

[Hunta]

Ты в курсе что Джон Кармак написал Doom на такой арифметике?

Знаю.

Только проц у него был 32бит.

MUL у нас тоже может дать 32 бита, разрядность входных данных ограничена.

Я в SPEED3 на это ограничение налетел, мне нужно было умножать 32-битные числа и делить 64-х битное на 32-ух битное