Простая работа с AY

[Barmaley_m]

Я портирую игру Dark Woods с QuickBasic 4.5 для DOS. Всего в игре 7 звуковых схем:

' QB4.5
PLAY "o0l50c"
PLAY "MBo4l64fgbbcc"
PLAY "MBo5l64cdefgabo6l64cdefgab"
PLAY "MBo0l64bagfedc"
PLAY "MBo3l64cdefgbg"
PLAY "MBo1l64cdefgabo2cdefgabo3cdefgabo4cdefgabo5l5cl20cco4l8bagbl5a"
PLAY "MBo0l15ffgfg+fg+a"

Стоит задача с минимальной сложностью, но с максимальной точностью воспроизвести подобие этих звуков на AY.

И все? Ну тогда я могу предложить решения, основанные не на эмуляции, а на интерпретации аргументов PLAY Qbasic и конвертирования этого в какой-нибудь формат с последующим воспроизведением на AY.

Какой целевой язык? Допускается ли реализация функции "Play" на ассемблере?

Для SDL-версии игры я вырезал эти звуки прямо из DosBox (Ctrl+F6 и потом - звук в wav-формате в папке DOSBox\capture). Но у меня не получается вырезать звук без пауз в начале и конце (не получается вырезать паузы до микросекунд с точностью)

А вот это непонятно. Любой звуковой редактор должен решать эту проблему при условии, что из DosBox получается нормальный wav. Никаких форматов mp3 - компрессия должна выполняться после, а не до обработки.

Микросекундная точность для звука - это в принципе недостижимо, т.к. на частоте дискретизации 44100Гц промежуток времени между соседними отсчетами составляет ~23мкс. Кроме того, человек даже такую задержку не заметит на слух. Задержки в 20-50 миллисекунд (это в 1000 раз больше, чем микросекунды) на слух никак не будут восприняты. Когда я совмещал видеоряд и звук в тех случаях, когда синхронизация между ними была нарушена, точности даже в 100мс (1мс=1000мкс) хватало, и разницы никак не было заметно.

Усложним вопрос. Какой библиотекой можно генерировать AY-подобные звуки для Windows/Linux (SDL)?

Я бы делал свою, основанную на эмуляции AY или Atari Pokey (как автор mzpokeysnd.c я бы скорее всего выбрал второй вариант). Дело в том, что генерация прямоугольных звуковых сигналов - это нетривиальная задача. Чтобы обеспечить высокое качество звука, необходимо привлекать цифровые фильтры и некоторые особые, нестандартные их реализации.

[Advertiser]

[Oleg N. Cher]

И все? Ну тогда я могу предложить решения, основанные не на эмуляции, а на интерпретации аргументов PLAY Qbasic и конвертирования этого в какой-нибудь формат с последующим воспроизведением на AY.

В принципе, склоняюсь к этому же! Нашёл тут такие интересные наработки Сергея Бульбы. На Дельфи. Нужно делать .dll или переписывать на Оберон.

YMEngine

YMEngine - это пакет исходных текстов на паскале, который позволяет легко добавлять эмуляцию YM2149F AY эмулятора в Ваши собственные программы. Если Вы считаете, что исходные тексты Ay_Emul слишком сложны для понимания, то можете смело воспользоваться опытом автора YMEngine (Sledge Hammer of Grinder), который сделал все за Вас. Вы можете скачать две демонстрации и две игры как примеры использования YM-Engine. Существует также адаптация пакета YMEngine к SDL с возможностью компиляции под Linux и другие платформы. Стоит отметить, что все пакеты YMEngine базируются на устаревшей версии Ay_Emul, в частности, не совсем правильно играются некоторые YM5 и YM6-файлы. Версия YMEngine под Windows содержит также спорные моменты в коде-обвязке WaveOut, унаследованные из старой версии Ay_Emul. Просьба, с любыми вопросами по пакетам YMEngine обращаться с начала к их авторам.

Подчёркнутые моменты, правда, как-то не впечатляют. Сразу руки опускаются.

SquareTone

SquareTone - это портированный под Linux Ay_Emul v2.7 beta 3. Имеется простой консольный плеер SimplePlayer, а также плагин для популярного XMMS плеера. Данная версия может проигрывать YM и PT3 файлы. Все исходные тексты и инструкции прилагаются. Проект расчитан для компиляции во Free Pascal. Преимуществами данного пакета служат его платформонезависимость (SDL), а также то, что пакет основан на более новой версии Ay_Emul, чем YMEngine, а это автоматически избавляет от некоторых ошибок, унаследованных в YMEngine из более старого Ay_Emul. Автор - Martin Andersson.

А вот здесь вариант - только для Linux (вывод через SDL).

Вариант Сергея Бульбы (как для Windows, так и для SDL), похоже, очень грамотный. Отпугивает отсутствие .dll/.so, декларируемая "устаревшесть" кода, отсутствие единостильной по интерфейсу работы с проигрыванием для различных платформ. И необходимость переписывать такую гору Дельфи-кода на Оберон, но это ладно, на крайнячок вариант.

Какой целевой язык?

Для Спека - любой. Ну кроме экзотики конечно. Асм. Для Win/Linux - Оберон или Си.

Допускается ли реализация функции "Play" на ассемблере?

Для Спека - безусловно, на чём же ещё. А для Win/Linux - ну наверное тоже, но я не пробовал асмовые вставки использовать. Но наверно можно. Или объектник готовый прилинковать.

У меня двойная задача. Звук нужен для игры. Музыка (PT3) - нужна просто шобы было, для будущих проектов. Платформа - Спек, винда, линукс и Java microedition. Для последней можно юзать wav или midi.

А вот это непонятно. Любой звуковой редактор должен решать эту проблему при условии, что из DosBox получается нормальный wav.

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

Я бы делал свою, основанную на эмуляции AY или Atari Pokey (как автор mzpokeysnd.c я бы скорее всего выбрал второй вариант). Дело в том, что генерация прямоугольных звуковых сигналов - это нетривиальная задача. Чтобы обеспечить высокое качество звука, необходимо привлекать цифровые фильтры и некоторые особые, нестандартные их реализации.

Не возражаю, надо глянуть. Оно на Си написано? И для каких платформ?

Reobne неплохой звучок сделал, будем разрабатывать этот вариант. Reobne, спасибо!

[Alex Rider]

Очень спорное и ничем не обоснованное утверждение.

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

Причина возможная, но не единственно возможная.

Ok, я бы во-превых и в-единственных не стал озвучивать игру на BASIC'е оператором PLAY потому что она перестанет идти на машинах, на которых нет 128к. Может быть, есть и еще причины. Моего уровня кодинга хватит чтобы озвучить игру и ассемблерными вставками, но я не уверен, что все игрописатели на бейсике могут это сделать, а альтернатива PLAY в этом случая - либо BEEP, либо всякие глючные мегабейсики, резко отжирающие память своим рантаймом.

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

Согласен с одним комментарием. Сначала надо сделать самое востребованное, а потом смотреть фидбэк и добавлять всякие опции.

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

Да. Но все зависит от универсальности этой либы. Если сделать максимально функционально, разработчик ради экономии памяти может плюнуть на либу и использовать BEEP или писать выод звука на ассемблере сам. Вариант с использованием команды PLAY из ПЗУ заведомо экономнее по памяти, но, как выяснилось, сильно геморройный. Опять же, плееры AY-музыки есть быстрые и длинные, есть медленные и короткие. Какой лучше включить в либу? Все? Хотя, нормальны трек, ЕМНИП, все равно существенно длиннее плеера, так что при его тспользовании уже сэкономить не получится (кстати, строки PLAY'а сильно короче компилированных музык).

[Barmaley_m]

А с учетом низкого порога вхождения это - хорошая альтернатива самописному плееру.

Что такое в твоем понимании "самописный плеер"? Кто его пишет? Автор библиотеки или автор прикладной программы? Если первое - то плеер такой же "самописный", как и оператор бейсика PLAY. Не Свыше же он возник, написанный кем-то непогрешимым.

Насчет низкого порога вхождения PLAY - это ты откуда взял? С чем сравнивал порог вхождения?

Стоит задуматься, почему оператором PLAY по сути никто не пользовался за весь период существования Spectrum 128 с 1986г, особенно после того, как этот стандарт стал базовым для ZX, а не факультативным. И почему, с другой стороны, такое широкое распространение получили ассемблерные плееры. Как при таком обилии 128-Only программ - оператором Play никто не пользуется?

ЯВУ - это не значит "язык для чайников". На ЯВУ должно быть возможно писать не только мелкие поделки, но и серьезные программы.

Моего уровня кодинга хватит чтобы озвучить игру и ассемблерными вставками, но я не уверен, что все игрописатели на бейсике могут это сделать,

А кто предлагает игрописателям на ЯВУ самим писать ассемблерные вставки для звука? Тут идет обсуждение как раз о том, чтобы автор _библиотеки_ для ЯВУ предоставил указанные ассемблерные процедуры, чтобы прикладной программист мог их просто использовать. В этом случае, почему бы сразу не предоставить нормальные процедуры без искусственных ограничений, накладываемых PLAY?

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

Библиотека для ЯВУ - это и есть рантайм. Глючным он будет или нет - зависит от автора, но какие-то хотя бы мелкие ошибки скорее всего неизбежны. И этот рантайм неизбежно будет отжирать память. Хочешь избавиться от этого - откажись от возможностей рантайма. Самая экономная по памяти программа - это отсутствие программы. Вся память свободна. Профит. Заодно и глюков не будет.

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

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

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

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

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

Более того, я бы в первую очередь включал в библиотеку ЯВУ те плееры, которые покороче (хотя и медленнее). В большинстве применений это лучший компромисс, и только там, где идет бескомпромиссная оптимизация по скорости, следует применять "быстрые" плееры.

(кстати, строки PLAY'а сильно короче компилированных музык).

Сильно короче? Сомневаюсь. Для воспроизведения одной ноты по всем трем каналам необходимо: сам оператор PLAY и как минимум 3 числа - аргументы. Так как числа в бейсике представлены и в ASCII, и в двоичной форме - то на каждый аргумент имеем 3 байта на ASCII + 6 байт двоичного представления + 1 байт на запятую или двоеточие. Итого около 31 байт на каждую строку Play. В компилированной музыке на каждую ноту тратится 3-4 байта на канал, итого 12 байт против 31.

[goodboy]

Amstrad внесли изменения в ПЗУ 128 и 48 басиков и впендюрили это в +2, +2A, +3.

ПЗУ в +2 от 128 отличается только двумя надписями.
+3 перелопатили посеръёзней для работы с контроллером дисковода.
поэтому также поплыл синтаксис использования рамдиска.
сильно сомневаюсь что в ПЗУ моделей +2AB/+3 есть разница

[Alex Rider]

Что такое в твоем понимании "самописный плеер"? Кто его пишет? Автор библиотеки или автор прикладной программы?

А даже и не важно. Ибо писателю на ЯВУ сделать свой плеер практически нереально, а сторонний плеер, висящий на прерываниях, будет диктовать свои малопонятные ограничения типа расположения себя любимого, музыки, таблицы прерываний, режима прерывний.... Это все же сложнее, чем

BASIC.PLAY('A', 'B', 'C'); // Ни о чем думать не надо!

Как при таком обилии 128-Only программ - оператором Play никто не пользуется?

А где такое обилие 128k BASIC only программ? А нету его. Потому что 128-й бейсик дает только 2 преимущества перед 48 - это RAM-диск с малоюзабельным MERGE! и пресловутый PLAY. И ради этих преимуществ программисту придется отказаться от поддержки 48к и писать в убогом и глючном 128к-редакторе.

В этом случае, почему бы сразу не предоставить нормальные процедуры без искусственных ограничений, накладываемых PLAY?

Библиотеки для чего? Для проигрывания музыки? Да, с PLAY музыку играть сложно (но можно). Для озвучки событий? А сколько надо процедур для создания всех возможных эффектов? Делать эффекты через плеер музыки? Если надо полсотни эффектов, сколько автор игры проведен в музредакторе чтобы их сделать, скомпилить, разместить в памяти и играть с помощью универсального плеера?

Не во всякой программе узким местом является именно память.

Ну в построителе биоритмов - да, согласен. Но разработка хорошей игры на ЯВУ как правило упирается в память, ибо она не резиновая, а идей много.

Для воспроизведения одной ноты по всем трем каналам необходимо: сам оператор PLAY и как минимум 3 числа - аргументы. Так как числа в бейсике представлены и в ASCII, и в двоичной форме - то на каждый аргумент имеем 3 байта на ASCII + 6 байт двоичного представления + 1 байт на запятую или двоеточие. Итого около 31 байт на каждую строку Play

Садись, "два". PLAY играет стринги, в BASIC PLAY "A","B","C" займет 12 байт, из них только 3 байта, собственно, данных. В компилируемой программе (при условии ASCIIZ-строк) данные для такого PLAY займут 6 байт. Если использовать ПЗУшный PLAY, то на этом расход памяти кончится. А количество эффектов, которое им можно создать, конечно несравнимо меньше, чем их можно создать в музредакторе, но тоже огромно.

---------- Post added at 20:42 ---------- Previous post was at 20:32 ----------

Oleg N. Cher, Я поглядел повнимательнее - в PLAY-таки можно вломиться из машкода минуя всякие BASIC'овские парсинги строк. Но ограничений все равно хватает. Для начала, верно сказано, он блокирующий, да еще и запрещает прерывания на время своей работы (но BREAK опрашивает и зовет BREAK into PROGRAM если нажат). При ошибках в строках зовет 128k-обработчик ошибок, чем это черевато - не знаю. Буфер принтера портит нещадно. Уговорить его отказаться от воркспейса можно, но калькулятор все равно будет использовать. Ну и да, в разных ПЗУ может иметь разные адреса, а на компах без 128 Бэйсика работать не будет.
В принципе, его можно перетянуть и в ОЗУ, но тогда надо сильно пилить напильником - вырезать MIDI, переключалки ПЗУ, использолвание IY (если не запрещать прерывания).
И то, и то реально. Советом помогу, кодом - нет (только если примерами).

---------- Post added at 20:45 ---------- Previous post was at 20:42 ----------

Кстати, неплохих результатов можно добиться, если просто реализовать в либе отправку замаскированного множеством (если они поддерживаются) массива байт (али record'а) в регистры AY.

[Barmaley_m]

Ибо писателю на ЯВУ сделать свой плеер практически нереально,

ЯВУ и "для чайников" - это разные вещи, не надо их путать. Опытный программист, которому по плечу реализовать плеер на ассемблере, может быть, захочет реализовать на ЯВУ игру или что-нибудь еще. Почему нет? Экономия времени и усилий разработчика.

К тому же, зачем делать свой плеер на ассемблере, когда их и так полно? Просто обернуть плеер в библиотеку для ЯВУ - и все.

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

Объектные файлы и библиотеки обычно являются перемещаемыми. О каких ограничениях на расположение идет речь?

музыки, таблицы прерываний, режима прерывний....

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

10 RANDOMIZE USR 49152
20 RANDOMIZE USR 49155: PAUSE 1: GO TO 20

В случае размещения плеера по адресу 49152. Прекрасно играет. Что в этом сложного?

BASIC.PLAY('A', 'B', 'C'); // Ни о чем думать не надо!

Да, совсем ни о чем не надо думать... Кроме содержания строк для проигрывания. Чтобы получить не просто "пук", а интересный звук, надо совершенно неудобным образом составлять эти строки. В то время как в музыкальном редакторе можно быстро сделать нужный звуковой эффект с визуальной и звуковой поддержкой. Ну, не то, чтобы совсем быстро, но это реально самый легкий способ, легче в принципе не бывает.

А где такое обилие 128k BASIC only программ? А нету его. Потому что 128-й бейсик дает только 2 преимущества перед 48 - это RAM-диск с малоюзабельным MERGE! и пресловутый PLAY. И ради этих преимуществ программисту придется отказаться от поддержки 48к и писать в убогом и глючном 128к-редакторе.

Ну, это ты привел свои причины. А для других людей они могли быть другими. В частности - разочарование возможностями PLAY. Обычно всем возможностям находится применение, но этой так и не нашлось. Хотя задумывалась как "легкая, с малым порогом входа". И получилось, что все, кто делал AY-звук, делали его на ассемблере, пока трекеры не появились.

Библиотеки для чего? Для проигрывания музыки?

А почему нет? Разве ты не допускаешь мысли, что какой-нибудь начинающий программист, знающий, к примеру, си, но не знающий ассемблера, захочет написать игру с музыкой? Самый легкий путь - сделать музыку в трекере, скомпилировать, потом вызвать плеер из ЯВУ в соответствии с документацией. А ты что предлагаешь - через PLAY музыку делать?

Делать эффекты через плеер музыки? Если надо полсотни эффектов, сколько автор игры проведен в музредакторе чтобы их сделать,

А как иначе? Делать эффекты через PLAY - думаешь, будет быстрее? Чем проведение времени в музредакторе хуже проведения времени с компилятором ЯВУ? Сначала написать программу, потом ее подправить, потом скомпилировать, запустить, и так для каждого изменения? В музредакторе ты можешь сразу слышать результаты изменений параметров. Он явно более приспособлен для создания звука, в том числе эффектов, чем любая среда программирования.

скомпилить, разместить в памяти и играть с помощью универсального плеера?

На компиляцию тратятся секунды, и один раз, когда редактирование завершено. Размещение в памяти и проигрывание - те же затраты возникают в случае использования PLAY. От них никуда не уйдешь.

И вообще, какие могут быть сложности с размещением плеера в памяти, если плеер доступен в виде модуля библиотеки для ЯВУ? Размещает его в памяти компоновщик. Автоматически.

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

Это ты в реальности наблюдал или просто предполагаешь?

Кстати, неплохих результатов можно добиться, если просто реализовать в либе отправку замаскированного множеством (если они поддерживаются) массива байт (али record'а) в регистры AY.

Ну вот это гораздо более дельная идея. Фактически, речь идет о простом и маленьком плеере спецэффектов на ассемблере. Что наводит на мысль взглянуть на продукцию в этом направлении таких опытных товарищей, как Shiru.

[daniel]

ПЗУ в +2 от 128 отличается только двумя надписями.

этого достаточно чтобы некоторый софт не работал. Например ксорки с ПЗУ. Кстати говоря эта проблема встречалась и во многих отечественных клонах которые позволяли себе вместо 1982 Sinclair... вставлять что-то типа Elbrus-001...

[Vitamin]

в BASIC PLAY "A","B","C" займет 12 байт

Сравни хотя бы с плотностью, понятностью и, самое главное, возможностями формата от Super Sonic (кстати, не взлетевшего, чего уж говорить про PLAY).
http://zxtunes.com/software.php?id=9

[Alex Rider]

Переписать это на прерывания, да и всё.

Я думал про это, не получится так просто. PLAY оперирует с задержками 1/96 секунды, на прерываниях можно сделать только 1/48,5 ~ 1/60 в зависимости от модели. На первый взгляд, в PLAY придется шибко дофига перепилить чтобы от этого отвязаться.