32 кБ, почти как на УКНЦ. Его ПЗУ я тоже вручную разбирал. Действительно долго, но когда сам вручную дизассемблируешь, то одновременно начинаешь понимать код.Цитата:
Сообщение от Hunta
Вид для печати
32 кБ, почти как на УКНЦ. Его ПЗУ я тоже вручную разбирал. Действительно долго, но когда сам вручную дизассемблируешь, то одновременно начинаешь понимать код.Цитата:
Сообщение от Hunta
Не совсем вручную (использую две программы и результат беру из одной или другой кусками), но пока подходящего инструмента (IDA не предлагать :) ) нет. Начал потихоньку писать, но ещё самое начало.
На первом проходе я на логику смотрю только если надо поточнее понять - код или данные. Ну, иногда глаз цепляет вышеприведённое. Особенно учитывая, что имеем своеобразный вариант оверлеев, резидентных в памяти :)
Разобрал (логика не до конца) ПЗУ от MXV11-B (использовал для нашей М8), там тоже страничная организация, но вызов кода из других страниц сделан малость по другому - в конца страницы две процедуры (страничный вызов, возрат из страничного вызова) и типа дальнего (на другую страницу) JMP-а.
У KDJ11-B вроде как нет - прямая запись в регистр отображения страниц и переход-вызов.
На первый взгляд - в случае MXV11-B легче анализировать код, но.. посмотри, как пойдёт..
Если не секрет, то в чем проблема с IDA?
За текущую версию не скажу, но та, которую в своё время пробовал - не позволяла задать (или я не нашёл) базовый адрес для кусков кода. Например - ПЗУ от KDJ11-B - это файл размером 32 кб, но принцип его работы - отображение 512-байтных страниц через два окошка с фиксированными адресами. То есть то, что с точки зрения IDA находится с адреса 1000 (2000, 3000) - на самом деле работает с адреса 165000 или 173000, причём понять - с какого адреса оно работает, можно только после логического анализа.
Возможно, это и можно задать, но даже если так - на втором этапе я начинаю переделывать код под использование пакета макросов структурных операторов (пример - на предыдущей странице) - и вот что то мне подсказывать, что это не получится сделать в IDA. То есть после первоначального дизассембла - всё равно выгружать в файл и дальше работать не с IDA
Хунта.. ты же самый умный в этой конторе :) Вот скажи какую арифметику с фиксированной точкой лучше использовать для 2D для физики 640х264?
Чего-то я маханул по моему с s15x16?
Что ты имеешь ввиду под - какую? Вроде как на УКНЦ особого выбора нет.Цитата:
Сообщение от S_V_B
Или ты имеешь ввиду - диапзон?
Да.. диапазон.. можно же s7x8..
Я не сталкивался, ты то же?
640 на 264 больше тянет на 10 бит на 9, так что для хранения всё равно будет 15 бит
Вычисления можно слегка оптимизировать, так как 640 - это 512+128, а 264 - это 256+8, то есть вместо умножения можно использовать сдвиги
Дальше пока не понял суть вопроса
- - - Добавлено - - -
Ну и результат умножения в общем случае вылезет за 16 бит
Суть вопроса про разрядность арифметики.
Про 512 я тоже думал..
Ты в курсе что Джон Кармак написал Doom на такой арифметике? Только проц у него был 32бит.
- - - Добавлено - - -
Два слова дофига..
Знаю.Цитата:
Сообщение от S_V_B
MUL у нас тоже может дать 32 бита, разрядность входных данных ограничена.Цитата:
Сообщение от S_V_B
Я в SPEED3 на это ограничение налетел, мне нужно было умножать 32-битные числа и делить 64-х битное на 32-ух битное