Разработка и ромхакинг > Ромхакинг и программирование
Sega MD Sound (Yamaha 2612/PSG) - Что оно такое и с чем его едят
<< < (2/4) > >>
r57shell:
Блин, с GEMS бы так (.
Segaman:

--- Цитата: goodbye от 10 Ноябрь 2012, 14:52:09 ---пусть :)
полюбому лучше слушать такое стерео чем хреновое моно в оригинале.

--- Конец цитаты ---
блин это то же самое что китацские колонки наворачивать.
у мну были одни. так они моно. я их разобрал, узнал че за усилок стоит. стоял стерео, но звук моно.
изучил схему...спаяли вместе :lol:
r57shell:
vladikcomper, тесты на железе были? узреть можно?
vladikcomper:
Конечно были. Все выпущенные версии Mega PCM и дополнения к ним (в виде гидов для Соник 1) проверялись на реальном железе, и широкой общественности уже предоставлялся полностью работоспособный продукт, что было подтверждено экспериментально =)

К сожалению, у меня нет флэш катриджа, так что приходилось просить разных людей. В частности, я протестировал и это:
http://www.youtube.com/watch?v=LCDx7YUzFZ4

Человек, который для меня это протестировал, даже сделал запись звука с железа, так что я сам мог услышать, как оно в реале звучит. Оказалось довольно впечатляюще, но чуть хуже, чем в эмуляторах, потому что на реальном железе действуют многие факторы, которые удерживают работу Z80, а значит и вывод звука (например, Z80 останавливается, когда выполняется DMA, что не эмулируют эмуляторы. во всех деталях я это описал здесь: http://forum.sonic-world.ru/topic/20447-sonic-1-mega-pcm-driver/page__st__25#entry253074637)

Узреть, увы не получится. Запись ту я уже удалил, когда чистил файлы.
Добавлено позже:

--- Цитата ---Блин, с GEMS бы так (.

--- Конец цитаты ---
С GEMS такого точно не добиться, как и со всеми звуковыми движками, которые полностью работают на Z80. Они должны каждый кадр отвлекаться на обновление FM/PSG звука, так что непрерывно выводить DAC никак не получится. Задержки в выводе вызовут нехилое падения качества.

Например, звуковая волна была такой:

а из-за задержек вывода звука сильно искажается:
MetalliC:

--- Цитата: vladikcomper ---на реальном железе действуют многие факторы, которые удерживают работу Z80, а значит и вывод звука (например, Z80 останавливается, когда выполняется DMA, что не эмулируют эмуляторы.
--- Конец цитаты ---

а ты уверен в этом ? если мне не изменяет склероз, во время DMA Z80 вполне себе продолжает работать, разумеется в это время обращаться к области картриджа нельзя.
то есть если Z80 будет играть PCM из буфера в своей памяти (который периодически должен наполняться M68K) вывод звука будет постоянным и равномерным.

и я кстати не уверен, что нормальные эмуляторы типа Regen или GenesisPlusGX не эмулируют это дело.
r57shell:

--- Цитата: vladikcomper от 14 Ноябрь 2012, 19:35:06 ---Добавлено позже:С GEMS такого точно не добиться, как и со всеми звуковыми движками, которые полностью работают на Z80.

--- Конец цитаты ---
vladikcomper, твой драйвер что ли не только в Z80 работает? он ещё и жрёт постоянно такты M68k?
моё представление крутого звукового драйвера: живёт в z80, а M68k только посылает команды. Ну и логично время от времени z80 читает через своё "окно" - нужный ему участок рома.
Добавлено позже:
На сколько я понимаю, z80 работает параллельно с M68k, и M68k не должен подпинывать z80 никакими прерываниями или прочей лабудой.
Единственное, ага, отсановки могут быть только во время синхронизаций и во время "не успевания" чего-либо, например чтения ))).
Segaman:
MetalliC, ты гений!
так же по моему и в гемс делается.
сам видел в дюне.
vladikcomper:

--- Цитата ---а ты уверен в этом ? если мне не изменяет склероз, во время DMA Z80 вполне себе продолжает работать, разумеется в это время обращаться к области картриджа нельзя.
--- Конец цитаты ---
Да, во время DMA Z80 может спокойно работать, пока он не обратиться к РОМу.
Обращаться к РОМу можно, но как раз при этом Z80 останавливается вместе с 68K, пока DMA не будет завершен (только тогда 68K даст Z80 ответ).

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

Использование буферов требует намного больше ресурсов, как памяти Z80, так и времени на его наполнение. В случае с прямым чтением из РОМа надо просто прочитать, а в случае с буфером, нужно прочитать, сохранить, чтобы потом прочитать. Скажем, чтобы воспроизводить сэмпл на частоте дискретизации ~26 kHz, нужно за один кадр заносить в буфер примерно 433 байта. Такой объем памяти будет переноситься очень долго (к тому же речь идет о Z80 и его 8-битной шине), а это выливается в задержки в воспроизведении. Качество будет хуже некуда.


--- Цитата ---то есть если Z80 будет играть PCM из буфера в своей памяти (который периодически должен наполняться M68K) вывод звука будет постоянным и равномерным.
--- Конец цитаты ---
Наполнение со стороны 68K еще хуже. Замучаешься с синхронизацией. Z80 не может сгенерировать прерывание для 68K, чтобы пополнить буфер в нужный момент. Т.е. 68K понятия не имеет, когда наполнить буфер, и сколько z80 успеет проиграть за определенный интервал времени.

И Z80 все равно придется останавливать во время выполнения, а значит - от какой проблемы пытались уйти, к тому и придем.


--- Цитата ---и я кстати не уверен, что нормальные эмуляторы типа Regen или GenesisPlusGX не эмулируют это дело.
--- Конец цитаты ---
Да, эмуляторы остановку Z80 при DMA не эмулируют. В этом я сам убедился.
Я также сомневаюсь, что они эмулируют так называемый 'cycle stealing' между процессорами. Когда Z80 обращается к РОМу через шину 68K, он крадет у 68K по 4 цикла на каждый акт чтения или записи (да, Z80 может даже писать в 68K RAM, проверено на железе).


--- Цитата ---vladikcomper, твой драйвер что ли не только в Z80 работает? он ещё и жрёт постоянно такты M68k?
--- Конец цитаты ---
У меня лишь DAC-драйвер. Все, что он делает - проигрывает PCM-ки (но делает это он профессионально =Р).
В Соник 1 используется звуковой движок SMPS, и он работает на стороне 68K. Все такие движки состоят из двух частей: сам движок, обновляющий FM/PSG (со стороны 68k), и собственно DAC-драйвер (со стороны Z80). Mega PCM - это мой новый драйвер, который может заменить родной драйвер в Соник 1, чтобы расширить возможности и качество воспроизведения цифровых сэмплов в игре.

Да, когда звуковой движок работает на стороне 68k, это отнимает немного времени от работы движка самой игры. Но у них есть одно преимущество. Только с ними можно добиться максимально возможного качества воспроизведения DAC-сэмплов (что я и делаю =Р). Ведь Z80 может непрерывно выдавать звук, не отвлекаясь ни на что. А в движках полностью на Z80, Z80 должен отвлекаться на обновление FM/PSG.
MetalliC:

--- Цитата: vladikcomper ---Скажем, чтобы воспроизводить сэмпл на частоте дискретизации ~26 kHz, нужно за один кадр заносить в буфер примерно 433 байта. Такой объем памяти будет переноситься очень долго
--- Конец цитаты ---

8бит 26кГц нежатый pcm это жирно слишком. да и где такой объем хранить ? карика не хватит же
в идеале нужно чтобы хватало 256б буфера, например пользовать 4бит ADPCM (или другое сжатие) и/или меньшую частоту.

--- Цитата: vladikcomper ---Наполнение со стороны 68K еще хуже. Замучаешься с синхронизацией. Z80 не может сгенерировать прерывание для 68K, чтобы пополнить буфер в нужный момент. Т.е. 68K понятия не имеет, когда наполнить буфер, и сколько z80 успеет проиграть за определенный интервал времени.
--- Конец цитаты ---

не вижу никаких проблем, с кольцевым буфером на стороне Z80 в 256байт всё легко и просто.
Z80 просто извлекает из этого буфера данные и играет, даже проверок при инкременте не нужно - допустим если указатель на буфер в HL - INC L. из минусов - этот L нужно постоянно записывать в память.

далее, раз в кадр M68K останавливает зилог, читает где сейчас его указатель, также берет указатель куда был записан последний байт в прошлый раз, вычитаем и получаем кол-во байт которое надо "долить", ну и доливает их в буферок.
короче, реализуем самый элементарнейший ринг-буфер.

и что-то мне кажется, что копирование не более чем 256байт один раз в кадр даст ощутимый глюк звука.
feos:
vladikcomper, ты случайно не эмукодер?
vladikcomper:

--- Цитата ---8бит 26кГц нежатый pcm это жирно слишком. да и где такой объем хранить ? карика не хватит же
в идеале нужно чтобы хватало 256б буфера, например пользовать 4бит ADPCM (или другое сжатие) и/или меньшую частоту.
--- Конец цитаты ---
В одном своем хаке я играл с Mega PCM целые песни, почти у всех частота была 22 kHz. Умудрился запихнуть пять штук (правда некоторые были коротки). Хотя песни занимали почти весь РОМ, качество на такой частоте было превосходное.


--- Цитата ---в идеале нужно чтобы хватало 256б буфера, например пользовать 4бит ADPCM (или другое сжатие) и/или меньшую частоту.
--- Конец цитаты ---
Буфер все равно же наполнять придется. Так что остановки в выводе звука неизбежны.

По времени выходит так: самый быстрый способ для загрузки буфера на Z80 - использовать LDIR, тогда на загрузку каждого байта уйдет 21 цикл + 16 циклов по окончанию переноса.
Получается 21*256+16 = 5392 цикла (не считая дополнительного кода на инициализацию регистров для LDIR, загрузку банка и т.д и т.п.)
По времени: 5392 / 3,58*10^6 = 0,0015 с, что составляет примерно 9% времени отображения одного NTSС-кадра (и это не считая времени задержки ответа 68k!). Дак тут все DMA в разы быстрее пройдут, чем наполнится буфер, а если вдруг наполнение буфера придется на работу DMA, время ожидания удвоится.

Чтобы воспроизводить PCM хотя бы на частоте ~15 kHz, неизбежно придется наполнять 256-байтный буфер каждый кадр. Учитывая вышесказанное, очень затратно получается.
Если использовать DPCM (не путать с ADPCM, этот алгоритм и 68K едва ли потянет), тут слегка получше: для той же частоты ~15 kHz придется наполнять буфер примерно раз в два кадра, но это тоже не очень-то выгодно выходит.

В общем, как ни крути - никакой выгоды в буферах в случае с воспроизведением DAC-сэмплов на Сеге нет.


--- Цитата ---vladikcomper, ты случайно не эмукодер?
--- Конец цитаты ---
Нет, но железо и некоторые нюансы знаю неплохо =)
feos:
vladikcomper,  а нет желания присоединиться к одному буйно развивающемуся проекту? Там практически готово само ядро, но звук еще в разработке.
MetalliC:

--- Цитата: vladikcomper ---По времени выходит так: самый быстрый способ для загрузки буфера на Z80 - использовать LDIR, тогда на загрузку каждого байта уйдет 21 цикл + 16 циклов по окончанию переноса.
--- Конец цитаты ---

самый быстрый способ LDIR  :lol: :lol: :lol: Z80-чайник детектед
давно так не смеялся, тебе еще кодингу на Z80 учиться и учиться
ощутимо быстрее будет в цикле подряд по несколько штук LDI (16 тактов вместо аж 21)
а еще быстрее стеком типа
ld sp, откуда
pop hl
pop de
pop bc
exx
и тп
ld sp, куда
push bc
push de
push hl

я думаю идея понятна
быстрее чем стеком перенос данных на зилоге не сделаешь, короче тебе еще нужно изобретать велосипеды уже использовавшиеся в демках и игрушках на спектруме аж двадцать лет назад ;)
Добавлено позже:

--- Цитата: vladikcomper ---(не путать с ADPCM, этот алгоритм и 68K едва ли потянет
--- Конец цитаты ---

ты видел демку BadApple!!!9 в соседней теме ? так там Z80 вполне себе играет 4bit 13kHz ADPCM

более того, глянь вот этот mod-плеер для Спектрума, там на том же 3,5Мгц Z80 играются четыре канала на 10кГц с разным pitch каждого, да еще и с различными эффектами.
в общем много чего можно сделать на зилоге с такой частотой, талант только нужно иметь.
vladikcomper:

--- Цитата ---Z80-чайник детектед
--- Конец цитаты ---
Серьезно, в чем смысл такого утверждения? Особенно в рамках ответа на мой предыдущий пост.
Я постарался во всех деталях описать все плюсы и минусы использования буферов, но вместо этого ты разглядел одно лишь предложение про LDIR и ответил в духе "ой-ты-ваще-чайник-рассмешил-меня, потому что вот в этом предложении описан не самый крутой способ, можно извращаться и получше".

Если тебя интересует мой опыт программирования на Z80, то в этой области я действительно не претендую на звание профи, и у меня нет в планах постоянно им заниматься. Оно мне понадобилось только для того, чтобы реализовать свою идею - написать годный DAC-драйвер.

К слову, Mega PCM - это вообще первое, что я написал на Z80. Когда приступал, был чайником, конечно, ведь опыта программирования конкретно на Z80 было ноль. В конце же работы над проектом я уже приобрел немало опыта. Моей задачей было написать серьезный и функциональный драйвер, с оптимальным кодом. И думаю, со своей задачей я справился, ведь то, что мой драйвер, с огромным количеством новых возможностей, работает быстрее оригинального драйвера Соник 1, в котором почти ничего нет, уже о чем-то говорит.


--- Цитата ---ощутимо быстрее будет в цикле подряд по несколько штук LDI
--- Конец цитаты ---

Ну, допустим, ты будешь использовать LDI, да. Ну быстрее, да. Ощутимо. К черту цикл, давай рассмотрим самый наилучший способ - 256 таких инструкций, идущих подряд. (Что кстати займет целых пол-кило памяти).
Ну получится в итоге, что исполнение занимает 7% от времени отображения NTSC-кадра. И все равно не выгодно.


--- Цитата ---а еще быстрее стеком типа
--- Конец цитаты ---
Ты уверен? Способ-то остроумный. Для переноса 6 байт прокатит (лучше не придумаешь), но нашем случае - сомневаюсь.

Скажем, как ты будешь оперировать оффсетами "куда" и "откуда"? Если оффсеты "куда" статичные и их можно каждый раз загружать как ld sp, xxxx, то в РОМе каждый раз приходится читать с разных мест. В таком случае, по когда ты получил 6 байт из буфера, лучшее, что ты можешь сделать - сохранить значение sp в память, потом записать буфер, заново загрузить sp из памяти. И так каждый раз. А это уже выливается в 40 циклов (20 на ld (xxxx),sp и 20 на ld sp, (xxxxx)). Ну в лучшем случае, это будет на 1-2% быстрее, но, думаю, очевидно, что пляски с сохранением и загрузкой значения стека сводят на нет всю гениальность этого метода + жирный размер кода.
Добавлено позже:

--- Цитата ---ты видел демку BadApple!!!9 в соседней теме ? так там Z80 вполне себе играет 4bit 13kHz ADPCM
--- Конец цитаты ---
Ты хотя бы видел сам алгоритм ADPCM? Аддаптивная Диференциальная Импульсно Кодовая модуляция.
Алгоритм подразумевает изменение шага квантования (шаг квантования "аддаптируется" под изменения волны), причем для предсказания следующего положения волны требуется умножать значение разности волн на величину шага.
Я знаю одного человека, великолепного программиста и разработчика алгоритмов, который написал свою, упрощенную реализацию ADPCM на 68K. Насколько помню, частота звука была 22 kHz. И это на 68K!

Мало того, что Z80 в два раза медленнее, так там еще нет операции умножения, а работа с 16-битными числами предоставляет некоторые трудности (в стандартной реализации 4-bit ADPCM все расчеты идут в 16-битных числах, разрядность выходного сигнала - тоже 16 бит). Это сложно, очень сложно. На гране возможного.

У меня есть мечта. Может когда-нибудь, я попробую реализовать ADPCM на Z80. Может быть, использование большего количества таблиц для промежуточных рассчетов поможет с этим. В любом случае, реализовать такой алгоритм на приемлимой частоте дискретизации, а я хочу более 8 kHz, очень сложно в поем представлении. Если кто-то написал реализацию ADPCM на Z80, то я снимаю перед ним шляпу - это действительно верх мастерства.
DrMefistO:
Я вставлю свои пять копеек, собственно по сути темы. Хочу понять и разобрать работу одного звукового драйвера на Z80: адреса, работа с 68k. Но какие-то все доки по Z80 сухие, ограниченные коротким описанием команды. А что оно делает, что получается и т.д. - хз.
Поэтому, кто имеет хорошие доки по Z80, выложите, или дайте ссылки, плиз. Важно именно сочетание 68k<->Z80. Переписывать драйвер у меня нет намерений, я лишь хочу понять как оно работает.
r57shell:
DrMefistO, пробовал отлаживать z80 прям во время игры?
DrMefistO:
Да, и твоим дебаггером кстати, но, не помню что, но что-то меня не получилось сделать в нем. Поэтому забил на такой способ. Лучше отладка+анализ дизазма.
r57shell:
надо помнить что у меня он глючно показывает регистры. не удалось воткнуться лучше, да и мне этого хватило, вот и забил.
DrMefistO:

--- Цитата: r57shell ---надо помнить что у меня он глючно показывает регистры.
--- Конец цитаты ---

Во, точно!) Именно по этому я и забил. А другого норм дебагера пошагового и нету( Так что ищу гуд доки)
MetalliC:

--- Цитата: DrMefistO ---Поэтому, кто имеет хорошие доки по Z80, выложите, или дайте ссылки, плиз.
--- Конец цитаты ---

я учил асм Z80 по вот этой книжке, большая часть книги тебе не нужна, только с стр. 18 общее описание проца и с стр. 38 система команд.
Добавлено позже:

--- Цитата: DrMefistO ---А другого норм дебагера пошагового и нету
--- Конец цитаты ---

в MESS/UME есть же, в консоли дебагера пишешь "focus 1" и он переключится на Z80, focus 0 переключает назад на Моторолу.
Навигация
Главная страница сообщений
Следующая страница
Предыдущая страница

Перейти к полной версии