Нет у меня понтевы, но проблем быть не должно.
Вид для печати
HardWareMan, раздумываю над конвертером , вот смотрю поток VGM
идет команда 28 , 00 ,то есть KEY OFF , а за ней пошли 28,04 28,01 28,05 28,02
И это все одна за одной и так может быть подряд до 20-30 команд , в этом нет никакого смысла , и весь файл забит таким хламом , и это я пока вижу потому что команда 28 часто используется , а как анализировать поток если команды для других регистров бестолковые... ???
- - - Добавлено - - -
PS мне кажется что создатель ранних версий формата решил не заморачиваться с правильными задержками ,а тупо сделал их при помощи такого хлама ,в итоге файл весит вместо 20-100к где то 1000-3000к , и этот формат используют до сих пор так как эмуль которым это грабят никто не правил.
Этой ерундой могут заниматься и драйвера. А дамп просто дамп. И эмуль тут ни причем.
Не не , как раз причем , только один эмуль может грабить VGM это Kega Fusion , и как раз он и выдает то ,что я привел выше , и треки идут с мусором и огромных размеров , есть типа сжималка VGM ,я ее пробовал она немного но не существенно делает файл меньше оставляя весь хлам.
В Кеге просто сделано сохранение дампа записей в регистры YM2612. Я делал дамп записи в регистры у драйвера Battle Toads & Double Dragon - там тоже хватало мусора без смысла.
Что то там не доделано , так как во всех мелодиях такой мусор как приводил выше , а глядя код плеера должно быть все иначе - запись регистров YM2612 пауза длинной в прерывание , опять запись регистров YM2612 (тоесть работа человеческого плеера) , а в сохраненном дампе из кеги мы видим совсем другую картину ,запись регистрв ,мусор ,запись регистров ,мусор. Дойдут руки сделаю осциллограмму , там это хорошо видно.
- - - Добавлено - - -
PS вот deflemask с форматом VGM 1.7 музыку VGM делает по человечески , регистры, пауза ,регистры ,пауза , плохо что чувак конвертер под трекер не сделал.
- - - Добавлено - - -
На минуту проигрывания VGM должно уходить в среднем 50-100 кб потока , а кега этот же поток делает 500-1000 кб
Когда я это делал, Кеги еще не существовало. Я напаивал дополнительные 8КБ ОЗУ (точнее, расширял штатное, чтобы не миррорилось), подключался к реальной сеге Орионом 128 через шину Z80 (МРН32 с боку был, использовал BUSR/BUSA, развязанная шинка). Идея была проста: я подменял код записи в YM (там 2 блока на RST висели) и оно помимо записи в YM копировало в дополнительные 8К адрес (0/2), регистр и данные (3 байта на запись). Вмещалось не особо много - после прогона играло несколько нот. Но связка 28/xx мелькала постоянно.
Картинок нет потому, что в 90х фотика у меня не было, железо, ессно, все утеряно после 3х переездов. А вот литература осталась. Есть тетрадка, там 2 или 3 версии платы расширения для Ориона для сопряжения с Сежкой. Я даже софт писал, он дампил звуковые сэмплы из картриджей. Да и вообще, навигацию делал. А еще, в качестве баловства, когда я себе собрал АЦП/ЦАП плату на ИР17+ПА1 2шт, я захватывал шинку у Z80 и считывал байт и отпускал. Адрес захвата: в кольце 1F00-1FFF. У GEMS это буфер для ЦАП. Орион играл цифровые сэмплы паралельно Сеге, лол. Иногда даже без щелчков склейки...
Господа железячники за темой следящие , возник вопрос ,а вообще думаю это неоходимость , на ZX-Bus есть несколько ног земли и питания , а не обсудить ли возможность ввести аналоговую землю и питание ?
Для обычных карт роли это не сыграет ,а вот для звуковых это просто необходимость , ибо никакими другими методами помехи от цифры не побороть.
Но поставив стаб ,через общую землю лезет ого го помех , если ты в своих компах сводишь на общей земле звук с бипера ,ау ,ковокса ,и карты то помех на звуке соберется много. Это в теории ,так как у меня нет в наличии твоих компов. Или я не прав ?
- - - Добавлено - - -
так курочить не надо , надо выбрать два пина на которые пойдет питание и земля прямо с бп , и мы получим прекрасную развязку для аналога.
Ну если бы ты поглядел все таки карты, то мог заметил что и землю я разделяю через 1 Омный резистор.
По шумам, шумомером не мерял, но на слух вроде ничего не пролезает. Единственно что надо понимать в каком месте объединять две земли. Их как правило объединяют в месте интенсивного обмена данными (по сути там где шина данных). Я уже с этим сталкивался в ZXM-SoundCard Extreme, когда полуличл кучу помех от того что не в том месте был резистор.
В добавок я на свои карты ставлю доп 5.25 разъем питания, что дает возможность при необходимости запитывать ее отдельно. Хотя конечно питание не отвязано в этом случае от основной плате. Но на Фениксе, как и на Эво есть джампер +12В, который можно снять и тогда вообще +12В на питание аналога будет не зависимым от питания платы компа.
В любом случае стандарт шины уже устоялся и не стоит его пересматривать в рамках существующих компов. Не каждый готов курочить комп, резать дороги и тянуть провода.
может Молекс какой нибудь отдельно для аналога подключать - и помех поменьше и в стандарт разъёма не надо лезть.
Mick, а в твоих компах делаются входы для дополнительного мекширования звука для карт ? Что бы весь звук (beep,ay,covox и т.д) не дергая разьемы шел в одни колонки ?
не совсем понял , сейчас в разъездах , распиши чуть подробнее, что тебе надо с RDY
Я только за ,делай , но смотри ,через порты софтина работает дольше ,для vgm это критично, поэтому я остановился на записи в память , есть мысли в финальной версии сдвинуть эти адреса с экрана,в идеале в буфер принтера , или можно вообще в ПЗУ.
Второе ,если будешь делать на плисине ,попробуй предусмотреть возможность спбоса SN-ки , для этого в нее надо записать пяток команд , иначе она гудит, то что написано аппаратно по мануалу у меня не прокатило.
Я насколько понял процесс записи в регистр SN-ки занимает 32 такта его частоты или не так.
Ты как бы пытаешься не держать шину эти такты и используешь регистр защелку. Но это все равно ведь не спасет от например повторного обращения (тут же), то есть один фиг тебе надо выждать в плеере необходимое количество времени для повторной записи. Иными словами сигнал RDY логичнее как бы еще и проверять программно, чтобы не было коллизий.
Или я не понял процесс.
Использование портов не подразумевает использовать из в vgm, хотя не отменяет. Скорее это дополнение, для любительского творчества.
Порты Ямахи предполагаю нацепить на те же порты что и Мунсаунд, где сидит OPL.
К тому же можно подцепить сигнал IRQ, для прерываний от карты, хотя надо поглядеть что их вызывает. Если как в Мунсаунде таймер, то будет совсем шикарно.
Ну Плисина этот громко сказано, скорее всего CPLD типа EPM7032STC44 или EPM7064STC44
Да , около 9 микросекунд.
Да.
В теории да ,но на практике я наоборот не успеваю подготовить данные и обработать данные в потоке , но тут переживать нечего , при выборке 44 кГц , мы пишем раз в 79 тактов , смысл проверять готовность SN-ки нет. А в каких то своих плеерах ,если ты их будешь писать ,думаю это не станет проблемой , Z80 не пуля )
Но если тебе для успокоения хочется ,то заведи для проверки RDY , но пока ты его программно будешь пытаться проверить ,он уже выйдет в готовность , не вижу смысла.
Попробуй на асме при выводе в нее данных и чтении через порта RDY такты посчитать.
это само себя исключает из объяснения выше.
Задействовать таймер от ямахи ? Можно ,но на VGM его некогда проверять ,нет у нас ни одного свободного такта , а на плеерах с перываниями ,нам это в обще не надо ,все по классике IM2. И в сеговском совфте таймер нигде не используется так как он не опрашивается. Это как бы велосипед который тебе придется самому разработать аппаратно и поддержать программно.
тут я не советчик или критик ,это мне ничего не говорит , я - ЛА3 :)
Дело в том что музыка для Мунсаунда может играть с разным темпом, то есть есть модули музыки по прерываниям 50Гц, а есть и 60Гц. В принципе есть и более с высокой частотой, но я их не пробовал. Так вот для проигрывания музыки с 60Гц я использовал прерывания от Мунсаунда, а прерывания от кадровой развертки игнорировал, благо есть у Ямахи флаг по которому можно определить она прервалась или кадры. Вот собственно и тут попробовать.
Опять же эти все плюшки уже никак не относятся к Сеге и ее музыке, это ближе уже к чиcтому OPN.
В VGM то же самое , но особенность построения плеера такова ,что задержки приходится считать программно. Если задействовать прерывания от карты ,то крепко усложняется схема , и полностью реорганизовывать плеер надо ,что по моим подсчетам вообще не получится.
А если ты будешь писать под своя аппарат свой софт (не VGM) то это будет конечно плюс для простоты проигрывания 60 гц.
Mick, думал уже как сброс SN-ке сделать ?
Пока нет. Но можно поступить как с SAA1099. У ней тоже нет хардварного сброса и чтобы не "пела" когда не нужно просто отключал входную частоту. Так можно поступить и тут.
То есть добавить порт или адрес памяти, куда нацепить один триггер. По сбросу он отключает генерацию частоты на SN. А в плеере сначала разрешаешь генерацию, а потом делаешь что хочешь.
При выходе из программы - отключаешь генерацию частоты.
Вот набросал предварительный вариант карты. Пока не глубоко влезал в железную часть посему что то возможно добавится, а что то уберется.
Схема удалена, так как есть более свежие версии.
Извините за не скромность, назвал карту ZXM-SegaBlaster :)
P.S. Внезапно обнаружил, что файло-место у меня на форуме приближается к критическим 20мб. Посему этот файл как рабочий будет в скором времени удален.
Попытался почитать про прерывания от YM2612 и понял, что прерывание возникают при переполнении любого из таймеров (A или B).
И отдельного флага прерывания как у YM278 нет. Посему надо будет проверять оба бита (хотя когда сам пишешь плеер то понятно какой таймер срабатывает), но все же.
Чтобы вызвать прерывание, надо сначала записать значение в таймер A (регистры 24h, 25h) или B (регистр 26h). Затем одновременно нужный таймер запускаем и устанавливаем флаг разрешения флага переполнения (регистр 27h)
Все правильно я понял?
Теперь о портах:
Для YM2612 предлагаю использовать те же порты, что и для Мунсаунда FM часть.
FM часть
порт C4h -> запись адреса регистра (набор регистров 1)
C5h - запись данных в регистры набора 1
С6h - запись адреса регистра (набор регистров 2)
C7h - запись данных в регистры набора 2
C4h на чтение - статус
Правда сразу же возникнет вопрос о совместном использовании двух карт (ZXM-SegaBlaster и ZXM-MoonSound). Но с другой стороны плодить кучу портов для однотипных устройств OPN - OPL как бы не комильфо. Очень можно сожрать все порты.
Также думал вести порт как Мунсаунде wave часть
Регистр 7Eh - запись адреса регистра
7Fh - запись или чтение данных
Но там только будет интересовать чтение второго регистра, по нему можно было детектить наличие Мунсаунда, так и тут.
Так как этой части нет в YM2612, то порт целиком виртуальный и отрабатывается CPLD.
В принципе вообще YM2612 можно было бы нацепить на порты AY, как в Турбосаунде FM часть. Но тогда могут быть коллизии при использовании с AY
Посему я считаю что не слишком это целесообразно.
Теперь по портам SN76489. В Спекке данный чип не применяется, посему нужно будет выделить порты.
В MSX был такой Franky cartridge. (SN76489 and VDP), который юзал порты 48h~49h
и плюс 3Fh на чтение статуса.
Так что жду ваши предложения и комментарии.
Напомню, это вопрос по портам, обращение через память будет взято как у JV-Soft (плеер он вроде написал, так что не будем изобретать велосипед)
Ну да.
Остается по сути вопрос по портам SN76489
Предлагаю:
48h - запись данных в SN76489
49h - запись в управляющий регистр виртуальный, чтобы разрешать работу генератора частоты для SN76489 (по сути такая же фигня как и с SAA1099)
49h - чтение статуса SN76489 (тоже виртуальный регистр)
И да, нужен все таки детект карты как в Мунсаунде (плюс два порта) или как то обойтись без этого. Или например загнать ее признак в порт 49h?
Пообщался я с Black Cat на предмет портов. Сразу отмечу обращался к нему я, а не как обычно наоборот.
Порты 48 и 49 для SN76489 он поддержал, а вот про порты YM2612 вышла целая дискуссия.
Поскольку YM2612 является приемником YM2203 по FM части, то есть YM2612 это OPN2, а YM2203 это OPN, то по логике музон написанный для TSFM (имеется ввиду FM часть) должен идти на этом чипе. Посему он ратует, что порты должны быть такие же как у FM части TSFM.
Иными словами дополнение к AY или к Turbosound.
В принципе логика в этом есть.
Но тогда возможен конфликт между TSFM и этой картой. Я имею ввиду ZXM-SoundCard и ZX-SegaBlaster. Как поведет себя плата TSFM, которая вставляется в гнездо AY сказать трудно.
Какие еще мнения есть на этот счет?
Так в теории ,проще переписать TSFM плеер под YM2612 ,чем городить кучу железа из пересикающихся портов ,в итоге нынешний софт все равно из моего понимания не сможет сыграть TSFM на YM2612 напрямую без правки кода.
Обновил схему http://zx-pk.ru/threads/29001-zx-ym2...l=1#post972551
Добавил пару конфигурационных джамперов на всякий пожарный. Также на всякий случай сигналы записи и чтения YM2612 пропущу через CPLD.
Так будет для начала гибче управлять ее.
А как все отладится, тогда что то и уберется.
Окончательный вариант схемы будет готов после разводки платы, ибо многие сигналы на CPLD поменяют свои выводы.
Какая тактовая у TSFM в FM режиме ? На слух инструменты совсем не похожи на YM2612
доки пока читаю по тсфм , у меня ее нет и этой темы я не успел коснуться, да по фм они практически идентичны , но получится ли сдружить софт при помощи плисины пока не понятно , порты ,частоты , переключение.
на недопс нашел инфу ,но исходники есть только под псшные утилиты ,исходники плеера тсфм что то не нашел , есть в открытом доступе ?
Могу конечно вилд плай поковырять что бы ym2612 запустить но все это время время...