khach 40 26 июля Опубликовано 26 июля · Жалоба 5 часов назад, Raven сказал: ) симулятор процессора - прогон фрагментов на симуляторе (для ускорения итераций RE). Для удачного прогона на симуляторе надо еще дамп инициализированного ОЗУ снять с реальными данными. Иногда это получалось через активный логический анализатор- дожидались инициализации системы при штатной работе с подключенной неактивной пробой ЛА, останавливали процессор резетом или RDY, принимали контроль над шиной ЛА, вычитывали дамп, если надо регинерировали ОЗУ динамическое. Хотя такое делали только на DIP40 корпусе 8088, как к 80188 подключаться для такого режима- надо думать. ps/ кое что полезное http://www.bitsavers.org/test_equipment/appliedMicrosystems/ES_1800/ и в родительском каталоге тоже. Но схемы не на все типы поддерживаемых микропроцессоров есть, только на моторолу нашел там. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 232 26 июля Опубликовано 26 июля · Жалоба 39 минут назад, khach сказал: Для удачного прогона на симуляторе надо еще дамп инициализированного ОЗУ снять с реальными данными. Не надо ничего этого. Всё намного проще - как писал выше. Достаточно: В 24.07.2024 в 13:52, jcxz сказал: А просто написать симулятор, который будет исполнять код 80188 в режиме интерпретатора. И исполнять это на каком-нить современном ARM-е. (вполне хватит производительности старших Cortex-M). Нужно только разобраться с записями/чтениями портов периферии. Если периферии используется немного и несложная, а общий размер прошивки большой, то думаю - такой путь будет даже проще/быстрее, чем дизассемблировать и разбирать прошивку. Интерпретатор команд написать нетрудно: система команд 8086 известна и детально описана. Симулировать можно даже не все команды, а только используемые в прошивке. Наибольшая трудность (имхо) будет в симуляции периферии. Но если её используется не слишком много и она не особо сложная, то и это будет также вполне по силам даже не слишком опытному бойцу. Т.е. - нужна только прошивка, схема и детальное описание используемой периферии МК. А средства отладки - они будут в платформе, на которой выполняется симуляция. Современные средства отладки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 59 26 июля Опубликовано 26 июля · Жалоба On 7/26/2024 at 2:33 PM, jcxz said: Интерпретатор команд написать нетрудно: система команд 8086 известна и детально описана. В 8086 был c чем-то наподобие MMU. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tonyk_av 42 26 июля Опубликовано 26 июля · Жалоба 1 hour ago, dimka76 said: В 8086 был c чем-то наподобие MMU. Не было там ничего подобного. Защищённый режим появился в 80286. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 51 26 июля Опубликовано 26 июля · Жалоба 2 hours ago, dimka76 said: В 8086 был c чем-то наподобие MMU. Нет. Просто сегментные регистры для расширения адресов до 1МВ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 232 26 июля Опубликовано 26 июля · Жалоба За основу можно взять это: https://github.com/iliasam/fake86_to_stm32f429_port В этом проекте есть симуляция выполнения команд 8086 (файл cpu.c). Но правда реализация там - на си, "в лоб", без всякого стремления к оптимизации. Потому работать должно ну оооооочень медленно. По нормальному - там нужно всё переписывать на асме и с глубоким задействованием мозга. Но по-крайней мере видно, что все команды 8086 там реализованы. Можно подсмотреть код реализации каждой команды (если есть какие-то неясности). Т.е. - вполне решаемо. Если переписать по нормальному, на асме, без лишнего хлама, да ещё храня содержимое регистров эмулируемого CPU 8086 в регистрах ARM (а не читая/записывая их каждый раз в ОЗУ, как сделано в том проекте), то думаю - скорости STM32F429 вполне должно хватить для эмуляции 8088, работающего на тактовой даже <=16МГц. Регистров у ARM вполне хватит для этого: 8шт. 16-битных РОН 8086 можно хранить в 4-х 32-битных регистрах ARM. IP - тоже в одном регистре ARM. Сегментные регистры - можно и в ОЗУ, а можно и потратить пару РОН ARM на них. Регистр флагов - ещё один регистр ARM. Итого: максимум нужно = 8 регистров ARM для хранения регистров эмулируемого 8086 (скажем: R5...R12) Самые тяжёлые в плане уложиться по времени при эмуляции будут имхо - арифметическо-логические команды регистр-регистр. Потому как выполняются на 8088 за 3 такта, а при эмуляции требуют много действий. Или же самыми тяжёлыми будут команды типа INC/DEC регистра. Которые выполняются за 2 такта. Вот прикинул код эмуляции команды "ADD AH, DL" i8088 на Cortex-M4: ;R6 - IP ;R7 - FLAGS (bits:27...31: AF:SF:ZF:CF:OF; bits:0...7 - for PF) ;R8 - AX:BX (bits:0...15 - AX; bits:16...31 - BX) ;R9 - CX:DX ;R10 - SI:DI ;R11 - BP:SP ;R12 - CS:DS ;R14 - ES:SS ;ADD AH, DL SBFX R0, R8, #8, #8 ;AH SBFX R1, R9, #16, #8 ;DL ADDS R2, R0, R1 BFI R8, R2, #8, #8 ;AH MRS R7, APSR ;SF, ZF, CF, OF LSLS R0, R0, #28 ADDS R0, R0, R1, LSL #28 RRX R7, R7 ;AF BFI R7, R2, #0, #8 ;for PF later Время выполнения этого кода на Cortex-M4 = 9 тактов. Т.е. = 9/180 = 50мкс; на 8088 на 16МГц = 3/16 = ~188мкс. Вроде как укладываемся с запасом. Да, конечно - после этого нужно ещё выбрать и декодировать код следующей команды и перейти на него. Но вроде как реально успеть по времени. Можно также попробовать сделать эмуляцию не с хранением РОН в регистрах ARM, а хранить в памяти: regAL EQU 0 regAH EQU 1 regBL EQU 2 regBH EQU 3 regCL EQU 4 regCH EQU 5 regDL EQU 6 regDH EQU 7 regSI EQU 8 regDI EQU 10 regBP EQU 12 regSP EQU 14 flagPF EQU 16 SECTION .bss:DATA:NOROOT(2) DATA emulData2: DS32 5 SECTION .text:CODE:NOROOT(2) THUMB LDR R3, =emulData2 ... ;ADD AH, DL LDRSB R0, [R3, #regAH] LDRSB R1, [R3, #regDL] ADDS R2, R0, R1 STRB R2, [R3, #regAH] STRB R2, [R3, #flagPF] MRS R7, APSR LSLS R0, R0, #28 ADDS R0, R0, R1, LSL #28 RRX R7, R7 Время выполнения увеличивается до 10 тактов, но размер кода немного меньше. PS: А ведь есть ещё Cortex-M7 с бОльшей скоростью. Если в M4 не влезет. Так что имхо - эмулировать реально. Если подходить с головой. Конечно - нужно ещё учитывать латентность флеша (если исполнять эмуляцию из него). Или попытаться всё (или самые критические части) всунуть в ОЗУ. Но всё-же, всё же - не думаю должно получиться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 27 июля Опубликовано 27 июля · Жалоба On 7/24/2024 at 12:54 AM, x893 said: Вперёд к высотам компиляции !!! https://openwatcom.org/ftp/install/ Watcom - классный тулчейн! 😃 Жаль, что в начале 2000-х не знал о нём, а сидел на Borland/Turbo... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 11 27 июля Опубликовано 27 июля · Жалоба 1 hour ago, repstosw said: 😃 Жаль, что в начале 2000-х не знал о нём, а сидел на Borland/Turbo... Странно - он ведь на тех же развалах CD-ROM'ов продавался. Соседи студенты с программистского факультета кивали и цокали языком - вещь! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 51 27 июля Опубликовано 27 июля · Жалоба On 7/26/2024 at 8:29 PM, jcxz said: За основу можно взять это: https://github.com/iliasam/fake86_to_stm32f429_port В этом проекте есть симуляция выполнения команд 8086 (файл cpu.c). Но правда реализация там - на си, "в лоб", без всякого стремления к оптимизации. Потому работать должно ну оооооочень медленно. По нормальному - там нужно всё переписывать на асме и с глубоким задействованием мозга. Но по-крайней мере видно, что все команды 8086 там реализованы. Можно подсмотреть код реализации каждой команды (если есть какие-то неясности). Т.е. - вполне решаемо. Если переписать по нормальному, на асме, без лишнего хлама, да ещё храня содержимое регистров эмулируемого CPU 8086 в регистрах ARM (а не читая/записывая их каждый раз в ОЗУ, как сделано в том проекте), то думаю - скорости STM32F429 вполне должно хватить для эмуляции 8088, работающего на тактовой даже <=16МГц. Регистров у ARM вполне хватит для этого: 8шт. 16-битных РОН 8086 можно хранить в 4-х 32-битных регистрах ARM. IP - тоже в одном регистре ARM. Сегментные регистры - можно и в ОЗУ, а можно и потратить пару РОН ARM на них. Регистр флагов - ещё один регистр ARM. Итого: максимум нужно = 8 регистров ARM для хранения регистров эмулируемого 8086 (скажем: R5...R12) Самые тяжёлые в плане уложиться по времени при эмуляции будут имхо - арифметическо-логические команды регистр-регистр. Потому как выполняются на 8088 за 3 такта, а при эмуляции требуют много действий. Или же самыми тяжёлыми будут команды типа INC/DEC регистра. Которые выполняются за 2 такта. Вот прикинул код эмуляции команды "ADD AH, DL" i8088 на Cortex-M4: ;R6 - IP ;R7 - FLAGS (bits:27...31: AF:SF:ZF:CF:OF; bits:0...7 - for PF) ;R8 - AX:BX (bits:0...15 - AX; bits:16...31 - BX) ;R9 - CX:DX ;R10 - SI:DI ;R11 - BP:SP ;R12 - CS:DS ;R14 - ES:SS ;ADD AH, DL SBFX R0, R8, #8, #8 ;AH SBFX R1, R9, #16, #8 ;DL ADDS R2, R0, R1 BFI R8, R2, #8, #8 ;AH MRS R7, APSR ;SF, ZF, CF, OF LSLS R0, R0, #28 ADDS R0, R0, R1, LSL #28 RRX R7, R7 ;AF BFI R7, R2, #0, #8 ;for PF later Время выполнения этого кода на Cortex-M4 = 9 тактов. Т.е. = 9/180 = 50мкс; на 8088 на 16МГц = 3/16 = ~188мкс. Вроде как укладываемся с запасом. Да, конечно - после этого нужно ещё выбрать и декодировать код следующей команды и перейти на него. Но вроде как реально успеть по времени. Можно также попробовать сделать эмуляцию не с хранением РОН в регистрах ARM, а хранить в памяти: regAL EQU 0 regAH EQU 1 regBL EQU 2 regBH EQU 3 regCL EQU 4 regCH EQU 5 regDL EQU 6 regDH EQU 7 regSI EQU 8 regDI EQU 10 regBP EQU 12 regSP EQU 14 flagPF EQU 16 SECTION .bss:DATA:NOROOT(2) DATA emulData2: DS32 5 SECTION .text:CODE:NOROOT(2) THUMB LDR R3, =emulData2 ... ;ADD AH, DL LDRSB R0, [R3, #regAH] LDRSB R1, [R3, #regDL] ADDS R2, R0, R1 STRB R2, [R3, #regAH] STRB R2, [R3, #flagPF] MRS R7, APSR LSLS R0, R0, #28 ADDS R0, R0, R1, LSL #28 RRX R7, R7 Время выполнения увеличивается до 10 тактов, но размер кода немного меньше. PS: А ведь есть ещё Cortex-M7 с бОльшей скоростью. Если в M4 не влезет. Так что имхо - эмулировать реально. Если подходить с головой. Конечно - нужно ещё учитывать латентность флеша (если исполнять эмуляцию из него). Или попытаться всё (или самые критические части) всунуть в ОЗУ. Но всё-же, всё же - не думаю должно получиться. А где реализация периферии ? Ждём ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 28 июля Опубликовано 28 июля (изменено) · Жалоба 8 hours ago, Raven said: Странно - он ведь на тех же развалах CD-ROM'ов продавался. Соседи студенты с программистского факультета кивали и цокали языком - вещь! Чтобы съездить на развалы, нужно было выбираться из ПГТ в крупный город. А это - не чаще чем 1 раз в 1-2 месяц. Поэтому довольствовался тем, что было. Был Borland/Turbo. И начинал с Паскаля. С Си познакомился чуть-позже. И по играм тех времён я уже что-то заподозрил, что есть что-то лучшее, чем Borland: DOS4GW и всё что с ним связанное. В институте кстати, лабы были на Turbo Pascal с вкраплениями x86 ассемблера. Ваткома там тоже не было. Так исторически сложилось, что развалины с диском Ваткома прошли мимо меня. Зато был ещё какой-то Borland pascal for Windows - переросток между ДОС-овским паскалем и между Дельфёй. Там ещё Пушкин на титульном окне рисуется 🤣 при загрузке. Рожает приложения в Win 3.1 стиле. Весь объектный. Не понравилось. Позже узнал о TMT Pascal - со всеми его 32-битностями под ДОС, тоже что и Ватком, но только Паскаль. С теми же PMODE, DOS4GW. http://old-dos.ru/files/file_1410.html Вот ещё есть DJGPP - GCC под ДОС, порт с Линукса. Тоже пользовался. Хорошая вещь, может в 32 бита + ДОС-экстендер. Правда немного специфичен: https://www.delorie.com/djgpp/ Вот коллекция оригинальных архивов Ватком: http://old-dos.ru/files/file_1555.html Последние версии, включая OpenWatcom - вроде оптимизируют достаточно хорошо, размер шага приращения +1 указателя - равен размеру структуры. И даже -C99 поддерживает, если в опциях прописать недокументированные ключи. Пользовался ими, остался доволен. Ватком С/C++ - это был флагман-компилятор для написания топовых ДОС-овских игрушек и эмуляторов игровых приставок. Также есть качественные ДОС-игры, написанные на Borland/Turbo. Изменено 28 июля пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 31 июля Опубликовано 31 июля (изменено) · Жалоба В 28.07.2024 в 03:00, repstosw сказал: В институте кстати, лабы были на Turbo Pascal с вкраплениями x86 ассемблера. Ваткома там тоже не было. Равно, как и у нас, только Турбо С, и паскаль, ну если не считать "программирования" на калькуляторах))))))))) В 23.07.2024 в 02:00, baumanets сказал: Реверс, пока ещё не окаменевшей, но очень спасающей пациентов "фигни". Так тут задача не в собственно разобраться в процессоре, а просто повторить необходимый функционал какого-то устройства. Причем, к.м.к. все это можно сделать на одном современном МК, нужно просто понять алгоритм работы, и судя по древности, он там не сверхсложный... ИМХО, пока ТС начнет хоть как-то "въезжать" в тонкости работы древнего оборудования, реверсер за денежку уже сделает то, о чем я написал выше... Изменено 31 июля пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khach 40 31 июля Опубликовано 31 июля · Жалоба Обычные компиляторы создавали код, который невозможно было всунтуть в эмбеддед приложения. COM файл имел сегмент кода и даных одинаковый, а в ембеддете код сидел в ROM а данные в RAM. EXE плодил кучу сегметов по количеству библиотек плюс сегмент под main да и с выделением места под данные были проблемы, т.к в старых ембеддед системах RAM часто была статикой малого размера и переменным на стеке не хватало места. Поэтому с компилятором и линкером приходилось изварщаться вручную и как раз ватком это умел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 215 31 июля Опубликовано 31 июля · Жалоба 3 минуты назад, khach сказал: Обычные компиляторы создавали код, который невозможно было всунтуть в эмбеддед приложения. COM файл имел сегмент кода и даных одинаковый, а в ембеддете код сидел в ROM а данные в RAM. EXE плодил кучу сегметов по количеству библиотек плюс сегмент под main да и с выделением места под данные были проблемы, т.к в старых ембеддед системах RAM часто была статикой малого размера и переменным на стеке не хватало места. Поэтому с компилятором и линкером приходилось изварщаться вручную и как раз ватком это умел. Это всё зависит от модели памяти, задаваемой при компиляции. Если задавать модель tiny, то всё можно было запихнуть в один сегмент (как это было в COM), получить exe и сделать из него com с помощью, например, exe2com. PS: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tonyk_av 42 31 июля Опубликовано 31 июля · Жалоба 1 hour ago, khach said: Обычные компиляторы создавали код, который невозможно было всунтуть в эмбеддед приложения. Ну вот не надо ля-ля! Всё для МК на 80186/188 делалось нормально обычным Turbo/Borland C/C++. Обычный ЕХЕ-файл грузился во флэш, а при запуске создавались и инициализировались области в ОЗУ. Уже верно отметили про СОМ-файлы, хотя я ими ни разу не пользовался. Производители контроллеров не зря ведь создали минималистичное окружение в виде ROM-DOS и MiniOS7, совместимое по вызовам с BIOS ПК и MS-DOS, чтобы использовать в МК инструментарий от ПК. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 232 31 июля Опубликовано 31 июля · Жалоба 2 часа назад, mantech сказал: Так тут задача не в собственно разобраться в процессоре, а просто повторить необходимый функционал какого-то устройства. Причем, к.м.к. все это можно сделать на одном современном МК, нужно просто понять алгоритм работы Опять 25... можно не понимать алгоритм. Вообще. А просто написать эмулятор. На подходящем современном МК. Если частота исходного 80188 не слишком высокая. Я выше приводил пример эмуляции на Cortex-M. И если исходный код весит хотя бы несколько десятков КБ, то путь эмуляции может оказаться гораздо проще. Чем изучение неведомо как написанного кода. PS: В те далёкие времена (времена 80188) довольно много кода писалось на ассемблере. Особенно для МК. А реверсить изначально ассемблерный код - это совсем не то, что исходно си-шный (после компилятора). Особенно - если его писал опытный человек, умеющий много хитрых приёмов - будет гораздо сложнее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
