Просмотр полной версии : Кто конвертнет ПЗУ Спектрума-128 в ANSI C?
т.е. перепишет каждую процедуру в ISO99-C функцию? Если это для проекта P.R. любопытные вещи у вас творятся...
Для того, чтобы отвязаться от процессора z80 в Васике и далее по восходящей. Мне хочется разгрузить z80 и загрузить Blackfin.
толкового начинающего/средней-руки кодера с опытом ZX и документацией по ПЗУ, месяц работы - будут предварительные результаты. Ты отказался от сотрудничества с P.R.? Или он вообще скрылся? А то ведь это по его части.
Там работы на 10 P.R. Он со мной не договорился ни о чем.
нужно либо очень много человеку заплатить, чтобы он за это взялся,
либо очень сильно заинтриговать, но тут без гарантий. Забьет через неделю и кердык.
В том и в другом случае нужны технические подробности... Легко написать ОСь на Сях, в какой-то мере похожую по организации на ОС Спек48/128. Но никакой совместимости с софтом ZX не будет. Разве что с программами на Бейсик. И то, если последние не обращаются по адресам. Т.е., если в них нету POKE, PEEK, RANDOMIZE USR... Можно конечно, эту задачу решить, но будет полный огород. Можно даже сделать некоторую совместимость с софтом ZX - но это будет ультраогород - в этом случае честнее портануть Linux и воспользоваться эмулятором. Но и это чушь - т.к. ничего интересного тут нет.
Вывод, либо забей, либо расскажи как ты видишь процесс "конвертирования ПЗУ в Си" :) Может какой-нибудь маньяк и решится взяться..
Нужна полная совместимость, включая системные переменные. Переговоры с маньяком готов провести в реале.
А можно поинтересоваться (верней, даже сказать, как Вы это себе представляете) как можно портировать ПЗУ 128 спека (SOS,B128,TR-DOS) на ANSI C с полной программной совместимостью c чем?? (процессором Z80 или совокупности Z80 + архитектура спектрума) если:
-Невозможно добиться тех же таймингов так как проц другой (так как уже отсуствует критерий по которому можо измерять время исполнения какого либо участка)
-ПЗУ представляет из себя набор из 16384 байт в общей сложности и программисты часто входили в середину подпрограммы (особенно при прямом доступе к ВГ93)
-подпрограммы как таковые официально не документированных их границы нашли дизасемблером (кроме разве что TR-DOS вызовов и некоторых RST)
1 и 2 пункт не позволяет сделать полной совместимости в принципе (с моей точки зрения, по крайней мере) да и частичную совместимость делают весья туманной.
РS. Думается мне это не в искуство писать нада было, а создать ветку специальную - Сада-маза :)
PPS. Не в коем случае ничего личного просто пытаюсь понять. (как говориться понять задачу это уже на 50% сделать её)
Я не Скутин, я Савичев. Что значит "лезли в середину"? Значит и этот кусок был функционально осмысленен и самодостаточен. На С это отдельная функция, а другая охватывающая содержит её вызов. Надеюсь понятно, что тормознуть что угодно это не проблема, в отличие от ускорить. Почему мы переписываем через функциональность? Раньше писался эмулятор проца и в него загонялся готовый код. Но ведь можно и по другому. Для программ использовавших системные переменные, системные функции абсолютно все равно, что изменится их "реализация". В нашей системе z80 не будет знать, что вокруг него вместо привычного железа, какое-то другое. Реализация не суть важна, лишь бы была функциональная идентичность. А переделав части приращенные к старому железу мы и осуществляем эффективную подмену. Делаем мы это с двоякой целью:
упрощение схемы;
наращивание функциональных возможностей.
Людям не придется целиком переучиваться, только, если они захотят - доучиваться и в этом несомненный плюс такого подхода.
А в чём смысл, вообще, подключения реального z80 к GPIO Blackfin ?
Имхо, программно Blackfin сможет эмулить 3,5-7Mhz спек, хоть и будет довольно загружен работой.
Есть ли VisualDSP в свободном доступе?
я таки думаю, что теме лучше быть в программировании, нежели в творчестве, ибо на творчество несколько непохоже...
Мне кажется идея совершенно нереальная и нереализуемая.
2Valen: как бы ни был хорош эмулятор он не сможет работать со 100% точностью и потому, что z80 содержит недокументированные возможности и потому, что в этой системе (Blackfin + все остальное) есть масса реакций на разные события, в то же время z80 умеет работать асинхронно и в пошаговом режиме, чем грех не воспользоваться :)
По поводу VisualDSP++ читайте архивы форума Телесистем разделы DSP и микроконтроллеры.
http://www.telesys.ru/wwwboards/mcontrol/index.shtml
Насчет реализуемости...можете прямо подключить z80 к любому микроконтроллеру (или к FPGA)где есть достаточное количество GPIO (побитно программируемых как входы, выходы или входы/выходы)и написать простенькую программку имитирующую работу ПЗУ и пошаговый режим, с возможностью сохранения трассы и там и там (через порты подключайте все шины z80 и вперед!).
К работе над C-BIOS приступаю, раз охотников не нашлось.
И все таки, как планируется организовать взаимодействие старого z80-кода с новым ПЗУ, написанном на С, где используеются определенные правила на передачу параметров в функцию и возврата результата?
это фигня, например, через глоб. переменные. Самое тяжелое, как уже упоминали, это сохранение таймингов и то, что частенько сп-проги прыгали в середину подпрограмм ПЗУ.
это фигня, например, через глоб. переменные.
Да, и учитывая все эти хаки мы получим конечно ansi-c код, который будет выглядеть как ассемблерный исходник :)
А что хотим ускорять? Работу синклер-бейсика? А много ли на нем написано?
Надеюсь, в следующие 25 лет будет написано куда как больше. Ставить на определенный процессор - это абсурд! Теперь вот приходится огород городить. Теперь ответ по существу. Код на z80 пересылает Blackfin через порты. Запас по времени при этом приличный ведь самая быстрая команда в турбо режиме у z80 выполняется за 2/7 мкс, но это регистровая команда а они BF по барабану ( z80 сам в себе может выеживаться как угодно, вот когда он дергает внешнюю память - тогда это интересно Blackfin-у). Он может держать в особой области - трассу - инфу об n-предшествующих командах и в них вылавливать инициализацию регистров перед вызовами, другой вариант - выдернуть содержимое любого регистра из z80, вставив в поток команд сответствующую команду, а уже эти данные засунуть нужной процедуре, кстати необязательно через стек, но это надо ковырять Visual DSP++ или GNU C/C++. Никто не мешает иметь несколько версий биоса, лишь бы они совпадали функционально и по интерфейсу.
PegasResearch
12.05.2007, 18:05
andrews
Там работы на 10 P.R. Он со мной не договорился ни о чем.
Правильнее сказать, что мы друг с другом ни о чём не договаривались ;-) Так за чем же дело встало? Предлагаю встретиться. Я писал вам e-mail с приглашением к встрече. Можно будет обсудить все вопросы: BlackFin, BIOS и прочее. Жду от вас сообщения:
[email protected]
P.S. В личку написать не могу, т.к. она у вас переполнена... :-(
Знаете, у меня был очень негативный опыт совместной разработки в 1999 году. Два генератора идей в проекте связанном с разработкой одного компа это ужасно! Вы будете стремится делать одно, а я совсем другое, а народ начнет поливать нас обоих. Вы не знаете, как это бывает, а я знаю очень хорошо. Не сочтите за неучтивость за публичный ответ.
Я должен довести дело моей жизни до конца. После 1999 года прошло много лет. Мне уже 47 и видимо это мой последний шанс сделать или не сделать свой собственный компьютер, как он мне видится вот уже почти 9 лет!
PegasResearch
15.05.2007, 18:30
у меня был очень негативный опыт совместной разработки в 1999 году
Да, понимаю. Согласен - в одиночку работать над проектом легче. Хотя, здоровая критика тоже никогда не помешает ;-). Как заваливаются проекты из-за непринятых решений (каждый тянет одеяло на себя) - очень хорошо представляю, так как дело с этим имел и не раз. Мой вывод однозначен - руководитель (архитектор, главный инженер - называйте как хотите) должен быть в единственном числе. Остальные разработчики могут только предлагать, но не настаивать и во всём слушаться руководителя, даже если его идеи кажутся им глупыми - иначе будет каша и растрата ресурсов.
Я же просто хотел пообщаться - не столько для совместного проекта, сколько по поводу железа вообще (так как вы "железячник"). Если у вас возникнет желание пообщаться (а я могу что-нить посоветовать в программной области), то обращайтесь - я всегда буду за.
Удачи вам с компьютером!
Вся схема этого компьютера 6-7 микросхем. А вот программирования выше крыши! Если оставите Вашу идею с АРМ-ом и не приметесь за DaVinci всегда буду рад видеть Вас в команде. Прошу только не рушить мою концепцию. Мне плевать по большому счету кто будет рулить. Видимо тот кто обепечит выживание проекту. Но вот замысел...его критиковали достаточно. С моей точки зрения он жизнеспособен и перспективен. Готов это еще раз обсновать в открытой дискуссии, но только уже в последний раз.
PegasResearch
15.05.2007, 20:47
Я читал на форуме о ZX yellow, но по-моему там ни один программист не высказался. Я мог бы привести несколько контраргументов вашей идее именно с точки зрения программиста (в том числе и по поводу BIOS - почему никто за это не возьмётся). Но большинство собравшихся на форуме мою точку зрения не разделят - так как они железячники. Да и было несколько похожих тем... А потому я не высказываюсь: свои дела есть, лучше на них время потратить. Да и чего воду в ступе толочь? ;-) Хотя, если проект коммерческий, то можно и потолочь, чтобы не прогадать.. это ведь "не для себя", а должно нести выгоду. Если захотите услышать критику - могу высказать ;-)
Я ведь тоже программист с 12 летним стажем, электронщик с 4 летним стажем и рук.группы, затем МП(4.5+1.5) с 6 летним стажем...так что конструктивно и надеюсь компетентно пока еще смогу обсуждать...так что высказывайтесь.
А сейчас я FAE...вот образчик моего недельного "творчества" про двухядерник ADSP-BF561
http://www.eltech.spb.ru/techinfo.html
это не чистого времени потому что приходится отвлекаться на клиентов, у которых есть вопросы по отладочникам и процессорам всей номенклатуры ADI.
Насчет "нести выгоду"...на днях как разгребусь со статьей надеюсь подключать к BF видеокамеру 320x240...прикупил вчера по дешевке.
ДАйте тоже кину камнем...
1 Что такое ZX BAsic?
2 Для чего его переводить в С?
3 Как можно реализовать обращение к конкретным адресам?
В ZX YSP 2 процессора( ADSP-BF532 и z80), но так как z80 подключен через GPIO BF, то работает он только тогда, когда этого хочет BF и как хочет. Поэтому при включении питания управление получает BF. Основная память загружается кодами для BF, а коды для z80 содержатся в ней как данные, кодами они становятся когда попадают через порты GPIO в циклах выборки инструкций z80. ПЗУ можно было бы не переписывать, если бы в нем не содержались коды, инициализирующие железо Спектрума и работающие с ним. Это железо ампутировано, а вместо него есть железо полностью с ним совместимое с точки зрения программистов. Память Спектрума и порты ввода/вывода отображены в части системной памяти. Диспетчер памяти будет реализован программно, поскольку MMU у BF не совсем полноценный. Что же касается бейсика, то переписать его на С следует по двум причинам:
1) на BF он будет раз в 20-50 быстрее выполняться;
2) его легче будет расширять.
Вставки машинного кода (и ассемблера) как для z80 так и для BF можно тоже реализовать. Любая инструкция прежде чем быть переданной на выполнение в z80 анализируется BF, и если это инструкции работающие с внутренностями z80 тупо на него передаются. Если же нет, то изымаются и запускают на выполнение нужные процедуры в BIOS компьютера. Их выполняет BF.
PegasResearch
17.05.2007, 22:01
Окей, тогда два вопроса.
1) Чем оправдывается использование Z80 "в железе" вместо запуска эмулятора Z80 на BlackFine? С инженерной и экономической точек зрения.
Комментарий. Вам уже этот вопрос задавали на форуме, вы ответили, что Z80 позволит более точно обрабатывать всё, что касается Z80. Либо вы:
1.1) не доверяете эмуляторам?, либо вы
1.2) считаете, что не хватит производительности BlackFine?.
Но почему вы так считаете? Т.е. какие имеются аргументы считать, что эмулятор не сможет 100% повторить Z80 или что не хватит производительности BlackFine? Кроме того, если вас смущает сама идея эмуляции "сердца" -
1.3) чем эмуляция Z80 отличается от эмуляции остального "железа"?
И второй вопрос касательно Basic.
2) Почему вы считаете, что выполнить реинжиринг кода проще, чем написать BASIC с "0"?
Жду ответов.
Добавлено через 2 минуты
Кстати, по поводу MMU - что значит "не совсем полноценный"?! В data sheet'e вроде написано, что всё Ок - Linux держит, размеры страниц 1/4/1024К поддерживает...
У BF относительно небольшая "быстрая память" L1-кэш. Он программно поддерживает функции видеоконтроллерра без дополнительных fpga, а также кучу сервисных функций связанных с эмуляцией ПЗУ для z80, обеспечения пошагового режима, трассировки выполняемого z80 кода и т.д. Преимущества: экономия памяти, 100% соответствие z80, возможности отладки присущие только 2-х процессорной системе.
С экономической точки зрения? подскажите с чем сопоставлять?какова стоимость разработки и верификации эмулятора z80 на BF?
Остальное железо какое именно? контроллер дисков я выбрасываю, звук выбрасываю(заменяю и то, и другое)...так что остается экран, клавиатура и джойстик.
Бейсик написан на ассемблере z80, и я скачал в инете комментированный дизассемблер. А 100% совместимость просто необходима!
MMU обеспечивает защищенность страниц, но не поддерживает трансляцию адресов. uCLinux не совсем Linux. Опробовать его можно и на писишке и на арме так как его порты есть под разные архитектуры.
а также кучу сервисных функций связанных с эмуляцией ПЗУ для z80, обеспечения пошагового режима, трассировки выполняемого z80 кода и т.д. Преимущества: экономия памяти, 100% соответствие z80, возможности отладки присущие только 2-х процессорной системе.
Как раз это дает эмуляция Z80 а не слушание и подсовывание ему сигналов причем на порядок проще.
вот вопросик решил программист в произвольный помент остановить проц и посмотреть содержимеое регистра R , такое реализуеца вашим методом через большую попу в то время как при эмуляции Z80 это всего лиш доступ к известной ячейке памяти. Ну нету у Z80 ни JTAG в что то в этом духе, а вот если захочет посмотреть состояние флагоф IFF1 IFF2 или режим IM ??? это уже практически нереализуемо.
Почему не реализуемо? Остановить программу можно по любым условиям, а также установить любые регистры и флаги, исполнением соответствующего кода. А уж фиксировать их в памяти вместе с трассой вообще без проблем. JTAG есть у BF и значит ножки z80 тоже JTAG доступны...т.е вы сможете отлаживать код для z80 и по JTAG (но не на BF, посколку он в этот момент не в рабочем режиме) только очень тормозно :)...а также иметь доступ ко всем шинам, внешней SDRAM и т.д. и т.п.
В общем то мне тоже казалось что написать эмулятор проще, но я не стал это писать. А почему не использовать уже имеющиеся эмуляторы? Вон Витамин писал под Linux исходы есть, US идёт с исходами... почему бы и нет? А если пытаться аппаратно отслеживать команды включения/выключения режимов прерывание, флагов IFF1|IFF2 и т.д... Фактически получается тот самые эмулятор к которому присоединили чужеродный для него элемент - Z80.
общем то мне тоже казалось что написать эмулятор проще, но я не стал это писать.
И на много проще :) и даже быстрее как в разработке так и в работе.
Но у PC шых эмулей есть одно свойство которое затрудняет работу эмуля с реальными железяками, а именно он на максимальной скорости работает запольняя буфера звуковые и т.д. нужное число тактов в фрейме а потом усыпает, что бы теже мультикоролы отрисовывать и т.д. нада некоторые меры принимать. Если уж и переделывать эмуль для BF то это брвть какой нить таймер на 3,5МГц лепить машину состояния что бы эмуль исполнял машинные циклы проца и работал в рилтайме. Вот.
А сесли гродить внешний проц то имха лучше eZ80 и средствами BF заставить его исполнять нормальный нативный Z80 код, а для отладки юзать имеющуюся в нем внутрикристальную(аппарат� �ую) отладку.
Нативный код не весь хорош. Та же арифметика и сортировка с поиском. А эмулятор z80 для BF однозначно не имеет смысла делать. Это не ARM! Его архитектура не предполагает классическую десктопную, да даже и мобильную ось. uCLinux это не десктопный Linux! Это средство для обслуживания цифровых потоков, железа BF и потоков квазипаралеллизма с компактным ядром полужесткого :) реального времени. BF предполагают ставить в мониторы, видеокамеры и т.п. встроенные решения. В РОБОТЫ(система зрения) кстати тоже можно! Домашний медийный mpeg3-4 комп тоже неплохое решение. В общем я оставляю z80 железный, а там жизнь покажет прав я или нет. Хватит ли его ресурсов на программную эмуляцию в добавок к его медийно-видеоконтроллерной функциональности или нет.
Нативный код не весь хорош.
а накой тогда ваще Z80??
uCLinux это не десктопный Linux!
Это ваще к чему??
BF предполагают ставить в мониторы, видеокамеры и т.п. встроенные решения. В РОБОТЫ(система зрения) кстати тоже можно!
То биш получается детектить движение на потоке от камеры на порядок проще чем исполнение Z80 кода??
z80 потому что Спектрум :)
Все что связано с видеообработкой вещи достаточно наработанные, а вот эмуль z80 на BF для первопроходцев :)
acidrain
19.05.2007, 22:50
Если же нет, то изымаются и запускают на выполнение нужные процедуры в BIOS компьютера. Их выполняет BF.
Имхо, Вы не поймете одного - разнице между исполнением Си (фактически асм) на одном проце и асм з80. Смысл такой - если мне нужно было на спеке просто перейти по адресу в пзу, где тупо записан RET, то я сделаю вызов через CALL именно на это RET, а что это за рет и из какой он ф-ции пзу - мне все равно. Как будет выглядеть вызов этого RET в вашем переписанном пзу? Hang up? Или каждый колл будет другим процем по таблице сверяться - стандартная процедура или ее часть?
На самом деле если переписать просто васик на си - то в сети есть уже такое дело с исходниками - ищите и обрящите.
Удачи!
ЗЫ. Не надо думать- надо делать, как в анекдоте. А так выглядет как мольба - вы сделайте, а я придумал...
Или каждый колл будет другим процем по таблице сверяться - стандартная процедура или ее часть?
Воистину. Вспомните первые эмуляторы, которые перехватывали только #3d13. Вас не удивляло, что в них не работали хотя бы немного нестандартные загрузчики? Вы хотите этой судьбы как минимум 50% софта? Ибо все они в той или иной степени используют пзу. Да еще и со своими точками входа...
Все нестандартные вызовы запустят обработчик исключений на BF, а уж он будет делать то, что запрограммирует юзер. Я здесь продвигаю новую технологию путем обсуждения. Цель заинтересовать кого-нибудь ею и найти единомышленников. А вы все привыкли делать в одиночку?
acidrain
20.05.2007, 14:37
Все нестандартные вызовы запустят обработчик исключений на BF, а уж он будет делать то, что запрограммирует юзер. Я здесь продвигаю новую технологию путем обсуждения. Цель заинтересовать кого-нибудь ею и найти единомышленников. А вы все привыкли делать в одиночку?
offtopic:
А как Вы хотели? Или берите "подчиненных" или тяните на себе. Есть лидер, а есть ведомые. Определитесь, Вы лидер или соучастник? И вперед! ;)
Добавлено через 19 минут
Все нестандартные вызовы запустят обработчик исключений на BF, а уж он будет делать то, что запрограммирует юзер
Представил картину - описанный мной случай, БФ лезет с проверкой - из таблицы ли вызоф? Нет? тада надо взять image ПЗУ и пасмареть чо там за команда з80 по этому адресу, потом проверить, а что пользователь по этому поводу думает. Потом вывести красную надпись на экран и паматюгатьси на кодера;)))
А работать когда будет вас спек?
Тут случайно нашел емуль и оську от sinclair QL, так там вообще супервасик - можно и его применить взамен старого, но толку то, если изначальные ошибки клайва сильно ограничили дальнейшее развитие спека? Может остыть, не искать славы и не трогать спек - пусь живет себе, как есть?
Все нестандартные вызовы запустят обработчик исключений на BF, а уж он будет делать то, что запрограммирует юзер.
А что по идее должен запрограммировать юзер? Наглое исполнение кода. Крайне желательно чтоб с ожидаемым временем исполнения (растактовка). В итоге приходим к тому, с чего все начиналось- эмуляция выполнения с точностью до команды/такта. В тех же эмуляторах работу вг-шки точно эмулировали отнюдь не для того, чтобы показать крутость кода...
В таблице ограниченное количество адресов стандартных точек входа(но их можно будет редактировать), она просматривается до того как инструкция загружается в z80. Если же адрес вычисляется в z80 и в программном счетчике оказывается нестандартная хрень, то и возникает ИСКЛЮЧЕНИЕ т.к. страница ПЗУ делается защищенной и всякий прыжок в нее КОНТРОЛИРУЕТСЯ. Что может сделать программа обработки исключения, не обнаружив корректного адреса. Например, прервать выполнение программы, выдать дамп трассы "последнего выдоха". Дальше юзер может прогнать по шагам и увидеть, как это произошло. Памяти под трассу может быть отведено хоть мегабайт, сервис отладчика обеспечивает 400 мипсовый монстр :) а вы говорите нафиг блэкфин.
Если этого не сделать, то и вновь пишущиеся программы на том же Бейсике со вставками машкода будут делать чудеса. А так будет мощнейший трассирующий дизасм-долбагерррррр!
Слишком много усилий для некому ненужного функионала.
Вот мой анализ для разных подходов программиста
1. Программист пишет на басике -> все висит мертвым грузом и тока создает тормоза проверяя таблицу, либо портит жизь от кривых процедур в калькуляторе каналах
2 Программист не юзает ПЗУ в принципе -> получается все висит мертвым грузом
3 Программист юзает басиковое пзу для в роле бивиса, то есть вызывает RST10, смыкает процедурки загрузить че нить с магнитофона записать че нить с магнитофона, н еще че то там (скажим с оговоркой что внесли наиболее часто используемые нестандартые точки входа в подпрограммы)
-> всё висит мертым грузом и создает тормоза, единственное полезное преимущество это она будит дико ругаться если пограммист неправильно указал адрес процедуры загрузки с магнитофона (это вычисляется прекрасно и без данного наворота) + побочка что нада образ ПЗУ хотя бы для того же знакогенератора
4. Программист юзает TR-DOS -> все висит мертым грузом и только создает тормоза, малюсинькая польза может быть как в врианте 3
5. Программист юзает по полной пзу TR-DOS в в частности куски процедур для прямого доступа к ВГ93, или прыгает на код C9 в ПЗУ -> Эта штука на БФ все обламает
6. Програмист юзает куски ПЗУ как ключ для пожатия шифровки и т.д. то есть юзает ПЗУ как набор байтов -> прийдется заниматься избыточностью даже если ПЗУ переписано на С нада будет хранить образ ПЗУ
То есть много избыточности с минимум пролезности.
Имхо такой подход (перехват точек входа) может быть полезен для перехвата вызова ПЗУ трдоса (как в эмулях) для получения данных вообще с любого внешнего устройства (хоть последовательного порта). Но в таком случае blackfin'a будет явно многовато.
Khampton
02.07.2007, 11:06
Слишком много усилий для некому ненужного функионала.
Вот мой анализ для разных подходов программиста
1. Программист пишет на басике -> все висит мертвым грузом и тока создает тормоза проверяя таблицу, либо портит жизь от кривых процедур в калькуляторе каналах
2 Программист не юзает ПЗУ в принципе -> получается все висит мертвым грузом
3 Программист юзает басиковое пзу для в роле бивиса, то есть вызывает RST10, смыкает процедурки загрузить че нить с магнитофона записать че нить с магнитофона, н еще че то там (скажим с оговоркой что внесли наиболее часто используемые нестандартые точки входа в подпрограммы)
-> всё висит мертым грузом и создает тормоза, единственное полезное преимущество это она будит дико ругаться если пограммист неправильно указал адрес процедуры загрузки с магнитофона (это вычисляется прекрасно и без данного наворота) + побочка что нада образ ПЗУ хотя бы для того же знакогенератора
4. Программист юзает TR-DOS -> все висит мертым грузом и только создает тормоза, малюсинькая польза может быть как в врианте 3
5. Программист юзает по полной пзу TR-DOS в в частности куски процедур для прямого доступа к ВГ93, или прыгает на код C9 в ПЗУ -> Эта штука на БФ все обламает
6. Програмист юзает куски ПЗУ как ключ для пожатия шифровки и т.д. то есть юзает ПЗУ как набор байтов -> прийдется заниматься избыточностью даже если ПЗУ переписано на С нада будет хранить образ ПЗУ
То есть много избыточности с минимум пролезности.
АБСОЛЮТНО СОГЛАСЕН
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot