i8080: возможно ли реализовать прерывания без доп. обвязки?

[vital72]

Но всеж таки, основная загадка, почему в стек заносится код команды, а не адрес возврата.

Для меня бОльшая загадка, почему в принципе прерывания срабатывают, в то время, когда они не разрешены ни одной командой EI с момента старта процессора.

вообще то разрешены, гляньте дамп, там есть эта команда, исходник я вбивал ручками по коду и тупо пропустил команду

[Lavr]

вообще то разрешены, гляньте дамп, там есть эта команда (EI), исходник
я вбивал ручками по коду и тупо пропустил команду

Ну это уже легче! А то прямо головоломка!



А временно заменить процессор на другой - нет возможности?


PS. И я вот еще думаю - а не вывести ли адрес возврата просто на индикаторы?

Code: Select all

   ORG 0038H

   POP H
       H - на индиктор
       L - на индиктор
   HLT

[vital72]

есть пять процессоров: два intel p8080a, два intel p8080a-1 и один nec d8080afc - на всех одно и тоже.

[Lavr]

есть пять процессоров: два intel p8080a, два intel p8080a-1 и один nec d8080afc - на всех одно и тоже.

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

Регистры-то в стек залетают правильно, значит "залипания" шин вроде не должно быть...

[Mixa64]

А я бы осциллографом посмотрел, что ВИ53 выдает в режиме 0 при записи в счетчик числа 0.

[Lavr]

А я бы осциллографом посмотрел, что ВИ53 выдает в режиме 0 при записи в счетчик числа 0.

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

[Bronto]

и asm:

Code: Select all

        lxi     sp,0500h       ;  указатель стека

И вот что в стеке в результате:

Code: Select all

04F0: 00 00 00 00 00 00 9A BC 56 78 12 34 02 00 C4 C3

У вас в верхушке стека адрес возврата 00с4 - случайный адрес выполнения в момент прерывания. А с3 - это мусор. Счётчик стека, перед сохранением адреса, декрементируется.

[Lavr]

По задумке прерывания будет слать таймер, вектор прерывания
будет всегда один - RST 7 (0ffh), формируется резисторами.

А вот, оказывается, в простейших системах, где не используется 580ВК28(38) или иная схема,
выполняющая фунции системного контроллера, с этим простым схемным решением RST 7
возможна очень трудно отслеживаемая засада...

И дело вот в чем: когда i8080 обслуживает прерывание последвательность действий такая:
шина адреса - в высокоимпедансном состоянии, подается строб чтения DBIN, и с шины данных
считывается либо код RST0...RST7, либо CALL ADDR.
При этом системный контроллер 580ВК28(38) или его аналог превращает строб чтения DBIN
процесора в сигнал INTA - по сути это строб чтения из "контроллера прерываний".
В этом случае трюк с резисторами = RST 7 работает хорошо, т.к. сигнал DBIN
перенаправлен в INTA, а сигналы чтения памяти MEMRD или чтения УВВ IORD
априори не активны.
И даже если никакого "контроллера прерываний" нет, то получается, что код 0FFH на шину
выдают только резисторы! И никакой другой источник не активизирован!

А теперь смотрим, как это сработает в простой системе: шина адреса - в высокоимпедансном состоянии,
но на шине адреса обычно какой-либо простой дешифратор пространства памяти подвешен!
Адресная шина от него отключилась и в хорошем случае, если на шинах никаких мешеющих
сигналов нет, и сам дешифратор типа ТТЛ, он понимает эту ситуацию, как если у него на
входе логические единицы и активизирует свой старший вывод - тем самым выберет устройство,
находящееся по старшему адресу!
И тут наш процессор выдает сигнал DBIN, который в простых системах просто поступает
на вса БИС памяти и БИС УВВ, включенные, как ячейки памяти...
Ясное дело, что никакого RST 7 от резисторов по 10К может и не произойти.

Забавно, что столкнулся с этим, отлаживая аналог Галаксии на КР580ВМ80А! Даже смешно стало -
там где "резисторы" пришлось изображать двумя шинными формирователями - никаких сбоев нет,
поскольку усложненная схема корректно их переключает.
Как только перешел в Proteus, который "понимает" притяжку резисторами, начали наблюдаться сбои...

Меня очень смущало, что в моем реальном "Специалисте МХ" трюк с резисторами работал без проблем!
Получается, что там в момент прерывания дешифратор срабатывал на порт 0FFFFH, а по логике
дешифрации "Специалиста МХ" на этом адресе нет ничего! Значит ничто и не мешало на шине
данных резисторам сформирвать код 0FFH, не смотря на активный DBIN!

[Mixa64]

А вот, возвращаясь к изначальному вопросу, еще раз глянул и, вроде, ответа так и не нашлось. А дело обстояло, похоже, таким образом, что при прерывании читался код C3 C3 C3 (что есть це-три на C3C3), а по адресу 0C3C3H читался уже 0FFH. Это и объясняет, почему в стек записывалось 0C3C4H. Косяк, (не, косячище!!), но забавный.
P.S. Да, ну и NOPы вставленные тоже объясняет, при прерывании с ШД читается тот же NOP и на этом всё, т.е. ничего не происходит.
P.P.S. Подтяжками против ОЗУ бороться сложно. ОЗУ если может, то всегда побеждает. Ежели таки его забороть, то это будет вечная подтяжка, и ОЗУ из схемы исключаем, как уже излишество.

[Lavr]

...при прерывании читался код C3 C3 C3 (что есть це-три на C3C3), а по адресу 0C3C3H читался уже 0FFH. Это и объясняет, почему в стек записывалось 0C3C4H.

А сам код 0C3Н в момент INT откуда на шинах возникал?

[Mixa64]

...при прерывании читался код C3 C3 C3 (что есть це-три на C3C3), а по адресу 0C3C3H читался уже 0FFH. Это и объясняет, почему в стек записывалось 0C3C4H.

А сам код 0C3Н в момент INT откуда на шинах возникал?

А у автора было, после инициализации вечный JMP на себя, C3 1C 00 по адресу 001CH. Если не отделить цикл чтения от цикла приема команды прерывания, то при прерывании на команде C3 она же многократно и прочитается. Это предположение. Думаю, мало кто проверял, потому что мало кто допускал такие косяки, типа читаем из ОЗУ по DBIN без вариантов. У меня предположение, что мегакосяк именно в этом, не отделено Memory Read от INTA.

[Lavr]

у автора было, после инициализации вечный JMP на себя, C3 1C 00 по адресу 001CH. Если не отделить цикл чтения от цикла приема команды прерывания, то при прерывании на команде C3 она же многократно и прочитается.

Очень похоже на правду, иначе совсем непонятно откуда 0C3H = 1100.0011b берется на шине.

Т.е. приходит INT, а в этой простой схеме по DBIN читается именно 0C3H из памяти,
поскольку не сделан DBIN --> INTA, а значит читается память.

Я в своей схеме задумался, что надо отслеживать на одиноком триггере бит D0 из STATUS,
и если он активен - глушить DBIN вентилем. Всё равно DBIN приходится инвертировать...

Кстати, а я вот не знаю, как поступает z80 в аналогичной ситуации?

[Mixa64]

(хм, а как в Радио-86РК было? Там прерывания изначально не задумывались, поэтому можно было и одним DBIN как стробом чтения обойтись).
У Z80 цикл приема вектора/команды прерывания индицируется необычным сочетанием сигналов, M1 вместе с IORQ вроде..Так что там если и есть грабли, то другого свойства.

[Lavr]

У Z80 цикл приема вектора/команды прерывания индицируется необычным сочетанием сигналов, M1 вместе с IORQ вроде..

Ну это "необычное сочетание сигналов" где-то тут нашли и разобрали что к чему...

А мне интересно в каком состоянии у него в этот момент ноги /RD и /WR -
я посмотрел - в нашей модели Z80 под Proteus коллеги как бы даже переводят
их в высокоимпедансное состояние - так ли это в реале?

[Lavr]

когда i8080 обслуживает прерывание последвательность действий такая:
шина адреса - в высокоимпедансном состоянии, подается строб чтения DBIN, и с шины данных
считывается либо код RST0...RST7, либо CALL ADDR.
При этом системный контроллер 580ВК28(38) или его аналог превращает строб чтения DBIN
процесора в сигнал INTA - по сути это строб чтения из "контроллера прерываний".

Вобще говоря, состояние шины адреса в момент обслуживания прерывания в большинстве источников
почему-то умалчивается... (только что глянул в Шахнова).

Но есть источники, утверждающие, что в момент обслуживания прерывания ША еще и активна:

Асинхронный сигнал высокого уровня ЗПР может появиться в любой момент цикла выполняемой команды. Поэтому внутренняя схема управления должна синхронизировать внешний запрос и установить соответствие с сигналами системной синхронизации, обеспечивая завершение выполнения текущей команды. В последнем такте последнего машинного цикла всех команд, кроме команды EI, при действии сигналов ЗПР=1 и РПР=1 по нарастающему фронту сигнала Ф2 устанавливается внутренний триггер прерывания. Это приводит к тому, что следующим тактом оказывается такт Т1 машинного цикла М3 (подтверждение прерывания). Он напоминает цикл М1 - выбора кода операции, так как в байте состояния установлен бит D5, но одновременно устанавливается и бит прерывания D0, который подтверждает восприятие микропроцессором запроса на прерывание, а бит D7 - считывание из памяти - сбрасывается.

В такте Т1 (рис. 3) МП выдает на шину адреса содержимое счетчика команд PC, а на шину данных - байт состояния, соответствующий циклу М3. В том же такте по нарастающему фронту сигнала Ф2 с максимальной задержкой 200 нс формируется низкий уровень на выводе РПР.

-----------------

Следовательно, МП будет игнорировать последующие запросы на прерывание до тех пор, пока триггер разрешения прерываний не будет установлен командой EI. В такте Т2 генерируется сигнал считывания ПМ, который в обычном цикле М1 вводит код операции из программной памяти в регистр команд. Но в цикле МЗ обращение к программной памяти запрещено (бит D7 равен 0), поэтому код операции должен быть сформирован подсистемой прерываний. Заметим, что в такте Т1 цикла МЗ инкремент PC не производится (формируется внутренний сигнал запрещения выхода схемы инкремента), поэтому в нем сохраняется адрес команды, которая выполнялась бы при отсутствии прерывания. Кроме того, в такте Т2 сбрасывается внутренний триггер прерывания.