Перестали работать тестовые программы btime, minfo, ulatest3.

[Spectramine]

Когда отрабатывают 69888 тактов, происходит обработка прерывания. А обработчик прерывания меняет адрес возврата, и этим обходит rst 0.

[апро]

Может я что то недопонимаю, но насколько я понял из книг по ассемблеру, прерывание начинает обрабатывться после команды IM 2, а закончится обработка должна командой RET. После команды IM 2 обработчик начинает считать такты в своих мудрёных счётчиках, и если результат счёта соответствует расчётному то программа работает , а если нет то доходит до команды RST 0. Но я не врублюсь , что заставляет программу доходить до какого то места и неожиданно начинать с другого.
Вот к примеру код трасировал в спектакуляторе. До команд с точками остановки программа не доходит никогда. А до команд которые стоят перед ними доходит. Как так? Что заставляет процессор бросить выполнять пограмму на пол пути? Красными стрелками я отметил где программа ещё вы полняется, а до отмеченых точек остановки не доходит. Я понимаю если бы там были команды переходов, но там INC E несколько штук. А в следующм месте POP DE.



А в моём реальном клоне программа отрабатывает до RST 0 в обоих местах, и не бросает выполняться на пол пути. В чём фокус?

Я могу предположить, что в отмеченных местах на картинке приходит следующий сигнал INT и каким то чудом прерывает выполнение программы в нескольких тактах от команды RST 0. Но я нигде не читал про такую фишку. Везде описаны прерывания только по команде IM.
И тут назревает следующий вопрос. Если поцессор бросает выпонять программу в этих местах, то откуда начинает дальше? Могу предположить с адреса на вершине стёка.

[null_device]

каким то чудом прерывает выполнение программы в нескольких тактах от команды RST 0. Но я нигде не читал про такую фишку. Везде описаны прерывания только по команде IM.

Немаскируемые прерывания NMI - нет?!

[Alex Rider]

Может я что то недопонимаю, но насколько я понял из книг по ассемблеру, прерывание начинает обрабатывться после команды IM 2

Что заставляет процессор бросить выполнять пограмму на пол пути?

Процедура обработки прерывания начинает работать в момент прихода импульса на вход /INT процессора. В Spectrum'е импульсы на этот вход поступают примерно 50 раз в секунду, а точнее с частотой обновления экрана. У разных клонов чуть разная частота обновления и геометрия экрана и скорость работы процессора.

Если процессор бросает выпонять программу в этих местах, то откуда начинает дальше? Могу предположить с адреса на вершине стёка.

Это правильное предположение. В момент прихода импульса прерывания как будто бы выполняется команда call, при этом на стек попадает адрес возврата. Обработчик прерывания завергается командой RET, адрес возвра снимается о стека и выполнение продолжается со следующей команды - как бы происходит аппаратный вызов подпрограммы. обработчику прерывания ничего не мешает подменить адрес возврата на стеке и "продолжить" выполнять программу с любого места.

А в моём реальном клоне программа отрабатывает до RST 0 в обоих местах, и не бросает выполняться на пол пути. В чём фокус?

На 100% не подскажу, потому что, повторюсь, я не дебажил этот код. Если обработчик подменяет адрес возврата, то достиженеи команды RST 0 зависит от того, успело ли прийти прерывание до этой самой RST 0. Если успело, то обработчик подменяет адрес, и выполнение обходит RST 0. Если не успело - RST 0 выполняется и сбрасывает машину.

От чего зависит успело или не успело? Скорее всего от модели эмулируемой машины. У ориигнального ZX Spectrum и, например, у ZS Scorpion за время между импульсами прерывания "тикает" 69888 тактов, у Pentagon128 - 71680 тактов. Соответственно, между прерываниями успевает выполниться и разное количество команд, Пентагон может "успеть" выполнить RST 0 до прихода прерывания, подменяющего адрес исполнения, а оригинал - нет.

[Spectramine]

Может я что то недопонимаю, но насколько я понял из книг по ассемблеру, прерывание начинает обрабатывться после команды IM 2,

Команда IM 2 не начинает обработку прерывания, она задает режим обработки прерывания.

а закончится обработка должна командой RET.

Обработка прерывания также может завершиться командой RETI или RETN. А может вообще не заканчиваться, можно на прерываниях построить и главный программный цикл, но так делают редко.

После команды IM 2 обработчик начинает считать такты в своих мудрёных счётчиках, и если результат счёта соответствует расчётному то программа работает , а если нет то доходит до команды RST 0.

Нет никаких счетчиков в обработчике прерываний, здесь, по крайней мере. Счетчики есть в основной программе. Вот например цепочка INC E в листинге - кусок такого счетчика.

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

Прерывание и заставляет. По сигналу INT делается подтверждение прерывания, и переход на обработчик прерывания (команды перехода НЕТ, это делается аппаратно, но есть адрес перехода, для режима IM 2 на спеке он хранится в памяти по адресу: (старший байт=регистру I, младший=$FF). А обработчик прерывания уже меняет адрес возврата, обходя этим команду RST 0.

А в моём реальном клоне программа отрабатывает до RST 0 в обоих местах, и не бросает выполняться на пол пути. В чём фокус?

Фокус в нестабильном времени кадра между прерываниями. Из-за вайтовых задержек программа не может точно вычислить время кадра в тактах, и прерывание должно произойти позже расчетного момента перед командой RST 0. То есть RST 0 отрабатывает, и идет сброс.

Я могу предположить, что в отмеченных местах на картинке приходит следующий сигнал INT и каким то чудом прерывает выполнение программы в нескольких тактах от команды RST 0. Но я нигде не читал про такую фишку. Везде описаны прерывания только по команде IM.

Вы неправильно представляете работу системы прерываний. По команде IM задается _режим_обработки_прерывани� �, а не происходит само прерывание. Сам прерывание происходит по приходу сигнала INT. Этот сигнал приходит со строгой периодичностью, с длиной периода, равной времени кадра между прерываниями (69888 тактов на фирменных 48 к, но с другой длиной на других машинах. Проблема в том, что точно вычислить эту длину на некоторых машинах программно можно, а на некоторых - нельзя (или можно, но используя другие приемы, не такие, как в данной программе)).

И тут назревает следующий вопрос. Если поцессор бросает выпонять программу в этих местах, то откуда начинает дальше? Могу предположить с адреса на вершине стёка.

Во время прихода сигнала прерывания на стек кладется адрес возврата - место, на котором программа была прервана. Команда RET в обработчике прерывания делает переход на это место, считывая его адрес со стека. НО - можно программно в обработчике прерывания изменить этот адрес перехода. В данной программе он просто пропускается на стеке ($FEFE INC SP:INC SP), а переход происходит на следующий адрес, хранящийся на стеке (EI: RET). EI (разрешение прерываний) нужно, т.к. при переходе в обработчик прерывания запрещаются аппаратно.

[апро]

Я не правильно представлял процес работы прерывания. Спасибо за разъяснения, я всё понял.

[Advertiser]