Вид для печати
Нужно внести свои изменения в ПЗУ 48кб. Из литературы есть: Полное описание ПЗУ ZX-Spectrum - Я. Логан, Ф. О'Хара' 83; Программ-АСС'92.
Возникает пара вопросов:
1. Есть или иные описания ПЗУ, чем-то лучше чем это?
2. В какие места ПЗУ наиболее безопасно вносить изменения для сохранение совместимости? А может есть места которые лучше не трогать? Или таких мест не существует?
3. Есть ли декомпилирование ПЗУ в виде код в txt, asm или аналогичных файлах?
Дизассемблер с описанием на основе логана с картой пустых мест и ссылками на референсы https://skoolkid.github.io/rom/Цитата:
Сообщение от tae1980
Вносить изменения в ПЗУ - глупая идея. Тысячи программ и игр используют части и куски подпрограмм ПЗУ, ты никогда не узнаешь их все. Так что не надо туда лезть. Вон там есть немного пустого места, попробуй туда запихать.
С адреса 386e есть 1170 байт, можешь туда впаяться.Цитата:
Сообщение от tae1980
Была одно время мода юзать ПЗУ как подсчёт какой-нибудь ксорки или ещё в каком виде контролировать её состояние...Цитата:
Сообщение от SoftLight
Это в целях всяких защит делалось, но теперь так конечно уже не делают...
Так что можно хоть свою версию ПЗУ писать - нормальные проги (где-то с 95 вроде года было негласное соглашение не юзать куски ПЗУ вообще никак, оно выродилось просто в инструмент запуска ну и Бейсик для подсчётов-тестов на скорую руку...) не юзают ПП ПЗУ, ибо столько разных их развелось что уже нет уверенности даже в RST#10 - что отработает как надо...
Хотя конечно процент мал, всё-таки в основном ПЗУ осталось рабочим, но это примерно как на Win10 использовать инструментал 3.11 (глубоко в недрах ядра до сих пор живут эти куски, и порой даже их используют, хоть и лезут глаза на лоб когда какой-нибудь вполне современный инсталлятор выкидывает окошко старой-старой винды и просит нажать кнопку "ОК", да не как-нибудь, а именно мышью! Это когда мыши с шариком обрезиненным были взлётом технологии...)
Кто-то кстати решал вопрос с местом в ПЗУ путём перекомпиляции существующих процедур, но применяя всякие извраты сокращал их в объёме - выдирая недостающие байты...
Но это тоже костыль...
Это всё ерунда и твои фантазии, не имеющие ничего общего с реальностью. Какие еще негласные соглашения :) Вот адаптирую тут игры с rgb 2019 года - практически КАЖДАЯ игра использует куски ПЗУ, для опроса клавиш или для задержек или для загрузки самой игры.Цитата:
Сообщение от Destr
Не трогайте ПЗУ, если хотите, чтобы у вас работали игры.
Вот-вот, о чём я и говорю...Цитата:
Сообщение от Shadow Maker
Не изменять (уж какая версия ПЗУ на борту - пусть та и будет)
Ну и конечно в своих прогах старатся обходится минимумом (клавиши или задержки ещё туда-сюда, даже бипер можно, а вот куча всего другого - порой смещена и нехило. В каком-то Ревю помнится уже об этом заметили - беда что нет кернельной части, иначе можно было-бы модифицировать ПЗУ как угодно, просто правя адреса вызова, но этого не произошло... Фантазии?)
Спасибо!Цитата:
Сообщение от Shadow Maker
Нужна спецальная версия для работы в качестве эмуляции спекка в режиме СПМ. Для чего по хорошему нужно использовать для своих целей первые 100 байт, и небольшой код в любом месте.Цитата:
Сообщение от Shadow Maker
Скорее всего первые 100 байт трогать будет нельзя, значит будем химичить с буферизацией.
Кстати, за клавиши...
Так и не разобрались почему если обработчик клавишь сидит в ПЗУ то нет дребезга, а если в ОЗУ то есть?
Где-то была статья, но закончилась она тем что автор сам признался - хз почему такое...
- - - Добавлено - - -
Ну да, вот оно:
http://zxpress.ru/article.php?id=3480
"Ну и, как вы уже догадались, единственная программа,
которая выдержала проверку по глючности, - это именно
подпрограмма опроса в ПЗУ Бейсика 48. Честно скажу, так и не
понял, что в ней магического, может, потому, что она именно в
ПЗУ расположена, а может, и по нескольким особенностям сразу,
только она практически никогда не глючит."
Фантазии относительно того, что некие "нормальные" проги не используют ПЗУ. По факту практически все используют, в той или иной мере. И дело не в нормальности, просто так реально проще делать. То, что криводелы поломали ПЗУ в каком-нибудь из клонов - это проблемы криводелов.Цитата:
Сообщение от Destr
Да пусть делают, криводелки и прочее...Цитата:
Сообщение от Shadow Maker
Наша задача, как ветеранов - хоть уберечь их (криводелов) от ошибок...
Пусть знают про подводные камни. Пусть будут готовы...
Может быть это самое лучшее что можем им посоветовать-подсказать, пусть не теряются в догадках если что, а хоть примерно в курсе откуда ветер дует...
Пусть у них не будет таких недоумённых вопросов и удивлённых глаз - как мы в своё время хватанули...
- - - Добавлено - - -
Не ошибается тот кто ничерта не делает.
Если пробуют - значит рано или поздно добъются-разберутся...
И это хорошо. Это значит прогресс двигается... Потихоньку-полегоньку :)
эти тоже умудряются применять в софте для im2 или как источник для лдировЦитата:
Сообщение от SoftLight
да небось в других испытанных им просто поленились сделать опрос нормальный с памятью на несколько кадровЦитата:
Сообщение от Destr
что примечательноЦитата:
Сообщение от Lethargeek
проверяя кучу софта в эмуляторе
в разном софте
наблюдается одно и то же явление
все время при переключении пунктов менюшек вверх\вниз кнопками
происходит 2-х кратное срабатывание (проскакивание 2-х пунктов сразу)
и нужно очень хитро и коротко нажимать (прям как при вводе зорбы)
на эмуле дребезга нет
так же как и на клавиатуре
эмуляция дребезга отключена
ЧЗНХ?
чо такая же херня была на реале? о_О
не смогли сделать нормальный опрос?
- - - Добавлено - - -
если только нужно заменить обработчики rst на своиЦитата:
Сообщение от tae1980
то их вполне можно заменить
и при обработке проверять от куда был совершен вызов по адресу возврата
если из своего кода то выполнять свою процедуру
конечно оно будет тормозить
и 70% совместимость не будет гарантирована
но такое можно вполне сделать
и что то останется рабочим
..конечно при прямом jp-е такое не прокатит... (но и на стеке скорей всего не будет лежать число похожее на адрес "своего" кода (по крайней мере вероятность низкая но есть) и во многих случаях обработка рст будет правильной даже так)
Было-было...Цитата:
Сообщение от NEO SPECTRUMAN
Это как Venom III
На скорпе (жёлтый)
Тоже быстро-быстро нужно шлёпать по клавишам (я так одну герконку расколотил, потом была плёночка - с ней полегче...)
Серенькая эта, как зовётся не знаю, но чисто под спек затачивалась...
(на Хоббите-64 этого кстати не было, но там и FLASH работал в 10 раз медленней, непонятно вообще, порты что-ли опрашивались по-другому...)
нет ладно на фирменных играхЦитата:
Сообщение от Destr
которые затачивались под резиновый спектрум
так наша же софтварь под наши дребезжащие клавиатуры
может там у кого то были впаяны 8 кондеров большой емкости на землю
которые сильно сглаживали дребезжащие данные на порту
и оно все прекрасно работало?
- - - Добавлено - - -
ато 100 нФ творят чудеса
до
https://jpegshare.net/images/a8/5d/a...6d01627aaa.png
после
https://jpegshare.net/images/4d/e7/4...9c7588fd4b.png
Хех, прикольно...
Только не было функционала такого, как-то всё попроще (Ц-20, на крайняк элт-осциллограф + распечатаные чёрт-те на чём матричном принтере и 100500 раз копированые диаграммы точек для контроля...)
у меня на старом ленинграде реальном так же (правда, там и клава была говённая)Цитата:
Сообщение от Destr
кто-то раньше здесь утверждал, что в случае венома причина - в нестандартном инте
ну номинал подбирал методом научного тыка же :)Цитата:
Сообщение от Destr
200 уже начинало резать полезный сигнал
меньше 100 было больше дребезга
150 у меня не нашлось
если чо это китайский одноразовый енкодер шириной миллиметров 10
с механическими щетками (без графита тупо метал по металу)
которые износившись стали жутко дребезжать
хотя первые года 4 отработал без глюков
но лет через 10 вращение в одну сторону просто перестал понимать...
...про софтварное определение что "дребезжит"
конечно же разработчег неподумал...
кажется код в ROM выполняется медленнее чем в RAM.Цитата:
Сообщение от Destr
Не-не!Цитата:
Сообщение от NEO SPECTRUMAN
Бро, я ошибся, ИНСТРУМЕНТАЛА
(всякое советское электронно-измерительное барахло, современного осциллографа я в глаза не видел, особенно который подключается к монику и тренды ведёт...)
Оговорился, впечатлён...
- - - Добавлено - - -
Ну вот тяжко в деревне с современными технологиями, я уже тут деградирую...
- - - Добавлено - - -
Где-то про страницы и адресацию и выборки данных был разговор...Цитата:
Сообщение от goodboy
Это когда я тормошил аппаратчиков...
Где-то карту давали - с неё было видно что нижние адреса опрашиваются быстрей всего... ( да и по тем микрухам - озу было медленней чем пзуха, а уж тем более ула...)
Или путаю...
- - - Добавлено - - -
Lethargeek, Тебя тоже с НГ
так и без инструментала было ясно что дребезг контактовЦитата:
Сообщение от Destr
...это просто было интересно
а на сколько он сильный и как выглядит
ну я тожо не виделЦитата:
Сообщение от Destr
мой осциллограф теплый и ламповый (притом буквально :) )
- - - Добавлено - - -
кажется с точностью на оборотЦитата:
Сообщение от goodboy
и то не всегда и не везде...
Такой (тёплый и ламповый) у меня из кабинета на утилизацию вынесли давеча...Цитата:
Сообщение от NEO SPECTRUMAN
Заодно зачерпнув пару литров ртути...
(я начальнику в очи заглянул - и увидел только что ему пофик как у него сотрудники тут живут...)
Ну лады...
До смерти как-нибудь дотянем, но неужели ни понимания, ни стыда...
(а откуда в *опе алмазы, конечно тупо в коровьи глаза заглянул - он даже не понял о чём я :) )
Было смешно...
Ну ладно, ртуть вычерпали... Примерно литров 200 ещё под полом осталось...
Ну дышим...
Осциллограф тёплый, ламповый вынесли на свалку...
Я даже не успел его толлком освоить (производственная модель, хотя такими сейчас уже не оперируют, этот был примерно 3 метра в ширину, куча задающих генераторов, но я не про этот...)
Я про другой. Который у бати был, бытовой, обычный, хз, не обращал я тогда на модели внимания...
Теперь-бы конечно обратил, но уже всё равно...
Вообще говоря, лучше не менять ничего. Совсем. Вот неполный перечень граблей, на которые я и другие в своё время наступали:Цитата:
Сообщение от tae1980
1) Клавиатура, таблицы соответствия скан-кодов буквам ("BHY65TG..."). Эту таблицу перемещать или изменять нельзя. Некоторые программы её используют, при этом не используя код опроса клавиатуры из ПЗУ;
2) "Свободное место" между кодом Бейсика и знакогенератором. Многие программы ставят на эти адреса регистр I, предполагая, что там записаны FFы, и ставя на адрес FFFF обработчик прерываний IM 2. Если по этим адресам в ПЗУ находятся не FFы - то первое же прерывание отправляет программу в отключку;
3) Код программ рисования линий, точкек и окружностей. Мне встречалась защита, которая помещает зашифрованный код программы в экранную область, затем вызывает подпрограмму "LINE" рисования линии в режиме OVER 1, тем самым модифицируя строго определённые части зашифрованного кода обратимым образом. В моём случае алгоритм LINE не менялся, так что линия рисовалась правильно... Только вот регистр R после отработки программы имел другое значение, в результате чего дальнейшая расшифровка программы шла неверно, и происходил полный сбой;
4) Коды подпрограмм калькулятора. Я в них исправлял ошибки, найденные Логаном и О-Харой, а также исправил "самозатирание" ПЗУ одной из таких подпрограмм. Всё бы ничего, но предательский регистр R, на который полагаются защиты, снова имел не то значение, что нужно;
5) Код обработчика NMI. Некоторые защиты его проверяют и, если он нестандартный - отказываются работать (это защита от разнообразных мониторов-отладчиков на основе NMI).
Были и другие сюрпризы, сейчас уже всех не вспомнишь. Но общий вывод такой, что какими бы малыми и безобидными ни были изменения ПЗУ, они могут привести к неработоспособности некоторых программ. И тут не важно, кто виноват - автор такой программы или автор изменений ПЗУ. Факт налицо - с изменениями ПЗУ программа не работает, без изменений - работает. Хочешь запускать программу - откати изменения ПЗУ назад.
Зачем? Для понимания работы ПЗУ это не нужно. Есть книга Логана и Хары. Чтобы компилировать ПЗУ назад? А зачем? При малых изменениях в этом нет смысла, достаточно просто изменить содержимое двоичного файла-образа в нужных местах. Смотри мою тему про BOGOBASIC. При больших изменениях, когда сдвигаются адреса некоторых важных подпрограмм, почти весь софт перестанет работать с таким образом ПЗУ.Цитата:
Сообщение от tae1980
Это понятно.Цитата:
Сообщение от Barmaley_m
Хочу реализовать работу с программами для режиме Спектрума 48кб из режима CP/M на Профи. А значит нужно куда-то вставить код для возврата и взаимодействия с CP/M, нужно перехватить ввод/вывод на магнитофон и подменить его чтением/записью в файл на винчестер и т.п. Придется действовать путём установки прыжков со входа в подпрограммы ПЗУ. Но всё равно нужно где-то разместить относительно небольшой код переключение на страницу с кодом реализующие взаимодействие с CP/M.
нет нуЦитата:
Сообщение от tae1980
когда шина стабильная
то вектор прерывания всегда считывается с одного адреса (2 байта)
так же начало вектора прерываний только по адресам кратным $100
ТОЕСТЬ
оставляем 2 байта с $FF в нужном месте
и можем использовать 255 остальных байта из этой "256 байтной страницы"
ну а таких целых 4 39xx 3Axx 3Bxx 3Cxx
если пзу позволяет
то сделать несколько вариантов с размещением в разных местах
чтоб если не работает один
пробовать другой
и по крайней мере
софт который юзает пзу для вектора прерываний
падать уже не будет
NEO SPECTRUMAN, на первом этапе я вообще не хотел трогать прерывание.
Для работы CP/M нужны первые 255 байт и часть адресов в конце. Планирую реализовать переключение на страницу с кодом CP/M с адресов #C000, в ней производить подмену первых 256 байт и последующие необходимые действия (нужны ещё будут буфера для операций чтения/записи), по окончанию восстанавливаем целостность ПЗУ.
Вот сам подобные переход планировался во время операций чтения/записи, для чего нужно перехватывать обращения к профильным подпрограммам ПЗУ. По сути вставить "JP NNNN" на входе в подпрограммы на кусок кода который переключит страницу и сделает переход на подпрограмму обработчик.
Вмешательство в ПЗУ минимальное. Из минусов возврат в CP/M можно будет реализовать только в момент работы с магнитофоном. В этом случае должно открываться окно позволяющее выбрать файл для загрузки/записи из которого уже можно вернуть в CP/M.
а к чему здесь прерывания?Цитата:
Сообщение от tae1980
я говорю про свободное место которое можно занять
и про не свободное, которое лежит среди свободного, которое занемать низя
Да, действительно. Что-то я не того.Цитата:
Сообщение от NEO SPECTRUMAN
Видно наложились два потока информации. Всё думаю как можно реализовать возврат в CP/M по какой либо комбинации клавиш, у Профи часто ИВМ клава, да и расшиерный кнопки дублируются комбинациями на обычной клавиатуре. Как получу первые положительные результаты, думаю всё таки внести незначительные правки в подпрограмму ПЗУ опроса клавы и задать нужные комбинации. Работать конечно будет только если запущенная программа использует профильные подпрограммы ПЗУ, но уже что-то :)
а профи нету nmi на кнопке?Цитата:
Сообщение от tae1980
Не понял. Не знаком с понятием "nmi". Если это магик кнопка. То есть, но на моём старом Профике не была выведена. Но что бы она для данного случая корректно работала, если не ошибаюсь, нужно править ПЗУ уже самого Профика. В работе CP/M она ни как не участвует.Цитата:
Сообщение от NEO SPECTRUMAN
Для этого не обязательно менять ПЗУ. Тем более, что изменённое ПЗУ не каждый потенциальный пользователь твоей системы сможет и захочет прошить.Цитата:
Сообщение от tae1980
Почему бы не воспользоваться приёмами, типичными для "расширений Бейсика" типа Beta-Basic, Laser-Basic или ПЗУ Interface 1?
Общий принцип там такой, что подменяется содержимое адреса возврата при ошибке (два байта, находящиеся по адресу, который хранится в системной переменной ERR_SP). Твоя подпрограмма обработки ошибок смотрит, что за ошибка была. Если это ошибка синтаксиса (C Nonsense in BASIC, 10:1) - то анализируется содержимое бейсик-программы, вызвавшей ошибку (для этого используется системная переменная, содержащая адрес следующего интерпретируемого символа - забыл название). Если содержимое бейсик-программы соответствует реализованным тобой расширениям - то это содержимое обрабатывается твоим кодом (происходит переход в CP/M и т.д.), в противном случае управление передаётся обратно бейсику, чтобы тот выругался по поводу NONSENSE.
Когда отработали твои программы обращения к винчестеру и т.д. - то указатель на интерпретируемый символ передвигается туда, где, с точки зрения бейсика, ошибок больше быть не должно. И происходит прыжок в соответствующую точку ПЗУ, как будто никакой ошибки синтаксиса не было. Исполнение программы продолжается бейсиком.
В такой системе менять содержимое ПЗУ вообще не нужно.
достаточно давно существует вообще альтернативная прошивка OpenSEbasic
https://www.worldofspectrum.org/info...cgi?id=0027510
вариант для использования в коммерческих/аппаратных клонах.
совместимость довольно высокая + новые команды/улучшения
ПЗУ в железе вообще трогаться не будет. У Профи ПЗУ отключаемое (это требование CP/M), на его место встаёт страница 0. Так что можно просто грузить нужный код. Из ограничений, CP/M использует для своих целей адреса 0-255, тут нужно не сложно химичить.Цитата:
Сообщение от Barmaley_m
Хочу сделать эмуляцию режима 48кб (в перспективе 128кб), а не просто работы в бейсике. Что бы можно было грузить (и не только) программы напрямую из CP/M. Для чего реализуем основной код "эмулятора" в одном из верхнем сегментах памяти, а в ПЗУ нужно буквально несколько байт которые включат нужную страницу и совершат переход на подпрограмму. Благодаря наводке NEO SPECTRUMAN "безопасные" места вроде найдены. Остальное дело техники. Правда геммора ещё будет много в других местах. Сейчас ломаю голову как реорганизовать использование памяти внутри самой CP/M, так что бы весь код системы и драйвера вынести выше 7 страницы. Задача так же весьма не тривиальная, так как весь код писался так что бы мог работать на 128кб и подобный перенос не планировался, а страница 5 вообще имеет особое значение.
А кстати. Такой вопрос к профессионалам, который давно интересует. Почему нижеследующая программа в адресе 30000 и 40000 звучит по разному? В 30000 как из бочки, а в 40000 звучит как в ПЗУ по первым четырёхзначным адресам? Ошибка отсчёта T-State или что-то совсем специфическое?
Так будет на всех версиях Spectaculator и последних версиях EmuZWin. На ранней версии эмулятора звук во всех областях одинаковый.
Скрытый текст
ORG XXXXX
LD HL, 1642 ; Длина звука
LD DE, 261 ; Тональность
beeper: DI
LD A, L
SRL L
SRL L
CPL
AND 3
LD C, A
LD B, 0
LD IX, BEIX3
ADD IX, BC
LD A, (23624) ; Цвет рамки во время звучания
AND 56
RRCA
RRCA
RRCA
OR 8
BEIX3: NOP
BEIX2: NOP
BEIX1: NOP
BEIX0: INC B
INC C
BEHLLP: DEC C
JR NZ, BEHLLP
LD C, 63
DEC B
JP NZ, BEHLLP
XOR 16 ; Цвет чередующейся полоски (16...24)
OUT (254), A
LD B, H
LD C, A
BIT 4, A
JR NZ, BEAGAIN
LD A, D
OR E
JR Z, BEEND
LD A, C
LD C, L
DEC DE
JP (IX)
BEAGAIN:LD C, L
INC C
JP (IX)
BEEND: EI
RET
[свернуть]
модель спектрума? наиболее вероятная причина - в медленной памяти (на пентагоне разницы не должно быть)Цитата:
Сообщение от Yuri80
оба очень давно не обновлялись, и не стоит принимать их за образецЦитата:
Сообщение от Yuri80
48-й режим, я только в нём работаю.Цитата:
Сообщение от Lethargeek
Я даже опыты с обнулением ПЗУ делал и рассчитывал время прохождения кругов по пустой памяти в режиме 3,5 и 7 МГц. И мне кажется, что опыт с музыкой, лишь часть той самой проблемы. Но выходит, она у многих эмуляторов в режиме 48K. Еще бы на десятке эмуляторов проверить этот глюк и на реальном. Подозреваю, что проблемы, скорее всего, в самих .exe файлах эмуляторов. А это только с помощью отладчика, типа OllyDbg ковырять.
Поэтому и спрашиваю, может кто сталкивался.
Я уже писал и размышлял на эту тему. Привожу картинку отдельно.
https://zx-pk.ru/attachment.php?atta...5&d=1757761689
Вот эта картинка, если скачать будет лучше видно:
Вложение 82785
https://worldofspectrum.org/faq/refe...htm#Contention
вам почитать для понимания, не самое простое описание но вроде все описано подробно.
Если дело в медленной памяти (а по описанию это наверняка оно и есть), то в эмуляторах нет проблемы, проблема в спектруме. Эмуляторы лишь его точно эмулируют. В 48к модели нижние 16к оперативы лежат в отдельных микросхемах, доступ к которым имеет не только проц, но и видеоконтроллер. И у видеоконтроллера приоритет, поэтому на время, в которое он читает очередные байты экрана, проц в эту нижнюю память не имеет доступа. И получается, что такты тикают, а программа не исполняется.Цитата:
Сообщение от Yuri80
Цитата:
Сообщение от krt17
Огромное спасибо за наводку на статью и разъяснения! Почитал и скачал документацию с вышеуказанного сайта. Еще одной тайной стало меньше. Никогда бы не подумал, что внутренние процессы так хорошо влияют, и это поддаётся вычислению.Цитата:
Сообщение от Eltaron
В моих опытах, при пустой памяти первая задержка начинается на шаге 21057, где команда 0 даёт 9 тактов, а следующие по 8. вместо 4-х.
Тема раскрыта.