NMI, IRQ, развёртка и совмещение видеорежимов (Страница 2 из 3)

На семерке NMI совпадает с кадровым гасящим импульсом. Гашение луча происходит после того, как отрисована последняя видимая строка. Луч при этом продолжает идти вперед. Обратный ход начинается в момент прихода кадрового синхроимпульса. Я к картинке Владимира пририсовал легенду, чтобы было понятнее.

А есть возможность проверить, сколько всего вызовов обработчика IRQ происходит за кадр? И посмотреть, нет ли повторных вхождений в обработчик IRQ в пределах одного запроса?

Насколько я понимаю, счетчик строк считает от 0 до 311. Пока он считает от 0 до 255 - это видимая часть кадра (256 телевизионных строк). Пока он считает от 256 до 311 - это невидимая часть (гашение). Вроде бы, никакого третьего состояния тут быть не должно.

По идее, можно выход SYNC процессора использовать. Первый переход SYNC в высокий уровень после установки сигнала IRQ - это начало обработки прерывания.

Ух, ё-моё...
Спасибо за картинки, они кое-что проясняют.

Во-первых, видно, что разработчики Рапиры не разобрались с IRQ и заставили работать совмещение режимов методом "грубой силы" (потому что обработчик вызывается много раз). Это довольно стрёмно, потому что стек может легко закончиться.

Во-вторых, видно, что сам обработчик прерывания короткий, меньше 40 тактов. Я подозреваю, что он изменяет некий счётчик и при достижении, например, нуля происходит переключение видеорежимов. И поскольку обработчик успевает 25-26 раз вызваться за время одного запроса IRQ, то даже небольшая неточность с количеством выполняемых тактов в эмуляторе приведет к тому, что появится "лишнее" время и обработчик сработает лишний раз.

Поэтому есть предложение - проверить, правильно ли выполняется вызов прерывания. Нормальный порядок должен быть такой:
1) ставится запрос IRQ
2) процессор заканчивает ту инструкцию, которую выполняет сейчас
3) выполняется вызов обработчика. Вызов должен занимать 7 тактов (http://www.6502.org/tutorials/interrupts.html)
4) выполняется код обработчика
5) выход из обработчика происходит командой RTI, она должна выполняться 6 тактов

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

Обработчик IRQ РАПИРы должен делать несколько вещей:
- сохранить регистры
- проверить флаг B (?)
- в зависимости от флага:
- либо обработать ситуацию с программным прерыванием (по команде BRK): вывести что-то вроде "система в нестабильном состоянии, рекомендуется перезагрузка" и вернутся в командный режим.
- либо инкремент и проверка счётчика
- в зависимости от счётчика - переключение ДК
- восстановить регистры и сделать RTI

Так что код там может быть не маленьким.

А вот в бейсик-прогах и в бадеровских часах могут быть варианты: либо обработчик IRQ цепляется к цепочке обработчиков (вектора где-то в $3Fx) - тогда он будет заниматься только инкрементом счётчика. Либо он цепляется к векторам $FFFx и там тоже делает только инкремент (и тогда обработка BRK не работает).

Поэтому и проверять эмулятор надо на разных классах прог.

LDA #$BD
STA $1B7C
LDA $C710
...
DEC $1B7C
BNE $1B7B
STA $C70A

Как-то $BD (=189) маловато для совмещённого режима (~3/4 экрана)... 189/500=37.8%, чуть больше трети...

В правильно написанном обработчике - да, так и будет. Но очень легко все испортить, добавив в обработчик команду CLI, поскольку после ее выполнения при активном сигнале IRQ произойдет повторный вызов обработчика внутри обработчика. Такой пример мне уже встречался, и я его даже сдуру скопипастил в свою тестовую программу проверки прерываний. Почему-то мне показалось, что она там нужна. Видимо, повлияло знакомство с прерываниями на 8080 и 8086 - там автоматом запрет прерываний не ставится и все надо ручками делать.

1CCA: STA $45     3
      PLA         4
      PHA         3
      ASL         2
      ASL         2
      ASL         2
      BMI $1CD8   2
      LDA $45     3
      JMP $1800   3   
1800: JMP $1B73   3
1B73: DEC $1B7C   6
      BNE $1B7B   2/3
      STA $C70A   4/0
1B7B: RTI         6

Если счетчик !=0, то 42 такта + 7 тактов на вызов прерывания. Если происходит 26 вызовов за один запрос, получается в сумме 49*26 = 1274 такта, при длительности запроса 1024 такта. То есть, уже что-то не то.

Да, теперь всё правильно: Рапира переключает режим на 207 строке развёртки, так что 208 уже полностью текстовая.

Я старый больной пью! К тому же, похоже, это была шальная ошибка: у INC, например, всё правильно.

Но развёртка всё ещё прибита гвоздями к тактам ЦПУ.

Кстати, а были в реальной жизни турбированные Агаты, у которых проц работал на сильно другой частоте? Нужно ли это уметь эмулировать?

В книге Мымрина было написано что применяя 6502А и 6502В можно увеличить скорость работы Агата.

А модуль CPU с ошибкой это какой? Тот что предоставил Марат Файзулин?
https://fms.komkon.org/

Или модуль Олега?

Была плата высокоскоростного сопроцессора ( http://agatcomp.ru/Images/new_CPU/sp-1.jpg ). И вроде кто-то писал, что у нее была поддержка в НиппельОС. Но никаких подробностей про нее я не знаю.

Кстати, любопытно - на сайте написано, что процессор у нее питался от 12 вольт, но в обвязке все микросхемы стоят стандартные, 5-вольтовые. У процессора было отдельное питание ядра что-ли?

PPS Вопрос на подумать: что будет, если в начале NMI-обработчика выключить таймер, а в конце, перед RTI - включить ?

NMI:
      STA $C050
....
      STA $C040
      RTI

Сразу скажу: аппаратура таймера отрабатывает с точностью до такта ЦП.
Т.е. !NMI уже к следующей, после "STA $C050", команде будет в высоком уровне.

У меня получилось следующее:

$x08A5:: 
$x08A6:: 
$x08A7:: 
$x0040::                         C040
$x08A8:: NMI{0}  включили NMI , выполняем команду RTI
$x08A9:: NMI{1}  этот байт запрошен, но не используется ЦП
$x01EB:: NMI{2}  это обращение к стеку не используется никак, реально всё сохранено со следующего байта
$x01EC:: NMI{3}  выгребаем из стека адрес возврата и слово состояния
$x01ED:: NMI{4}  
$x01EE:: NMI{5}  
$x0CAB:: NMI{6}  пытались сделать выборку очередной команды, но так и не стали её выполнять
$x0CAB:: NMI{7}  
$x01EE:: NMI{8}   опять всё на стек
$x01ED:: NMI{9}  
$x01EC:: NMI{10}  
$x1FFA:: NMI{11}  NMI process{0}  
$x1FFB:: NMI{12}  

Нашел тут обсуждение ситуации, когда выполняющийся относительный переход приводит к задержке обработки прерывания (https://atariage.com/forums/topic/16855 … struction/). Может, с RTI что-то похожее?

Если я правильно понял, у семерки разрешение прерываний должно происходить по нарастающему фронту φ0. То есть, к следующей инструкции за STA $C040, процессор уже должен прерывание распознать.