Emu80 v.4

[Pyk]

DemonId7, см. почту.

Слепил наспех отображение в отладчике адреса последней
выполненной команды DI и состояние стека при этом.
На случай, если еще кому-то вдруг понадобится:

http://emu80.org/v4beta/Emu80qt_40341_test.exe.zip

[Advertiser]

[ivagor]

в моем коде нет ни одного байта с кодом 0xF3.

Чисто теоретически можно представить вариант запрета прерываний и без DI. Вход в обработчик по прерыванию и нештатный выход из него без EI.

[DemonId7]

Слепил наспех отображение в отладчике адреса последней
выполненной команды DI и состояние стека при этом.

Указывает на подпрограмму чтения состояния жесткого диска из ПЗУ контроллера, в стеке тоже сплошь адреса из того же ПЗУ (видимо команды на чтение сектора). Бряк на этот адрес результата не дает, прерывания исчезают, а всплытия по бряку нет.
Остается вариант аварийного завершения RST 7. Интересно, чего же я такого слепил, что даже прошитый в ПЗУ обработчик прерывания вылетает

Чисто теоретически можно представить вариант запрета прерываний и без DI. Вход в обработчик по прерыванию и нештатный выход из него без EI.

Да, только это и остается.

[ivagor]

Извините, вклинюсь, раз речь зашла о совместимости пзу ПК8000 с z80. Раньше патчил основное пзу, но его вряд ли кто будет менять, а в этом году переделал под внешнее. Только такой вариант не совместим с другими внешними пзу, например досами, что весьма печально. Собирался подумать на эту тему, но так и не собрался, выкладываю как есть. Кроме совместимости с z80 здесь поправлена маленькая математическая неточность/особенность. В комплекте конфиг для emu, но думаю легко переделать и под emu80 по аналогии.

[ivagor]

Например можно запоминать адрес, где произошел последний запрет прерывания и "тип" запрета - DI или вход в обработчик. Когда зависли - смотрим, кто запретил.

[Pyk]

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

[DemonId7]

Нашёл ошибку. В модуле CP/M BIOS обработчик rst 7. Я его практически полностью срисовал с оригинального МДОС (что на дискетах). Там на входе проверяется последний байт, откуда был вызван обработчик, и если он равен 0xFF, то происходил выход из обработчика, без вызова обработчика в ПЗУ и без разрешения прерываний. Когда приходило прерывание на команде mvi L,0xFF, то и исчезали прерывания.
Никогда не знал для чего эта проверка. Теперь знаю - чтобы мозги пудрить
Походу будет очередной релиз CP/M.

Pyk, спасибо за помощь.

[ivagor]

проверяется последний байт, откуда был вызван обработчик, и если он равен 0xFF, то происходил выход из обработчика, без вызова обработчика в ПЗУ и без разрешения прерываний

Похоже на "пропуск" команды rst 7, но на следующий вопрос - "а зачем?" нужно разбираться (в чем вряд ли есть смысл).

[Pyk]

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

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

Упс, ivagor меня опередил

[svofski]

Pyk, кстати на заметку -- недавно столкнулся с этим, вдруг пригодится для RPi. Запускал v06x на андроиде. И вот на одном телефоне все хорошо, а на другом, более древнем, при включенном аудио-фильтре хрюкает и тормозит. Фильтр мудреный, 100 отводов, с simd инструкциями завернутыми в страшный темплейтный код, кто его знает.. Убираю вычислительную часть фильтра, ничего не улучшается. И тут я заметил, что смещение входного буфера, в который семплы складываются по 1.5e6 штук в секунду, увеличивается выражением вроде i = (i + 1) % sizeof buffer.

На современных x86/amd64 этого вообще не заметишь. А на ARM %, в зависимости от тыщи параметров, может компилироваться в библиотечный вызов даже с -O3. И тогда один целочисленный % 1500000 раз в секунду легко перевешивает умножитель-сумматор с плавающей точкой с сотней отводов, но 48000 раз в секунду. Переделал на обычную проверку на переполнение и все стало быстро, а вычислительная часть фильтра выполняется практически незаметно.