Мой новый эмулятор - ZX Miracle

[ZXMAK]

Для меня, например, всегда играла роль именно обратная связь. Если я что-то начинаю делать, а обратной связи нет, я закрываю лавочку. Как, например, с реверсом Z80. Вроде кажется, вау,такая интересная тема. А потом смотришь, она не на столько интересна всем. Вернее, интересна, но только в виде готового продукта. А углубляться в нюансы никому не интересно. Я смотрю на это и думаю, ага, люди мне показывают, что я, видимо, ошибаюсь, концентрируясь на этой теме. Лучше заняться чем-то более востребованным. Да, и сказать по-честному, 99.9999% игр и пользователям не нужна пореверсово-точная эмуляции. Будет, хорошо. Нет, и так все прекрасно работает. И мультиколоры, и пультиколоры)

мне кажется у меня также

Я бы наверно и не возвращался к обновлению эмулятора, потому что интереса у людей уже нет, да и людей которым это интересно осталось мало. Просто столкнулся с тем, что на raspberry pi, на котором я сейчас сижу нет нормально работающего эмулятора, а иногда хочется чтото запустить, поиграть в тот-же lode-runner, посмотреть какой-то новый zx софт, который появился за это время. Потыкался я с zemu, fuse и полез исправлять и допиливать свой эмуль, чтобы под linux работал. Вначале было подозрение что эмулятор для raspi тяжелая задача, т.к. тот-же fuse тормозит сильно, особенно на загрузке с магнитофона, но уже сейчас он летает не особо хуже чем на полноценном десктопе, разве что макс скорость при прокрутке загрузок не такая шустрая. Обнаружились древние ошибки в отладчике, которые как-то работали и я их почему-то не замечал раньше на десктопе, сам удивляюсь Переделал скан клавиатуры, теперь в файле конфигурации задается не только биндинг на кнопки хоста, но и вся матрица для сканирования - конфиг теперь определяет какая кнопка или комбинация кнопок биндится на какую ячейку матрицы. Причем опрос клавиатуры ускорен в 20 раз, получилось довольно прикольно, т.к. код очень простой, но работает шустро и дает возможность задавать конфигурацию матриц клавиатуры полностью в конфиг файле для разных моделей - классический спектрум, профи, орель и т.п. В коде получаешь сразу готовые значения с матрицы, причем опрос происходит максимально эффективно даже если есть сложные кобинации кнопок и если где-то в биндинге ошибки - сразу видно по логу.

[Titus]

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

Людей, конечно, все меньше, но все же есть и будут.
Мне ZXMAK2 нравится тем, что он лучше других синхронизирует звук и видео. Во всяком случае, лучше спектакулятора, хотя спектакулятор в чем-то удобнее. Но если мне надо посмотреть именно что-то плавное, то это я запускаю ZXMAK2.

[ZXMAK]

синхронизирует звук и видео

да, это возможно единственный эмулятор с отдельными потоками для GUI и рендеринга. Совместить это без проблем было не просто, но я очень хотел сделать так, чтобы на отрисовку и эмуляцию не влиял GUI, помню консультировался со спецами в DirectX, которые советовали сделать просто все в одном потоке для простоты. Я много раз возвращался к такому варианту, но потом снова и снова пытался разными способами реализовать и в конце концов я таки сделал это и это работает во всех режимах, помню в хвост и в гриву тестил код в разных комбинациях, на нескольких дисплеях, с разными разрешениями и частотой развертки, на разных видеокартах, когда половина окна на одном дисплее, вторая половина на другом и т.п. и в конце концов все проблемы удалось решить

А код для звука ZXMAK2 использован и в эмуляторе Zero, автор спрашивал разрешение использовать в его эмуляторе.

[ZEman]

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

[Titus]

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

Плюс у тебя там есть выбор от чего синхронизироваться, аудио, видео или таймер. Это тоже может помочь в случае с какими-нибудь кривыми звуковухами.
Например, у меня есть звуковуха Audigy 2, которая была очень крутой в свое время, но на современных виндах ее дрова кривые, и аудиобуфер подсасывается рывками. Спектакулятор сразу дрожит изображением при скроллингах, т.к. синхронизируется по звуковому буферу. А в твоем эмуле все четенько.

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

которые советовали сделать просто все в одном потоке для простоты

Я тоже с своем эмуляторе ушел от одного потока.
Сперва сделал два потока.
В основном крутится GUI.
Во втором эмуляция и Direct2D, чтобы обновлять окно.
Но потом понял, что надо вообще 3 потока, чтобы отрисовка (не GUI, а Direct2D) никак не могла тормознуть звук даже при самой серьезной загрузке компа.

[ZXMAK]

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

у меня на linux с usb звуковухой такая-же ситуация. Проблема в том, что драйвер звуковой карты обновляет позицию воспроизведения слишком редко, где-то раз в 30-40 мс, в то время как для 50 Гц нужно 20 мс. Если пропуски кадров можно решить буферизацией, то неравномерность интервалов синхронизации сказывается на плавности скроллинга - он становится дерганным.

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

[Titus]

Не знаю, с чем это связано, толи особенность USB

Думаю, что с особенностью драйверов звуковухи под USB.
Звуковухи под USB для винды тоже худшие характеристики буфера имеют, чем PCIe.

Редкое обновление еще можно скомпенсировать предсказанием.
А вот не просто редкое, а неравномерное, т.е. когда у тебя 100 раз буфер обновился раз в 10мс, а на 101, раз в 20мс - вот это засада.
А такое у меня встречается в одной звуковухе. Видимо, она имеет промежуточный буфер, и когда он набегает, позиция резко перескакивает. Такое вряд ли скомпенсируешь предсказанием, т.к. очень длинный интервал набегания, измеряемый десятком секунд. Тут просто надо смириться, что будет потеря кадра) Или потеря звукового фрейма) По выбору)

[Lethargeek]

Думаю, что с особенностью драйверов звуковухи под USB.
Звуковухи под USB для винды тоже худшие характеристики буфера имеют, чем PCIe.

Редкое обновление еще можно скомпенсировать предсказанием.
А вот не просто редкое, а неравномерное, т.е. когда у тебя 100 раз буфер обновился раз в 10мс, а на 101, раз в 20мс - вот это засада.
А такое у меня встречается в одной звуковухе. Видимо, она имеет промежуточный буфер, и когда он набегает, позиция резко перескакивает. Такое вряд ли скомпенсируешь предсказанием, т.к. очень длинный интервал набегания, измеряемый десятком секунд. Тут просто надо смириться, что будет потеря кадра) Или потеря звукового фрейма) По выбору)

о, а можешь с ней моё поделие потестировать?
ссылка через блог на sc https://zx-pk.ru/blogs/680.html

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

[ZXMAK]

Думаю, что с особенностью драйверов звуковухи под USB.
А вот не просто редкое, а неравномерное, т.е. когда у тебя 100 раз буфер обновился раз в 10мс, а на 101, раз в 20мс - вот это засада.

оно именно так и получается, когда позиция воспроизведения обновляется слишком редко. При синхронизации от звуковой карты в этом случае получается, например два кадра приходят с нулевой задержкой между ними, а потом третий через 40 мс. Это видно, если записать моменты времени когда обновление приходит. Но я думаю это не совсем из-за того, что USB устройство. Насколько помню, я пробовал ту-же USB звуковую карту на другом компьютере, тоже под linux, и там обновление от драйвера приходило нормально. Вероятно это связано с мощностью процессора или особенностями материнки - сложно сказать.

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

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

В ZX Spin тоже отдельный поток эмуляции с рендерингом.

речь не совсем об этом. В ZXMAK2 эмуляция, вывод звука, рендеринг, GUI - все в отдельных потоках. Т.е. 4 потока. Обычно в приложениях рендеринг и GUI в одном потоке, в этом случае все просто. В ZXMAK2 рендеринг и GUI в отдельных потоках, поэтому задержки в GUI не влияют ни на рендеринг, ни на эмуляцию. И вот об этом разделении на потоки GUI и рендеринга и идет речь. Заметить это в Windows можно при перетаскивании окна, при подхватывании его за заголовок. Программы с GUI и рендерингом в одном потоке приостанавливают обновление окна на некоторое время (около 1 сек). Эта задержка связана с тем, что винда в это время крутит какие-то свои внутренние циклы.

[Titus]

Заметить это в Windows можно при перетаскивании окна, при подхватывании его за заголовок. Программы с GUI и рендерингом в одном потоке приостанавливают обновление окна на некоторое время (около 1 сек).

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

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

о, а можешь с ней моё поделие потестировать?
ссылка через блог на sc https://zx-pk.ru/blogs/680.html

Если доберусь до той тачки, где эта звуковуха.