+- DC-SWAT Forum (http://www.dc-swat.ru/forum)
+-- Форум: Sega Dreamcast (/forum-2.html)
+--- Форум: Hardware (/forum-9.html)
+--- Тема: GD-Rom (/thread-1888.html)
RE: GD-Rom - ValeraK - 02.11.2012 21:27
Нашёл я наконец-то поставщика отладочного модуля Atmel STK594 под кристаллы At94S05/10, сегодня оплатил 4425руб (включая 900руб за доставку из Питера).
Как приходит платка, начну потихоньку разбираться с STK в рамках продолжения работ по проекту GDromSD.
RE: GD-Rom - cybdyn - 03.11.2012 12:27
эт хорошая новость. обновлять информацию будете на своём сайте, блэкфина уже ведь нет в проете?
как я понял, сначала надо разобраться/освоить как с такими чипами работать, и уже потом как прикрутить к дриму, так ?
есть ли примерные прогнозы по срокам?
RE: GD-Rom - ValeraK - 03.11.2012 13:07
(03.11.2012 12:27)cybdyn писал(а): эт хорошая новость. обновлять информацию будете на своём сайте, блэкфина уже ведь нет в проете?
как я понял, сначала надо разобраться/освоить как с такими чипами работать,
и уже потом как прикрутить к дриму, так ?
есть ли примерные прогнозы по срокам?
Да схему опубликую, всё времени не хватает, к сожалению блэкфин для данного проекта не катит - у дешёвого не хватает лапок (хотел заюзать лапки SDA,SCL - обломился, они туда фильтр встроили с задержкой, в результате не успеваю парсить сигналы), а более продвинутый кроме того, что дорог, ещё и требует рассыпухи...
Ну по всем подсчётам at94s самый оптимальный выбор, дёшев, всё что нужно есть, без излишеств. Да придётся разобраться с внутрянкой, но fpslic позволит создать задуманное в минимальные сроки и с простой интеграцией в дрим.
Правда немцы соглашаются продать кристаллы кратностью не менее 90, ну может под какой-нить проект ещё встрою эти кристаллы.
Главное AtSTK594 с софтом удалось найти за разумные деньги, есть с чего начать, что-бы получилось желаемое.
RE: GD-Rom - cybdyn - 04.11.2012 01:13
тонким моментом пока остается процсесс передачи по DMA: прокатитли останов/продолжение передачи, так как никаких микросхем мы не ипользуем для буферизации(SRAM / SDRAM) то это либо прямой поток с карты, либо есть
какието ресурсы у фгпа-шной части или у контроллера ? в любом случае карто тоже не выдаёт анные не прерывно, а посекторно и последовательно.
фат систему как я понял использовать не планируете?
RE: GD-Rom - ValeraK - 04.11.2012 15:09
(04.11.2012 01:13)cybdyn писал(а): тонким моментом пока остается процсесс передачи по DMA: прокатитли останов/продолжение передачи, так как никаких микросхем мы не ипользуем для буферизации(SRAM / SDRAM) то это либо прямой поток с карты, либо есть
какието ресурсы у фгпа-шной части или у контроллера ?
фат систему как я понял использовать не планируете?
Дык у fpslic есть freeram, именно для того чтобы решить эти проблемы, я и заложил этот кристалл, поскольку он решает рилтайм относительно железа, что в свою очередь упрощает взаимодействие по хард/софт.
А для кого нужен FAT? органичнее разместить структуру аналогичную GD-Rom, просто из соображений геймплея, да и с упаковкой для уменьшения бэндвитчь.
Утилитку я-ж выложил на своём веб серваке, по степени упаковки не намного хуже zip.
RE: GD-Rom - cybdyn - 05.11.2012 02:48
хорошо когда есть разные варианты видиния вопросов)). с нетерпением жду, когда это будет реализовано на практике.
RE: GD-Rom - SWAT - 05.11.2012 10:25
Главное преимущество файловой системы, это одновременное расположение нескольких игр на флешке. Сейчас они стоят копейки, можно брать большие объемы, заливать кучу игр и радоваться. А ты хочешь это на корню обрезать, за каждой игрой бегать к компу чтобы ее залить какой то утилитой (даже не просто копипастом).
RE: GD-Rom - ValeraK - 05.11.2012 13:29
(05.11.2012 10:25)SWAT писал(а): одновременное расположение нескольких игр на флешке.
Сейчас они стоят копейки, заливать кучу игр и радоваться. за каждой игрой бегать к компу чтобы ее залить какой то утилитой.
А нужно-ли иметь на одной флэшке несколько игр?
Значит придётся придумывать хард/софт для выбора конкретной игры, да и на контроллер дополнительная нагрузка по поиску нужной информации в данный момент + расход ячеек памяти => а это тормоза во время игры...
Возникнет проблема с много-дисковыми играми, они-ж отслеживают открытие привода и смену носителя...
Судя по тому, что стоимость sd карточек практически пропорциональна ёмкости, можно купить пучок флэшек и залить на них по игре на каждую.
Я же хочу чтоб игруля даже не подозревала, что ей подсунули вместо GDRom SDcard, дорабатывать игрушки? это уж слишком...
Ну насколько я знаю для dos/win тоже есть утилитки типа DD, ну например winimage etc. А поскольку не так часто сменяется игрушка, то "бегать" придётся не так часто, ведь для прохождения одной игры требуется весьма значительное время.
RE: GD-Rom - cybdyn - 05.11.2012 13:54
не факт что работу с файловой системы так просто реализовать, так что она может и весь проект обрезать)))...
хотя в случае дрима, тут немного поблагоприятнее условия, с тем что данные (2048 байт сектор) в формате кратном секторам карты (512). -> (512 * 4 = 2048)
несколько игр можно и при этом способе хранить, только какойто описатель имиджей вначале разместить, далее меняется только адрес первого сектора...
вопрос в другом - как заливать образы:
1- точно не могу сказать, но возможно утилита для загрузики образов на усб флэшку для пс2 (некая usbutil***) может както записывать файлы не разрывно. тогда фат нужна только на этапе определения этого начального адреса конкретного образа игры. это можно и силами дрима даже сделать....!
вообще у файловой системы есть особенность - это размер кластера. если его увеличить до размера файла или тем самым уменьшить число кластеров. то инфы требуется минимум, вроде в ext fat большой кластер можно сделать.
2 - какойто драйвер/софтик написать, чтобы сырыми секторами через картридер записывать.
3- усб контроллер типа FX2 ставить на плату, и выбирая нормальный образ наша прога закидывает в нужном формате.
вообше по началу хоть както пусть реализовано будет, доработать всегда можно. нет пределу совешенствованию)))
а глядиш появится какойнить фпслик с арм ядром и всё обработает... слышал что уже в циклоне-5 такое есть.
с кучкой флэшек это конечно на цирк похоже, но на первых парах почемубы и нет)))
да, короче, пусть будет хоть какое устройство, остальное доделается!!
"Главное преимущество файловой системы, это одновременное расположение нескольких игр на флешке" - главное что воткнул и залил игры не применяя утилит.
RE: GD-Rom - SWAT - 06.11.2012 14:13
(05.11.2012 13:54)cybdyn писал(а): "Главное преимущество файловой системы, это одновременное расположение нескольких игр на флешке" - главное что воткнул и залил игры не применяя утилит.
И это безусловно тоже.
RE: GD-Rom - ValeraK - 06.11.2012 16:34
(06.11.2012 14:13)SWAT писал(а):(05.11.2012 13:54)cybdyn писал(а): "Главное преимущество файловой системы, это ... что воткнул и залил игры не применяя утилит.И это безусловно тоже.
Ну утилиту типа Нортон командер или иной файловый менеджер всё же придётся применить.
Да со стороны писюка возможно это и проще, но вот со стороны дримкаста придётся кучу проблем решать:
как выбрать конкретную игру?
как быть с совместимостью этого решения с играми?
как _быстро_ и с минимальными затратами достучатся к сегменту _неиндексированных_ данных учитывая разнообразные размеры секторов (audio, data)?
как обеспечить возможность обычного оперирования носителями, открыть крышку - вынуть диск - вставить диск?
В конце-концов для удобства работы под чем всё задумывается? imho всё-же нужно думать о геймплее в первую очередь, а значит приоритет следует отдать дримкасту. Написать удобный шелл для формирования флэшки из zip архива с tosec gdi вполне решаемая задача.
RE: GD-Rom - cybdyn - 07.11.2012 02:16
например так:
дримшел выбирает конкретную игру по некой таблице "адрес/размер/название игры". он сам сидит на карте в начале к примеру, таблица за ним, далее хранатся сами имджи игр... дрим шел грузится как первый образ по умолчанию.
выбрав/запустив игру дримшел ресетит дрим передав предварительно эмулятору смещение на образ, далее оно просто его добавляет к искомому lba
вынуть вставить диск , это надо думать добавлять ли кнопочку - закрытия крышкы . если поддерживать её то емулю просто нужно хранить ещё одно смещение на следующий образ, как добавить этот следующий образ - можно в поддеожке дримшела сделать.
разделение аудио и данных : ну принимая тот факт что в перемешку (вроде!) не хранятся. оно либо вначале аудио потом данные или наоборот, ну вообщем както этото можно зафиксировать, что при адресации в конкретную область ясно что хочет дрим считать данне либо воспроизвести аудио, тем более что это как то и в командах отражено. (read / play)
"как _быстро_ и с минимальными затратами достучатся к сегменту _неиндексированных_ данных учитывая разнообразные размеры секторов (audio, data)?"
про это я не совсем понял, .... если данные кратны 512 то никаких проблем по поиску учитывая что мы знаем начало имиджа (смещение) и то что он записан непрерывно,.... а аудио трэки не знаю, а как это в вашем методе решается? ну можно оставить как они есть, нужен некий только механизм учитывающий особенности разделения аудио треков, паузы там всякие и т.д...
вот кстати, касательно того же расбери пи , в принципе есть какието мысли по использование чегото подобного, ведь как раз на всякую обработку файловой системы и разных алгоритмов работы эмуля нужно чтото подобное, а по железу имею виду со стороны плис, необходим только набор регистров и механизм быстрого транспорта данных с карты в интерфейс г1. т.е плис нужна только для согласования шины г1 с каким либо носителем. а управление учень даже удобно применить на какомнить быстром мощном и недорогом устройстве, и как вариант освоив данное ядро можно потом самому заложить/применить такую микруху типа этого кортекса. тем боле у него ещё всяких фич немерено, типа эзэр-нэта и усб-хоста.
подытожу : с нашей стороны нужна плата которая втыкается в г1, на ней простенькая плиска, сд слот ( + ide для хдд) и на эту плату както садиться расбери. желательно конечно , так чтобы были доступны все его "сладкие" порты)) , обмен с плиской можно делать по какому либо из доступных протоколов spi, i2c, может даже быстрее если это так надо и паралельную шина на gpio заюзать....
конечно ещё разобраться как програмить под бэри))))
RE: GD-Rom - SWAT - 08.11.2012 07:28
ValeraK, если бы народ до этого ничего
Понятно что так проще и быстрее, но спрос на эту простоту будет такой же простой. В общем делай как знаешь, больше переубеждать не буду
RE: GD-Rom - ValeraK - 08.11.2012 23:10
(08.11.2012 07:28)SWAT писал(а): Я уже устал от попыток оградить тебя от работы над бесполезным устройством
На самом деле в моей идее нет противоречий, _никто_ не запрещает сделать мастер-бут на sd карточке отформатированной как fat32, положить на неё _кучу_ игрушек в виде zip файлов (в распакованном архиве у gdi игр дублируются имена файлов-сессий) простым копированием через картридер.
GDromSD загрузит мастер-бут с менюшкой типа дримшела, ну а чел выберет игрулю из списка лежащих на флэшке файлов.
В этом случае вопрос только к написанию проги загрузчика игр из файловой системы на дриме, ну а железо при этом останется прежним.
Так что можно формировать содержимое карточки по своему усмотрению, ну придумают ещё какой-нить формат или захотят запустить эмулятор другой консоли на дриме, я зачем буду блокировать такую возможность?
RE: GD-Rom - cybdyn - 09.11.2012 00:39
да это всё понятно..... так когда говорите уже можно будет пощупать?
RE: GD-Rom - cybdyn - 09.11.2012 02:02
у меня тож всякие мысли есть как обойти систему, и свести к минимуму любые выполнение второстепенных задач типа этой фат: поскольку предпологается что устройство будет иметь большую скорость обменна данными с картой и консолью то можно решить вопрос о дефргментации файла, софтварно это будет выполняться кодом оболочки, испоняться как одна из функций шела... как и работа с самой фат....
у меня вообще подозрения, что нелинейность возникает при переполнение карты в смысле при много кратном переписывании (удаление /запись нового) файлов. шел будет просто следить за этой нелинейностьюю и предуредит/и по возможности исправит.... ну вобщем как то можно решить этот вопрос.. тогда аппаратуре (эмулю) действительно требуется знать только начальный адрес сектора образа ну на всяк случай и размер файла и никаких файловых систем...
конкретно практчески я это попробую сделать в параллельном проекте)))
на мой взгляд, пока вопрос вовсе не этом, а реалищовать хоть какоето работующее устройство, в плане чтобы оно вообще могло нормально работать(эмулировать) пусть даже при искуственно идеальном расположении данных на карте.
так как до этого ещё пилить-и -пилить)))
RE: GD-Rom - ValeraK - 09.11.2012 05:11
(09.11.2012 00:39)cybdyn писал(а): да это всё понятно..... так когда говорите уже можно будет пощупать?
Оплатил, жду доставки отладочного модуля STk594.
Как придёт, настрою софт, запущу пару примеров и тогда уж к делу.
RE: GD-Rom - Retro - 09.11.2012 11:13
ValeraK а вообще (в будущем) реально будет сделать шоб сахранки игр сохранялись не на визуал мемори,а на флешку где хранится образ?
RE: GD-Rom - ValeraK - 11.11.2012 06:00
(09.11.2012 11:13)Retro писал(а): ValeraK а вообще (в будущем) реально будет сделать шоб сахранки игр сохранялись не на визуал мемори,а на флешку где хранится образ?
Не думаю, что это возможно, ведь в списке atapi команд gdrom нет команд для записи на носитель, соответственно в играх нет поддержки этого метода сохранения. Можно дополнить команды до полного сета, но в этом случае получим не совместимость, да и сами игрульки придётся патчить...
RE: GD-Rom - cybdyn - 11.11.2012 15:46
карта работает в составе джоя, а тот по шине MAPLE , которая к самому процу подведена.
поэтому два варианта:
1- софтом перхватить обращения если есть возможность через сисколы и перенаправить на гд-эмуль.
2- как отдельное устройство (или допонительно в проекте в гд-эмуля) - делать ещё и эмуль джоев-карт дрима: использовав пару проводов с порта джоев (SCKA/SCKB). но тогда на крату sd необходимо уже ПИСАТЬ данные.
вообщем - ничего невозможного, но сходу по шине G1 не получиться.и всё это пока доп затраты по времени.