DemonId7, придумаем что-нибудь. Проще всего прямо в код добавить проверку и сделать специальную сборку, могу попробовать вечером.
Для очистки совести спрошу только: проблема воспроизводится на реале? У меня в эмуляторе была ошибка, которая как раз проявлялась в том, что в редких случаях самопроизвольно запрещались прерывания. Вроде бы я ее исправлял уже, но мало ли...
- - - Добавлено - - -
Еще один вариант проверки, кстати: поменять процессор в конфиге на z80 и проверять командой ld a, i.
Проблема есть и на реале, "зависание" в любой момент времени, непредсказуемое и непонятное (точнее бесконечный опрос буфера клавиатуры, который без прерываний никогда не заполнится). Если в отладчике ручками добавить в буфер клавиатуры что-то, то программа без проблем работает дальше и даже могут опять появиться прерывания. То есть, это не порча кода, не джампинг в неизвестность, а "просто" исчезают прерывания, скорее всего где-то в недрах BIOS "Суры". Понятно, что это как-то связано с моим кодом, но вот как - пока даже представить не могу. Чертовщина какая-то
Просто заменить процессор не получится, там нужно BIOS патчить. Кажется товарищ ivagor этим когда-то занимался. Меня это не устраивает, поскольку проблемы скорее всего как раз во взаимодействии с биосом "Суры" - в моем коде нет ни одного байта с кодом 0xF3.Сообщение от Pyk
Извините, вклинюсь, раз речь зашла о совместимости пзу ПК8000 с z80. Раньше патчил основное пзу, но его вряд ли кто будет менять, а в этом году переделал под внешнее. Только такой вариант не совместим с другими внешними пзу, например досами, что весьма печально. Собирался подумать на эту тему, но так и не собрался, выкладываю как есть. Кроме совместимости с z80 здесь поправлена маленькая математическая неточность/особенность. В комплекте конфиг для emu, но думаю легко переделать и под emu80 по аналогии.
DemonId7, см. почту.
Слепил наспех отображение в отладчике адреса последней
выполненной команды DI и состояние стека при этом.
На случай, если еще кому-то вдруг понадобится:
http://emu80.org/v4beta/Emu80qt_40341_test.exe.zip
Чисто теоретически можно представить вариант запрета прерываний и без DI. Вход в обработчик по прерыванию и нештатный выход из него без EI.
Указывает на подпрограмму чтения состояния жесткого диска из ПЗУ контроллера, в стеке тоже сплошь адреса из того же ПЗУ (видимо команды на чтение сектора). Бряк на этот адрес результата не дает, прерывания исчезают, а всплытия по бряку нет.
Остается вариант аварийного завершения RST 7. Интересно, чего же я такого слепил, что даже прошитый в ПЗУ обработчик прерывания вылетает
Да, только это и остается.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
DemonId7, завтра попробую сотворить что-нибудь для отлавливания такого случая...
Например можно запоминать адрес, где произошел последний запрет прерывания и "тип" запрета - DI или вход в обработчик. Когда зависли - смотрим, кто запретил.
Ну да. А если это был вход в обработчик, то на входе запоминать адрес стека, ждать выход и в случае выхода с запрещенными прерываниями вываливаться в отладчик.
Нашёл ошибку. В модуле CP/M BIOS обработчик rst 7. Я его практически полностью срисовал с оригинального МДОС (что на дискетах). Там на входе проверяется последний байт, откуда был вызван обработчик, и если он равен 0xFF, то происходил выход из обработчика, без вызова обработчика в ПЗУ и без разрешения прерываний. Когда приходило прерывание на команде mvi L,0xFF, то и исчезали прерывания.
Никогда не знал для чего эта проверка. Теперь знаю - чтобы мозги пудрить
Походу будет очередной релиз CP/M.
Pyk, спасибо за помощь.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
