repstosw

Вы правы. Да, ошибся. Слово "эмулятор" понял как раз именно в этом контексте. Меня троллят с 2008 года всякими Dingoo A320 и прочим китайским шлаком, который воспроизвоидт игры весьма дёрганно..... И меня раздражает подход "на отъ*б*сь " в китайских приставках. Но пипл хавает, ему по* на то что фреймы пропускаются и дёргаются. Дешевизна - вот путь к успеху! Даже если качество страдает. Поэтому пост jcxz был мной понят неправильно. jcxz, я понял. Всё - обиды снимаю! Всё ОК! В моей плате пины под JTAG не выведены :) Прийдётся отлаживаться любительскими методами))

Мне не нужны даже даром готовые эмуляторы игровых приставок (особенно дешёвые) - интересно самому сделать. Расцениваю как плевок в мою сторону. Спасибо. Удачи!

Сделал через таблицу переходов (точнее - вызовов функций). Работает, дало небольшое увеличение в скорости. Код такой: void opcode_0(void) { ... } void opcode_1(void) { ... } void opcode_2(void) { ... } void opcode_3(void) { ... } typedef void (*Handler)(void); #pragma DATA_ALIGN(32) const Handler ARM_Handler[0x1000]= { opcode_0,opcode_1,opcode_2,opcode_3, ........ }; void arm_new(void) { opcode= ..... ...... ARM_Handler[opcode](); } Таблица и код находятся в SDRAM, она закеширована по L1D, L1P, L2. При попытке скопировать таблицу ARM_Handler[0x1000] в L2 и выполнить код ARM_Handler_L2[opcode]() сославшись на эту таблицу(в L2) приводит к вылету - контроллер сбрасывается. Хочется скопировать эту таблицу в L2 и дёргать указатели функций из неё, чтобы исключить промахи кеша (ведь выборки из ARM_Handler[] случайные). Почему с копированием таблицы в L2 указатели на функции становятся невалидными? (Кеш L2 я сбрасываю, если что, хотя это тут не нужно, так как L2 некешируемый регион и любая запись в него приводит к фактической записи данных) Связано ли это как-то с адресацией данных? Может относительная адресация вместо абcолютной ? Пробовал разные data access model: - на near вообще не собирается, так как на смещение надо более 15 бит (линковщик ругается), far_aggregates и far работает. Общий объём бинарного образа - около 1 МБ Включена опция: DP relative addressing - она ускоряет выбор данных или нет?

Проблема решилась: вынес все CASE16 отдельно CPP/H-файл и оформил в виде функции . Успешно скомпилировал. А в исходном файле немного изменил алгоритм и добавил вызов той самой функции. Иными словами - распилил на 2 C-файла и получил 2 объектника.

Для GBA эмулятора. Выходит 25-30 FPS, вместо нужных 60 FPS. Звук тарахтит - фрагмент проигрыается дважды, так как звуковая подсистема требует данные чаще, чем эмулятор успевает заполнить буфер. Звук там "мягкий" - зависит от растактовок процессора приставки (программные задержки). Сделал ресемплинг, просто растянув отсчёты - темп понизился, тарахтение исчезло, но и тон снизился , что не нужно. Хочется чтоб именно был звук как на распев без снижения частоты (tempo stretching with pitch saving) Нашёл пару алгоритмов на гитхабе, но они ппц какие сложные. Хочется проще... А что если исходный фрейм повторять дважды, а склеивать с нахлёстом? Нахлест взять 1/4 длины фрейма. Начальный и конечный нахлест усреднить...

Есть аудио-сигнал, распиленный на фреймы одинаковой длины. Длина фрейма, частота семплирования, разрядность известны. Нужно понизить темп воспроизведения с сохранением тональности. Как? Нужен алгоритм, желательно на C/C++. Гугл выдаёт готовые программы, нужне сам алгоритм!

Насколько ускорит выполнение кода таблица с указателями? И как заставить компилятор switch делать в таблицу, а не условия? TI Compiler не поддерживает GCC финт ушами наподобие: goto &&OPCODE[n];

У вас вот это есть? - ".... включая мой Cherry Trail https://01.org/linuxgraphics/documentation/hardware-specification-prms " можете ссылкой поделиться на скачивание? (а вдруг я тоже буду на "атомах" что-нить делать?)) )

Вот такой асм-листинг вышел - на 103 700 строк: ARM-NEW.rar

Версия 7.4.24 успешно скомпилировала на максимально возможной с ним оптимизации. Пиковое потребление памяти - около 2 ГБ. Компилировалось - 1 час с небольшим. Но скорость кода им порождаемая, меньше, чем у 8.3.3 - так что пока проблема не решена. Чуть-позже посмотрю настройки и попробую отсечь часть кода. Результаты напишу. P.S. Под БлекФины Visual DSP v. 5.0 компилировал этот код 17 часов на стареньком компе 800 МГц с 64 МБ оперативы с Win98 :) Несколько лет назад!

Сейчас спустился на версию компилятора 7.x.x уже целый час компилится, всё никак не может собраться: Обратите внимание, пакет компилятора 32-битный, а не 64-битный. Хотя железо и ОС - 64 битные. Почему?

С исходниками та же фигня. (не обязательно у интела) Так что если есть что-то ценное - сохраняйте на диски! Хотя стоп! Ведь надо просто зарегаться вроде как: https://01.org/user/register

Компилирую очередной "шедевр эмуляции" - эмулятор ядра ARM7TDMI. Ключи такие: Проблема: не хватает оперативной памяти компа чтоб завершить компиляцию. В диспетчере задач оптимизатор занимает около 3 ГБ памяти на пике. Затем благополучно вываливается ошибка: Прикладываю сорец который не компилируется: ARM-NEW.cpp На -O2 тоже облом. Компилирует только на -O1, что не устраивает совсем! Что можно предпринять чтоб скомпилировать на максимальной оптимизации? Пилить сорец на части вроде не выйдет - там большой свитч на 6000 строк........

У меня есть все PDF-ки которые были тут: https://01.org/linuxgraphics/documentation/driver-documentation-prms/2014-intel-processors-based-bay-trail-platform Ага :) Опен хард такой опен-хард - что доступно ограниченное количество времени........ То же самое и с фриской было с их i.MX. Было SDK под баре-метал и сплыло... Мудачество со стороны производителя железа. Мол пишите под андроид... да нах он сдался мне? (зла не хватает!)

Перенес эмулятор Capcom Play System 1 и 2. За основу брал caname. Задолбался его вычищать. Учитывая большую любовь MAME к точности эмуляции и универсальный системный подход, большой скорости ждать не пришлось. caname - огрызок от MAME заточенный на CPS1,2. И ещё, 32 МБ мало - там только куча требует 16 МБ чтобы создать среду эмулятора. Оптимально - 64 МБ как было в TF. Лучше 128. Эмулятор ворочает на C6745 на 35..40 FPS, вместо целевых 60. Но это лучше, чем ничего. Можно конечно пропуск кадров сделать - но это не моё. Лучше честно видеть все кадры на медленной скорости, чем половину вообще не видеть )) Размер экрана в CPS1,2 384x224 пикселей (логически до 512x256 - скролл). Игры специфические. Видео-профит: https://www.youtube.com/watch?v=D_TOI35BflI Также - используется PRU1 для отправки кадра на LCD, предварительно декодировав палитру

Нубу в BGA как проверить что первая пайка упешна или нет? И где взять "собак на опыты"? К тому же, портить микросхемы - дорогое удовольствие

Бегло просмотрел даташиты... Ну что-же... Внушает! ))) Чем-то даташит видеокарты 3Dfx Voodoo3 напомнило. По идее, польза от этих pdf-ок должна быть. При условии что если базовый адрес регистрового файла известен.

Более младшие версии этого драйвера есть в исходниках? Аппноты кто-нибудь составлял? Или реверс GPU прийдётся заменить на реверс исходников драйвера Linux? Для меня любая ОС - как пятая конечность человеку. Ибо громоздко и лишнее. Ну может только срубить бабла по-быстрому на электронике. Для души применять я бы не стал. Исключение только для крохотных ОС делаю типа u-Cos, FREE RTOS и им подобным, которые ничего кроме как переключателя контекста не представляет. Хотя как моя практика показала, что прерываний достаточно. Может задачи пока такие не попадались, где ОС нужны.... Но псевдо-многозадачность спокойно делается DMA, таймерами и прерываниями. Mali400 - это классический GPU всех АРМ-ов. Ненавидимо по причине закрытости.

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

Да присматривался я к OMAP-L137, в QFP корпусе есть только на 300 МГц. И в Россию их поставку ограничили. А вот C6745 ещё лежат на складах нашей Родины со старых времён ))

Тоесть будете программировать этот камень под Win10 ? А как же ваше утверждение с другой темы по поводу: "... пускать под линуксом аудио ... совсем не улыбает..." ? И почему Win10 ? То что видеоядро закрыто - минус в карму интела. Не mail400 случайно? Если да, то давить бульдозером! Даёшь свой блиттер на FPGA! )))

Исходники автора теперь находятся здесь - переработаны под отладочную плату STM32H7 Nucleo: https://vrtp.ru/index.php?showtopic=30174&st=0 Там же и референсный код (который брался за основу) эмуляторов. Эмуляторы которые выложены: 1) NES - "Дендик" 2) GB(C) - "Геймбой" ч/б, цветной 3) Atari Lynx 4) SMS - SEGA Master System (простая, не путать с МегаДрайвом который навороченее) 5) PCE16 - Turbo Grafx 16 Для начального освоения более чем достатчно.))

BGA :) Обидно, хоть учись паять их... Доки открыты? Аппноты? На регистровом уровне их программировать можно будет?

Андроид и малина всё испортили. Люди зажрались. Форумы умерли. Обсуждения как раньше нет и не будет.

Всё просто как "дважды два": Во-1: мне это интересно Во-2: интересно было пощупать C6745 DSP на предмет уделывания им Блекфина и STM32H7 (сравнить производительность на мультимедиа-приложениях) В-3: макет заточен как отладочная плата на C6745 - лишней не будет, архитектура крайне удачна: на этой доске очень удобно изучать неизведанные перифералы, отлаживать алгоритмы (не только для хобби!) В-4: коммерческого выхлопа нет. Дай бог хотя бы частично отбить затраты. По первому - навеяно вот этими темами: 1) https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=61161 - я - автор данных приставок и мои посты. 2) https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=146347 - всё-же после небольших колебаний, я решился 3) https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=142964&page=6 - немного тут (с 6 страницы) Кстати, некоторые товарищи в другом форуме считают, что STM32H7 уделают C6745 DSP - причем свято и непогрешимо в это верят, что начинают лезть своими дебатами, аж смешно! )) Переписал рендеринг на ассемблере для PRU1, включил unaligned word access для эмулятора СЕГи. В итоге скорость возросла ещё больше!!! https://www.youtube.com/watch?v=c7B8XvB4c7c Да у меня Блекфин BF532 давился от этого эмулятора на 400 МГц, а на 600 - 700 МГц получилось впритык:60 FPS. А тут C6745 на 456 МГц + PRU 228 МГц переваривают код эмулятора намного быстрее!!! Только положительные впечатления! Самый лучший микроконтроллер, который я только использовал (после AT91RM9200, BF532, BF533, STM32F407, STM32H743)