ПЗУ в +2 от 128 отличается только двумя надписями.Сообщение от daniel
+3 перелопатили посеръёзней для работы с контроллером дисковода.
поэтому также поплыл синтаксис использования рамдиска.
сильно сомневаюсь что в ПЗУ моделей +2AB/+3 есть разница
ПЗУ в +2 от 128 отличается только двумя надписями.
+3 перелопатили посеръёзней для работы с контроллером дисковода.
поэтому также поплыл синтаксис использования рамдиска.
сильно сомневаюсь что в ПЗУ моделей +2AB/+3 есть разница
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Что такое в твоем понимании "самописный плеер"? Кто его пишет? Автор библиотеки или автор прикладной программы? Если первое - то плеер такой же "самописный", как и оператор бейсика PLAY. Не Свыше же он возник, написанный кем-то непогрешимым.
Насчет низкого порога вхождения PLAY - это ты откуда взял? С чем сравнивал порог вхождения?
Стоит задуматься, почему оператором PLAY по сути никто не пользовался за весь период существования Spectrum 128 с 1986г, особенно после того, как этот стандарт стал базовым для ZX, а не факультативным. И почему, с другой стороны, такое широкое распространение получили ассемблерные плееры. Как при таком обилии 128-Only программ - оператором Play никто не пользуется?
ЯВУ - это не значит "язык для чайников". На ЯВУ должно быть возможно писать не только мелкие поделки, но и серьезные программы.
А кто предлагает игрописателям на ЯВУ самим писать ассемблерные вставки для звука? Тут идет обсуждение как раз о том, чтобы автор _библиотеки_ для ЯВУ предоставил указанные ассемблерные процедуры, чтобы прикладной программист мог их просто использовать. В этом случае, почему бы сразу не предоставить нормальные процедуры без искусственных ограничений, накладываемых PLAY?
Библиотека для ЯВУ - это и есть рантайм. Глючным он будет или нет - зависит от автора, но какие-то хотя бы мелкие ошибки скорее всего неизбежны. И этот рантайм неизбежно будет отжирать память. Хочешь избавиться от этого - откажись от возможностей рантайма. Самая экономная по памяти программа - это отсутствие программы. Вся память свободна. Профит. Заодно и глюков не будет.
Никто и не предлагал изобретать "серебряную пулю" на все случаи жизни. Должен быть какой-то разумный компромисс между возможностями и затратами на их реализацию.
А вот эти постоянные отсылы к экономии памяти... К чему это? Не во всякой программе узким местом является именно память. Сколько я писал программ на спектруме, разной сложности, и даже создавал на Z80 встраиваемые приложения с ограниченной памятью - экономить приходилось, но не так, чтобы уж прямо совсем по дну скрести, чтобы отказываться от музыкального плеера ради лишней пары десятков байт. Не стоит раздувать из мухи слона.
Конечно все. Прикладной программист использует наиболее подходящий для его программы, а компоновщик включит выбранный программистом плеер (или урезанную звуковую библиотеку с минимальными возможностями) в сборку проекта.
Более того, я бы в первую очередь включал в библиотеку ЯВУ те плееры, которые покороче (хотя и медленнее). В большинстве применений это лучший компромисс, и только там, где идет бескомпромиссная оптимизация по скорости, следует применять "быстрые" плееры.
Сильно короче? Сомневаюсь. Для воспроизведения одной ноты по всем трем каналам необходимо: сам оператор PLAY и как минимум 3 числа - аргументы. Так как числа в бейсике представлены и в ASCII, и в двоичной форме - то на каждый аргумент имеем 3 байта на ASCII + 6 байт двоичного представления + 1 байт на запятую или двоеточие. Итого около 31 байт на каждую строку Play. В компилированной музыке на каждую ноту тратится 3-4 байта на канал, итого 12 байт против 31.
А даже и не важно. Ибо писателю на ЯВУ сделать свой плеер практически нереально, а сторонний плеер, висящий на прерываниях, будет диктовать свои малопонятные ограничения типа расположения себя любимого, музыки, таблицы прерываний, режима прерывний.... Это все же сложнее, чем
Код:BASIC.PLAY('A', 'B', 'C'); // Ни о чем думать не надо!А где такое обилие 128k BASIC only программ? А нету его. Потому что 128-й бейсик дает только 2 преимущества перед 48 - это RAM-диск с малоюзабельным MERGE! и пресловутый PLAY. И ради этих преимуществ программисту придется отказаться от поддержки 48к и писать в убогом и глючном 128к-редакторе.
Библиотеки для чего? Для проигрывания музыки? Да, с 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.
Последний раз редактировалось Alex Rider; 07.11.2014 в 20:34.
этого достаточно чтобы некоторый софт не работал. Например ксорки с ПЗУ. Кстати говоря эта проблема встречалась и во многих отечественных клонах которые позволяли себе вместо 1982 Sinclair... вставлять что-то типа Elbrus-001...
Сравни хотя бы с плотностью, понятностью и, самое главное, возможностями формата от Super Sonic (кстати, не взлетевшего, чего уж говорить про PLAY).
http://zxtunes.com/software.php?id=9
ЯВУ и "для чайников" - это разные вещи, не надо их путать. Опытный программист, которому по плечу реализовать плеер на ассемблере, может быть, захочет реализовать на ЯВУ игру или что-нибудь еще. Почему нет? Экономия времени и усилий разработчика.
К тому же, зачем делать свой плеер на ассемблере, когда их и так полно? Просто обернуть плеер в библиотеку для ЯВУ - и все.
Объектные файлы и библиотеки обычно являются перемещаемыми. О каких ограничениях на расположение идет речь?
Где ты вообще видел плеер, который накладывает такие жесткие ограничения? И даже если видел - кому он нужен, если есть нормальные плееры без подобных ограничений? Если плеер доступен в виде исходника - его можно скомпилировать на любой адрес. Компилированная музыка обычно тоже является перемещаемой. Прерывания - это вообще вне компетенции плеера, ими занимается вызывающая программа. У самого плеера есть только две точки входа: INIT и PLAY, первую надо вызвать перед проигрыванием, вторую вызывать каждое прерывание. Даже на бейсике можно встретить что-то типа:
В случае размещения плеера по адресу 49152. Прекрасно играет. Что в этом сложного?Код:10 RANDOMIZE USR 49152 20 RANDOMIZE USR 49155: PAUSE 1: GO TO 20
Да, совсем ни о чем не надо думать... Кроме содержания строк для проигрывания. Чтобы получить не просто "пук", а интересный звук, надо совершенно неудобным образом составлять эти строки. В то время как в музыкальном редакторе можно быстро сделать нужный звуковой эффект с визуальной и звуковой поддержкой. Ну, не то, чтобы совсем быстро, но это реально самый легкий способ, легче в принципе не бывает.
Ну, это ты привел свои причины. А для других людей они могли быть другими. В частности - разочарование возможностями PLAY. Обычно всем возможностям находится применение, но этой так и не нашлось. Хотя задумывалась как "легкая, с малым порогом входа". И получилось, что все, кто делал AY-звук, делали его на ассемблере, пока трекеры не появились.
А почему нет? Разве ты не допускаешь мысли, что какой-нибудь начинающий программист, знающий, к примеру, си, но не знающий ассемблера, захочет написать игру с музыкой? Самый легкий путь - сделать музыку в трекере, скомпилировать, потом вызвать плеер из ЯВУ в соответствии с документацией. А ты что предлагаешь - через PLAY музыку делать?
А как иначе? Делать эффекты через PLAY - думаешь, будет быстрее? Чем проведение времени в музредакторе хуже проведения времени с компилятором ЯВУ? Сначала написать программу, потом ее подправить, потом скомпилировать, запустить, и так для каждого изменения? В музредакторе ты можешь сразу слышать результаты изменений параметров. Он явно более приспособлен для создания звука, в том числе эффектов, чем любая среда программирования.
На компиляцию тратятся секунды, и один раз, когда редактирование завершено. Размещение в памяти и проигрывание - те же затраты возникают в случае использования PLAY. От них никуда не уйдешь.
И вообще, какие могут быть сложности с размещением плеера в памяти, если плеер доступен в виде модуля библиотеки для ЯВУ? Размещает его в памяти компоновщик. Автоматически.
Это ты в реальности наблюдал или просто предполагаешь?
Ну вот это гораздо более дельная идея. Фактически, речь идет о простом и маленьком плеере спецэффектов на ассемблере. Что наводит на мысль взглянуть на продукцию в этом направлении таких опытных товарищей, как Shiru.
Господа, спасибо за активное обсуждение. Уточню задачу. Я портирую игру Dark Woods с QuickBasic 4.5 для DOS. Всего в игре 7 звуковых схем:
Стоит задача с минимальной сложностью, но с максимальной точностью воспроизвести подобие этих звуков на AY. Соответственно по аналогии я вспомнил про PLAY из Basic128. Полагаю, блокируемость звуков в проигрывателе ПЗУ не станет серьёзным препятствием. Ведь там скорее всего используется банальная задержка. Переписать это на прерывания, да и всё.Код:' QB4.5 PLAY "o0l50c" PLAY "MBo4l64fgbbcc" PLAY "MBo5l64cdefgabo6l64cdefgab" PLAY "MBo0l64bagfedc" PLAY "MBo3l64cdefgbg" PLAY "MBo1l64cdefgabo2cdefgabo3cdefgabo4cdefgabo5l5cl20cco4l8bagbl5a" PLAY "MBo0l15ffgfg+fg+a"
Для SDL-версии игры я вырезал эти звуки прямо из DosBox (Ctrl+F6 и потом - звук в wav-формате в папке DOSBox\capture). Но у меня не получается вырезать звук без пауз в начале и конце (не получается вырезать паузы до микросекунд с точностью), а даже маленькая пауза уже портит картинку игры со звуком. Есть программы для обработки звуков, которые сами ищут паузы (например, mp3DirectCut), но они заточены всё-таки не для этого.
Усложним вопрос. Какой библиотекой можно генерировать AY-подобные звуки для Windows/Linux (SDL)? Сейчас для вывода wav использую SDL_mixer.dll
Обидно, что код самой игры без UPX'а весит 30 кб, а с SDL_mixer и wav'ками получается около 500 кб.
Я думал про это, не получится так просто. PLAY оперирует с задержками 1/96 секунды, на прерываниях можно сделать только 1/48,5 ~ 1/60 в зависимости от модели. На первый взгляд, в PLAY придется шибко дофига перепилить чтобы от этого отвязаться.
И все? Ну тогда я могу предложить решения, основанные не на эмуляции, а на интерпретации аргументов PLAY Qbasic и конвертирования этого в какой-нибудь формат с последующим воспроизведением на AY.
Какой целевой язык? Допускается ли реализация функции "Play" на ассемблере?
А вот это непонятно. Любой звуковой редактор должен решать эту проблему при условии, что из DosBox получается нормальный wav. Никаких форматов mp3 - компрессия должна выполняться после, а не до обработки.
Микросекундная точность для звука - это в принципе недостижимо, т.к. на частоте дискретизации 44100Гц промежуток времени между соседними отсчетами составляет ~23мкс. Кроме того, человек даже такую задержку не заметит на слух. Задержки в 20-50 миллисекунд (это в 1000 раз больше, чем микросекунды) на слух никак не будут восприняты. Когда я совмещал видеоряд и звук в тех случаях, когда синхронизация между ними была нарушена, точности даже в 100мс (1мс=1000мкс) хватало, и разницы никак не было заметно.
Я бы делал свою, основанную на эмуляции AY или Atari Pokey (как автор mzpokeysnd.c я бы скорее всего выбрал второй вариант). Дело в том, что генерация прямоугольных звуковых сигналов - это нетривиальная задача. Чтобы обеспечить высокое качество звука, необходимо привлекать цифровые фильтры и некоторые особые, нестандартные их реализации.
Сделал в программе.
Хорошая программа. Немного топорный интерфейс. Нельзя сделать эффект с огибающей. А так - нормально.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
