Ищу нормальный дизассемблер, желательно с оболочкой под i8035 (ну или 8051) - а то к такой древности С возможностью дизасемблировать с указанного адреса (то есть программа изначально с многочисленными .org xxxx причем не путем написания командных строк на 2000 символов), расставлять метки, корректно обзывать регистры ВВ работать под виндою а не требовать себе MSDOS 2.0 и 8086 с 512 кБ и не килобайтом более) - штук пять скачал - хоть и говорят что под 8051, но от последовательности E5h, C5h почему-то входят в ступор (типа не знают такой команды), дизассемблируют в неведомых мнемониках (хоть и заявлен 8051) или вообще вешаются.
Wladimir_TS А НА КОЙ??? Именно дизассемблер - ведь коды для MCS51 можно просто по распечатке с карандашиком в руке и картой команд перед носом расписать?? Другое дело ассемблер и дебаггер-отладчик - дык и то добро ВАЛОМ имеется. Заглянь сюда viewtopic.php?f=62&t=59015 и сюда viewtopic.php?f=62&t=94201 ежли чего не найдеш/не разбереш - пиши в личку или в "винной"
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
То же самое, что и по MCS51 относится и к 8035(8048) /касательно распечатки на листочке и карандашика + карта команд/. Есть и симулятор для ПК (работает в DOS-окне под ХР).
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Тяжко на листочке - кода много, причем код х....ый - много брошеных участков, к которым нет обращений некоторые места непонятны
А есть какие-то симуляторы ? Только для работы программы требуется отработка INT0 с определенной частотой и фазой относительно сигнала на T0 (точнее наоборот - согнал на T0 появляется с некоторой задержкой относительно INT0, основная-ж программа в глухом цикле.
Подобрал более-менее дизассемблер - анализирую код - подскажите (лет 15 лет с 8051 ядром не работал - все забыл)
JMPP @A - переход в пределах текущей страницы памяти программ (надо знать точный адрес кодов самой команды) http://img.radiokot.ru/files/20529/1keqbopmd6.GIF воть как-то так... Воть добавкой архивчик с симулятором
Ежли 0х00A0 то прыгнет на 0х00(содержимое аккумулятора) т.е адрес страницы + содержимое аккумулятора (не суммируется, а замещает младший байт!!) находимся на странице 0 - 0х0000 и допустим в аккумуляторе 0х55 прыгаем на 0х0055 А что на момент выполнения того JMP смотреть самому... Возможно задан условный переход по таблице - как раз двухбайтовое значение. А само условие загружается в аккумулятор и после некотора шаманизму дает смещение на нужный указатель вектора перехода.
Почему - команда ORL A,#0F0h установит старшие 4 бита в "1"
В ячейке 37 счетчик без ограничения - считает 00h-FFh по кольцу
Вообще программа странная - куски осмысленного кода на которые нет переходов и переходы на куски бессмысленного кода.
ЗЫЖ - программа с бумажной распечатки лохматого года (цифровая версия не сохранилась) а вот теперь изделие возрождаем, а программа зашитая не работает.
Создается ощущение, что фейковая или какая-то промежуточная версия. Среди всего этого главное найти участок основного алгоритма (все-равно в другой процессор пойдет на 8051 ядре), а пока он не найден
Осталось 20% неразобранного когда, остальное таблицы или мусор.
Вот что делает код:
CPL A MOV R2, А MOV R0, #3Bh MOV R1, #39h CALL M0
M0: MOV A, @R0 CPL A ADD A, R2 JC M1 CPL A MOV @R1, A RET M1: MOV @R1, #0 RET
Я по памяти пример дал - главное там ПРОСТАЯ ПОДСТАНОВКА, а не "считать в А данные из ячейки в РС+А и прыгнуть" (на что намекают двойные скобки возле А). Если "всегда 0хFy" то искомая точка в области 0x00F0 - 0x00FF. Касательно всяческих восстановлений - проще заново прожку написать под "черный ящик с указанными параметрами", нежли старое раскапывать. Тем более, что для дизассемблера точное положение команд относительно адреса(а в Ваших фрагментах этого нету) играет весьма немаловажную роль. Т.е. распечатка должна иметь следующие обязательные поля:
Код:
адрес | код | метка | мнемоника | комментарий xxxx | xx | ..... |...........|....................
и таких строчек в пустографке столько, сколько байт в ПЗУ. А уж затем те строчки заполняем сначала кодами в соответствии адресу и далее начинаем мозготреп со карандашиком.
_________________ ZМудрость(Опыт и выдержка) приходит с годами. Все Ваши беды и проблемы, от недостатка знаний. Умный и у дурака научится, а дураку и .. Алберт Ейнштейн не поможет и ВВП не спасет.и МЧС опаздает
На основе 8035/8048 никаких особо хитрых алгоритмов соорудить НЕ ПОЛУЧИТСЯ. Разве что вариации на тему программно-аппаратной сцепки под конкретный тип кристалла в качестве кодера/декодера - но такой примитив весьма легко раскрывается ибо и структура кристалла ИЗВЕСТНА и система команд СТАНДАРТНА. Тем более при всего-то 2048 строк с байтовой начинкой (выше нельзя - будет задействовано ВНЕШНЕЕ ПЗУ программ). С 48-м я под эмулятором не работал (просто там нечего эмулировать при "прожке на листочках" и макете) - а вот аналогия такового под 51-й вполне прекрасно в DOS окне под ХР работает.
Да... Ешшо когда-то было в моде IDA PRO - может где инет подскажет или местны ХАКЕРЫ.
Это требуется установить - есть-ли алгоритмы, какие и насколь они хитры.
Дизассемблировано 100% обработано уже более 80%.
Программа занимает в общей сложности 8192 байта естественно во внешнем ПЗУ (I8035 (1816ВЕ35) не имеет встроенного ПЗУ). Страницы переключаются старшими битами порта 2. ОЗУ только внутреннее 60 байт не считая пространства RONов (используются только R0-R3 первого набора и аккумулятор). Примерно 40% таблицы и много табличных вычислений.
Сейчас уже полностью разграничил зоны данных и зоны программы, все метки обработаны. Уже 6 или 7 явных ошибок с формированием адресов для чтения памяти программ - ошибка на "1" бит всегда...
Начал делать таблицы переменных с диапазонами возможных значений.
Хреново что совсем нет контроля выхода переменных за пределы - только образка ANDами (может это и ускоряет - но сложно установить пределы возможного изменения переменных для проверки отдельных участков кода)
Самая проблема в полнейшем непонимании работы многих кусков кода связанных с математикой.
Найден неплохой эмулятор, но на нем опять-же не отработать переферию. Но это я пока не знаю как вообще без полноценного внутрисхемника, который позволяет ставить аппаратные точки останова, а лучше вести лог состояний регистров без замедления работы процессора, как старый ICE4000
ЗЫЖ - привязка к адресам ЖЕСТОЧАЙШАЯ - вставить в код 1 команду и все развалится - данные (таблицы) плотно перемежаются с программым кодом и обращение к их адресам вычисляемо из других таблиц. Да уж - собирали программу явно на бумажках.
Как я понял у Вас ни опыта работы с ассемблером ни опыта дешифровок поготовому изделию... Внешняя память программ для 8035 и открыта для доступа и садомазохизм. Разве что изврат с перебором адресов (аналогия мозготрепа для дешифровки времен Z80/I8080) здесь оправдан. Ошибок там никаких нету - просто есть разница между обработкой смещения для машинного компилятора и для "ручной" компиляции для "коротких" переходов
и "особое ограничение" по области раздела страниц (исключительно особенности 8035) для участков программ, расположенных в пределах нескольких страниц (начало на одной с продолжением на следующей).
Как я понял у Вас ни опыта работы с ассемблером ни опыта дешифровок поготовому изделию...
Писал для 8051 на ассемблере когда-то и под 8080 а вот 8035 не трогал Опыт дизассемблирования имеется, а вот структуру и особенности работы 8035 - увы.... Давно это было. Пишу под AVR немного (ассемблер)
Код полностью дизассемблирован разделен на данные и собственно программу, контрольно ассемблирован с полным совпадением.
Уже 1 ошибка 100% - переход на середину команды причем на код недопустимой операции. -1 к адресу перехода потребно
SCM Truncated 1.38 некорректно отрабатывает команду JMPP @А- вне зависимости от содержимого аккумулятора - переход на адрес 0
Частично уже откоментировано и разобрано. Примерно для 30% переменных установлено их назначение и диапазоны изменения. Потихоньку движусь.
Нужен симулятор i8035, корректно отрабатывающий JMPP @A и MOVP A,@A
Следующий вопрос - как это работает :
MOV R0,#33h MOV A,@R0 ; В ячейке указатель на ячейку таблицы 03-EF JZ NEK_M1 XRL A,#1 ; A = A XOR 1 JZ NEK_M1 ; При каких значениях в А установиться флаг Z ????? MOV A,@R0 Далее процедура чтения из памяти программ 2х последовательных байт
В приведенной таблице (из PDF) не совсем ничего не понял
Корректнее чем то, что я выложил вряд-ли найти удастся. Литература по 48-м лежит в сундуке КОТА там весьма путево расписано https://sunduk.radiokot.ru/loadfile/?load_id=1431792682 ... и по другим библиотекам - прочитайте/обновите в памяти. Мне 35/48 вспоминать смысла нет - давно исчезнувшая и весьма жестко-неудобная мелкосхема. Далее кой-чего от них к ПИКам среднемладшим перекочевало (относительно сегментации памяти), благо там этот вопрос несколько по-другому решен.
Код:
MOV R0,#33h ; загрузить в указатель адрес точки назначения MOV A,@R0 ; (В ячейке указатель на ячейку таблицы 03-EF) считать в аккумулятор содержимое из ячейки ОЗУ с адресом 0х33 JZ NEK_M1 ; если А=0 идем на метку XRL A,#1 ; (A = A XOR 1) по другому "инверсия содержимого бита 1 аккумулятора" JZ NEK_M1 ; (При каких значениях в А установиться флаг Z ?????) если результат = 0 идем на метку MOV A,@R0 ; иначе повторяем загрузку аккумулятора содержимым ОЗУ из ячейки 33
Кстати... У 35/48 ФИЗИЧЕСКОГО флага Z НЕТУ - оценивается текущее содержимое аккумулятора. Какой реальный физический адрес у того R0 (0х00 или 0х17) зависит от текущего регистрового банка. Это касается режима косвенной загрузки указателей при работе из другого банка РОН (один из множества спецприемов для изголяжа над любителями дармовщинки и хитрых ветвлений с извратом).
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
С возможностью дизасемблировать с указанного адреса (то есть программа изначально с многочисленными .org xxxx причем не путем написания командных строк на 2000 символов), расставлять метки, корректно обзывать регистры ВВ работать под виндою а не требовать себе MSDOS 2.0 и 8086 с 512 кБ и не килобайтом более) - штук пять скачал - хоть и говорят что под 8051, но от последовательности E5h, C5h почему-то входят в ступор (типа не знают такой команды), дизассемблируют в неведомых мнемониках (хоть и заявлен 8051) или вообще вешаются.
