Я не случайно дал ссылку на форум. Там ответ автора трекера, который поддерживает SID и что более важно сохранение его в .vgmСообщение от XCHG
А значит поддержка есть. И глядя на на полученный файл, видно что это дамп регистров. Осталось понять поддерживает ли он треки использющие прерывания отличный от кадровых и цифровые семплы.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Есть интересная программа "Java SID Player Music Library V2" написанная на Java.
Одна из возможностей позволяет сохранить дамп регистров SID.
В текстовом формате )
- - - Добавлено - - -
Причем писать она умеет только в реальном времени.
А что ещё нужно?)) Говорите, на java? Тогда, запустив под linux, вспоминая, что порт - это файл, можно написать простую программу, которая будет принимать значения и сохранять их по квантам времени. А далее - дело техники. Получится хоть и более объемный, но все таки, PSG) А сжать потом - не проблема. Считаю эту идею одной из самых простых. Сам ещё не вникал, но звучит как решенная задача.
Речь про HardSID? Так во первых под линухом он может и не поддерживаться. Во вторых он вроде работает по USB. В третьих нужно переделать это в пакетный режим. Не ждать же по 3 минуты на конверсию каждого трека.
В общем у java плеера преимуществ в плане переделки никаких не видится. С тем же успехом можно пилить ZXTUNE или любой из десятков других плееров.
Докладываю ситуацию. На данный момент ядро плеера написано, прослойка универсальных драйверов (перенос с чипа на чип осуществляется сменой дефайна, все остальное разруливается само собой) для micro-sd (spi режим чтения-записи + fatFS), AY плеера (режим работы в "нотном режиме" (для последующего использования как звуковой синтезатор), режим чтения из памяти (источник подставляется и протестирован как с UART, microsd, внешняя ОЗУ, внешняя flash)), клавиатуры (Драйвер сам опрашивает и дает ядру информацию о том, что произошло с клавишей. Только нажали, долго держат, кликнули, ... В общем, все возможные события. Писал так, чтобы и в других проектах можно было использовать...). И вот самый главный сейчас вопрос - экран. Я заказал несколько штук. Приехал раньше всех экран на ili9340. 240x320. Под него написал GUI интерфейс. GUI так же универсальный и может работать с любыми LCD (в том числе и монохромными). Но есть загвоздка. Экран без буферизации. А это значит, что записал - то сразу на экране. Памяти у МК (взял самый популярный stm32f103cbt6), всего 20 кб RAM. Из которых на все издержки моих драйверов + FreeRTOS + система-прослойка с предприятия (Она обеспечивает переносимость кода без переписывания на любой кристалл. На работе разрешили использовать.) уходит 16 кб. Так что хранить изображение в ОЗУ мы не можем (нам нужно 240*320*2 байт). Пришлось попытаться работать без буффера. Напрямую. Вот только тогда часто приходится переключаться с режима данных на режим команд. А это отжирает уйму ресурсов. + перенастраивать все время DMA для передачи 2-х байт на пиксель - тоже слишком. В итоге - экран отрисовывается так, как на скрине ниже - за 2-3 секунды. Это, я считаю, ужасно долго. Выхода я вижу 2.
1. Использовать только что пришедший мне LCD OLED 128*64 (0.96 дюйма). Тогда мне хватает ОЗУ, чтобы затащить все в контроллер и уже закончить на время с разработкой ПО. Т.к. основная цель будет достигнута почти сразу.
2. Сменить чип на F103 в 100-ногом корпусе, купить внешнюю SRAM, подключить по FSMC шине и буферизировать данные там. Тогда отрисовка экрана будет мгновенной. И я оставлю цветной 16-ти битный LCD в 2.2 дюйма.
Я не могу определиться с тем, какой вариант выбрать. Для меня оба хороши. Но в случае выбора LCD с 2.2 дюймами, я поставлю сразу 2 AY чипа (кроватки под них). Для 28 выводов + 40. Ядро поддерживает до +бесконечности параллельных чипов. Выбор за вами.
Касательно аудио-части. Тут коллеги по работе разъяснили мне, что я тупой в плане аналоговой схемотехники и им лучше знать. Так что сейчас они проектируют и тестируют схему микшера на высококачественных операционных усилителях с двупольным питанием) После чего пришлют мне тестовую модель. Они так же сейчас проектируют 2 версии. На дорогом высококачественном AD с двух полярным питанием, или на менее дорогом, но с большими шумами, но с одно полярным. Тут я по слуху решу, что лучше.
Бонусы: при использовании LCD в 2.2 дюйма + RAM, в чипе еще есть SDIO. Так что будет 2 карты. Одна SD формата по SPI, а вторая micro-sd на SDIO.
Вадим Димтревич, спасибо за информирование по проекту!
С отображением информации на экране мне представляется целесообразным 2 подхода.
1. Использовать минималистический 2х16 монохромный LCD дисплей - красивостей нет, но и ресурсов почти не требует от основного ЦП. Можно подключать по iic по 2-м проводам всего.
2. При использовании полноценного многоцветного дисплея - к нему уже потребуется свой отдельный контроллер, со своей прошивкой и массивами ОЗУ. Общение с основным контроллером - по какой-либо шине.
Промежуточные варианты - требуют непропорциональных результату усилий.
1. Символьные индикаторы не рассматриваю в принципе. Ибо - нафиг. Не для того я 2 недели GUI писал и прослойку клавиатуры для перемещения по нему. + другие красивости.
2. К крутому экрану (как на фото) не нужно ничего кроме 1-го чипа SRAM внешней памяти. Она стоит не дорого. И работать с ней не сложно (я уже написал прослойку-драйвер).
Пока ждал вашего сообщения - решил дописать GUI возможность работы с графическим OLED. Вот что вышло. Как по мне - это среднее между тем LCD и символьным.
Сегодня кончил тестировать прослойку для FatFS по работе с micro-sd. Теперь 8 из 12 карт работают (Остальные не поддерживать SPI режим в принципе. Ибо не откликаются даже на те, которые воспринимают все, не зависимо от версии).
Еще немного о работе с картами памяти. У меня реализована запись. При первом открытии директории производится поиск и сортировка psg файлов, а так же вычисление их размеров. Полученные данные будут лежать в системных файлах в той же директории. Касательно того, ради чего создавался этот плеер (чего ОЧЕНЬ НЕ ХВАТАЛО в самой первой реализации в этой ветке), удаления файлов - сейчас пишу безопасную прослойку. Чтобы проблем не было.
Вот фото GUI, с которым будет 1-я версия плеера. Будет еще множество улучшений. Все же GUI еще сырой. Но все же.
- - - Добавлено - - -
3. I2C не люблю очень. Слишком не нравится мне этот интерфейс. Прямо до ужаса. Пока в плеере используется UART (для выдачи отладочной информации), USB (пока в виде теста, пытаюсь поднять USB<->MIDI), SPI (потенциометры, LCD, microsd, сдвиговые регистры (на них кнопки и AY, но все работает слажено и тормозов нет).
Я потихоньку делаю свой недо-плеер, на основе https://geektimes.ru/post/273968/
Вначале тоже все думал по поводу экрана, пробовал разные варианты, потом решил отказаться от него за ненадобностью.
Плееру экран не особо и нужен.
Мой форм-фактор плеера: "стационарный вариант", плеер целиком размещен внутри подходящей по размеру аудиоколонки, дисплея нет. Управление воспроизведением - через 4-х канальное радиоуправление http://ru.aliexpress.com/item/2016-N...6-fb51ed7307c1 . Колонка играет моно, но одновременно плеер вещает свою музыку по bluetooth. Если захочется - можно прослушать стерео на внешней bluetooth колонке или гарнитуре.
Я не особенный меломан, но решил проверить, как одна и та же мелодия звучит на эмуляторе и в реале. Один и тот же PSG. Это ничем не подкреплено и субъективно, но мне кажется, что звучание существенно различается. Бульбовский проигрыватель воспроизводит мелодию иначе и немного лучше, чем она есть в оригинале. Так что аппаратный плеер имеет право на существование, эмулятор не передает истинного звучания.
Кстати. Кто-нибудь знает что о Ricoh 2A03? Имели ли опыт работы с ним? Звук тоже нравится) После этого плеера приступил бы именно к нему.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
