Rumata,у меня получается,что первый дешифратор,состоящий из горсти инверторов и четырёх ЛА2 выбирает конкретный адрес:$000078. А это вектор 6-прерывание по кадровому синхроимпульсу 
Как это понимать?
Второй дешифратор,DD14 выбирает адрес,или даже диапазон адресов:$3Fxxxx,что соответствует расположению ПЗУ картриджа.
Правильно? 
а вот и зацепка. я не могу прочитать адрес 78. мой ром крашится при чтении.
если взломщик выключить, то все отлично работает.
предположу, что взломщик ожидает чтение адреса 78 только тогда, когда происходит вертикальное прерывание, следовательно если я его читаю - получаем краш.
разбираюсь дальше. попробую читать адрес по нажатию кнопки, а также попробую писать переменную до прерывания и после прерывания - потому что похоже что взломщик клинится в вертикалочку и разводит там беспорядочки
Добавлено позже:даже по байтам читать не дает.
пробовал дергать байты 79,7A и 7B по отдельности.
Добавлено позже:подтверждаю, взломщик долбится в вертикалку, заменяет ее на свою, выполняет свои грязные делишки и возвращает в обычное прерывание.
я поставил счетчик и ввел код во взломщике, чтобы он его чинил.
запись внутри вертикалки увеличивает число ровно на 1.
запись в основном цикле увеличивает число на рандомное в пределах 1-2.
Добавлено позже:капаюсь в коде и хочу выдвинуть предположение:
что если при запросе по адресу
$7А взломщик отключает
картридж и включает свой
РОМ.
потому что если это так, у него в
VINT записано
$0000 и команда
$4EB9 вместо адреса, что как бы повлечет за собой
Illegal Address, а у взломщика там аккурат
функция записи переменных из включенных кодов, после чего он прыгает по адресу
VINT+2 (т.е.
$7A) где выполняет
4eb9, что триггерит взломщик обратно в
Картридж и
CPU переходит по адресу, который находится
выше VINT (т.е. адрес записанный в
$7C), где как правило всегда стоит
rteДобавлено позже:просто если мое предположение верно, то починить взломщик будет воще изи:
- цепляем ногу A21 и A22 на РОМ взломщика, чтобы он всегда читался в адресах выше 4 мегабайта
- я переписываю код активации введенных кодов так, чтобы он триггерил пространство адресов сразу обратно в картридж, а потом из своего уютного 4 мегабайта выполнял активацию кодов
- ну и возврат обратно в картридж посредсвтом rte
что получаем в итоге:
вот так было
| .::Состояние::. | .::Пространство::. |
| Картридж | РОМ картриджа |
| Триггер в $7A | РОМ взломщика, активация кодов, триггер обратно |
вот так станет
| .::Состояние::. | .::Пространство::. |
| Картридж | РОМ картриджа + РОМ взломщика выше $400000 |
| Триггер в $7A | РОМ взломщика, переход в $400000, триггер обратно в РОМ картриджа, активация кодов |
результат: неглюченный звук, на %98 реже зависание игры
Добавлено позже:т.е. все глитчи и баги вызывал
ROM взломщика будучи резко переключенным из
ROM-а игры, потому что в таком случае
Z80 особенно сильно страдает.
ну и как известно
Z80 вполне вправе при должном желании
повесить себя (а заодно и
всё остальное) к хренам собачьим.
Добавлено позже:либо более дешевый вариант, хакнуть код взломщика, чтобы он выполнял такие действия при триггере:
- останавливать
Z80- активировать
коды- возобновлять
Z80-
тригериться в ром
кстати
Z80 можно возобновлять и из
шел-кода выделив под него место в стеке. так например время
Z80 в пространстве взломщика снизится почти до нуля.
то есть:
- останавливать
Z80- активировать
коды- записать шеллкод
триггера в картридж и
возобновления Z80 в стек
- записать ссылку на шелл код в стек
- выполнить
rts- внутри шелл кода
безопасно триггернуться в картридж- внутри шелл кода
возобновить Z80- внутри шелл кода выполнить
rteну и код активации введенных кодов можно оптимизировать на добрый десяток циклов засчет отказа от бит-шифт команд
Добавлено позже:murgatroid_79, сколько у нас места под ROM можно максимально сделать?
я имею ввиду сколько ног адреса подведены к ROM взломщика?
если 256кб это не предел, это будет просто супер новость
и тот же вопрос про встроенную RAM
