Плеер музыки ZX-Spectrum на одной микросхеме

Говорят, первый раз запоминается на всю жизнь. Люди запоминают свою первую любовь, первый поцелуй, первый автомобиль, первый брак, первую ипотеку. Вот и я запомнил свой первый компьютер, ZX-Spectrum. Через него у меня произошло первое знакомство с программированием, компьютерными играми и музыкой. И даже сейчас, много лет спустя, глядя на какой-либо алгоритм, я порой вдруг задумываюсь — «А как этот код можно было бы написать для Z-80?» Поэтому, когда я первый раз взял в руки микроконтроллер ATtiny85, то сразу понял, что на нем можно сделать плеер музыки ZX-Spectrum. С тех пор прошло более десяти лет, но то одно, то другое, и до реализации у меня никак не доходили руки. А тут вдруг удалось исполнить свою давнюю мечту, поэтому сегодня я с радостью делюсь с вами тем, что у меня получилось.

Не буду оттягивать время и сразу оставлю ссылку, по которой можно послушать, что у меня в итоге получилось. Возможно, вы даже продолжите чтение статьи под эту прекрасную мелодию (не забудьте снять режим «без звука» в видеоплеере GitHub’а):

github.com/kdekaluga/zx-spectrum-music-player/tree/main/Examples

Почему именно ATtiny85? Прежде всего потому, что он маленький и самодостаточный, может работать полностью автономно без единого внешнего компонента, только подай на него питание. С другой стороны, у него есть два канала высокочастотного ШИМ, которые можно использовать вместо ЦАПов для вывода стереофонического звука, а встроенного ПЗУ объемом 8 КБ должно хватить как для самой мелодии (которые на Спектруме занимали примерно 3-6 КБ), так и для кода эмуляции плеера.

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

Что же понадобится реализовать?

1. Эмуляция звукового чипа AY-3-8910.
2. Какой-либо плеер музыки, портированный на AVR.
3. Непосредственно, сама мелодия.

Достать мелодию – не проблема, огромный архив есть на сайте https://zxart.ee/, где можно не только поискать знакомые названия, но и тут же прослушать выбранные варианты в МР3. Кстати, на этом сайте есть и большой архив демок для ZX-Spectrum, так что если вы раньше имели какое-то отношение к демосцене или же вам просто интересно посмотреть, как оно тогда было – заходите, не пожалеете. Демки смотреть тоже можно прямо на сайте, там есть браузерный эмулятор Спектрума.

Написать программный эмулятор звукового чипа также несложно, ведь он простенький, неплохо документированный, да и лет 25 лет назад я уже разок эмулировал его для процессоров x86, осталось только вспомнить, куда делся тот исходник. А вот что у меня вызывало серьезные опасения, так это плеер и его портирование для платформы AVR. Дело в том, что, во-первых, AVR использует два разных адресных пространства для обращения к ОЗУ и ПЗУ, в то время как во всех обычных процессорах, включая Z-80, и ПЗУ, и ОЗУ доступны из единого общего адресного пространства. А, во-вторых, в те далекие времена для ускорения выполнения программы на Z-80 повсеместно использовался самомодифицирующийся код, что принципиально невозможно реализовать на AVR. В общем, код плеера не получится просто портировать покомандно, лишь заменив регистры одного процессора на регистры другого (как обычно делают в таких случаях), в нем придется разбираться досконально, чтобы переписать его под другую платформу с учетом её особенностей. Поэтому начать я решил именно с плеера – если с ним ничего не выйдет, проект можно будет снова закопать на неопределенный срок без лишних потерь. Если же портировать плеер удастся, с реализацией остальной части задумки проблем не возникнет.


В качестве плеера выбрал относительно простой по возможностям, но достаточно популярный в начале 90-х годов плеер от музыкального редактора Sound Tracker. В те годы музыка, написанная в этом редакторе встречалась во многих демках для Спектрума, включая такие легенды как Lyra II, Shock или Insult. Также большим плюсом Sound Tracker было то, что его скомпилированная музыка (без плеера) не содержала в себе абсолютных адресов, только смещения, что позволяло динамически размещать её в памяти по любому желаемому адресу. Это было редкостью, ведь в то время о вопросах релокации кода и данных на Спектруме никто не задумывался, т.к. многозадачных систем не существовало. Разработчики просто создавали программы, способные работать лишь по строго фиксированному адресу, так как точно знали, что он всегда будет доступен.

То же самое относилось и к музыке – были такие форматы, внутри которых содержались абсолютные адреса, что не позволяло свободно перемещать мелодию по памяти компьютера. Это создавало определенные трудности при написании музыкальных демок – программ, в памяти которых хранилось сразу пару десятков популярных мелодий, и пользователь мог выбирать, какую из них он хотел бы прослушать. Но авторы Sound Tracker пошли другим путем и использовали только смещения, а конечные адреса высчитывали непосредственно в процессе инициализации плеера, что делало перемещение мелодии по памяти тривиальным. За это музыка в данном формате была отдельно любима кодерами. В современном мире скомпилированные и готовые к воспроизведению мелодии Sound Tracker имеют расширение *.STC (Sound Tracker Compiled).

Правильнее всего код плеера было бы взять непосредственно из самого Sound Tracker’а – загрузить какую-либо мелодию, откомпилировать и сохранить на диск вместе с плеером. Однако, для этого нужно настраивать и запускать эмулятор. И тут вдруг я вспомнил про искусственный интеллект – почему бы не дать ему задачу сделать всё сразу – и найти, и дизассемблировать двоичный код? Это бы серьезно сократило время на поиски и изучение формата, а, значит, и на всю разработку.

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


Тогда я постарался найти уже готовый байт-код плеера и скормить ChatGPT его. Код удалось найти на гитхабе в виде массива данных в исходнике для С++. Теперь нейросети оставалось лишь перевести его в двоичный файл и дизассемблировать в инструкции Z-80, с чем она вполне должна была справиться. И, на первый взгляд, у неё даже получилось, она выдала вот такой листинг:


Меня сразу насторожило – зачем в плеере бессмысленная последовательность LD A, I; XOR A? В Z-80 регистр I отвечает за адрес таблицы векторов прерываний, плеер не должен её трогать. Я уж было подумал, что исходный код плеера на гитхабе был с ошибками или же ChatGPT каким-то образом неверно перевел массив С++ в двоичный код или даже подменил его содержимое. Но всё оказалось проще – посмотрев таблицу команд Z-80, я понял, что это код команды OUT ( C ), A, которую ChatGPT просто неправильно дизассемблировал. Выяснение правды отняло у меня некоторое время, но это склонило меня к тому, что нейросети нельзя доверять такую ответственную операцию, как дизассемблирование исходного кода, поэтому я принялся искать нормальный дизассемблер Z-80 онлайн.

И такой был найден:


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


По сути, задача была решена, дальше надо было лишь разбираться с кодом и адаптировать его под AVR. Однако, я решил дать нейросети еще один шанс и просто попросил её прокомментировать дизассемблированный код – даже если она частично угадает где что происходит, мне уже будет легче в нем разобраться. ChatGPT снова «не подвел» и выдал прекраснейшие своей информативностью комментарии:


Тогда я вдруг вспомнил про его китайский аналог – DeepSeek, и решил попробовать его. Почему-то у меня не получилось загрузить в него тестовый файл, так что весь дизассемблированный код пришлось вставлять в промпт. Тем не менее, мы оба справились – я смог вставить исходный текст, а он дать более-менее вменяемые комментарии:


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


Дополнительно я нашел описание формата STC-файла, и хоть оно тоже содержало как минимум одну ошибку, всей суммарной информации уже хватило, чтобы переписать код плеера под AVR. Изначально я хотел делать это на ассемблере, но потом вдруг подумал, что высокоуровневый код плеера может оказаться полезным, если в будущем я захочу сделать аналогичный плеер на другом микроконтроллере, поэтому решил сразу переводить его на С++. В целом, это оказалось не так сложно, как я думал, и за вечер плеер был написан. Правда оставался открытым вопрос, каким образом я смогу исправить в нем ошибки, если ни исходный, ни полученный код у меня нет возможности отлаживать? Но тут просто понадеялся, что ошибок в коде не будет :)

Не думаю, что весь код плеера окажется вам интересен, поэтому здесь приведу только кусочек, а с остальным вы можете ознакомиться в репозитории самостоятельно:


Забегая вперед, скажу, что ошибки в коде всё-таки оказались, их было три. И все три пришлось исправлять «на слух», сравнивая звучание мелодии в эмуляторе с оригиналом на сайте. Самой значительной ошибкой было то, что я всегда использовал первый инструмент независимо от выбранного в мелодии – просто написал m_samples->m_points[samplePosition] вместо ch.m_sample->m_points[samplePosition]. А самая «хитрая» была в коде эмуляции звукового чипа, о ней я расскажу чуть позже.

Когда плеер был готов, можно было перейти к эмуляции AY-3-8910. Этот чип имеет в своем составе три генератора прямоугольного тона, однобитный генератор шума, программируемый генератор огибающей и три 4-битных ЦАПа. Частоты всех генераторов настраиваются программно, управление «хозяйством» происходит через 14 8-битных регистров, находящихся внутри чипа:


Первые 6 регистров задают период основного тона трех каналов А, В и С. 6-й регистр задает период генератора шума. 7-й регистр управляет микшером чипа и разрешает включать или выключать генерацию тона и шума в соответствующих каналах. Следующие три регистра определяют громкость звука в каналах А, В и С, а также отвечают за включение или выключение в них огибающей. И, наконец, последние три регистра задают период и форму огибающей. Всего чип поддерживает 8 разных форм:


Поскольку чип достаточно простой и умножения делать не умеет, включение огибающей в каком-либо канале автоматически устанавливает в нем максимальную громкость. Также отдельной особенностью генератора огибающей является то, что любая запись в регистр #13 сбрасывает генератор и огибающая начинает воспроизводиться сначала. То есть, в отличии от других регистров значение в нем следует обновлять только в случае изменения формы огибающей.

В общем, понятно, что эмуляция огибающей будет наиболее сложной задачей, поэтому я решил начать именно с неё. Если посмотреть картинку выше, все огибающие можно разделить на два типа – одиночные, когда после окончания одного периода на выходе поддерживается постоянный низкий или высокий уровень и периодические, когда генератор огибающей генерирует треугольный или пилообразный сигнал. Чтобы не разделять такие типы в эмуляторе, я решил, что каждая огибающая будет представлять собой последовательность из 4-х сэмплов, где первый и второй будут проиграны лишь один раз, а третий и четвертый будут повторяться бесконечно. Различных сэмплов будет тоже четыре – возрастающий, понижающийся, низкий и высокий. Таким образом, комбинируя эти сэмплы в нужные последовательности можно будет представить все доступные в AY формы сигнала.


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

Изначально я хотел выбрать частоту дискретизации для эмулятора равной традиционным 44100 Гц, однако, изучив документацию на AY обратил внимание, что базовой частотой для всех генераторов является входная частота чипа, деленная на 16. В российском клоне Спектрума AY тактировался с половинной частотой центрального процессора, то есть, 1.75 МГц, таким образом, базовой частотой генераторов были 109375 Гц. Если поделить это число на 2.5 мы получим 43750 Гц, что весьма близко к 44100, так что я решил сделать частоту дискретизации именно такой – это позволит использовать более «круглые» коэффициенты при расчете приращений фазы для DDS.

Точность DDS напрямую определяется разрядностью аккумулятора фазы и частотой дискретизации. Если при частоте дискретизации 43750 Гц использовать 16-разрядный аккумулятор, единице младшего разряда будет соответствовать 43750/65536 = 0.67 Гц. Если предположить, что приращение фазы определяется с точностью до единицы младшего разряда (типичная ситуация для целочисленных вычислений), мы получим итоговую погрешность генератора до 0.67 Гц. Это будет практически незаметно при генерации высокочастотных сигналов, однако весьма много при генерации низкочастотных. То есть, мне надо использовать 24-разрядный аккумулятор, который при той же частоте дискретизации будет уже обеспечивать точность в 0.003 Гц.

Исходя из изложенных принципов был написал следующий код:


Вначале он увеличивает аккумулятор фазы, хранящийся в переменной g_ayEnvelopePos на значение g_ayEnvelopeAdd. Установка флага переноса после такого приращения означает, что эмуляция текущего периода сигнала огибающей завершена и необходимо перейти к следующему, то есть, выбрать новый сэмпл по таблице последовательности. Выбор семпла производится в соответствии с описанными выше правилами – первый и второй семплы проигрываются лишь однократно, а третий и четвертый повторяются бесконечно. Наконец, 4 старших бита аккумулятора фазы определяют номер точки семпла, которая должна попасть на выход (которым является регистр R0) в данный момент. Весь код эмулятора огибающий в худшем случае занимает 47 тактов процессора.

Следующим шагом происходит эмуляция генератора шума. По сути, генератор шума AY – это однобитный генератор случайных чисел, работающий с заданной частотой. А, значит, его можно реализовать, совместив DDS с LFSR, про который я рассказывал в одной из предыдущих статей. В этой связке LFSR будет генерировать случайные биты, а DDS выдавать их на выход с нужной скоростью. Так как минимальная частота генерируемого шума в AY достаточно высокая и составляет 109375/31 = 3.5 КГц, разрядность аккумулятора фазы можно понизить до 16 бит. LFSR я взял из предыдущих проектов длиной 31 бит.


В работе эмулятора шума есть весьма интересная ситуация – максимальная генерируемая частота шума составляет 109375/1 = 109375 Гц, то есть, в 2.5 раза больше, чем частота дискретизации! Что же делать в этом случае? А ничего, ведь шум – это поток случайных битов. Если он идет с частотой 109375 Гц, а мы будем на него смотреть лишь 43750 раз в секунду, мы будем видеть только 43750 битов из 109375. Но, так как эти биты случайны, то, что мы будем видеть всё равно останется для нас случайной последовательностью. А это значит, что можно смело ограничить максимальную частоту генерации случайных бит до 43750 Гц.

Несмотря на то, что аккумулятор фазы генератора шума имеет разрядность 16 бит, приращение фазы необходимо оставить 24-битным, т.к. его максимальное значение может быть 163840, что не умещается в 16 бит. Для сложения с таким приращением к аккумулятору будет временно добавляться третий байт, изначально равный нулю. Если после сложения его значение станет отличным от нуля, это будет означать, что надо перейти к новому «периоду» шума и, соответственно, сгенерировать новый случайный бит. В худшем случае код эмуляции генератора шума занимает 46 тактов, что дает максимальное общее время в 93 такта.

Завершающим этапом будет происходить эмуляция генераторов тона и микшера для трех каналов. Для генерации тона будет использован такой же DDS с 24-битным аккумулятором фазы, но так как на выходе нужно получить простой меандр, результат будет браться напрямую из 23-го бита аккумулятора. Кстати, каналы тона в чипе AY тоже могут генерировать частоту вплоть до 109375 Гц, но такая частота никогда не применялась на практике в плеерах, ведь она не слышна человеческим ухом. Эмулятор будет в этом случае создавать более низкую частоту, зеркально отраженную на спектре от точки 43750 Гц.


Важным моментом внутренней архитектуры AY является выходной ЦАП – так как он имеет весьма малое количество разрядов, для обеспечения возможности регулировки громкости выходного сигнала в достаточно широких пределах, его передаточная характеристика выбрана обратной логарифмической:


Таким образом, для получения реальной амплитуды выходного сигнала необходимо провести табличное преобразование полученной громкости в требуемый процент заполнения для PWM-выхода МК. Я решил сделать выход монофоническим, чтобы иметь возможность подключить к схеме один звукоизлучатель, поэтому складываю результат всех трех каналов вместе в регистр R21. Однако ничего не мешает переделать код на стереофонический выход, ведь PWM-канала у таймера МК два.

В итоге, общее время работы кода эмулятора AY получилось равным 224-м тактам процессора в худшем случае. Добавим сюда сохранение регистров при входе в прерывание и восстановление при выходе, а также другие накладные расходы, после чего можно считать, что обработчик прерывания занимает порядка 270 тактов из 366 доступных. То есть, вполне укладывается в отведенное ему время, хотя и занимает несколько больше, чем я ожидал.

А что было бы, если бы обработчик не уложился? В принципе, ничего фатального, нужно было бы лишь снизить частоту дискретизации эмулятора до подходящего значения, например, до 25 КГц. Это снизило бы максимальную выходную частоту, которую способен воспроизвести эмулятор, но для мелодий Спектрума это вряд ли так уж критично.

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

Ну, и последним «кирпичиком», необходимым, чтобы плеер запустился является расчет приращений фаз всех DDS на основе значений регистров эмулируемого чипа. Он выполняется 50 раз в секунду, после каждого вызова кода плеера и поэтому написан на С++:


В этом коде нет ничего необычного, сначала все значения рассчитываются с помощью 32-битной арифметики, а потом разом устанавливаются нужные глобальные переменные. Чтобы случайно вдруг не получилось, что часть переменных обновится, а часть еще будет содержать старые значения, на время присвоения прерывания МК запрещаются.

И вот теперь можно рассказать о «хитрой» ошибке, закравшийся в код эмуляции AY. По документации минимальное значение, которое можно занести в регистры периода равняется 1. Что будет, если занести туда ноль документация не указывает. На практике же занесение нуля полностью эквивалентно занесению единицы – соответствующий генератор выдает на своем выходе максимальную частоту. И если с генератором тона это не применяется (так как он генерирует сверхзвуковую частоту в этом случае), то с генератором огибающей вполне, ведь его максимальная выходная частота в 16 раз меньше и всегда попадает в звуковой диапазон. Вот именно этот факт я и забыл учесть в своем изначальном коде, где при занесении нуля в регистр периода генератор огибающей просто останавливался. Нашлось это тоже «на слух» в одной из мелодий, которая звучала в эмуляторе неправильно.

На этом можно считать, что программная часть закончена, поэтому перейдем к аппаратной. А её, по сути, и нет – необходимо просто взять запрограммированный чип ATtiny85, подать на него питание и снимать готовый аудиосигнал с выхода PB4 (вывод номер 3). Если вы хотите подключить к «проигрывателю» наушники или динамик, это можно сделать напрямую без дополнительных фильтров, PWM-сигнал усреднится непосредственно на звуковом излучателе. А вот если соберетесь подключать какой-либо усилитель, лучше добавить на выход ФНЧ хотя бы на RC-цепочке, так как не каждому усилителю понравится 250 КГц на входе. Подходящими номиналами могут быть, например, резистор 100 Ом и конденсатор 220 нФ (только не используйте электролитический, он плохо работает на высоких частотах).

Вот так выглядит мой плеер сейчас – он пока что еще остался на макетной плате:


У меня на выход МК добавлен RC-фильтр и делитель, после чего установлен разъем 3.5 мм под наушники, чтобы можно было записать воспроизводимую мелодию на компьютер. Ссылка на пример работы плеера уже была в начале статьи, но повторю её еще раз тут:

github.com/kdekaluga/zx-spectrum-music-player/tree/main/Examples

Теперь настало время подвести итоги. Есть ли у проигрывателя какое-либо реальное применение? Вряд ли. Можно, конечно, дополнить чип USB-штеккером для питания и разъемом для наушников, после чего убрать это в небольшой напечатанный корпус и подарить на день рождения знакомому поклоннику Спектрума, но это единичные случаи. Можно попробовать использовать, например, вместо дверного звонка, но боюсь, одна и та же мелодия быстро надоест. В общем, проект носит скорее развлекательно-демонстрационных характер из раздела «смотрите, как еще можно сделать». Но если вдруг у вас есть идеи, где это можно использовать с пользой – напишите в комментариях, будет очень интересно.

Ах, да, общий объем кода эмулятора и плеера в памяти МК составляет около 2700 байт, то есть, под мелодию остается порядка 5500 байт, и этого хватает для практически всех мелодий в STC-формате, но не для абсолютно всех. Парочка больших мелодий, таких как, например, Laser-Dance требуют немногим больше места. Но решение есть – переписать код плеера на ассемблер, тогда, наверное, можно уместить весь обслуживающий код в 2 или даже 1.5 КБ. Однако, веской причины делать это сейчас нет.

На этом у меня всё, спасибо за внимание. Исходный код можно найти здесь:

github.com/kdekaluga/zx-spectrum-music-player