Да всё уже получилось. На первой странице ссылки на свежую сборку выложены. Вот нисколько не охота делать ещё более идеальную модель, и так уже вычисления еле укладываются во фрейм, на слабых компах мой эмулятор уже работать не будет нормально, т.е. как-то работать будет, но звук будет разрываться уже.
Не знаю как по научному называется та штука, с которой я боролся, но выглядит она так:

меандр - даёт амплитуду, примерно равную амплитуде меандра, с частотой меандра

сигнал со скважностью < 2, но с той же частотой, что и меандр выше, даёт амплитуду, меньшую пропорционально скважности, но той же частоты.
Такое никакими фильтрами не сотворишь. Можно получить либо сильно песочащий звук, либо срезав всю верхушку - глухой, вообще ни разу на пищалку не похожий.

После Ваших диаграмм я опять перестал понимать проблему.
Рад, что получилось. Непонятно только, что там за сверхсложные вычисления, обычно в фильтрах хватает нескольких сложений и умножений.
Попробовал обе сборки (x86 и x64) под wine.
Обе запускаются и работают (в смысле окно БКашки функционирует). На вид обе версии неотличимы.
Но есть неприятный косяк: при попытке сменить диск выскакивает слепая менюшка (без текста), в поле "Система" сообщение "Ошибка чтения", а мы еще ничего не читали.



Кроме того, при нажатии любой клавиши цветной режим меняется на черно-белый, окно отладки пустое...
Эх, опять не везет!
Конечно, чего ждать от эмулятора в эмуляторе...
Под виндой все нормально (насколько успел глянуть на работе).
Спасибо за желтый курсор. Теперь все видно! :)
И еще момент. У меня на ноуте экран небольшой, я никак не могу выставить нормальное разрешение для окна БКашки (это 1024х768), когда линии не рвутся и не двоятся.

И это ещё самый простой вариант, многоголосие из Клавесина выглядит и моделируется гораздо сложнее.

для звука - не самые сложные, но там, если даже звука нет, приходится постоянно вычислять среднее значение сигнала для пищалки, ковокса и AYшки, чтобы когда звук на них появится, не было резких щелчков. Нужно постоянно отслеживать позицию фильтров БПФ, чтобы когда звук появится не было искажений. Это немного. Самое трудоёмкое - формирование изображения. Оно отжирает 60% всех вычислений во фрейме. Остальные 40% - на всё остальное.

Видимо каких-то ресурсов в wine всё таки не хватает. Если бы была возможность пересобрать эмулятор в какой-нибудь старой студии - 2010 (минимально поддерживаемая) или 2013 и посмотреть как оно поведёт себя под вайном, может бы что-то прояснилось.

Подозреваю, что это из-за того, что переключение посажено на кнопку Scroll Lock

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

есть ещё 768х576, 512х384, при которых линии не рвутся и не двоятся.
Я вообще хотел добавить в меню установку фиксированных размеров экрана. Но не смог решить вопрос, как перепозиционировать пристыкованные окошки и изменить размер основного окна при заданном фиксированном размере экрана. Когда-нибудь решу проблему.

Оно у всех эмуляторов посажено на scroll lock, но я-то нажимаю обычные буквы/цифры!
Но, в общем, неважно. Оно чем дальше, тем несовместимостей больше. Всего не охватить. Пусть уж хоть под виндой нормально работает...

Мне, например, было бы удобнее, чтобы все окошки были отдельными (как в исходном Gimpе). Экранчик на ноуте маленький, пристыкованные окна только мешаются.

Залез я в исходники (конечно, смотрю я на этот С++ как баран на новые ворота...). Действительно, в функции CSpeaker::RCSHIMCalc() экспоненты вычисляются.
Не надо их вычислять. Смотрите:

Здесь я обозначил m_fcurrentvol - текущее значение амплитуды, c_damp - это константа затухания амплитуды за один такт. Это просто число. Я не смог его вычислить из Вашего кода. Оно, по идее, должно быть равно значению 1 - экспонента за один такт (т.е. маленькое число, значительно меньше единицы).

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

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

Я тоже не смог найти простой, изящный и непонятный способ решения, поэтому решил задачу в лоб.

Приведенный в посте выше алгоритм дает экспоненциальный заряд-разряд. Как Вы и хотели.

Верно, только чтобы он работал с удовлетворительной точностью, выполнять вычисления нужно как можно чаще. А у меня и без того ресурсов нет, чтобы делать бессмысленные вычисления. Я лучше буду изредка вычислять экспоненту, это всё равно быстрее получается и менее ресурсоёмко.

Признаюсь: совсем ничего не понимаю в Ваших аргументах.
Достаточно частоты вывода звука 20 кГц. Для нынешних процессоров - это как раз в столетие! Какая нагрузка, вообще не ясно?
И ту же экспоненту надо считать/выводить с такой же частотой. Где тут экономия?

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

Недостаточно. 44100Гц - удовлетворительный минимум. Я бы вообще 96кГц сделал, но думаю, не все потянут, а мне звук AYшки, генерируемый с такой частотой дискретизации понравился больше.
Я пробовал делать вычисления из поста https://forum.pk-fpga.ru/viewtopic.php?p=6193#p6193 с частотой дискретизации звука 44.1кГц - фигня получается - слишком малая частота, пробовал с частотой дискретизации проца - 3мГц, получается лучше, но не то, что нужно.

Я же говорил: экран - основная нагрузка, всё остальное - должно выполняться за время, которое оставляет экран, а это не так уж и много.

Экспоненту достаточно считать с частотой дискретизации звука + в моменты записи данных в регистр 177716. Умножения, чтобы интерполяция приблизилась к экспоненте, надо делать как можно чаще, либо с частотой процессора, либо кратно ей, иначе будет не экспонента, а примерно похожая на неё ломаная кривая.
Всё равно мы не поймём друг друга, пока вы будете выдвигать теории, не подтверждённые практикой, а я наоборот - сугубо практический результат, без всяких теорий.