Пока что просто дизассемблер. В отличие от Никодимовского и от Charles Dotty'вского быстрый и знает ограничения для всех команд. И не выдаёт какие-то левые команды.
Я немного потестировал его с помощью ассемблера sega-asm и мельком просмотрел дизасм файла, состоящего из пятикратного повторения всех слов (от 0000 до FFFF), но в случае ошибки для исправления достаточно отредактировать таблицу в исходнике.

Посмотрим.... Заточки в виде констант для MegaDrive приветствуются!

Не понял, поясни. Ты имеешь в виду константы ограничений именно на MC68HC000 и ему подобные?
Нашёл ошибку в таблице для xxxI и ошибку с вычислением оффсета для прыжков. Я когда переделывал управление выводом Address, Hex values и т.д. поменял способ вычисления PC, а при вычислении смещения забыл убрать добавление двойки.

угу
буду дизасемблировать BEX!!!
а исходняки не дашь?

Позже.
Он на сях, если что.

так этож хорошо что на сях

Я имею в виду обозвать области ОЗУ, VDP, Z80 и т.д.

Фраза "заточки в виде констант для MegaDrive" очень информативна
Добавил префиксы, см. первый пост.

Я использовал такую карту:


Заодно подправил маленький недочёт с чтением больше чем 2 параметров с названиями файлов: раньше программа читала все параметры с именами (не ключи!) и, если их было больше 2, могла переполнить буфер, отведённый для номеров параметров, которые указывают имена файлов.

Достаточно информативна, на мой скромный вкус. ;) Под этим еще подразумевается, что дизасм, заточенный под сегу, мог бы еще сам представлять таблицу векторов в виде таблиы указателей на определенным образом названные проедуры, в соответствии с назначением вектора. А еще бывает полезно так же разобрать в виде структуры с именованными полями заголовок, а еще до кучи вставлять автокомментарии, скажем, на конкретные использующиеся в опкодах регистры. Чтобы при виде 0хА00000 сразу было понятно, что это за порт. ;)

Но все это прекрасно можно сделать автоматом с помощью плагина-лоадера или даже скрипта для IDA Pro, для сеги помнится лоадер был. Имхо, когда написали "Иду", все дизассемблеры, даже специфически заточенные, почили в обозе. ;)

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

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

И как бы ни была хороша ИДА, она не эмулятор, тем более не одного процессора одновременно. Было бы хорошо, если бы её можно было прикручивать к эмуляторам в реальном времени (или наоборот).
Посмотрел пару сеговских ромов в версии 5.2: switch-конструкции типа JSR $xx(pc,xx) даже не пытается распознавать Или я анализ не настроил...

С какой-то из версий 4.х ида получила возможность работать как отладчик с помощью плагинов, а с некоторых пор в версиях 5.х появился отладчик макосовых и винсешных программ. А вообще, естественно, дизассемблер - это не эмулятор, и ставить ему это в вину просто бесполезно.



Я уже не раз высказывался по этому поводу тут и в спорах с HwMan'ом... Косвенная адресация по регистрам в общем случае не по зубам автоматическим дизассемблерам. Вариантов, которыми можно делать переходы по таблицам и прочей муйни море. Можно запрограммировать себе какие то несколько из них, но они никогда не смогут автоматически точно сказать, куда может прыгнуть определенного вида инструкция, даже в простейшем M6502 (не говоря уж о М68К). Все равно, таблицы указателей приходится искать вручную, число функций тоже вручную. Далеко не всегда таблица читается из константы непосредственно перед прыжком. Далеко не всегда вообще присутствует прыжок как таковой. Далеко не всегда эмулирование и отслеживание констант при прогоне даст все возможные варианты - игра сама по себе далеко не всегда передает управление по всем своим функциям и автоматически имитировать все возможные варианты - невозможно. Именно по этому ида - интерактивна. Весь код, неподвластный автоматическому дизассемблированию, на лету превращается в асм при помощи человека... На каждый конкретный случай уже можно организовать скриптовое автоматическое дизассемблирование и дополнить им автоанализ...

Можно же выдать сообщение, что анализ прервался на команде(-ах) типа JMP $08(pc,d0.w), посмотреть пару команд повыше, писалось ли какое значение в d0 (часто бывает типа move.w $0C(pc,d1),d0, т.е. по этому адресу двухбайтные смещения для адреса из следующей команды), по размерности смещений выдать их список +- пару штук от начала и конца (чтобы наверняка не прогадать) и попробовать выдать дизасмовый код для каждого поинтера, так чтобы пользователь видел, где поинтеры начинаются и заканчиваются. И кнопочки сделать W и L, чтобы можно было менять размерности поинтеров, если прога неправильно определила.
Между тем, в виндовых экзешниках конструкции с вычисляемым прыжком ИДА спокойно определяет. На сеге они чуть сложнее, но это ничего не значит.

1. Упаси господи от этих мессаг, выскакивающих каждый раз, когда дизассемблер впадает в ступор. Команд таких может быть много, или очень много, а некоторые еще могут друг на друга прыгать.
2. Значение, записанное в d0 как правило вычисляется из другого значения - индекса элемента в массиве (следовательно, исходный параметр был умножен на 2 или 4 и он может быть в любом регистре, может передаваться по цепочке регистров, прежде чем будет умножен или во время этого... etc. etc.). Тем более, кто сказал, что этот регистр будет инициализироваться в этой процедуре? Это может быть оформлено как подпрограмма, получающая в нужном регистре уже нужное значение, а вызов ее, скажем, происходит внутри функци вызываемой аналогичным образом. В общем случае вызов может произойти в любом месте программы и отследить его просто невозможно.
3. По размерности смещений список может быть огромный - 65 тысяч или 4 миллиарда, 256 уже за глаза хватает, чтобы бросить. Тем более таблица смещений может содержать вообще один элемент. Даже если предположить, что процедуры начинаются сразу за таблицей поинтеров и принять за конец таблицы поинтеров смещение первой процедуры, в общем случае такой алгоритм может провалиться, потому что никто не заявлял, что все должно быть расположено именно так.
4. Вычисление прыжка на виндовых екзешниках происходит исключительно благодаря наличию сигнатурных файлов для различных компиляторов. Код они генерят однообразно даже с учетом оптимизации, каждая сигнатура позволяет распознавать стандартные куски кода, в том числе тот, что генерируется для switch-case операторов. Если программист сделает это сам вручную на асме, да еще если через задницу, дизассемблер провалится.

Все остальное, что ты описываешь, и делается с помощью иды в интерактивном режиме после или во время работы автоанализатора. Человек, как ни странно, сразу может определить размерность поинтеров, конец и начало массивов и прочая и прочая...

Еще примеры?

Заставь ка автоматический дизасм распознавать переход:

<присвоение индекса>
<вызов подпрограммы>
<указатель>
<указатель>
...
<процедура>
...
<процедура>

где, подпрограмма берет адрес начала таблицы указателей из стека - адрес возврата процедуры, вычисляет смещение указателя по индексу и прыгает на заданую указателем процедуру. Дизасм в этом месте даже не остановится, разве что ругнется на недопустимый операнд, если умный, и пойдет дизасмить все подряд до первого ret. Вместо call или jmp может вообще стоять ret а перед ним производиться оперции со стеком для записи в него нового адреса перехода вместо предыдущего адреса возврата.

Санч в теме. Тем более, я уже приводил пример работы со стеком. Кстати, на ВМ80, когда нельзя было использовать [HL] и команда PCHL проваливалась, я делал PUSH BC/RET, при условии, что адрес в [BC]. Вот так то.

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


Про прыжки тоже думал, и про чтение из портов тоже. И т.д.
Не знаю, чем ограничиваются возможности ИДЫ СДК, насколько можно менять саму ИДУ (от простого загрузчика заголовка до смены всей системы меню ИДЫ или создания новых форм/действий,etc.), поэтому ниженаписанное может быть неактуально.
К примеру, делаю анализ Тинитуна. Находит небольшую часть кода. Остальную не находит. Почему? Остановилась на вычисляемых прыжках. Теперь мне их все вручную искать и дорабатывать или как?
А нормальную программу можно настраивать, если что, и неугодные мессаги отключить. Их можно и в фон запихнуть.


Может быть что угодно, но если программа что-то предположит и наткнётся на подобие истины, почему бы и нет? Порог подобия можно сделать задаваемым, правда, это нелегко. А если она наткнётся на явную ошибку, то не скажет об этом и мы ничего не теряем. Как в шахматах: пока противник делает ход, программа рассчитывает его наиболее ожидаемые ходы и считает наперёд. А если он сделает не такой ход, ничего страшного, не наше ведь время потратили.
Насчёт "что угодно": часто чтение из A10003 бывает занесением этого адреса в A0 и обращением к (A0,D0), где D0=0..2. А вот в Aah! Harimanada сделали наоборот: адреса записывается в D0, меняется A0. Теперь же не браковать все игры на предмет использования первой процедуры из-за одной неправильной игры. Кстати, в ней же совсем уж невычислимые прыжки.
Если говорить о просмотре кода выше и даже просмотра ссылок верхнего уровня и т.д., то это, наверно, не сложнее, чем сделать компилятор ЯВУ с хорошей оптимизацией под разные процессоры или смешанные модели, а такие есть и занимают не очень много.


Опять "предположить". В общем, читайте первый абзац.
Поинтеры чаще всего не "сразу" за командой вызова, а недалеко от того значения pc, которое используется как база для регистрового смещения. Написано $50(pc,d0), можно поискать и там, и за таблицей тоже. С (An) сложнее. Насчёт размерности: очень глупо перебирать все поинтеры. Отличить последовательно поинтеров от последовательности правильных команд можно научить даже программу. Часто (но не всегда) поинтеру идут по возрастанию и имеют схожий размер (типа 0672 0732 06F4 41F9 - конец - уже команда). Если за процедурой идёт ещё что-то недекодируемое, можно попробовать и это присобачить или поискать другие ссылки на эту область данных. Программа ведь не обязана работать по самому топорному алгоритму?
"Найденные" поинтеры и код по ним можно выдать сразу в несколько тултипов. Можно сделать, чтобы одним скроллом показывалась сразу другая очередь, это всё мелочи интерфейса, про которые многие забывают, а зря. А дальше юзер сам решит, что делать.


Что именно конкретно? Я кроме этих прыжков с поинтерами и кнопками W, L и пр., ничего не описывал. Если ты про пункт 3, то читай ответ. В крайнем случае, можно просто давать пользователю быстро переходить между местами ступоров, а то искать вручную очень утомляет.

Конец цитировать не буду, отпралю к "общим случаям".

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

Я не спорю, ИДА очень крутая вещь, но она не идеал и если её хватает для запросов многих или лично вас, это ничего не значит. И необязательно ИДА, а вообще всё, к чему вы привыкли.
Не пойму только, почему приходится писать что-то вроде 1-го абзаца, вы ведь должны понимать очевидные вещи, не дендюшка всё-таки. И почему все так противятся любым предложениям? В конце концов, кто хочет чего-то добиться, может получить какой-то результат. А может не получить. А кто не хочет, тот результата точно не получит.

Уф, скока написал. И во что переросла тема про маленький дизасм?

upd: Да, совсем забыл. Я уже писал на дендюшке про невозможность "чистым последовательным анализом" найти недоделанные секреты/etc. в играх или всё то, на что стоит заглушка.
И вообще, хватит рассуждать о преимуществах последовательных анализаторов, какие бы они ни были, и сплошных дизасмов. Все методы хорошы.

А я вот какую каку делал..... И забросил. Нету времени, да и дизасм уже как бы и не нужен, когда есть такие отладчики, типо тех, что делают на эмуленде. Я вот блатую автора Регена их повторить.

У меня своё представление о хорошем дебаггере но раскрывать его не буду, а то полетит гора помидоров
Но чувствую, ВЯ и даже автор Регена не не сделают и части того, что мной задумано. Проще уж самому когда-нибудь сделать.