DC-SWAT Forum

про разъём - тут ктото выкладывал номер заказа... в какой теме не помню. но в одной из недавних точно. может найду... ещё на буржуинских форумах была инфа.

по ссылке написано.. но чёто лень врубаться пока, если так "по-русски" ктобы рассказал... мож в личку потом напиши если не трудно... основные принципи передачи сигналов, там как я понял оба сигнала как данные и как клок...

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

Вроде этот разъём должен подойти http://www.molex.com/webdocs/datasheets/...TACLES.pdf

(04.05.2012 16:59)ValeraK писал(а): [ -> ]Осталось спаять сэмплер анализатора. спаяю на макетке сэмплер на 32канала с глубиной в 512KB.

Чего-то я совсем загрузился текущей работой, сразу за паяльник хватаюсь ... Не вспомнив про DE0-Nano, а на ней 32мега sdram, поищу ядрышко простого контроллера да и скидаю проект сэмплера в квартусе...

тут чтото про разъёмчики говорят. (http://jon.rocatis.dk/?p=66)

"Sure! This is the DigiKey number: 53408-0509.
The Molex numbers are:
534080579
525840579
526020579"

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

*или вторым после SD мода)))

что тема заглохла,а так было интересно((

главное само дело не заглохло)))

пока делаю принципиалку и выбыраю коплектуху... как что появиться выложу тут...

Вроде разобрался с форматом GDI имеджей. Собираюсь написать конвертор файлов сессий в один индексированный файл для прямой записи на SD карточку.
В качестве "пробы пера" написал простенький конвертор raw2wav в формате ELF Unix, теперь можно послушать музыку из игр которые хранят её в отдельных сессиях на диске.

Ну ты изобрел велосипед... Таких утилит куча в инете, всяких разных, есть и более продвинутые, например SoX.

(22.05.2012 08:46)SWAT писал(а): [ -> ]Ну ты изобрел велосипед... Таких утилит куча в инете, всяких разных, есть и более продвинутые, например SoX.

Пускай, пускай человек кавыряется раз душа щас лежит к этому делу

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

(22.05.2012 08:46)SWAT писал(а): [ -> ]Ну ты изобрел велосипед...

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

Делай делай, прога лишней не будет, всегда пригодится!!!

Valera_K: "Вроде разобрался с форматом GDI имеджей" - есть там какие особенности, в плане размера секторов и т.п или всё тож самое 2352 кадр?
просто дрим сам работает с форматом, а читате чисто секторами, я так полагаю..

Да нет там никаких особенностей, это обычный ISO 9660.

Дописал конвертор делающий из нескольких файлов TOSEC GDI один имедж файл DII для записи на SD карточку.
Формат простой:
16байт заголовок имеджа,
16байт * КоличествоСессий - заголовки сессий,
8байт * КоличествоСекторов - индексы на содержимое секторов и время MSF,
само содержимое секторов упакованных mRLE.
Упаковка простейшая, чтобы поменьше перекачивать с карточки в контроллер, но при этом не тратить вычислительные ресурсы контроллера, что повысит скорость отдачи сектора(ов). Индексы нужны что-бы указывать на сектора разного размера и для быстрого поиска запрошенного ATAPI сектора по MSF.

Для примера результат работы утилитки над имеджем игры:
Midway's Greatest Arcade Hits Volume 1 v1.000 (2000)(Midway)(PAL)[!][compilation]
Размер архива Midway's.zip - 62762613 байтов.
Сумарный размер всех Midway's файлов в архиве - 1187870693 байтов.
Размер Midway's.dii без сжатия секторов - 1191911016 байтов.
Размер Midway's.dii со сжатием секторов - 114713891 байтов.

Размер без сжатия дан просто для оценки накладных расходов на структуру имедж файла. Имедж получился с вдвое худшим сжатием чем zip, но зато гораздо более быстр для поиска и предоставления данных.

P.S. Что и в какой форме записывать на SD карточку определился, теперь дело за контроллером имитирующим GD-Rom.

не, пока для меня там мудрёная математика, до лучших времён оставлю вникание в такие вопросы))...

я вот выбрал EP3C5E144-8N и AT89SXXXX , рисую принципиалку в Orcad 16.0, потом к печатникам...

пока думаю как сделать мультизагрузку. по моей идее файл с прошивкой для плис должен лежать на карте SD, при старте контроллер грузит плиску, но в итоге хочется получить максимальный трансфер с карты, это может сделать плиска, поэтому канал SPI както надо переключить, сначала доступ к карте у контородллера, потом он передаст плиске этот канал..

по ходу на плате если делать в виде платки гдром, надо разьём sd карты ставить к краю корпуса дримки, чтобы в корпусе сделать прорезь для карты, а плиску ближе рзъёму карты , т.к слышал беда с длинными проводами есть...

ещё на плате буде 1-2 иде для винта. остальные пигы для gpIO... порт G2 какнить позже освоится))

если к разъму довести/допаять CS биоса, будет ещё и свой "биос мод", с особенной заставеой. биос тож можно залить на карту ))) и грузить какой душе угодно))

---

"...теперь дело за контроллером имитирующим GD-Rom. " -это как выясениться самое главное))

кстати выбирал контроллерю наткнулся, на недорогоие 32битные на ARM CORTEX , мож кто пользовался , или Valera_k чтонить о них знает, по цене соизмеримы что и мной выьранный на 51 ядре. (8бит)

ValeraK, это все конечно хорошо, но я бы советовал в любом случае сделать поддержку именно GDI, CDI и NRG, так как народ не очень то любит все эти конвертации (это можно видеть сейчас на моем примере). В моем то случае понятно, мне это делать просто необходимо, чтобы сделать образ как можно проще для лоадера, но если уж ты взялся за более продвинутый девайс, то будет крайне не осмотрительно делать поддержку только этого специфического образа. Я бы советовал его сделать как более производительную альтернативу, но не как не основным образом.

(25.05.2012 07:51)SWAT писал(а): [ -> ]ValeraK, но я бы советовал в любом случае сделать поддержку именно GDI, CDI и NRG, так как народ не очень то любит все эти конвертации

Согласен, есть определённые напряги из-за необходимости сначала во что-то преобразовывать, а потом записывать. Но ведь я хочу затем заливать имедж dii напрямую на SD карточку посекторно, без файловой структуры. Такой подход позволит микроконтроллеру очень быстро обращаться к секторам просто взяв из индекса адрес сектора и сдвинув значение адреса вправо на 9 бит - получить LBA номер сектора флэшки с началом сектора gdrom, ну а все последующие сектора расположены именно _последовательно_.
Общая мысль такова: да придётся потратить некоторое время на конвертацию и на запись ДисковымДублёром (кстати dii меньше по размеру чем исходные файлы - времени на эту операцию меньше), но ведь главным является не эти потери времени - можно и подождать, а вот во время игры не хочется иметь тормоза из-за контроллера перегруженного излишними вычислениями и разбирательством с инкапсуляцией.
Исходя из этого структура записи на флэшке _должна_ быть удобной именно контроллеру интерфейса gdrom.

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

учитывая что данные реально нужны только 2048 на сектор, то вроде особых напрягов итак не вижу..

MSF в LBA думаю не там много занимает времени))) а в случае ATAPI вообще не надо конверить , транслируется команда как есть...


так что, ктонить пользовался 32битнимы ARM контриками?))

(25.05.2012 08:21)ValeraK писал(а): [ -> ]Согласен, есть определённые напряги из-за необходимости сначала во что-то преобразовывать, а потом записывать. Но ведь я хочу затем заливать имедж dii напрямую на SD карточку посекторно, без файловой структуры.

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