Нетрадиционная обработка прерываний

[Alekcandr]

Посмотрел ещё раз схемы по ссылкам, сформулировал такие проблемы и риски:
1. если делать сигнал прерывания, снимаемый работой обработчика с устройством (обработчик пишет в порт, устройство снимает сигнал), то получается очень хрупкая архитектура - достаточно не обработать любое одно прерывание любым способом и обработчик будет вызываться после каждой команды, причём отключить программно это одно прерывание будет невозможно.
2. если делать сигнал прерывания, снимаемый уведомлением, формируемым аппаратно (по выставлению вектора на шину данных), то в принципе для отключения обработки достаточно поставить RETI по вектору.

По мне эти два способа жизнеспособны на 100%. От ZX до ОС реального времени.

По остальным способам надо схему в симуляторе рисовать, или схему паять. И проверять.

Может Z180 использовать? Там и много частоты, и периферия, и прерывания.

[masterspammer]

Посмотрел ещё раз схемы по ссылкам, сформулировал такие проблемы и риски:
1. если делать сигнал прерывания, снимаемый работой обработчика с устройством....
2. если делать сигнал прерывания, снимаемый уведомлением, формируемым аппаратно...

По мне эти два способа жизнеспособны на 100%. От ZX до ОС реального времени.

Жизнеспособны, мне больше второй нравится, первый имеет цену ошибки выше.

По остальным способам надо схему в симуляторе рисовать, или схему паять. И проверять.

Угу, вчера вечером в голову засунул идею, утром уже что-то вырисовалось.
Опишу так, на выходных порисую. Описание для одного сигнала:
1. на входе из сигнала берётся фронт (два D-триггера, тактируемые тем же синхросигналом, что и процессор, но в противофазе, дальше логический элемент, дающий импульс, когда уровень на входе сменится на активный - как тут http://www.junradio.com/nach/TTL/Part1/1-6.htm - там рис 1.56, только не XOR, а OR или AND, чтоб импульс был один), это будет установка для обычного RS-триггера.
2. выход RS-триггера (выходы всех таких триггеров на самом деле) выставляется на шину данных тем или иным способом (приоритетным шифратором как у Ориона Про или все биты сразу как я предлагал в первом сообщении).
3. по сочетанию !M1 !IORQ и тактового сигнала формируется сигнал подтверждения; важно чтоб этот сигнал никогда не был одновременно активен с сигналом cброса RS-триггера.
4. сигнал подтверждения тем или иным способом (на самом деле зависит от выбранного варианта в пункте 2 варианта) раскладывается на один или несколько сигналов подтверждения конкретного прерывания; сигнал подтверждения конкретного прерывания - сброс RS-триггера.

Теперь разобраться с фазами и выбрать микросхемы так, чтобы по максимуму использовать триггерные сборки, регистры, а не на ТМ2 собирать (получится, но будет очень много корпусов)

Может Z180 использовать? Там и много частоты, и периферия, и прерывания.

Не знаю, я пока настроился на Z84C0020 и может быть на KC80. Z180 совсем другой проц по железной части, насколько помню; ну и это не будет решением для Z80

[aav8]

Не обязательно делать отдельные триггеры на запрос
прерывания:
К примеру ВВ51 сама снимает запросы (RxRdy/TxRdy)
после записи/чтения регмстра данных.

[masterspammer]

Не обязательно делать отдельные триггеры на запрос
прерывания:
К примеру ВВ51 сама снимает запросы (RxRdy/TxRdy)
после записи/чтения регмстра данных.

Рассматривал такой случай (и держал в голове чтоб не потерять с ним совместимость), для ВВ51 просто, а вот если я хочу подать прерывание с произвольной схемы или кнопки, то придётся наворачивать именно то самое, а оставить неснятый сигнал - фатально. Если принимать сигнал по перепаду, то И его можно не снимать И подобные ВВ51 будут работать без изменений. (Конечно, можно сделать триггеры только там, где это требуется, если делать законченное устройство, то на ВВ51 триггер не нужен, а для контроллера/конструктора/микропроцессорного_стенда лучше подстраховаться).

[Alekcandr]

Посмотрел ещё раз схемы по ссылкам, сформулировал такие проблемы и риски:
1. если делать сигнал прерывания, снимаемый работой обработчика с устройством....
2. если делать сигнал прерывания, снимаемый уведомлением, формируемым аппаратно...

По мне эти два способа жизнеспособны на 100%. От ZX до ОС реального времени.

Жизнеспособны, мне больше второй нравится, первый имеет цену ошибки выше.

В этих двух вариантах ошибка может возникнуть при не правильной программной обработке прерывания (забыть о IN A,(n) или RETI). Такая же ошибка будет и с ВВ51. Необходима программная реакция на аппаратное прерывание (аппаратную маскировку прерывания пока не рассматриваем). По мне это правильно.

Опишу так, на выходных порисую.

Будем посмотреть

p.s. Можно почитать в z80-documented.pdf подробненько о этих двух способах.

[masterspammer]

...В этих двух вариантах ошибка может возникнуть при не правильной программной обработке прерывания (забыть о IN A,(n) или RETI). Такая же ошибка будет и с ВВ51.

Только в первом случае, во втором обработка аппаратная.

Необходима программная реакция на аппаратное прерывание (аппаратную маскировку прерывания пока не рассматриваем). По мне это правильно.

Именно обойтись без обязательности программной реакции и хочется. Чтоб поставил REТI и достаточно (прерывание не спамит). Как с NMI.

p.s. Можно почитать в z80-documented.pdf подробненько о этих двух способах.

Читал, не сказал бы, что как-то подробненько.

[Alekcandr]

Во 2-м случаи еще как спамит если заместо RETI сделать RET. Там (фирменное прерывание от Zilog) ведь аппаратный детект RETI на стороне источника прерывания c высшим приоритетом. А в 1-м случаи аппаратный детект IN A,(n) по порту n. Что в 1-м, что 2-м требуется специальная команда. Но то такое, если вы считаете по другому спорить не буду. Это как c Z180. Одни считают его микроконтроллером, другие процессором со встроенной периферией.

Читал, не сказал бы, что как-то подробненько.

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

[masterspammer]

Во 2-м случаи еще как спамит если заместо RETI сделать RET. Там (фирменное прерывание от Zilog) ведь аппаратный детект RETI на стороне источника прерывания c высшим приоритетом. А в 1-м случаи аппаратный детект IN A,(n) по порту n. Что в 1-м, что 2-м требуется специальная команда.

Во втором случае (и в обдумываемой схеме) подразумевал детекцию не RETI, а факта попадания вектора на шину (!IOREQ + !M1), если ловить RETI, то да. Но и в случае с RETI всёж легче "обработать" прерывание (по минимуму), даже не зная, кто его породил.

Самое смешное, что детектор RETI/RETN у меня в задумках есть...

Да уж куда подробней, все разжевано в отличие от фирменного мануала.

В контексте прерываний что там, что там минимум

Дальше только программный практикум

Скорее даже аппаратный - особенно bonus level - отловить факт обработки NMI.
Макетка, светодиоды, кнопки...

[Alekcandr]

Во втором случае (и в обдумываемой схеме) подразумевал детекцию не RETI, а факта попадания вектора на шину (!IOREQ + !M1), если ловить RETI, то да. Но и в случае с RETI всёж легче "обработать" прерывание (по минимуму), даже не зная, кто его породил.

Самое смешное, что детектор RETI/RETN у меня в задумках есть...

Я то думал в контексте Zilog, а если в обдумываемой схеме, то …

В контексте прерываний что там, что там минимум

Аж целый чаптер 5 Я этой брошюркой намного чаще пользуюсь, чем либо другим. Все компактненько и по делу.

[masterspammer]

В контексте прерываний что там, что там минимум

Аж целый чаптер 5 Я этой брошюркой намного чаще пользуюсь, чем либо другим. Все компактненько и по делу.[/quote]
Ну вот очень компактненько и многого просто нет.
Например, как понять, что процессор начал обработку NMI? Так и не нашёл.

[masterspammer]

Все компактненько и по делу.

Ну вот очень компактненько и многого просто нет.
Например, как понять, что процессор начал обработку NMI? Так и не нашёл.

[Alekcandr]

Например, как понять, что процессор начал обработку NMI? Так и не нашёл.

NMI у основной массы людей, и у Zilog ассоциируется с чем-то типа – ТРЕВОГА! Волк украл зайчат Вот и мало информации. Вон продвинутые программисты делали защиту от NMI на ZX. Там далеко не все сразу очевидно, да.

А так, как показа практика спустя много лет, вся эта не документированная инфа фигня (нет. упрощенный дизайн в силу существующей технологии в то время) сейчас вылазит боком. Приятно запустить сегодня на реале Z280 CP/M или MSX, где следовали официальной документации.

p.s. чего-то форум опять заглючело. фантомные посты.

[masterspammer]

NMI у основной массы людей, и у Zilog ассоциируется с чем-то типа – ТРЕВОГА! Волк украл зайчат Вот и мало информации. Вон продвинутые программисты делали защиту от NMI на ZX. Там далеко не все сразу очевидно, да.

Угу, а хотелось хотя бы watchdog сделать. И мне по определённым причинам нужно кровь из носу определить его срабатывание, иначе не выходит (адрес 66h будет не на той странице).

упрощенный дизайн в силу существующей технологии в то время

О, да! Один регистр переключения банков в ZX128 чего стоит (можно только 8 банков, бит выше занят другим, хотя есть и неиспользуемые биты - при простой перестановке можно было бы потом сделать 32 банка, но нет, пусть там видеостраница переключается), ну или "прерывания" в Радио-86РК...

p.s. чего-то форум опять заглючело. фантомные посты.

Я редактировать хотел, но получилось хуже.

[masterspammer]

Так... порисовал эпюры, схему прикинул (вариант из изначального поста с прямой подачей). Выходит сложновато, но релизуемо. Самое муторное - приведение "диких" сигналов к требуемой синхронизации и выделение фронтов. "Диких" это значит чёрт-те откуда, с шумами и дребезгом.

С другой стороны, модуль получается изолированный (входы и подтверждения прерываний, !M1, !IORQ, CLK, выход на шину данных) можно сделать на в виде отдельной платки. К вечеру схему отсканирую (ну и ещё посмотрю глазами) и выложу.

Сейчас главный вопрос для меня в том, чего я хочу больше - программируемого приоритета (и заплатить за это числом прерываний) или как раз их числа. Сделать 5-7 программируемых или 10 с фиксированным приоритетом (это если взять ИВ3). Режим прерываний явно IM2 - не хочу терять RST.

[masterspammer]

Вот схема; пояснения - красным показаны сигналы прерывания, в итоге преобразуемые в INT_S; "обработка" выделена зелёным, INT_R - сброс триггеров, важно, что INT_S и INT_R невозможны одновременно; защёлка в ИР23 - по окончанию !M1 (возможно её надо задержать добавлением 1-2 лог. элемента для работы на высокой частоте).

Верхний вариант - несколько (до 7) сигналов проходят через "очищающие" регистры на входе (какие именно - зависит от числа каналов и имеющихся микросхем - ТМ9, ИР23) и по фронту устанавливают каждый свой RS-триггер, далее защёлкиваются в регистр и выдаются как есть на шину данных, вместе с регистром I образуя вектор; во время выставления по сигналу INT_R они сбрасывают каждый свой RS триггер через "прозрачный" регистр ИР40 (можно применить ЛП4, ЛП6, да хоть сборку инверторов с третьим состоянием).

Ниже - вариант с приоритетным шифратором (изменяемый фрагмент) - защёлкивается уже номер прерывания, а по сигналу INT_R сбрасивается один триггер по расшифрованному коду.

Схема сброса не показана.