Emu80 v.4

[ivagor]

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

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

[Pyk]

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

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

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

[DemonId7]

В оригинальном коде видны следы другого кода, в частности попытка останавливать мотор дисковода по таймеру. Рискну предположить, что и этот непонятный код из той же серии.
Еще раз спасибо, без этого отладчика я бы ни в жизь не нашел источник проблемы Теперь можно заканчивать софтину, осталась немного.

[ivagor]

Возможно это традиция для разработчиков ПК8000. В основном пзу в обработчике прерывания тоже есть фрагмент-рудимент (c 2600h) который не используется (по крайней мере я не нашел, кто и как мог бы его вызвать).

[svofski]

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

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

[Pyk]

svofski, спасибо за полезные наблюдения, буду иметь в виду. Я правильно понял, что там было даже не 64-битное деление?

А с телефонами на android/ARM тоже недавно немного поэкспериментировал - тормозит со звуком, скорее всего по аналогичной причине. Считаю, что нормальная работа на ARM важна, обязательно вернусь к этому вопросу, в том числе попробую выловить % в критичных участках. Но это все скорее уже ближе к осени, летом руки нечасто доходят до эмулятора... А вообще emu80 сам по себе более тормозной из-за того, что ради унифицированности зачастую приходилось жертвовать эффективностью...

[svofski]

Pyk, нет, обычный unsigned int. Транслируется в __aeabi_uidivmod, это фишка арма. Собственно можно скомпилировать с -save-temps и пошукать по .s файлам.

[Manwe]

Исходники (GPL v.3):
https://github.com/vpyk/emu80v4

Жаль, что нет сборки под MacOS

[Pyk]

Жаль, что нет сборки под MacOS

Действительно...
Кто поможет сделать сборку?

[Pyk]

Ну, раз желающих помочь нет, пришлось самому
Протестируйте, плиз, сборку под MacOS, у кого есть возможность:
http://emu80.org/v4beta/Emu80qt_40344_macos_test.zip

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