Просмотр полной версии : Кадровые прерывания ( 50гц ).
Чую, что такой вопрос лучше задавать в разделе для начинающих. :smile:
В общем, я тут читаю о прерываниях процессоров каждые 20 миллисекунд и его важном сакральном значении для любого компьютера. И никак не пойму, зачем оно вообще нужно и что процессоры делают, получив это прерывание? Вроде бы дисплейная часть есть автомат, непрерывно генерирующий VSYN, HSYN, и в соответствии с ними выводящий содержимое памяти. И процессору по идее должно быть до лампочки, где в какой момент времени находится луч на экране. Для него экран это озу. Записанное процессором окажется на экране в любом случае, и всегда в нужном месте. Самое позднее, через 20 миллисекунд. Так зачем процессор дергать прерыванием от важных задач каждый кадр ?
В общем, пришел к выводу, что прерывания с частотой обновления экрана облегчают синхронизацию вывода на экран с другими нужными процессами. При этом, если прерывание приходит на процессор, но в какой-то программе не требуется его обрабатывать, можно ставить программную заглушку вместо обработки экранного прерывания (выход по RETI ).
Elvys, Процессору вообще ничего не нужно! Он мечтает побыстрее выполнить программу, и чтобы питание компьютера отключили. :)
Нужно это для ЗАДАЧ! Для тех задач, которые выводят быструю динамическую графику, без мерцания, глюков. Для извращений вроде рисования на бордюре и мультиколора.
Во вторую очередь это подсчёт времени, проигрывание звука, опрос клавиатуры и прочее. Ну, нету у спектрума других таймеров, а считать такты процессора обычно чересчур муторно и ненадёжно(у разных компьютеров возможны разные задержки, плюс бывает режим "турбо").
Упс... Т.е. если в спекки ввести RTC, то прерывания 50 гц потеряют актуальность в большинстве задач?
Вижу только одно дело, которое на левый таймер не повесить - синхронизация вывода на экран с другими задачами в системе. К примеру, оцифровка аналогового сигнала в реальном режиме времени и вывод графика на экран.
Elvys,
Обычное применение этого прерывания, это игры, так?
Не совсем так. Игры бывают разные, текстовых очень много, логических, и они запросто могли-бы обойтись без прерываний. Они его если используют, то просто потому что оно есть. С другой стороны, в графическом редакторе курсор мерцать не должен. В редакторе спрайтов просмотр анимации должен быть гладким. В музыкальном редакторе, музыка не должна дёргаться. И конечно ДЕМКИ! Демкам прерывание ещё чаще нужно, чем играм.
...читают с диска определенные *.мр3 файлы...
Да, всё так, только не mp3 файлы, а данные для AY-сопроцессора, и читаются заранее, а по прерыванию они расшифровываются и передаются в AY для проигрывания.
Я когда то сообщение написал, после этого ваше увидел. Ну и соответственно оно моментально потеряло актуальность. :) Отредактировал, а Вы уже ответить успели :)
Elvys, А, ничего страшного, может кому другому пригодится, пускай висит.
Я вот только уточнить хочу: пусть там программа использует прерывание чтоб у нее курсор не моргал, звук не хрипел и изображение сменялось плавно и равномерно. Но, у любого прерывания есть приоритет. И если совпадет во времени прерывание, имеющее более высокий приоритет и прерывание от кадров, то хочешь - не хочешь, а процессор его пропустит. Это может привести не только к спецэффектам но и к зависанию выполняющейся в данный момент программы. Как такие ситуации решаются?
Kakos_nonos
30.09.2015, 10:46
У спектрума только одно прерывание - кадровое. Других нет. Когда приходит прерывание, то происходит call на обрпботчик, выполняется код обработчика, потом ret и проодолжается выполняться основная программа.
null_device
30.09.2015, 10:56
у любого прерывания есть приоритет
Как бы - немаскируемые прерывания имеют более высокий приоритет.
Как такие ситуации решаются?
В спектруме весьма слабо реализована система многоуровневых прерываний.
Когда процессор получает прерывание, то если оно разрешено, нормальный ход исполнения программы прерывается и управление передается в специальную программу обработки прерываний. Место расположения этой обрабатывающей программы зависит от того, какой режим прерывания включен. Программа обработки прерывания прекращает свою работу, когда встречает специальную команду возврата, после чего управление вновь передается той программе, которая была прервана.
А еще подпрограмма обработки прерывания должна укладываться в количество тактов в прерывание.
У любого прерывания есть приоритет. И если совпадет во времени прерывание, имеющее более высокий приоритет и прерывание от кадров, то хочешь - не хочешь, а процессор его пропустит.
Пропустит может только если в интервале между прерываниями не будет времени у процессора на обработку (запретят прерывания надолго, либо будут приходить постоянно более приоритетные прерывания). Обычно будет откладываться по времени момент обработки прерываний и только когда их несколько учитывается приоритет (исключение вложенные прерывания).
Это может привести не только к спецэффектам но и к зависанию выполняющейся в данный момент программы. Как такие ситуации решаются?
У Z80 есть только два прерывания IRQ и NMI (последний на классическом спектруме не используется). Так что там попросту нет проблем с приоритетами - источник прерывания один: не обработали в этот раз, так прерывание придёт в следующий раз.
Когда прерываний физически несколько, то тут уже спасает выделенный для этих целей контроллер прерываний, в нем запоминает факт прерываний приходящих по фронту сигнала, учитывает приоритет и если нужно формируется вектор прерывания для процессора, по завершению обработки прерывания процессор контроллер прерываний получает сообщений об этом и внутри контроллера прерываний сбрасывается. В случае если по одному входу до обработки пришло несколько сигналов о прерывании, то такая ситуация фиксируется в программно доступных регистрах контроллера и/или формируется отдельное прерывание об этом в процессор.
Как бы, считал что у Z80 для прерывания используется вход INT а не NMI. Схема ленина (http://zxfiles.narod.ru/leningrad31/leningrad3.gif)тому подтверждение.
null_device
30.09.2015, 11:21
Elvys, как бы - эти два вывода учавствуют в работе процессора с прерываниями. Загляните в даташит:
INT Interrupt Bequest - Запрос прерывания
Вход. Активный уровень - низкий. Сигнал /INT, формируемый устройством ввода- вывода, анализируется в конце выполнения текущей команды. Запрос учитывается, если триггер прерываний (IFF1), управляемый программно, установлен в состояние "разрешить прерывании", и не активен сигнал /ВUSRQ
NMI Non Maskable Interrupt - Немаскируемый запрос прерывания
Вход, запускаемый отрицательным фронтом. Фронт запуска активизирует внутренний триггер NMI. Линия /NMI имеет более высокий приоритет, чем /INT и всегда распознается в конце выполнения текущей команды, независимо от состояния триггера разрешения прерываний. /NMI автоматически производит перезапуск (рестарт) ЦП с адрес 66H. Содержимое счётчика команд (адрес возврата) автоматически сохраняется во внешнем стеке. Т.о. пользователь может возвратиться к прерванной программе.
Я вот и свожу все к контроллеру прерываний (хоть спектруму и не светит). Есть RTC - это высший приоритет в системе, есть RS-232 , клавиатура, контроллер НГМД, монитор питания ( это уже обработка по NMI ), дисплей со своими кадровыми прерываниями... По логике, эти самые кадровые прерывания будут иметь низший приоритет в системе с контроллером приоритетных прерываний. И следовательно, иногда их обработка может быть пропущена.
Я вот и свожу все к контроллеру прерываний (хоть спектруму и не светит).
Ну, а для чего? :)
Чтобы научиться качаться на качелях не обязательно знать тензорное исчисление. Для того качели и сделаны, чтобы качаться и наслаждаться их простотой. :)
null_device
30.09.2015, 11:29
К сожалению, в ПЗУ «СПЕКТРУМА» в процедуре обработки немаскируемого прерывания «NMI» содержится грубая ошибка (кто знает - случайна ли она?), благодаря которой обработка «NMI» или приводит к рестарту компьютера с нулевого адреса, или не дает никаких результатов, производя обычный возврат в точку, откуда было вызвано прерывание.
Оно используется "волшебной кнопкой" BDI, при его наличии.
Я вот и свожу все к контроллеру прерываний
А еще "второе прерывание" используется таким девайсом, как AMX-mouse
Вообще, хотел только понять, в чем смысл иметь в компьютере прерывания с частотой обновления экрана и нельзя ли от них отказаться. Уяснил, что это прерывание очень нужное, что бы получить жесткий реалтайм при выполнении некоторых программ. Теперь вот пытаюсь понять, как быть с ситуациями, когда есть несколько прерываний с разными приоритетами и что делать что бы не терять прерывания.
Как то решалось же это на ibm pc xt....
null_device
30.09.2015, 11:54
Теперь вот пытаюсь понять, как быть с ситуациями, когда есть несколько прерываний с разными приоритетами
Таких ситуаций - на спектруме, в принципе не так, чтобы много.
Как то решалось же это на ibm pc xt
Специальным набором микросхем (для Z80 CPU это, вроде Z80 PIO).
что делать что бы не терять прерывания.
Не совсем понятно, что под этим подразумевается?
Не терять прерывания, это я о том, что скажем во время дисковых операций музыка не хрипела и картинка не тормозила. Т.к. прерывания от контроллера дисковода имеют более высокий приоритет и приходить будут часто. Пересылками то процессор занимается.
Как сказал бы ААА, прерывание нужно, чтобы VNN (помним тебя...) мог рисовать свои шедевры на бордюре... Таки да, другим путем это не сделать, даже если обвесить спектрум всякими контроллерами прерываний. Прерывание "начало кадра" - самое важное на свете :)
Не терять прерывания, это я о том, что скажем во время дисковых операций музыка не хрипела и картинка не тормозила. Т.к. прерывания от контроллера дисковода имеют более высокий приоритет и приходить будут часто. Пересылками то процессор занимается.
есть такая демка "condommed" там встроен самый лучший Дисковый драйвер с музыкой.
посмотри... не пожалеешь.
null_device
30.09.2015, 12:37
во время дисковых операций музыка не хрипела и картинка не тормозила
Работа оболочки tr-dos в отличном от "стандартного" режиме прерываний реализована на уровне - совсем никак.
Реализовать второй режим прерываний с работой tr-dos - возможна, но это "костыли" в чистом виде (что, в общем-то не помешало codebusters реализовать дему с процедурой чтения дискеты в реальном времени, да и ряду других программистов проделывать нечто подобное).
прерывания от контроллера дисковода имеют более высокий приоритет и приходить будут часто
Большим приоритетеом обладает только момент вызова через "волшебную кнопку".
Определитесь, что вас интересует: гипотетическое устройство с реализованной, развитой системой векторов прерывания; или спектруем - где подобный программно-аппаратный комплекс незадействован?
Вообще, хотел только понять, в чем смысл иметь в компьютере прерывания с частотой обновления экрана и нельзя ли от них отказаться. Уяснил, что это прерывание очень нужное, что бы получить жесткий реалтайм при выполнении некоторых программ. Теперь вот пытаюсь понять, как быть с ситуациями, когда есть несколько прерываний с разными приоритетами и что делать что бы не терять прерывания.
Как то решалось же это на ibm pc xt....
Это классические прерывание VSYNC, чтоб запускать процесс обновление изображения на экране, когда этом меньше всего будет приводить к видимым искажениям.
Просто на Спектруме это было вообще единственным прерыванием. И оно не для "жесткого реалтайма" (это уже потом особым шиком для мультколор эффектов использовали). По нему обрабатывались программные таймера (аппаратных ведь нет), сканировалась клавиатура и прочее...
Чтоб не терялись прерывания нужно увеличивать скорость обработки (повышать частоту процессора), уменьшать темп прерываний (использовать периферию с FIFO или с DMA доступом).
Так зачем процессор дергать прерыванием от важных задач каждый кадр ?
А ты не обязан его обрабатывать. Поставь RETI по 0x0038 или вообще запрети прерывания по DI.
Но любая задача, которая сводится к тому, что надо как-то реализовать два потока исполнения, неизменно приведёт к использованию этого прерывания.
А то, что оно приходит в начале отрисовки экрана - ну, так проще схемотехнически. А через несклолько лет существования спектрума, когда начали париться за красоту картинки и плавность, оказалось, что это ещё и удобно.
Сейчас смотрел схему "Ириши". Система прерываний там сделана через контроллер ВН59. Но с модуля графического дисплея на этот контроллер ничего не приходит. Получается покадровые прерывания там отсутствуют? Это вообще единственный советский бытовой компьютер, использующий контроллер приоритетных прерываний?
---------- Post added at 13:09 ---------- Previous post was at 13:00 ----------
To troosh:
Если я вас правильно понял, то на спектрум можно воткнуть произвольный генератор импульсов прерываний с известным интервалом и это будет работать вместо покадровых прерываний? Забудем на минутку о красивости бордюра и мультиколоре. Просто спеку нужен был хоть какой то таймер и в качестве его использовали покадровое прерывание?
Если я вас правильно понял, то на спектрум можно воткнуть произвольный генератор импульсов прерываний с известным интервалом и это будет работать вместо покадровых прерываний? Забудем на минутку о красивости бордюра и мультиколоре. Просто спеку нужен был хоть какой то таймер и в качестве его использовали покадровое прерывание?
Видимо всё так и есть.
Процессору пофик как и когда формируется прерывание.
Просто когда оно приходит - он бросает все дела и начинает исполнять код с заранее заданого адреса. Всё остальное - в руках программера.
Теперь точно разобрался. Покадрового прерывания может и не быть, но его удобно использовать что бы знать в какой момент времени начнется отрисовка кадра. И как следствие - рассчитать положение луча на экране в любой момент времени отображения одного кадра.
Сейчас смотрел схему "Ириши". Система прерываний там сделана через контроллер ВН59. Но с модуля графического дисплея на этот контроллер ничего не приходит. Получается покадровые прерывания там отсутствуют?
Не до жиру значит было, да и обычно в советских компьютерах про удобство работы с графикой/звуком в последнюю очередь думали.
Если я вас правильно понял, то на спектрум можно воткнуть произвольный генератор импульсов прерываний с известным интервалом и это будет работать вместо покадровых прерываний? Забудем на минутку о красивости бордюра и мультиколоре. Просто спеку нужен был хоть какой то таймер и в качестве его использовали покадровое прерывание?
Да, именно так.
Я тут подумал, как быть, когда прерываний несколько и контроллер прерываний ими командует. Длительность КСИ, она же примерно 110 микросекунд. Если КСИ подать на контроллер прерываний и настроить его на реагирование по уровню импульса, то для контроллера прерываний это будет означать длительность присутствия сигнала запроса прерывания равной длительности КСИ. Теперь, если любое другое прерывание с более высоким приоритетом будет обработано менее чем за время длительности КСИ, то запрос прерывания от кадровой потерян не будет. Z80 обрабатывает одну инструкцию за четыре такта и имеет, при частоте 4 Мгц, одну обработанную инструкцию в микросекунду. Таким образом, за время длительности сигнала КСИ можно выполнить до 100 инструкций. После чего успеть принять запрос прерывания от кадровой и обработать уже его. Если я верно понимаю принцип работы ВН59.
И как следствие - рассчитать положение луча на экране в любой момент времени отображения одного кадра.
Можно было-бы, если бы не куча клонов с разным временем отрисовки, медленной памятью и прочими радостями.
Так что от привязки к кадрам польза только одна - можно знать точно что отрисовка экрана началась. Все остальные эффекты прибиты к конкретным моделям...
можно обойтись и без IM2 (как например в игре renegade) там подвязка к чтению аттрибутов из несуществующего порта #FF, но это справедливо только для некоторых фирменных моделей.
также можно сделать привязку на im1 вместо im2 (только на машинах где есть ПЗУ с 128ым бейсиком)
blackmirror
20.10.2016, 10:32
Возник вопрос: какая длительность запроса кадрового прерывания? В EmuZWin путём экспериментов выяснено, что если EI поставить сразу за DI, то следующая команда не приводит к потерям прерываний если для её выполнения требуется не более 4х обращений к памяти, то есть LD HL,XXX или LD A,(XXX) прокатывает, а вот LD HL,(XXX) может привести к потере прерываний. Можно ли сделать чтобы запрос прерывания запоминался или как-то удлинить его скажем до 5 мс?
Spectramine
20.10.2016, 10:48
Возник вопрос: какая длительность запроса кадрового прерывания? В EmuZWin путём экспериментов выяснено, что если EI поставить сразу за DI, то следующая команда не приводит к потерям прерываний если для её выполнения требуется не более 4х обращений к памяти, то есть LD HL,XXX или LD A,(XXX) прокатывает, а вот LD HL,(XXX) может привести к потере прерываний. Можно ли сделать чтобы запрос прерывания запоминался или как-то удлинить его скажем до 5 мс?
Стандартная длительность импульса запроса прерывания для 48к моделей - 32/33 такта для early/late моделей. Для 128к - 36 тактов. Насколько я знаю, удлинить его можно только аппаратно, а запомнить - никак.
blackmirror
20.10.2016, 10:54
weiv, а если очень хочется использовать SP не по назначению, есть какой либо еще способ подсчитывать кадры кроме прерывания?
(вернее нужно подсчитывать не кадры, а время)
Spectramine
20.10.2016, 18:55
weiv, а если очень хочется использовать SP не по назначению, есть какой либо еще способ подсчитывать кадры кроме прерывания?
(вернее нужно подсчитывать не кадры, а время)
SP в смысле, что на стек кладутся возвраты и регистры во время входа в обработчик... Не знаю, ещё одним способом измерения времени может быть чтение порта FF, но это сложнее, и не будет работать даже на +2A/+3, не говоря уже об отечественных клонах. Проще таки использовать прерывания, а финты с SP оформлять строго в рамках времени между двумя импульсами прерывания.
blackmirror,
1. Подсчитывать такты процессора.
2. Всё таки использовать IM2, а порчу памяти сразу восстанавливать.
Вариантов восстановления много:
2.1 Если известен регистр, в который только что считалось из стека - использовать это:
org #bfbf
entrypoint $
ld (rethl+1),hl
pop hl
ld (retpc+1),hl
ld (retsp+1),sp
push bc ; восстанавливаем из bc
ld sp,IntStack
Push af
ld hl,IntCounter
L_001
inc(hl)
jp nz,IntExit
inc l
jp L_001
IntExit
pop af
retsp ld sp,0
rethl ld hl,0
retpc jp 0
IntStack equ #c000
IntCounter defb #ff,0,0,0,0,0,0,0 ; хватит на 11 млрд. лет
Как начать читать с помощью стека?
2.1.1 Перед блоком, который будем читать, иметь пару_байт, которые не жалко запортить.
2.1.2 Сделать DI: LD SP,BeginRead: POP BC: EI, и надеяться, что длинны прерывания хватит.
2.1.3 Сделать LD C,(HL):INC HL: LD B,(HL): INC HL: LD SP,HL
2.2 Хранить информацию для восстановления. (как в AMAUROTE)
В примитивном виде - держать в памяти две копии информации.
3. Хитрить дальше и изворачиваться сильнее. :)
blackmirror
21.10.2016, 00:03
Если известен регистр, в который только что считалось из стека - использовать это:
Этот чудесный код полностью решил проблему, хотя вместо EXX пришлось пользоваться IX/IY, теперь прерывания не запрещаются и не теряются.
2.1.2 Сделать DI: LD SP,BeginRead: POP BC: EI, и надеется, что длинны прерывания хватит.
В эмуляторе даже на DI: EI: LD HL,(MEM) длины прерывания не хватает - теряются.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot