GD-Rom

[ValeraK]

Нашёл я наконец-то поставщика отладочного модуля Atmel STK594 под кристаллы At94S05/10, сегодня оплатил 4425руб (включая 900руб за доставку из Питера).
Как приходит платка, начну потихоньку разбираться с STK в рамках продолжения работ по проекту GDromSD.

[cybdyn]

эт хорошая новость. обновлять информацию будете на своём сайте, блэкфина уже ведь нет в проете?

как я понял, сначала надо разобраться/освоить как с такими чипами работать, и уже потом как прикрутить к дриму, так ?
есть ли примерные прогнозы по срокам?

[ValeraK]

(03.11.2012 12:27)cybdyn писал(а):  эт хорошая новость. обновлять информацию будете на своём сайте, блэкфина уже ведь нет в проете?

как я понял, сначала надо разобраться/освоить как с такими чипами работать,
и уже потом как прикрутить к дриму, так ?
есть ли примерные прогнозы по срокам?

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

Ну по всем подсчётам at94s самый оптимальный выбор, дёшев, всё что нужно есть, без излишеств. Да придётся разобраться с внутрянкой, но fpslic позволит создать задуманное в минимальные сроки и с простой интеграцией в дрим.
Правда немцы соглашаются продать кристаллы кратностью не менее 90, ну может под какой-нить проект ещё встрою эти кристаллы.

Главное AtSTK594 с софтом удалось найти за разумные деньги, есть с чего начать, что-бы получилось желаемое.

[cybdyn]

тонким моментом пока остается процсесс передачи по DMA: прокатитли останов/продолжение передачи, так как никаких микросхем мы не ипользуем для буферизации(SRAM / SDRAM) то это либо прямой поток с карты, либо есть
какието ресурсы у фгпа-шной части или у контроллера ? в любом случае карто тоже не выдаёт анные не прерывно, а посекторно и последовательно.

фат систему как я понял использовать не планируете?

[ValeraK]

(04.11.2012 01:13)cybdyn писал(а):  тонким моментом пока остается процсесс передачи по DMA: прокатитли останов/продолжение передачи, так как никаких микросхем мы не ипользуем для буферизации(SRAM / SDRAM) то это либо прямой поток с карты, либо есть
какието ресурсы у фгпа-шной части или у контроллера ?

фат систему как я понял использовать не планируете?

Дык у fpslic есть freeram, именно для того чтобы решить эти проблемы, я и заложил этот кристалл, поскольку он решает рилтайм относительно железа, что в свою очередь упрощает взаимодействие по хард/софт.

А для кого нужен FAT? органичнее разместить структуру аналогичную GD-Rom, просто из соображений геймплея, да и с упаковкой для уменьшения бэндвитчь.
Утилитку я-ж выложил на своём веб серваке, по степени упаковки не намного хуже zip.

[cybdyn]

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

[SWAT]

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

[ValeraK]

(05.11.2012 10:25)SWAT писал(а):  одновременное расположение нескольких игр на флешке.
Сейчас они стоят копейки, заливать кучу игр и радоваться. за каждой игрой бегать к компу чтобы ее залить какой то утилитой.

А нужно-ли иметь на одной флэшке несколько игр?
Значит придётся придумывать хард/софт для выбора конкретной игры, да и на контроллер дополнительная нагрузка по поиску нужной информации в данный момент + расход ячеек памяти => а это тормоза во время игры...
Возникнет проблема с много-дисковыми играми, они-ж отслеживают открытие привода и смену носителя...
Судя по тому, что стоимость sd карточек практически пропорциональна ёмкости, можно купить пучок флэшек и залить на них по игре на каждую.
Я же хочу чтоб игруля даже не подозревала, что ей подсунули вместо GDRom SDcard, дорабатывать игрушки? это уж слишком...

Ну насколько я знаю для dos/win тоже есть утилитки типа DD, ну например winimage etc. А поскольку не так часто сменяется игрушка, то "бегать" придётся не так часто, ведь для прохождения одной игры требуется весьма значительное время.

[cybdyn]

не факт что работу с файловой системы так просто реализовать, так что она может и весь проект обрезать)))...
хотя в случае дрима, тут немного поблагоприятнее условия, с тем что данные (2048 байт сектор) в формате кратном секторам карты (512). -> (512 * 4 = 2048)

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

вопрос в другом - как заливать образы:
1- точно не могу сказать, но возможно утилита для загрузики образов на усб флэшку для пс2 (некая usbutil***) может както записывать файлы не разрывно. тогда фат нужна только на этапе определения этого начального адреса конкретного образа игры. это можно и силами дрима даже сделать....!

вообще у файловой системы есть особенность - это размер кластера. если его увеличить до размера файла или тем самым уменьшить число кластеров. то инфы требуется минимум, вроде в ext fat большой кластер можно сделать.

2 - какойто драйвер/софтик написать, чтобы сырыми секторами через картридер записывать.

3- усб контроллер типа FX2 ставить на плату, и выбирая нормальный образ наша прога закидывает в нужном формате.

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

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

---

с кучкой флэшек это конечно на цирк похоже, но на первых парах почемубы и нет)))

да, короче, пусть будет хоть какое устройство, остальное доделается!!

---

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

[SWAT]

(05.11.2012 13:54)cybdyn писал(а):  "Главное преимущество файловой системы, это одновременное расположение нескольких игр на флешке" - главное что воткнул и залил игры не применяя утилит.

И это безусловно тоже.

[ValeraK]

(06.11.2012 14:13)SWAT писал(а):  

(05.11.2012 13:54)cybdyn писал(а):  "Главное преимущество файловой системы, это ... что воткнул и залил игры не применяя утилит.

И это безусловно тоже.

Ну утилиту типа Нортон командер или иной файловый менеджер всё же придётся применить.
Да со стороны писюка возможно это и проще, но вот со стороны дримкаста придётся кучу проблем решать:
как выбрать конкретную игру?
как быть с совместимостью этого решения с играми?
как _быстро_ и с минимальными затратами достучатся к сегменту _неиндексированных_ данных учитывая разнообразные размеры секторов (audio, data)?
как обеспечить возможность обычного оперирования носителями, открыть крышку - вынуть диск - вставить диск?

В конце-концов для удобства работы под чем всё задумывается? imho всё-же нужно думать о геймплее в первую очередь, а значит приоритет следует отдать дримкасту. Написать удобный шелл для формирования флэшки из zip архива с tosec gdi вполне решаемая задача.

[cybdyn]

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

выбрав/запустив игру дримшел ресетит дрим передав предварительно эмулятору смещение на образ, далее оно просто его добавляет к искомому lba

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

разделение аудио и данных : ну принимая тот факт что в перемешку (вроде!) не хранятся. оно либо вначале аудио потом данные или наоборот, ну вообщем както этото можно зафиксировать, что при адресации в конкретную область ясно что хочет дрим считать данне либо воспроизвести аудио, тем более что это как то и в командах отражено. (read / play)

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

вот кстати, касательно того же расбери пи , в принципе есть какието мысли по использование чегото подобного, ведь как раз на всякую обработку файловой системы и разных алгоритмов работы эмуля нужно чтото подобное, а по железу имею виду со стороны плис, необходим только набор регистров и механизм быстрого транспорта данных с карты в интерфейс г1. т.е плис нужна только для согласования шины г1 с каким либо носителем. а управление учень даже удобно применить на какомнить быстром мощном и недорогом устройстве, и как вариант освоив данное ядро можно потом самому заложить/применить такую микруху типа этого кортекса. тем боле у него ещё всяких фич немерено, типа эзэр-нэта и усб-хоста.
подытожу : с нашей стороны нужна плата которая втыкается в г1, на ней простенькая плиска, сд слот ( + ide для хдд) и на эту плату както садиться расбери. желательно конечно , так чтобы были доступны все его "сладкие" порты)) , обмен с плиской можно делать по какому либо из доступных протоколов spi, i2c, может даже быстрее если это так надо и паралельную шина на gpio заюзать....
конечно ещё разобраться как програмить под бэри))))

[SWAT]

ValeraK, если бы народ до этого ничего слаще редьки не ел не использовал, то для него и это было бы в радость. Но так как они уже щупали DreamShell, то это будет для них мало привлекательное решение. Поверь, иметь коллекцию игр, любую из которых можно запустить без гемора, кликнув по соответствующей иконке, в любой момент - очень важно. Я уже устал от попыток оградить тебя от работы над бесполезным устройством Понятно что так проще и быстрее, но спрос на эту простоту будет такой же простой. В общем делай как знаешь, больше переубеждать не буду

[ValeraK]

(08.11.2012 07:28)SWAT писал(а):  Я уже устал от попыток оградить тебя от работы над бесполезным устройством

На самом деле в моей идее нет противоречий, _никто_ не запрещает сделать мастер-бут на sd карточке отформатированной как fat32, положить на неё _кучу_ игрушек в виде zip файлов (в распакованном архиве у gdi игр дублируются имена файлов-сессий) простым копированием через картридер.
GDromSD загрузит мастер-бут с менюшкой типа дримшела, ну а чел выберет игрулю из списка лежащих на флэшке файлов.
В этом случае вопрос только к написанию проги загрузчика игр из файловой системы на дриме, ну а железо при этом останется прежним.
Так что можно формировать содержимое карточки по своему усмотрению, ну придумают ещё какой-нить формат или захотят запустить эмулятор другой консоли на дриме, я зачем буду блокировать такую возможность?

[cybdyn]

да это всё понятно..... так когда говорите уже можно будет пощупать?

[cybdyn]

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

конкретно практчески я это попробую сделать в параллельном проекте)))


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

[ValeraK]

(09.11.2012 00:39)cybdyn писал(а):  да это всё понятно..... так когда говорите уже можно будет пощупать?

Оплатил, жду доставки отладочного модуля STk594.
Как придёт, настрою софт, запущу пару примеров и тогда уж к делу.

[Retro]

ValeraK а вообще (в будущем) реально будет сделать шоб сахранки игр сохранялись не на визуал мемори,а на флешку где хранится образ?

[ValeraK]

(09.11.2012 11:13)Retro писал(а):  ValeraK а вообще (в будущем) реально будет сделать шоб сахранки игр сохранялись не на визуал мемори,а на флешку где хранится образ?

Не думаю, что это возможно, ведь в списке atapi команд gdrom нет команд для записи на носитель, соответственно в играх нет поддержки этого метода сохранения. Можно дополнить команды до полного сета, но в этом случае получим не совместимость, да и сами игрульки придётся патчить...

[cybdyn]

карта работает в составе джоя, а тот по шине MAPLE , которая к самому процу подведена.

поэтому два варианта:
1- софтом перхватить обращения если есть возможность через сисколы и перенаправить на гд-эмуль.
2- как отдельное устройство (или допонительно в проекте в гд-эмуля) - делать ещё и эмуль джоев-карт дрима: использовав пару проводов с порта джоев (SCKA/SCKB). но тогда на крату sd необходимо уже ПИСАТЬ данные.

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