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

[Лас]

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

В общем, эта процедура ищет в памяти последовательность #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=$  !!!
        ;тут можно восстановить режим прерываний, если изменяли его ранее

[Destr]

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

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

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

[Лас]

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

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

[Alex Rider]

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

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

[psb]

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

[Alex Rider]

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

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

[Advertiser]

[psb]

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

[bsivko]

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

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

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

[psb]

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

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

[bsivko]

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

В самом худшем случае будет одно завывание. Т.к. если 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 раз более высокую.