BIOS Disassembling

[ValeraK]

(28.04.2012 12:17)SWAT писал(а):  Конечно стек уже реализуется софтварно, но если бы он был хардварный, это только плюс, но тогда можно забыть об обратной совместимости.

Я в текущей разработке VoIP использовал WIZnet W5300, удобен тем, что простой корпус, MAC и PHY на одном кристалле, TCP/IP встроенный, шина 8/16 бит с обращением к регистрам как индексно, так и адресно напрямую как к памяти. Правда совместимости с BBA не будет... У WIZnet есть более продвинутый кристалл W7100A с встроенным контроллером mcs51, на нём можно было-бы прикинутся BBA если-б знать точно его регистры, помимо тех что у Rtl. Думаю, что BBA не особо нужен, в инет я через модем лазил, в онлайн игры играл, но баловство всё это. Практической необходимости нет, можно конечно встроить в bios загрузку с сервера (например NBD) игрушек, но объём работы очень-но большой, а результат не удобнее чем с CF на G2.

[cybdyn]

вообщемто вопрос стоя так, что BBA это набор регистров и буфер данных для дрима и все данные обрабатываются софтварно. а на что перевести это устройство - другой вопрос.

ValeraK, так на чём остановилсь. в каком направлении будете двигаться г1-эмуль гдрома или г2+CF ???

[ValeraK]

(29.04.2012 01:16)cybdyn писал(а):  так на чём остановилсь. в каком направлении будете двигаться г1-эмуль гдрома или г2+CF ???

G2 и CF это уже другие реализовали, ввиде переходника G2 => IDE => CF => SD.
Так-что эта задача уже решена.

Я потихоньку веду работу над устройством вместо GD-Rom на G1.
Планирую так:
1. отпаиваю от dreamcast разъём G1 и припаиваю его к шине IDE чтобы можно было подключить реальный GD-Rom к PC для посылок команд и анализа ответов реального GD-Rom на них.
2. подключить шустрый контроллер с LCD индикатором к шине G1 с небольшой прогой создающей ответы на команды посылаемые bios-ом.
3. к контроллеру подключить SD карточку и написать поддержку имеджей.

В принципе можно было-бы использовать FPGA, но у меня есть подозрение, что это будет дольше по времени и более дорогостоящее решение, только перекомпиляция проекта съедает кучу времени, а приближений к окончательному варианту может оказаться много.
Например тот-же ADI Blackfin из младших/дешёвых моделей вполне справится. У blackfin есть модельки с полной поддержкой SD интерфейса и интерфейсом I2S, звук с аудио треков тоже нужно будет гнать.

[cybdyn]

"G2 и CF это уже другие реализовали, ввиде переходника G2 => IDE => CF => SD.Так-что эта задача уже решена."
это имеется ввиду схема битмастера IDE к G2? так они просто подключили или уже игры запускают?

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

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

[ValeraK]

(30.04.2012 18:43)cybdyn писал(а):  это имеется ввиду схема битмастера IDE к G2? так они просто подключили или уже игры запускают?

Да эта схема не для игр, а так чтоб попробовать. Линух на этой схеме файлы пишет.

> через ATA регистры, каким образом контроллер сымитирует их? даже если и самый шустрый.
Ключевое слово _шустрый_. Чисто програмно - лапками портов иммитируем аппаратный интерфейс. Присмотрелся я к ADI bf592, дешёвый (~200р), быстрый (200/400MHz) и излишков снаружи почти нет (кварец, стабилизатор1v35 и spi eeprom для загрузки софта), корпус вполне поятельный.
Ну а если совсем плохо с быстродействием, то можно изредка и IOREADY подёргать :-)

> в плис это просто - создать поле регистров и память внутреннюю или доступ к SRAM/SDRAM.
Регистры это десятая часть дела. Структуры протоколов/данных/аудио нужно чем-то поддержать, при DMA трансфере чтобы не вешать большую кэш микруху нужно подсосать данные с флэшки в одном цикле. Вот тут-то и начинается веселуха...

> для анализа работы платы гдром можно на дриме писать прогу и по компорту обмениваться с компом командами и результатами, не надо ничего паять
А как в этом случае отладить аппаратную часть, да ещё и всё в комплексе?

---

Объединил из нескольких источников распиновку интерфейса G1 GD-Rom.
У кого есть время посмотрите pls на таблицу в аттаче, может я что-то напутал,
не хочется наступать на собственные грабли.

[cybdyn]

оч. интересно посмотреть как он лапками будет имитировать регистры в которые надо писать/читать, а также есть регистр командного пакета глубиной 12(16) байт типа фифо какогонить.
могу конечно предположить, что скорости может и хватить (200мгц) чтобы сработало прерывание по стробу чтения или записи (#IORD / #IOWR) и успеть:
1- определить в какой рег пишем , короче - детериенировать адрес
2- захватывем что пишет дрим либо выставляем дриму на чтение.
про передачу данных я уже молчу...

структуру данных ответа прописывает контроллер в буффер - это программная часть задачи,
а апппаратная - дрим забирает данные по пио или дма. причём оговоренное число данных, так что с точки зрения интресфейса нет никаких структур и разных протоколов, кроме простого вычитывания указононго обьема данных по PIO или DMA.
с конкретикой DMA я не разбирался, но может быть два варианта:
1- арбитром является дрим и он задаёт все стробы и соответственно скорость передачи данных из буфера,
2- как в истинном дма - устройсво запрашивает шину (#ioREQ), а дрим отдаёт сигналом #ioACK , и далее устройство само должно вырабатывать все стробы записи в память (или скорее в промежуточн буфер шины г1 котор в холли).

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

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


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

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

ноги шины г1, а точнее конектора гдрома (50 пин) - я неплохо разглядел в полных схемах на дрим.

[ValeraK]

(01.05.2012 01:08)cybdyn писал(а):  оч. интересно посмотреть как он лапками будет имитировать регистры в которые надо писать/читать, а также есть регистр командного пакета глубиной 12(16) байт типа фифо какогонить.

Дождались ~RD/~WR на соответствующем ~CS, вектор в blackfine достаточно быстр, а дальше дело софта, на растактовке асм вполне успевает. ВижуалДСП я давно выкинул, пишу на асме под blackfin (могу компилятор запостить), проц с очень-но правильной архитектурой - задачи данного порядка щёлкает как семечки.
Я вполне разделяю Ваше мнение о FPGA, разумеется нет проблем с таймингами и рилтаймом, но есть одно НО, _цена_ и время разработки. Нужно изготовить готовое изделие с минимальным количеством компонентов и низкой итоговой стоимостью.
С FPGA, DSP, MCU, SoC я работаю достаточно долго, у мня нет проблем с боардами для экспериментов. Самое сложное подобрать элементную базу для конкретного проекта исходя из ряда параметров. В данном случае пушка для воробёв ни к чему, нужна дешевизна/простота и повторяемость.

> наладка железа производиться со строны кода для дрима , котрый я как раз уже изучяю в асме и компиляцию си файлов.
Всё-же посмотрите на мою прогу sh4script, проц SuperH достаточно прост для понимания, если не обращать внимания на обратную польскую запись. Небольшую тестовую прогу ковырянию в железе можно на этом скрипте быстро скидать. Компилятор конечно тупой, но зато не требует внешних приблуд/конфигов и позволяет сразу получить машинный код исполняемый на реальном железе дрима. Описание Hitachi проца у меня есть, если надо запостю.

> ноги шины г1, а точнее конектора гдрома (50 пин) - я неплохо разглядел в полных схемах на дрим.
Ну эт и ежу понятно (включая и pp.se - сколько намучался исправляя его баги), вопрос в третьем столбике по определению типа сигналов и как их интерпретировать. В соответствии этим определениям я и хочу спаять переходник.

P.S. Похоже буржуины спецом вносят дизы в доки, чтоб не допускать реальных воплощений идей...

[Rio]

Цитата:линуха перейти, показав насколько он удобнее и безопаснее.

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

[cybdyn]

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

пока не смотрел скрипт програму, вроде думаю хватет того что есть. мне не так много то и надо от кода.
только если ваша програмка имеет больше приемуществ по сравнению с обычным ГНУ компилятором?

а что там по пинам непонятно? какие дизы обнаружили?

[ValeraK]

(01.05.2012 17:15)cybdyn писал(а):  для меня пока по времени как раз осваивать новый контроллер больше чем взять то что есть.

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

> и по времени в плане заготовок под рукой похожий проект, только тут вроде как даже чемто проще.
Ну лежат у меня DE-Nano, с последнего семинара Altera поляк мне про CyclonV много дифирамбов напел, без спору у FPGA огромные перспективы и будующее, но надо проще быть - соизмерять возможности и самодостаточность.

> пока не смотрел скрипт програму, вроде думаю хватет того что есть. мне не так много то и надо от кода. только если ваша програмка имеет больше приемуществ по сравнению с обычным ГНУ компилятором?
Скрипт на сколько это возможно, близок к ассемблеру, перед гну паблик основной плюс - быстрота и простота как развёртывания, так и написания _простенькой_ проги. Посмотрите примеры которые я вложил в архив - проще не придумаешь.

> а что там по пинам непонятно?
Названия G1 и функционал в разных источниках разнятся, я прописал с точки зрения IDE интерфейса, возможно что-то и напутал, хотя логический анализатор вроде подтверждает мои транскрипции сигналов.

> какие дизы обнаружили?
Ну не полная правда хуже вранья, путаница в последовательности данных etc.
Поосмотрите как в pp.se описан maplebus, а затем посмотрите как в моём сырце ccp идёт ввод с клавиатуры, разница с точностью до наоборот. Вроде описано всё правильно, но если сделать как написано, то это приводит к полной не работоспособности проги, приходится мозгами скрипеть проверяя каждое утверждение.

[cybdyn]

ну вот когда по вашему методу заработает как надо, тогда осознаю приемущества и изучу более подробно))).
пока, как мы видим, рулят и работают только методы SWAT-а: SD и BIOS моды ))))

может в txt или pdf файл напишите, что насобирали и где что разнится...

а что там за анализатор логический, есть какие-нить картинки...?

про мапл ничё не могу сказать - не исследовал. pp.se -это эмуль мапла ?
кстати по мапл - изучали протокол?, а то хотел как то сделать переходник на джои от пс2(пс1).??

[cybdyn]

то что я понял по г1:

[ValeraK]

(01.05.2012 23:20)cybdyn писал(а):  пока, как мы видим, рулят и работают только методы SWAT-а: SD и BIOS моды ))))

Лучшее только то, что реализовано. Пока не сделал небуду говорить, что мой метод лучше. Хотя идея сесть на G1 мне кажется интереснее.

> может в txt или pdf файл напишите, что насобирали и где что разнится...
Всё один-в-один, правда я не понял для чего нужен сигнал emphasis?

> а что там за анализатор логический, есть какие-нить картинки...?
Так по быстрому спаял, просто пишет в ram логические состояния при изменении их. Простая схемка DD защёлка со входа и выхода которой логические уровни поданы на элементы исключающее-или, если обнаруживается разница на следующем стробе, то ведётся запись в ram и увеличивается адресный счётчик. Затем кнопками проигрываю содержимое ячеек на светодиодах и анализирую изменения. Вот думаю ещё 16 разрядов добавить к 8 имеющимся, тогда можно будет и содержимое пакетов смотреть.

> про мапл ничё не могу сказать - не исследовал. pp.se -это эмуль мапла ?
Сервак с которого я начинал изучать дрим mc.pp.se/dc/

> кстати по мапл - изучали протокол?, а то хотел как то сделать переходник на джои от пс2(пс1).??
MapleBus достаточно прост, со стороны дрима программировать его я научился. Можно сделать переходники, у меня есть на мышку/клавиатуру. Врятли эт комунить надо, родное железо доступно для покупки.

[cybdyn]

"правда я не понял для чего нужен сигнал emphasis?" - на 100% не у верен, но это типа если на диске царапики или ошибки начинают переть, то как бы этот сигнал говорит, что надо типа приглушить звук. этот цифровой канал как бы миксируется с основным звуком в аике, вот там некий алгоритм затухания или затушовывания, чтобы вские бяки не звучали))) ведь СDDA как известно не использует crc в секторе , это чисто данные, пожтому подлииность их нельзя проверить, чисто приглушить только...

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

а со стороны железа, что нужно плис или микроконт.
намшку и клаву в смысле сами делали..

[ValeraK]

(02.05.2012 17:06)cybdyn писал(а):  но это типа если на диске царапики или ошибки начинают переть, то как бы этот сигнал говорит, что надо типа приглушить звук.

А ну тогда я его никогда вырабатывать не буду, у мне всегда звук без ошибок считывается с флэшки :-)

> так с этого анализатора собратьбы данные в комп и анализировать))) , или там можно успеть чтото разобрать с этими лампочкаи... ?
Хотел сделать переливку в комп через LPT, не стал делать поскольку пары кнопок шаг вперёд-назад оказалось достаточным, схемка то одного вечера, а усложнение требует времени - ну лень мне было :-)

> а со стороны железа, что нужно плис или микроконт. намшку и клаву в смысле сами делали..
На mc-pp.se описан протокол транспортного уровня maplebus, копеечный микроконтроллер (типа AVR) справится с этой задачей. Я сначала купил переходник (пожалел денег на родную мышку) с ней шёл диск с графическим редактором, но как оказалось переходник плохо совместим с прогами dreamcast. Ну и как всегда бывает в таких случаях - заплатил дважды, сходил и купил родные мышку, клавиатуру и заодно руль с пуру-пуру прикупил.

[ValeraK]

Есть у кого возможность купить разъёмы для шины G1?
Нужно оба и с GD-Rom и с Dreamcast, не хочется корёжить живую консоль...

[cybdyn]

"копеечный микроконтроллер (типа AVR) справится с этой задачей." - а на физическом уровне. там вроде какаято хитрая система сигналов sdcka/sdckb?

[shadow]

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

[ValeraK]

(03.05.2012 10:34)cybdyn писал(а):  а на физическом уровне. там вроде какаято хитрая система сигналов sdcka/sdckb?

На самом деле ничего хитрого в http://mc.pp.se/dc/maplewire.html нормально описано. Если взять tinyAVR 20MHz питание 5v, то 2MHz на поток и ещё останется куча тактов на всё остальное. USB же програмно делают, а у него поток 1.5MHz - один порядок.

[ValeraK]

(04.05.2012 07:15)shadow писал(а):  ValeraK, есть у меня дохлая материнка от дрима, если почту оплатишь, то отправлю..

Tnx, если очень понадобится, я в личку кину свои координаты. Открыл верхнюю крышку dreamcast, снял GD-Rom посмотрел на разъёмы и что-то жалко стало ломать. Я хотел припаять GD-Rom к писюку на IDE и посмотреть как он будет отзыватся на команды.
Почесав репу решил пойти по обсуждавшемуся на форуме иному пути, может он будет быстрее и проще. Думаю всё-же припаять параллельно разъёму на материнке полный логический анализатор и слить весь протокол обмена при загрузки с диска, у меня появится реальный лог траффика.
Осталось спаять сэмплер анализатора. После праздника поеду в Екатеринбург за печатными платами по одному из договоров, ну и заскочу в промэлектронику куплю микросхемы и спаяю на макетке сэмплер на 32канала с глубиной в 512KB.

P.S. Вырисовывается другая проблемма, где покупать разъём стоящий на GD-Rom? не получится ли так, что страссирую/спаяю плату, а разъемов не будет, я же не могу заставлять людей отпаивать самим соеденитель, а потом только использовать устройство на реальном дриме...