Advanced MicroMachine (часть 3), Портирован эмулятор Nintendo GameBoy Опции

[Glucik]

Приглашаю посетить ресурс:
http://gamebox.uraldev.ru/forum/viewtopic....=5&p=13#p13

кратко:
на свой девайс (ARM9) портировал эмулятор популярной во всём мире карманной игровой приставки!
Фотки, ссылки на видеоролики там же.
Готов выслушать предложения, вопросы, критику, пожелания.

[Glucik]

Код эмуляции Z80 взят из cingb029. Он чисто на Си.
Не хочу обламывать, но имхо АРМ7 не хватит- у АРМ9 уже близко к пределу. Может потому что на асме не оптимизировано. х.з.

Дубль два по вопросу о быстром контроллере.

[khach]

Код эмуляции Z80 взят из cingb029. Он чисто на Си.
Не хочу обламывать, но имхо АРМ7 не хватит- у АРМ9 уже близко к пределу. Может потому что на асме не оптимизировано. х.з.

Спасибо, посмотрел эмулятор. Может ,как опытный в эмуляторостроении, подскажете- у меня есть задача модернизировать старинную систему, у которой процессор-z80. Система имеет кучу плат ввода-вывода и еще больше плат с памятью (на анлогах РФ1). Хочется вынуть родной Z80, вместо него вставить мелкую платку на LPC2148 (нужен быстрый интерфейс к компу и отладчик), в нем крутится эмулятор Z80 и в памяти хранится дамп прошивки прибора. Из-за этого внешняя шина освобождается только на операции обращения к портам. Такая система реализуема? Требуется сохранить тайминги как и на реальном Z80.
По поводу быстрого эмулятора. В проекте gngeo есть модуль drz80 - эмулятор Z80 написнный на армовском ассемблере. Пока еще не разбирался с ним, но может инфа пригодиться.

[AlexandrY]

Команды z80 контроллер на LPC проэмулирует пожалуй быстрее чем они выполнялись на 8 МГц Z80.
Но шинную активность ARM воспроизвести не сможет. Т.е. при эмуляции он безнадежно отстанет.
И если в оригинальной проге есть зажержки включающие циклы на внешней шине, то здесь будет облом.
Облом вообще будет поскольку сравнять скорость эмулятора и оригинала в проекте cingb нет никаких средств.
Хотя поскольку тики Z80 там считаютcя, то можно было бы наверно по какому либо таймеру на промежутках по 10 мкс прецизионно тормозить эмулятор.

Спасибо, посмотрел эмулятор. Может ,как опытный в эмуляторостроении, подскажете- у меня есть задача модернизировать старинную систему, у которой процессор-z80. Система имеет кучу плат ввода-вывода и еще больше плат с памятью (на анлогах РФ1). Хочется вынуть родной Z80, вместо него вставить мелкую платку на LPC2148 (нужен быстрый интерфейс к компу и отладчик), в нем крутится эмулятор Z80 и в памяти хранится дамп прошивки прибора. Из-за этого внешняя шина освобождается только на операции обращения к портам. Такая система реализуема? Требуется сохранить тайминги как и на реальном Z80.
По поводу быстрого эмулятора. В проекте gngeo есть модуль drz80 - эмулятор Z80 написнный на армовском ассемблере. Пока еще не разбирался с ним, но может инфа пригодиться.

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

А правда в том, что на RTOS его портировать было бы гораздо проще и естественней.
Поскольку этот эмулятор весь базируется на сервисах POSIX файловой системы, то скажем на той же ARTX прект даже не надо вычищать от файловых операций, как это пришлось скорее всего делать в вашем случае.

Что касается LCD, то как видно в эмуляторе там просто делается периодический вывод в некий экранный буфер.
Задача портирования была просто по прерываниям это буфер пересылать на LCD.
Это работы еще на час.
Итого цена портирования - 2 часа.

Ну, спасибо.
Обязательно применю этот проектик как демку в своих платформах.
Остался только вопрос где сами игры достать. Не подскажете?

Ога
И ОРТОДОКС вдобавок, млин... Ведь работает всё БЕЗ ОПЕРАЦИОННОЙ СИСТЕМЫ
Напрямую с камешком...

[Glucik]

Ну, спасибо.
Обязательно применю этот проектик как демку в своих платформах.
Остался только вопрос где сами игры достать. Не подскажете?

хттп://emu-russia.нет/ru/скачать/ромы/Nintendo-GameBoy-Color/0-Z/
хттп://emu-russia.нет/ru/скачать/ромы/Nintendo-GameBoy/0-Z/

В общем Google рулит

Что касается LCD, то как видно в эмуляторе там просто делается периодический вывод в некий экранный буфер.
Задача портирования была просто по прерываниям это буфер пересылать на LCD.

Можете, по-подробнее расписать, как вы видите портирование эмулятора cingb. Интересует в частности алгоритм всего эмулятора, а именно по части : 'Z80', железа и экранного буфера.

Интересно услышать другие(не свои) мысли по данной теме!

В gameboy.c есть такой фрагмент:

Код

  /* video update */
  lcdclks-=Z80_TICKS;
  if (LCDC & 0x80) { /* if lcd on */
    if (lcdclks<0) {
      lcdphase++;
      if (lcdphase==3) {
    if ((LY>142)&&(LY<153)) {
      lcdclks=GB_VCLKS[3];lcdphase--;
      hdma_update();
      if ((STAT&3)!=1) { /* v-blank */
        STAT=(STAT&0xFC)|1;vblankoccured=1;
        vblankdelay=GB_VBLANKDELAYCLKS;
      } else {
        if (LY==148) drawscreen();
      }
    } else {

Интересует вот такое условие: if (LY==148) drawscreen();

Тоесть если я прально понял, что как только счетчик координат по Y достиг значения 144 (т.е. весь буфер отрисован), то перекинуть буфер на экран.

Вы же говорите, что можно на прерывание повешать. Вот интересно узнать - как можно?

В самом эмуляторе используется только клавиатурное прерывание и всё. Весь цикл эмуляции в основной программе:

Код

Z80_HALTED=0;
breakpoint=-1;
lastbreakpoint=-1;skipover=0;db_trace=0;
err=0;
while (!err)
{
if (!Z80_HALTED)
{
  err=ExecOpcode();
}
  /* update registers & interrupt processing */
  gameboyspecifics();
}

А синхронизация там достигается ожиданием обратного хода луча по кадру (60Гц), поэтому на быстрых ПК оно будет одинаково работать(если мониторы гонят кадр с 60 Гц, есть и 70 :/ )

На АРМ9 бОльшую часть времени именно съедает эмуляция 'Z80' и железа. Лишь только на втором месте стоИт перерисовка LCD.

Сообщение отредактировал Glucik - Nov 12 2008, 04:00

[AlexandrY]

Я сказал про прерывание просто потому чтоб вас не напрягать лишним упоминанием RTOS

Но по жизни там где стоит drawscreen я посылаю ивент в RTOS и останавливаюсь на семафоре.
Ивент вызывает в другой задаче процесс перекодировки экранного буфера и пересылку DMA непосредственно в LCD.
В этой же задаче проверяется насколько опередил сигнал завершения формирования кадра в симуляторе реальное время для заданной частоты кадров. На разницу времени инициализируется таймер RTOS который потом и снимет семафор на продолжение работы симулятора.
Это позволит добиться прецизионной покадровой синхронизации.

Сделано так потому что, я этот симулятор планирую просто как одну из задач работающих на платформе.
Т.е. при желании смогу запустить несколько симуляторов геймбоев одновременно.
Одновременно экран геймбоя могу отдавать как картинку в вебстранице встроенного сервера любому клиенту через интернет. В идеале на локалке даже позволить играть с этим симулятором через WEB броузер используя видеострим в MPEG4.
Плохо, что мужик там ничего не смог сделать со звуком и ему не удалось портировать свой движок под Windows.
Но я тут думаю доделать это используя известный симулятор на PC для uC/GUI

Можете, по-подробнее расписать, как вы видите портирование эмулятора cingb. Интересует в частности алгоритм всего эмулятора, а именно по части : 'Z80', железа и экранного буфера.

Интересно услышать другие(не свои) мысли по данной теме!


Тоесть если я прально понял, что как только счетчик координат по Y достиг значения 144 (т.е. весь буфер отрисован), то перекинуть буфер на экран.

Вы же говорите, что можно на прерывание повешать. Вот интересно узнать - как можно?


А синхронизация там достигается ожиданием обратного хода луча по кадру (60Гц), поэтому на быстрых ПК оно будет одинаково работать(если мониторы гонят кадр с 60 Гц, есть и 70 :/ )

На АРМ9 бОльшую часть времени именно съедает эмуляция 'Z80' и железа. Лишь только на втором месте стоИт перерисовка LCD.

[Glucik]

Я сказал про прерывание просто потому чтоб вас не напрягать лишним упоминанием RTOS

Ничего страшного!
Получилось, что я сам написал некое подобие ОСи. Только не real-time

Но по жизни там где стоит drawscreen я посылаю ивент в RTOS и...

Спасибо за ответ!

Плохо, что мужик там ничего не смог сделать со звуком и ему не удалось портировать свой движок под Windows.
Но я тут думаю доделать это используя известный симулятор на PC для uC/GUI

Звуковой движок брал из gnuboy 1.0.3 - отлично имплантируется в cingb

Кроме этого, сохр./восст. машины тоже самому нужно обдумать.

[AlexandrY]

Ну вот, портировал на Windows под движок симулятора uC/GUI в среде Visual Studio 2008

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

Не подкинете ли заведомо рабочую прогу для проекта cingb?

Прект весть выложу когда заработает.

Ничего страшного!
Получилось, что я сам написал некое подобие ОСи. Только не real-time
Спасибо за ответ!
Звуковой движок брал из gnuboy 1.0.3 - отлично имплантируется в cingb

Кроме этого, сохр./восст. машины тоже самому нужно обдумать.

[AlexandrY]

Отбой! Прочитал таки вашу статью о симуляторах и осознал те же ошибки
Теперь крутится без тормозов.
Осталось конвертировать экран геймбоя в DIB формат.
Ваш симулятор у меня под XP глючит. Кажется мне, что делать под DirectX было плохой идеей.

Ну вот, портировал на Windows под движок симулятора uC/GUI в среде Visual Studio 2008

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

Не подкинете ли заведомо рабочую прогу для проекта cingb?

Прект весть выложу когда заработает.