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

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

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

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

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





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

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

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

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

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

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



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

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

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



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

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

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

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


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

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

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

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

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

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

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

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

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

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

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



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



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

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

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

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

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

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

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

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

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

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

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




Сделал через таблицу цветов. Тоесть цвета GBC 5:5:5 => Display 3:3:2
У афтара cingb вообще трансляция на 64 цвета только (дизеринг неизбежен)
Я расширил до 256 цветов (строго говоря - уже не эмулятор, а улучшайзер )



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

Сообщение отредактировал Glucik - Nov 14 2008, 02:46

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

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