[vik0 0]

Для точных таймингов, а также если жалко тратить быстродействие арма на ногодёржество, можно CPLD поставить на эмуляцию этих таймингов.

Тогда можно сделать еще шаг вперед и поставить FPGA с soft-core Z80 :)

[LordVader 0]

Тогда можно сделать еще шаг вперед и поставить FPGA с soft-core Z80 :)

 

Можно. Только среди 5в-толерант девайсов дороговатые ФПГА получатся, а циклон какой-нить придётся обвешивать преобразователями уровней. А кроме того, для арма софт можно на сях переписать, хотя бы частично. =)

[khach 35]

Для точных таймингов, а также если жалко тратить быстродействие арма на ногодёржество, можно CPLD поставить на эмуляцию этих таймингов.

 

Сорцов эмулятора З80 в инете поищите, их есть =)

Так и предполагается- LPC2148 и EPM7128S. Вот только бы кто помог по связке одного с другим и начинкой CPLD. Интерфейс между ними быстрый только SSP возможен, параллельной шины то нет.

Пока как-то с таймингами несростается- неуспеваю пропихать туда- сюда данные и адрес и сигналы управления. Тайминги кстати аппаратно счетчика АРМа считать будут.

Если у кого есть интерес к такому девайсу давайте новую ветку откроем.

[LordVader 0]

Так и предполагается- LPC2148 и EPM7128S. Вот только бы кто помог по связке одного с другим и начинкой CPLD. Интерфейс между ними быстрый только SSP возможен, параллельной шины то нет.

Пока как-то с таймингами несростается- неуспеваю пропихать туда- сюда данные и адрес и сигналы управления. Тайминги кстати аппаратно счетчика АРМа считать будут.

Если у кого есть интерес к такому девайсу давайте новую ветку откроем.

 

А критичен именно быстрый обмен с периферией?

Я бы сделал так: по СПИ (или ССП) посылаю адрес, данные, направление обмена. Как только последние данные отправились, автомат в CPLD начинает процесс эмуляции таймингов Z80. Как обмен кончился, выдаёт прерывание, например, на арм.

Если же критична максимальная скорость, имхо параллельный интерфейс, правда ног CPLD может не хватить =)

[AlexandrY 3]

Команды 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 часа.

 

Ну, спасибо.

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

Остался только вопрос где сами игры достать. Не подскажете?

 

 

 

Ога ;)

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

Напрямую с камешком... :wub:

[Glucik 0]

Ну, спасибо.

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

Остался только вопрос где сами игры достать. Не подскажете?

 

хттп://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.

Изменено 12 ноября, 2008 пользователем Glucik

[Glucik 0]

Вы используете язык Си - это абстрагирование от железа

 

Никакое это не абстрагирование. К регистрам на Си обращение довольно прозрачно.

 

Другое дело, когда кто-то извне пытается навязать планировку задач ИМЕННО ТАК, как не нужно мне, например. И эта бинарная байда съедает тонны ресурсов (памяти в первую очередь).

 

На примере uCos/II я убедился, что проект громоздкий и неповоротливый. Гораздо проще это порешить программой-одиночкой, делающей именно ТО, ЧТО НУЖНО И НЕ БОЛЕЕ.

[1891ВМ12Я 0]

Никакое это не абстрагирование. К регистрам на Си обращение довольно прозрачно.

Ну например на pic16 если не ошибаюсь используется регистр аккумулятор и всякие системы адресации, в контроллерах avr все иначе, Си позволяет абстрагироваться от этих существенных различий в работе с регистрами... Регистр превращается в обычную переменную... Разве не абстрагирование?..

На примере uCos/II я убедился, что проект громоздкий и неповоротливый. Гораздо проще это порешить программой-одиночкой, делающей именно ТО, ЧТО НУЖНО И НЕ БОЛЕЕ.

Ну мне uCos/II тоже не нравится. Согласен, громоздкое и запутанное. Есть разные RTOS... Легкие и простые в применении, не навязывающие какие-то сложности, просто позволяющие написать программу эффективнее и красивее даже, более качественно разделить параллельные задачи чем одиночный цикл...

[AlexandrY 3]

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

 

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

Ивент вызывает в другой задаче процесс перекодировки экранного буфера и пересылку DMA непосредственно в LCD.

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

Это позволит добиться прецизионной покадровой синхронизации.

 

Сделано так потому что, я этот симулятор планирую просто как одну из задач работающих на платформе.

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

Одновременно экран геймбоя могу отдавать как картинку в вебстранице встроенного сервера любому клиенту через интернет. В идеале на локалке даже позволить играть с этим симулятором через WEB броузер используя видеострим в MPEG4.

Плохо, что мужик там ничего не смог сделать со звуком и ему не удалось портировать свой движок под Windows.

Но я тут думаю доделать это используя известный симулятор на PC для uC/GUI

 

 

 

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

 

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

 

 

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

 

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

 

 

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

 

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

[Glucik 0]

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

 

Ничего страшного!

Получилось, что я сам написал некое подобие ОСи. Только не real-time :)

 

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

 

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

 

Плохо, что мужик там ничего не смог сделать со звуком и ему не удалось портировать свой движок под Windows.

Но я тут думаю доделать это используя известный симулятор на PC для uC/GUI

 

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

 

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

[1891ВМ12Я 0]

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

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

[AlexandrY 3]

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

 

Но нет под рукой простенькой тестовой проги.

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

 

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

 

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

 

Ничего страшного!

Получилось, что я сам написал некое подобие ОСи. Только не real-time :)

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

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

 

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

[AlexandrY 3]

Отбой! Прочитал таки вашу статью о симуляторах и осознал те же ошибки

Теперь крутится без тормозов.

Осталось конвертировать экран геймбоя в DIB формат.

Ваш симулятор у меня под XP глючит. Кажется мне, что делать под DirectX было плохой идеей.

 

 

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

 

Но нет под рукой простенькой тестовой проги.

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

 

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

 

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

[Glucik 0]

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

 

ОГА!!!

ГНУлюбы токо этого и ждут, чтобы другие за них работу делали, а сами и пальцем не ударят! :smile3046:

 

Оказывается, что у 'нас' фатальных ошибок намного больше чем в РТОС. По-мойму вообще безаргументально в данном случае.

 

Извините, не удержался.

 

 

Осталось конвертировать экран геймбоя в DIB формат.

 

Сделал через таблицу цветов. Тоесть цвета GBC 5:5:5 => Display 3:3:2

У афтара cingb вообще трансляция на 64 цвета только (дизеринг неизбежен)

Я расширил до 256 цветов (строго говоря - уже не эмулятор, а улучшайзер )

 

Ваш симулятор у меня под XP глючит. Кажется мне, что делать под DirectX было плохой идеей.

 

Он под DOS. Чистый DOS... :wub:

В AuMAPI rev.8 сказано что не на всякой ХРени пойдёт.

Изменено 14 ноября, 2008 пользователем Glucik

[AlexandrY 3]

Тут согласен.

Показатель уровня - это не юзанье RTOS, а понимание их правильного тактического применения.

 

Использование неполноценных opensorcе-ных осей может вполне затормозить развитие проектов и внести лишние итерации.

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

 

 

ОГА!!!

ГНУлюбы токо этого и ждут, чтобы другие за них работу делали, а сами и пальцем не ударят! :smile3046:

 

Оказывается, что у 'нас' фатальных ошибок намного больше чем в РТОС. По-мойму вообще безаргументально в данном случае.