Вместо HALT

[Barmaley_m]

если у тя вся машина в твоем распоряжении то да
а если тебе выделило какойто время некоторая многозадачная ОС то уже не совсем...

Автор исходной программы не использовал такую ось.

А вообще в многозадачных осях пользовательскому коду строго запрещено разрешать или запрещать прерывания. В процессорах с MPU инструкции вроде DI или CLI являются привилегированными, так что этот запрет реализуется принудительно. При написании драйверов принудительного ограничения нет, но все равно надо следовать документации на ось, иначе драйвер будет глючным.

Если автор драйвера считает необходимым нарушить запрет на изменение состояния прерываний - то лучше ему подумать еще раз, а надо ли. Зачем это может быть надо? Варианта два:
1) блокировка многопоточного доступа к данным. Вместо запрещения прерываний следует пользоваться функциями блокировки, предоставляемыми осью, например, KeAcquireSpinLock в случае винды;
2) обеспечение исполнения критичного по времени кода. Снова-таки, либо ось может быть для этого по определению не предназначена, либо в ней должны быть функции, фактически запрещающие или разрешающие прерывания, но автору драйвера до этого не должно быть дела, его задача - вызвать нужные функции и полагаться на их работу.

Это общие принципы построения осей, им следуют как минимум крупные оси, а мелкие - тут все зависит от компетентности их авторов.

[Advertiser]

[Spectramine]

Ну, вроде, разобрались - разработчики пофиксили баг LD A,R в CMOS Z80 очень мощно - после LD A,R/LD A,I не может произойти прерывание (как после EI во всех Z80), а в Кае длительность INT - два цикла M1, как раз на одну команду LD A,R.

- - - Добавлено - - -

Так что и из-за процессора и из-за Кая, комплексно.

[SoftFelix]

после LD A,R/LD A,I не может произойти прерывание (как после EI во всех Z80), а в Кае длительность INT - два цикла M1, как раз на одну команду LD A,R.

Это можно отловить программно для доработки теста? В Тесте INT'а Ковалевского, у меня длительность ровно на границе Мало-Норма.

[Spectramine]

Это можно отловить программно для доработки теста? В Тесте INT'а Ковалевского, у меня длительность ровно на границе Мало-Норма.

Так оно ж программно и отлавливается - если тест виснет, это показатель того, что INT надо фиксить, или будут и в играх проблемы.
Тут вроде как не тест надо дорабатывать, а Кай - 2 цикла M1 на INT это явно маловато. В стандартном спеке длительность INT 32 такта, если брать по 4 такта на цикл M1 - это 8 циклов M1 надо.

Слегка поправил тест - поставил время проверки 2 секунды, и предупреждение, что, если программа виснет, INT проблемный:CMOSz80tst.zip

[shurik-ua]

В стандартном спеке длительность INT 32 такта

а почему нигде не используется схема подтверждения прерывания по даташиту на проц z80 ? - а именно INT_ACK = /IORQ OR /M1.

[Barmaley_m]

а почему нигде не используется схема подтверждения прерывания по даташиту на проц z80 ? - а именно INT_ACK = /IORQ OR /M1.

В "Орель БК-08" используется такая схема. Никаких проблем, проц никогда не "просыпает" INT, потому что во время действия сигналов M1, IORQ прерывание уже подтверждено. С другой стороны, если подтверждение прерывания не приходит в течение около 25 тактов (при запрещеных прерываниях) - то запрос снимается до следующего кадра. Возможно, в Spec256 нет автоснятия запроса, из-за этого пропущенное прерывание срабатывает сразу после EI.

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

[Spectramine]

Так оно ж программно и отлавливается - если тест виснет, это показатель того, что INT надо фиксить, или будут и в играх проблемы.
Тут вроде как не тест надо дорабатывать, а Кай - 2 цикла M1 на INT это явно маловато. В стандартном спеке длительность INT 32 такта, если брать по 4 такта на цикл M1 - это 8 циклов M1 надо.

Слегка поправил тест - поставил время проверки 2 секунды, и предупреждение, что, если программа виснет, INT проблемный:CMOSz80tst.zip

@goodboy выявил несовершенство моего теста - на его сером +2 тест то выдавал ошибку процессора, то не выдавал. Не выставил начальный TStates при заходе в тестовый цикл, и при определенных условиях за 2 секунды ошибка проца ни разу не ловилась. Исправил тест, если кому интересно:Z80CMOStst2.zip

[goodboy]

при определенных условиях

ещё и `снег` на экране появлялся (комп подключал к телеку по ВЧ - качество было неважное),
хотя вот он в эмуле (и в новом варианте теста тоже снежит)

[SoftFelix]

а в Кае длительность INT - два цикла M1, как раз на одну команду LD A,R.

Я так понимаю, что эту длительность задаёт комбинация на входах D0...D3 сдвигового регистра. D1 и D2 посажены на GND. Это и задаёт длительность INT'а в два цикла /M1? А сколько это в тактах?



Вот что на КАЕ показывает Тест INT'а Ковалевского. В ТУРБО-неТУРБО длительность всегда одинаковая и находится ровно на границе МАЛА-НОРМА. Когда-то давно комрад Шепелёв (насколько я помню) опубликовал в журнале "Радиолюбитель" тест длительности INT'а. Там давалась норма 28...32 тактов процессора. На КАЕ сейчас данный тест во всех режимах показывает "Too short!".

ТУРБО включено.


ТУРБО выключено.


Ближе.


Я так понимаю, что если INT чуть удлинить, то проблема с подвисанием уйдёт? На вскидку 5-ую ногу регистра отцепляем от +5В и сажаем на GND. Железячники тут есть? Ход мысли правильный (с ответом можно переместится в эту тему)?

[vlad]

а почему нигде не используется схема подтверждения прерывания по даташиту на проц z80 ? - а именно INT_ACK = /IORQ OR /M1.

Потому, что так проц INT# не пропустит (если в схеме триггер используется), да и не все игры корректно работают, например в Cybernoid играть становится труднее, игра делается что-ли динамичнее. Поначалу понять не мог в Spec256 в чём дело, пока не убрал INTA# и не вернул стандартную длительность INT# и автоматом сразу добавилась проблема в турбо, нужно эту длительность ещё в разы удлинять для турбо, из-за проблем работы игр.