Xpeccy

Эмулируемые железяки на вывод звука вообще не влияют, они только сообщают о своей громкости, не надо их сюда приписывать.
Суть такова:
Есть кольцевой буфер размером 16кб. Во время эмуляции считается сэмулированное время, и через определенные промежутки с текущей железяки снимается громкость, несколько таких значений подряд усредняются и этот усредненный сэмпл ложится в буфер. Это всё происходит в потоке эмуляции. Без ускорения эмуляция происходит кусками, цель каждого куска - заполнить буфер на столько семплов, сколько хочет SDL. Это делает звук более гладким, но разрывает графику. Иначе будет наоборот, но ещё хуже.
Далее есть SDL-овский callback на воспроизведение звука, он работает в своём собственном потоке. Первые пара буферов пропускается, чтобы не пересекаться с заполнением буфера. Воспроизведение идёт с того же самого кольцевого буфера, но чуть позади заполнения. В идеале заполнение и воспроизведение идут с одной скоростью, не догоняют и не обгоняют друг друга. Но если вдруг воспроизведение догнало заполнение на расстояние одного буфера, то оно откатывается назад - тут происходит проигрывание прошлого буфера.
Есть два особых случая - эмуляция запаузена и эмуляция запущена на полной скорости (insert). В первом случае всё должно быть как описано выше, но т.к. устройства не эмулируются, то снимаемый сэмпл звука не меняется, это тишина. А во втором случае я, возможно, опять накриворучил...

> Первые пара буферов пропускается, чтобы не пересекаться с заполнением буфера. Воспроизведение идёт с того же самого кольцевого буфера, но чуть позади заполнения.

Говорили же старшие - никогда не заполняй воспроизводимый буфер. Воспроизводи только "задний". Если нужен такой большой запас - делай 3 буфера. В unreal-е три буфера. Каждый, правда, в 200 байт (и этого всегда хватает, и лага практически нет).

У тебя после "тишины" инсерта (или дебаггера) указатель воспроизведения оказывается не "перед" указателем заполнения. Иногда. И ненамного. Настолько ненамного, что они периодически пересекаются.

Цитата:

---

Сообщение от SAM style

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

---

зачем всё это при живом SDL_QueueAudio? с которым нужно следить только за длиной очереди

Цитата:

---

Сообщение от Lethargeek

зачем всё это при живом SDL_QueueAudio?

---

Потому что сначала там присутствовало ещё и alsa.
Да и SDL1 придётся бросать. Хотя, нафиг он мне сдался теперь...

Это конечно, прикольно как там кольцевой буфер глючить (делов, то). Ну, мне уже не интересно, писал эмуляторы в начале 2000г. И как там чего у каждой платформы (железа) сделано, не объять. Все это выходит за рамки Z80 (zx).

Давайте становиться первым в мире плагинным эмулятором. До этого были попытки у ZXMAK2, но там все уперлось в ZX.

Цитата:

---

Сообщение от OrionExt

Давайте становиться первым в мире плагинным эмулятором. До этого были попытки у ZXMAK2, но там все уперлось в ZX

---

На самом деле это не так и сложно сделать в рамках xpeccy. Он и так почти состоит из обособленных блоков. Но сейчас на что-то такое времени и сил нет. Может, позже соберусь и сделаю

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

• как я понял, CIA тактируется на частоте CPU, примерно 1МГц с отклонениями. Значит, таймер в большинстве случаев отсчитывает такты CPU. Да? (не считаем счетчик внешнего сигнала и счетчик таймера B по переполнению таймера А)
• Вделал загрузку самых простых тапок - raw tape image, пробую загрузить по LOAD - получаю дулю с покоцаными данными. Во время пилота irq генерирует только /flag, но как только начинаются данные, включается irq от таймера А - он там зачем? По дебагу вижу irq от мофонного сигнала с периодами ~380/520/680 тактов, и иногда в них вклинивается irq от таймера А.
• И ещё вопрос - когда таймер стартует, в его счетчик всегда записывается значение инициализатора? Даже когда "стартует" уже запущенный таймер?

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

Насчет тестов. Сам написать не смогу, потому как в 6502 не силён. Если есть таковые в виде PRG (что-то типа снапшота) для разных компонентов коммодора - буду рад заиметь. Находил такие только в d64, но до эмуляции дисков мне ещё как до Луны ползком.

== added

Нашёл ещё один даташит на CIA. Перегрузка таймера работает не так, как я сначала думал:
- при переполнении таймер всегда инициализируется
- при записи в старший регистр таймера в остановленном состоянии он тоже инициализируется
- бит "force load" в контрольном регистре значит "инициализировать таймер прямо сейчас" - сначала я думал, этот бит значит "перегружать таймер при переполнении или оставлять его FFFF).
- при запуске таймера без бита "force load" он, соответственно, не инициализируется

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