Определение текущего адреса

Вот самое оригинальное решение топика :). Алгоритм, естественно, можно модифицировать. Но идею я постараюсь до вас донести, спектрумисты.
Процедура, естественно, релоцируема.
Прерывания можно и не запрещать, если вы уверены в том что не данная процедура не модифицирует код процедуры обработки прерываний и вызываемых ею подпрограмм в неподходящий момент.)

В общем, эта процедура ищет в памяти последовательность #18,#02
и если находит, то обнуляет смещение, и если получается что она модифицировала сама себя, то IX будет указывать на нашу программу и мы его скорректируем с PC, а если модифицировала что-то иное - то тут же восстановит данные и поиск продолжится.

Код:

;тут надо бы запомнить режим прерываний, процедуру писать не буду di ;а можно и не запрещать прерывания по вышеизложенным причинам. ld ix,#4000 ;начинаем искать в памяти с этого адреса bad ld a,#18 ;ищем код JR not_jr cp (ix+0) ;в памяти лежит JR? inc ix jr nz,not_jr ;если не JR, поиск далее ld a,(ix+0) ;иначе берем смещение за JR cp 2 ;сравниваем с величиной относительного смещения нашего JR jr nz,bad ;оно не такое как у нас? ld (ix+0),0 ;если значение такое же, то уничтожаем смещение DEFB #18 ;вот тут после JR (код #18) DEFB 2 ;cмещение указывает через ловушку jr trapped ;<----сюда попадем если обнулили искомое смещение. ld (ix+0),a ;иначе попадаем сюда. восстанавливаем смещение jr bad ;и снова ищем JR trapped ;cюда попадаем, если уничтожили нужное смещение ld (ix+0),a ;восстанавливаем байт смещения ;IX установлен на байт смещения LD DE,16 ADD IX,DE ;вот и все. PC вычислен ;IX=$ !!! ;тут можно восстановить режим прерываний, если изменяли его ранее

Цитата:

Сообщение от Лас

Вот самое оригинальное решение топика

Я прикидывал такой вариант, но он не подходит если в код в области ROM лежит.
Там ведь менять нельзя?
Или я опять не понял требований темы?

А если в общем плане (при нормальных условиях, без извратов с неизвестным стеком, ROM, IM и т.д.) - то это самый лучший вариант.

Цитата:

Сообщение от Destr

А если в общем плане (при нормальных условиях, без извратов с неизвестным стеком, ROM, IM и т.д.) - то это самый лучший вариант.

Я извиняюсь, но это самый подходящий вариант при любых условиях :), за исключением работы этого варианта из ПЗУ. Но такого условия не стояло. Условие стояло - "пзу может отсутствовать" :).
Да, пзу может отсутствовать. Прерывания мы запретим. Стек может быть где угодно (неизвестен) и режим прерываний может быть любым (IM 0,1,2). А состояние прерываний (enable/disable) может определить, сохранить и восстановить даже зеленый нуб.

Цитата:

Сообщение от Лас

Вот самое оригинальное решение топика .

Круто! Гениально! Респект! Спасибо! Буду использовать этот вариант.

есть один минус значительный: например, если на прерываниях висит музыка, мы их запрещаем на очень долгое время - будут завывания... так что, все же, не любые условия.

Цитата:

Сообщение от psb

есть один минус значительный: например, если на прерываниях висит музыка, мы их запрещаем на очень долгое время - будут завывания... так что, все же, не любые условия.

Да, не учел этого... Да и время вызова получится существенное. Придется идти на такие хитрости и ограничения:
1) во время поиска прерывания не запрещать, запрещать только на момент проверки адреса;
2) сделать настройку на адрес при первом вызове;
3) запретить перемащать код в памяти после первого вызова (ну или делать проверку по ключу на перемещение и повторять настройку при перемещении).

и весь этот геморрой, чтобы не юзать стек (который наверняка можно юзать) и не портить экран на неск. тактов (которые даже не увидишь).

Цитата:

Сообщение от psb

есть один минус значительный: например, если на прерываниях висит музыка, мы их запрещаем на очень долгое время - будут завывания... так что, все же, не любые условия.

При необходимости процедуру можно ускорить в разы и даже в десятки раз.

Например в памяти располагаем ключ из одинаковых байт X длиной в N. При поиске ищем байт X с шагом N. Если нашли, определяем его хвост. Меняем хвост. Если это наш измененный хвост, значит мы нашлись.

Цитата:

Сообщение от bsivko

При необходимости процедуру можно ускорить в разы и даже в десятки раз.

только запрос на прерывание обычно длится 28 тактов.

Цитата:

Сообщение от psb

есть один минус значительный: например, если на прерываниях висит музыка, мы их запрещаем на очень долгое время - будут завывания... так что, все же, не любые условия.

В самом худшем случае будет одно завывание. Т.к. если PC один раз определен, то всю процедуру можно свернуть в "LD HL, const; RET"

Если оценить по времени процедуру Лас, то в наиболеевероятномслучае (если вся память не забита кодом #18) время поиска составляет ~64k*40 тактов, что порядка 0.6-0.7 с.

Вот модифицированная на ускорение программа Лас'а:

Код:

ld ix,#4000 ;начинаем искать в памяти с этого адреса ld de,#0010 ;шаг поиска bad ld a,#18 ;ищем код JR not_jr cp (ix+0) ;в памяти лежит JR? add ix, de jr nz,not_jr ;если не JR, поиск далее ; докатываем до конца блока из #18 loop18 inc ix cp (ix+0) jr z, loop18 dec ix ld a,(ix+0) ;иначе берем смещение за JR cp 2 ;сравниваем с величиной относительного смещения нашего JR jr nz,bad ;оно не такое как у нас? ld (ix+0),0 ;если значение такое же, то уничтожаем смещение jr block ; #18 15 раз. DEFB #18,#18,#18,#18,#18,#18,#18,#18,#18,#18,#18,#18,#18,#18,#18,#18 block DEFB #18 ;вот тут после JR (код #18) - 16й #18. DEFB 2 ;cмещение указывает через ловушку jr trapped ;<----сюда попадем если обнулили искомое смещение. ld (ix+0),a ;иначе попадаем сюда. восстанавливаем смещение jr bad ;и снова ищем JR trapped ;cюда попадаем, если уничтожили нужное смещение ld (ix+0),a ;восстанавливаем байт смещения ;IX установлен на байт смещения LD DE,16 ADD IX,DE ;вот и все. PC вычислен ;IX=$ !!! ;тут можно восстановить режим прерываний, если изменяли его ранее

Здесь имеем скорость перебора ~ в 16 раз более высокую.