nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 01:31



Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3  Next
i8080: возможно ли реализовать прерывания без доп. обвязки? 
Author Message
Senior
User avatar

Joined: 17 Jun 2014 04:29
Posts: 126
Location: 93.80.157.217
Reply with quote
Lavr wrote:
vital72 wrote:
Но всеж таки, основная загадка, почему в стек заносится код команды, а не адрес возврата.

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


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


26 Jul 2014 12:40
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
vital72 wrote:
вообще то разрешены, гляньте дамп, там есть эта команда (EI), исходник
я вбивал ручками по коду и тупо пропустил команду

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

Image

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


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

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

_________________
iLavr


26 Jul 2014 13:04
Profile
Senior
User avatar

Joined: 17 Jun 2014 04:29
Posts: 126
Location: 93.80.157.217
Reply with quote
Post 
есть пять процессоров: два intel p8080a, два intel p8080a-1 и один nec d8080afc - на всех одно и тоже.


27 Jul 2014 04:36
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Post 
vital72 wrote:
есть пять процессоров: два intel p8080a, два intel p8080a-1 и один nec d8080afc - на всех одно и тоже.

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

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

_________________
iLavr


27 Jul 2014 04:46
Profile
Doomed

Joined: 25 Aug 2009 07:02
Posts: 459
Location: Москва
Reply with quote
Post 
А я бы осциллографом посмотрел, что ВИ53 выдает в режиме 0 при записи в счетчик числа 0.


27 Jul 2014 16:11
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Mixa64 wrote:
А я бы осциллографом посмотрел, что ВИ53 выдает в режиме 0 при записи в счетчик числа 0.

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

_________________
iLavr


28 Jul 2014 03:04
Profile
Writer

Joined: 19 May 2014 03:47
Posts: 17
Location: Челябинск
Reply with quote
Post Re:
vital72 wrote:
и asm:
Code:
        lxi     sp,0500h       ;  указатель стека


И вот что в стеке в результате:
Code:
04F0: 00 00 00 00 00 00 9A BC 56 78 12 34 02 00 C4 C3



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


15 Apr 2015 14:02
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
vital72 wrote:
По задумке прерывания будет слать таймер, вектор прерывания
будет всегда один - 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! :wink:

_________________
iLavr


27 Apr 2017 18:09
Profile
Doomed

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


28 Apr 2017 04:23
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Mixa64 wrote:
...при прерывании читался код C3 C3 C3 (что есть це-три на C3C3), а по адресу 0C3C3H читался уже 0FFH. Это и объясняет, почему в стек записывалось 0C3C4H.
А сам код 0C3Н в момент INT откуда на шинах возникал?

_________________
iLavr


28 Apr 2017 04:49
Profile
Doomed

Joined: 25 Aug 2009 07:02
Posts: 459
Location: Москва
Reply with quote
Lavr wrote:
Mixa64 wrote:
...при прерывании читался код C3 C3 C3 (что есть це-три на C3C3), а по адресу 0C3C3H читался уже 0FFH. Это и объясняет, почему в стек записывалось 0C3C4H.
А сам код 0C3Н в момент INT откуда на шинах возникал?

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


28 Apr 2017 05:49
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Mixa64 wrote:
у автора было, после инициализации вечный JMP на себя, C3 1C 00 по адресу 001CH. Если не отделить цикл чтения от цикла приема команды прерывания, то при прерывании на команде C3 она же многократно и прочитается.

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

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

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

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

_________________
iLavr


28 Apr 2017 06:02
Profile
Doomed

Joined: 25 Aug 2009 07:02
Posts: 459
Location: Москва
Reply with quote
(хм, а как в Радио-86РК было? Там прерывания изначально не задумывались, поэтому можно было и одним DBIN как стробом чтения обойтись).
У Z80 цикл приема вектора/команды прерывания индицируется необычным сочетанием сигналов, M1 вместе с IORQ вроде..Так что там если и есть грабли, то другого свойства.


28 Apr 2017 06:26
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Mixa64 wrote:
У Z80 цикл приема вектора/команды прерывания индицируется необычным сочетанием сигналов, M1 вместе с IORQ вроде..

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

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

_________________
iLavr


28 Apr 2017 06:41
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
когда i8080 обслуживает прерывание последвательность действий такая:
шина адреса - в высокоимпедансном состоянии, подается строб чтения DBIN, и с шины данных
считывается либо код RST0...RST7, либо CALL ADDR.
При этом системный контроллер 580ВК28(38) или его аналог превращает строб чтения DBIN
процесора в сигнал INTA - по сути это строб чтения из "контроллера прерываний".

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

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

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

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

_________________
iLavr


28 Apr 2017 09:00
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 45 posts ]  Go to page Previous  1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.