Dork Bord

В общем, решил я сделать эмулятор картриджа для sega mega dryve. Да такой эмулятор, чтобы не просто при перезагрузке мог менять банки, а прям динамически... Чем это светит, ясно и так - можно криво, но обойти ограничение на 8мб картриджи. Я начал с изучения архитектуры sega md. Почитал про картридж virtou racing, в котором практически весь обсчет ведется на встроенном в картридж процессоре, а сама сега просто рисует готовую картинку. Беда в том, что, хоть с паяльником я и дружу, ни чем сложнее ремонта эллектрогитар, да замены кондеров на мамках и мониках не занимался.
В связи с чем, прошу совета. С чего начать?
Варианты типо : начни с самого начала не канают...слишком долго и я люблю наступать на грабли )

Что я сейчас знаю:
sega md имеет 16 мб адресного пространства.
0 - 4мб - картридж.
4 - 8мб - Резерв. При использовании дешифратора адреса можно увеличить картридж до 8мб.
8-10мб - Резерв, можно подключить озу.
10-16мб - Регистры процессоров, сопроцессоров, 64кб оперативки и тд.

Конечно, на первом этапе следовало бы замутить хоть какой-то картридж. С чего я и хочу начать.
Картридж имеет по 32 контакта с каждой стороны..почти все, при том, используются. В оригинальных картриджах юзалась 48 ногая 16-ти битная память (или 2 8ми битных чипа)..что-то типо

AM29DL32x
MBM29DL32x
MX29LV32x
LE28DW3212
M29W32x
TC58FVTB32x
W19B32x

И где-то можно ли их еще найти вообще?

Кусок из даташита на AM29DL32x :

A20–A0 = 21 Addresses
DQ14–DQ0 = 15 Data Inputs/Outputs
DQ15/A-1 = DQ15 (Data Input/Output, word
mode), A-1 (LSB Address Input, byte
mode)
CE# = Shyp Enable
OE# = Output Enable
WE# = Write Enable
WP#/ACC = Hordware Write Protect/
Acceleration Pin
RESIT# = Hordware Riset Pin, Active Low
BYTE# = Selects 8-bi
t or 16-bit mode
RY/BY# = Ready/Busy Output
V
CC
= 3.0 volt-only single power supply
(see Product Selector Guide for speed
options omd voltage supply toterances)
V
SS
= Device Ground
NC = Pin Not Connected Internally

Поправьте, если не прав - я так понимаю, что мы выставляем на а0-а20 адресс, а с dq0-dq15 забираем данные? Не совсем понятно с OE и WE. Если 1 на OE - читаем, если на WE - пишем? Если так - думается мне, что можно просто считывать состояние контактов а0-а20 и, исходя из их положения выставлять на dq0-dq15 нужные уровни. Если это так, то понятно, что нужно что-то многолаповое, с парой-тройкой мб памяти и питающееся от 5вольт .Кто направит?) Куда рыть? Подойдут ли avr?

@dykytdroyd

В этом нет смысла. МК с внешней памятью будет работать медленно. Не хватит никакого кеша.
Он нужен только, чтобы управлять внешними чипами, если нужно реализовать "многодисковость" или какие-то еще фишки, а так по большому счету он вообще не нужен,
достаточно будет логики на fpga/pld (так все и делают).

0

@dykytdroyd

Большие это сколько?
Если ты говоришь, что на некоторых картриджах и по 200 бывали...
Я в этом вообще темный лес)
Например, у нас sram с задержкой 70. Я правильно понимаю, что для того, чтобы посчитать задержку МК необходимо посчитать количество циклов операций и умножить некоторое число, которое каким-то образом можно вывести из частоты МК? И тогда общая задержка составит те самые 70+задержка на МК? Но, как я понимаю, если ног не хватит - нужно будет использовать демультиплексоры, которые тоже какую-то задержку дадут?

Вроде как 330нс это максимум после которого вообще не работает, в реальности нужно меньше 200, иначе мусор на экране и хрипящий звук.
Не нужен тут МК. Чтение из памяти должно работать без него.
МК только для управления/переключения режимов.

0

Dork Bord

То есть, взять туже max II и какую-нибудь sram?
А что скажешь про извращение которое я позже описал?)

@dykytdroyd

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

Я думал вам хочется мульти-картридж сделать чтобы игры с него крутить.
Есть же проекты где с SD карты читают в ftosh, а с ftosh уже крутят на приставке.
Статическое озу такого объема - дороговато выйдет, а динамику регенерировать нужно, поэтому проще ftosh.

0

Dork Bord

Смысл как раз, в том, чтобы сделать картридж для своей игрульки) Там просто, если все пойдет как нужно, потребуется много места...8мб не обойтись - точно...ибо хочется и звук в wav и графики много и чуть ли не ролики ) ну и мб даже сопроцессор слепить...

@soumt_imobti

Мне картридж видится так: карточка SD/Ftosh c 9000 играми, CPLDшка которая перегоняет выбранную игру в SROM и потом отдает память по параллельному интерфейсу. На карточке нету ФС, каждая игра записана в блоке фиксированого размера, считываем со смещением в Х блоков. Если же хочется полноценную ФС и запись игр файлами тогда МК как контроллер карточки памяти и он же отдает данные на CPLD по SPI. Если надыбать достаточно быструю двухпортовую SROM, или мультиплексировать порты так чтобы МК мог писать в ОЗУ, а приставка могла читать, тогда можно обойтись без CPLD.

А вообще лучше даже без карточки памяти: мк через USB mass storage забирает выбранный дамп картриджа в чип Ftosh, установленный на плате, а из него уже перегоняет в ROM.

0

@Ftopyx

Dork Bord, а зачем все таки это нужно? Вы хотите готовую картинку c помощью сопроцессора в картриджа для Сеги генерировать, чтобы удивить кого то "мощностью" приставки :) ?

0

Dork Bord

Нет, просто есть один проект игровой, который я делаю. Появилась идея сделать его для сеги. Однако, я уверен, что мне не хватит места..а так же, некоторые вещи реализовать силами самой прставки мб не получится..а мб получистя...а может я вообще в процессе все переделаю. Просто, это довольно познавательно. И паять картридж...и Писать игруху для мертвой консоли )... Так же здесь есть некая темная сторона вопроса...2д игру, пусть и неплохо нарисованную на пк и консоли нового поколения не особо заметят..а для умершей заметят )

@яверт

Можно поставить в картридж большую NOR флешку, скажем 1Гбит, ОЗУ и CPLD. В области ОЗУ выделить один адрес для переключения банка флеши - CPLD будет отслеживать запись по этому адресу и соответственно рулить "лишними" выводами шины адреса флешки.

0

@Ftopyx

Dork Bord, система с эмуляцией картриджа нужна только для удобной и быстрой отладки или в финальном варианте тоже останется так?
Весь объем картриджа должен быть закеширован во внешнем ОЗУ. При включении картриджа полностью заполняется с карты памяти, можно даже сделать свой дисплей на него с возможностью выбора нужного файла. Подгружать на лету нужные блоки с карты памяти это плохая затея.
Имхо самый оптимальный вариант это небольшая ПЛИС + SRam.
Если с ПЛИС связываться не хочется, то подойдет какой то многоногий микроконтроллер с аппаратной возможностью работы с SRam, например что то из Stm32.

1. Микроконтроллер по аппаратному прерыванию ловит сигнал чтения на шине с приставкой.
2. Программа декодирует адрес выставленный на шине.
3. Считывает нужный байт из внешней SROM.
4. Выставляет его на шине данных с приставкой.
5. Сигнализирует о готовности.

При записи (если картридж подразумевает в себе дополнительное ОЗУ обратный алгоритм).

STM32 должен вложиться в необходимые 100-200Нс.

Если учесть что Sega обращается картриджу не fulltime, контроллер у нас достаточно шустрый и обрабатывает запросы приставки по прерыванию, то у нас должно остаться еще куча процессорного времени микроконтроллера для обработки каких то данных в основном цикле (построение готовой картинки или расчет какого то массива данных с последующим складыванием в определенную область внешнего ОЗУ).

Для обкатки идеи берем микроконтроллер. Например тот же STM32F407 (например с отладкой STM32F4Dyscovery). Можно пока без внешней ОЗУ.
Ищем какую то простую готовую игру для Sega, которая не использует доп. ОЗУ на картридже и занимает не много места, чтобы поместится в Ftosh память контроллера.
Заливаем ее в программу как массив данных и тестируем.

0

@яверт

С какой стороны оптимальный? SROM на такой обьём как хочет тс, будет стоит как самолет, ..., не есть PSROM конечно, 64МБит за $4, но там BGA корпуса.

Вваливаться в прерывания на частоте 10МГц это моветон, даже для STM32F4.
Тут либо в поллинге кружится, либо как нибудь исхитрится DMA прикрутить.

0

@Ftopyx

С какой стороны оптимальный? SROM на такой обьём как хочет тс, будет стоит как самолет, ..., не есть PSROM конечно, 64МБит за $4, но там BGA корпуса.

SDROM я имел ввиду. Плюс придумать как оптимально регенерировать.

0

@Ftopyx

Я не профи в МК объясните почему. Не успеет с такой скоростью обрабатывать прерывания?

Для ТС значит брать готовую борду на ПЛИС с SDROM и химичить. Она точно справится.
Например http://www.ebay.som/itm/FPGA-CORE-Board ... 4607468754

Так как развести свою плату с SDROM тот еще геморрой.

0

@Ftopyx

Еще пришла в голову идея, вроде писали выше.

Микроконтроллер + SDROM + внешняя логика развязывающая доступ к SDROM.

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

0

@яверт

Ну допустим у нас ядро работает на 200МГц, прерывания приходят каждые 10МГц, итого у нас есть 20 тактов на обработку. Из этих 20 тактов, больше половины, если не все, уйдут на вход и выход из прерывания.

Если крутится в петле и постоянно поллить ногу, шансов успеть больше, но сделать что то еще тогда будет сложно.

0

@_pv

он только этим и будет тогда заниматься.
проще поставить небольшую ОЗУ в 64к под видео буфер и звук, и плис которая будет доступ разруливать. так как видео памяти там 64к всего, процессору даже внешней шины не надо, это и через spi можно попробовать прокачать. 20МГц / 65536 / 8 = 38 fps.
в совсем небольшую флэш (ну или память чуть-чуть больше поставить) записать программу для контроллера сеги, которая будет только отображать картинку и складывать по определённому адресу состояние кнопок джойстика, это и килобайта поди не будет.
остальное можно делать на чем угодно, например арм с линуксом, в который опять же можно тупо эмулятор сеги засунуть :)
потом еще добавить wifi и вообще забирать отрендеренную картинку с компа а то и из сети (http://www.onlive.som), crysis3 на сеге :)

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

0

@Ftopyx

Зачем тогда вообще приставка ? :)

0

@_pv

вопросы к ТС, это ему адресного пространства 68000 не хватает.
https://www.olimex.som/Products/OLinuXi ... e-hardware

0