Озадачился вот таким вопросом: "Каковы приемущества железной эмуляции перед программной эмуляцией ?"

Поясню:

Железная эмуляция - реализация частей эмулируемой приставки (процессор, звук, видео и пр.) на FPGA (по-русски ПЛИС) - тоесть создаём схемный аналог компонентов приставки

Программная эмуляция - реализуем части приставки программно, управляя нижним слоем который в свою очередь ворочает железом нативно

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

Применение ПЛИСов, например при эмуляции видеоконтроллера потребует: отдельную VRAM, видео-DAC, в общем схемотехнические нагромождения налицо.

Мало того, недостаточно HDL-моделей ПЛИСов, изобилуют только CPU и некоторая примитивная периферия (типа PSG и пр.)

ИМХО, не вижу преимуществ Hard Emulation из-за громоздкости и отсутствия HDL-моделей некоторых компонентов.

Поправьте если не так.

Попробуй программно реализовать FM синтезатор, который бы хотя-бы на 90% повторил аппаратный. Со всеми гармониками и пр. лабудой. Так же, что проще: собрать два узла, которые работают асинхронно, каждый на своей частоте, и взаимодействуют друг с другом. При этом тайминги взаимодействия получаются сами по себе (мы помним, что есть куча софта для приставок, сильно зависимых от таймингов аппаратуры). Или все же реализовать это безобразие программно, постоянно подгоняя тики, стэйты и все такое? Вот примеры аппаратной реализации на FPGA:
NES/SNS on FPGA Japan:


Заметь, с выводом на VGA монитор. Можно подключить к панельке с VGA/DVI входом. Без искажений PAL системы. А кому нужен хендхелд с экраном в 2,8 дюйма? Тем более, что китайцы их уже штампуют пачками на любой вкус...
NES on Cyclone:

не совсем уверен, что FPGA-варианты реализуют это более точнее, так как приходилось иметь дело с однокристальной "СЕГой", в которой звук был просто ужасен.

с YM2612 ситуация более, чем неопределённая - её даташита не видел никто, не говоря уже о внутренней эквивалентной схеме.

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



проще первое, НО при условии, если известно о внутренней структуре эмулируемых чипов. Опять же, на примере YM2612 я даже не могу представить, какая логика должна быть у неё, чтобы исторгать FM-синтез. По-моему делителями и мелкой логикой не отделаться ...

Не совсем ясно, исходя из каких данных написали FPGA-модели, которые эмулируют периферию (например 2A03, PSG, TMS9918) ?
Используются ли исходные тексты программных эмуляторов (для тех же коэффициентов деления, таблиц частот, громкостей, огибающих) ?

Реально ли при таком подходе заэмулить YM2612 ? Или получится также как в программном эмуляторе?



видел, там ещё SNES на FPGA есть, плюс страница kevin norton. Кроме картинок ничего там не нашёл.



Не вижу трудностей хендхелд с мелким дисплеем переделать под TV (в частности, касаемо моих изделий). Просто пока не задавался целью.
Некоторые хендхелды (типа Динго-А320) дают композит, но качество увы, правда...

Думаю, что приставки с большим монитором/экраном будут нужны также, как и хендхелды.

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

Потому что проще и доступней.

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

Сюда приплюсовывается ещё доступность софт-эмуляторов, особенно портируемых (чисто на C/C++).

Думаю, что самому писать эмуль "с нуля" - трудоёмкая и долгая задача - люди тратят на это годы, пока не обрастают бородой и седеют

Вот я например не знаю VHDL, знаком только поверхностно с ним. Но даже если освоить его, эмулировать блоки приставки - хлопотное дело!
В железе тем более...

Вот что пока удалось найти:
YM2149 (SSG)
YM2413 (OPLL)
SN76489 (PSG)
6502
Z80
M68000
TMS9918
V9938

короче, только NES, MSX или SMS делать...

Ни о каких Мегадрайвах и Снесах речи и быть не может

А те дяди-японцы, которые сделали SNES на FPGA, наверняка работали в приставочных конторах, имелся доступ к документации =)



Не хочу ни с кем спорить, просто хочу выявить плюсы и минусы обоих типов эмуляции.

Железная эмуляция отталкивает по причинам:

1) жесткая привязка к железу
2) большое количество корпусов (всякие DAC'ы, Память, управляющие контроллеры и т.п.)
3) отсутствие VHDL-моделей на "экзотику" (типа YM2612, SEGA MD VDP)

Четвертым пунктом можно дополнить отсутствие знаний, но это ликвидируется при желании.



Да я вот тоже не могу понять, зачем воспроизводить "металличность" звучания того же YM2612, когда качество можно повысить программной эмуляцией? Тоже и относится к снятию галочки "Sprite Limit"

Это конечно уже не точная эмуляция, а улучшайзеры, но всёравно приятно

Главная проблема - отстутствие полной и достоверной информации как по интерфейсной (программной) части чипов, так и по "физической" (т.е. их аутпуту). Вон на гендеве на протяжении 30 страниц и полутора лет пытаются довести до ума YM2612, постят огромные посты и картинки, а толку... И то тема появилась из-за найденной японской доки, а так эта история насчитывает лет десять


Как ни странно, но тот же 2612 звучит лучше и приятнее эмуляторов. Если плохие игры выдавали пиликанье, это не значит, что это весь его потенциал.

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

Я не совсем понимаю определение "железной эмуляции". Если это перенос кода эмулятора на железку с подключением к ней некоторых схем, то это та же программная эмуляция на чуть более низком уровне и на более примитвном железе.
А под полным копированием схемотехники я понимаю копирование всех внутренних узлов и даже физ. элементов, а это в домашних условиях невозможно и называется не эмуляция, а копирование. Иначе, так TA-07 можно назвать эмулятором YM2612, хотя это его копия.
Поясните плиз подробней.

В общем здесь VHDL-код микросхемы PSG SN76489 (правда, в Мегадрайвах он заинтегрирован в VDP). После компиляции этого кода и прошивки в FPGA имеем тотже результат, что и даёт оригинальный SN76489 (правда отличия всё-же есть), тоесть теже выводы по функциональности (данные, адрес, управление), что даёт возможность грубо говоря вместо SN76489 поставить FPGA.

Или вообще все микросхемы приставки утолкать в FPGA со всеми межблочными соединениями.
Результат - будет приставка, почти иденитичная по работе, что и оригинал, НО внутренняя схема отличается радикально.

При таком подходе также создаются виртуальные процессоры, которые работают также как и аппаратные(почти).

Вот как я понимаю термин "железная эмуляция".

На счёт TA-07 и YM2612 - не совсем уверен, что это копии

---- добавлено ----

Ктати пришла в голову такая мысль (натолкнуло медленное исполнение эмулятора GBA на DT) - а что если взять ARM9 и настроить его MMU так, чтобы карта памяти совпадала с адресами периферийников GBA, а РОМы GBA (они ARM7) крутить на ARM9 ?

Получится не совсем эмуляция - код игр будет исполняться вживую, а периферию эмулировать каким-нибудь FPGA (для меня нереально) или DSP (очень даже реально) - к нему привешать экран и PCM-кодек.

Зато не будет уже эмуляции CPU, которая занимает много ресурсов. У меня к примеру эмуль VisualBoy при эмуляции GBA на PC (750MHz) с нулевым пропуском кадров идёт рывками заикаясь, хорошо идёт только на P-4 1600 MHz.

Правда проблемы будут с внешними прерываниями и ДМА (память GBA - видеопроцессор)

Кто что скажет? Перспективно ли такое направление реализовать полу-эмуляцию GBA?

Насчет переспективности ничего не могу сказать, но одну могу сказать ARM'ы имеют крайне навороченую систему команд и все эмуляторы GBA, DS в своей работе стараються использовать "интерпретацию" вместо "динамической рекомпиляции" в этом лежит основная причина такой медленой работе всех этих эмуляторов. Живой работающий рекомпилятор этого процессора я видел только в "макароне" но вот там он как раз никому и не нужен ибо скорость проца всего 2мгц, а вот где оно действительно нужно я встречал лишь попытки на которые в итоге был положен крест, авторам банально не хватает опыта.

про динамическую рекомпиляцию (dynarec, JIT) слыхал и читал (просматривал даже некоторые исходники).

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

я немного говорил выше о другом.
РОМы GBA исполнять напрямую без эмуляции ARM9-м процессором (коих навалом в магазинах).
Обращение к периферии на шине перехватывать небольшой логикой+DSP.
Логика при этом преобразует адреса и стыкует к порту DSP.
В DSP сидит прошивка, эмулирующая периферию GBA (видеоконтроллер, звукоконтроллер, джойстик)
Память тоже не эмулируется - она тоже реальная - прикручена к ARM9 или внутри него

Вместо картриджа взять SD-карточку и на моменте загрузки системы - её содержимое сливать в память, которая по адресам самого картриджа лежит
(не забываем что у нас ARM9 с MMU, который позволяет транслировать странично память (виртуальные адреса), поддерживаются размеры станиц по 1мб, 4кб, 1кб).

Гемор только с DMA-обращениями, не совсем додумал как можно их сделать. Думаю, нужно обрабатывать адреса (той самой логикой) и эмулировать DMA ARM9 через прерывания (тем самым дополнительно получим эффект "замороженности" CPU, когда DMA тянет контент из ROM)

Вот так пока я это вижу.

Эм кто заточен? Если нужен мультиплатформеный рекомпилятор, то это вполне себе достижимо, но вот кому оно надо?

коды одного процессра переделываются под коды другого процессора, а потом запускаются, так?

в одном из эмуляторов GBA видел, что там инструкции ARM7 подменялись на x86 (название хоть убей, не помню).

кстати, в Dingoo a320 говорят, что эмуляция GBA там не хуже сеговской/снесовской...
да и проц там не ARM

интересно, какой эмуль GBA в неё пихнули?

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

и всё-же интересно какой эмуль GBA в Динге взят за основу?
не думаю что китайцы его на асме переписывали а тем более писали сами с нуля

P.S. все эмули перепробовал на старом Duron 750Mhz - все хрипят либо заикаются при нулевом фреймскипе.
Нужно 4 кадра пропускать, чтоб звук нормально шёл.

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

Я думаю, все дело в том, что в аппаратуре реализованные блоки работают абсолютно паралельно, ты всегда знаешь, что и сколько времени займет. А вот многопоточное приложение написать - нужны определенные навыки. Синхронизация потоков под исполнением однопоточного процессора (пусть и с заточкой под многопоточность) и под управлением Windows, пути которой неисповедимы, вообще титанический труд. Так же, многие вещи, которые в железе получаются как само собой разумеющееся, в программной реализации вызывают просто головную боль. К примеру, кто из вас (подчеркиваю, из тех, кто реально сам писал эмулятор, а не копировал чужие исходники) столкнулся с синхронизацией вывода звука и изображения, помнит, каково это? Звук загнан в жесткие рамки системы (11/22/44кГц, требуется размер буфера вывода, что дает лаг звука по отношению к сцене на экране), а изображение отбирает просто 99% всей вычислительной мощности. Помните? В железе собираются 2 модуля (пусть даже "эмуляционные" - т.е. FPGA по сорцам эмулятора) и вуаля - все тайминги соблюдены.

Именно.

Тоже верно.

PS Роль программной эмуляции очень велика. Я не против нее. Я просто говорю, что в железе можно достичь лучшего результата с меньшими затратами.

PPS

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

Со звуком действительно трудно было, когда портировал эмуляторы. Всё дело в том, что размер буфера звука должен чётко фиксирован исходя из разрядности, битрейта и частоты приставки. Иногда невозможно с точностью до байта определить. Добавим сюда же vsync дисплея, получим асинхронную работу буфера (прерывание звуковой карты) и обратный ход луча монитора. В итоге звук очень сильно лажает...
Благо, что потом нашёл способ как нормально сделать



Согласен со всем.



В домашних условиях можно изучить топологию кристалла и "срисовать" схему?

Или лучше VHDL-модель писать исходя из сорцов эмуляторов звуковых чипов?

Легко. Декап чипа с фотками под микроскопом стоит около 100 баков. Есть фирмы, что все сделают сами, нужно только отправить пару-тройку оригинальных образцов. Mefas предоставляет этот сервис. А тут люди изучали декапсулированный OPLx. А так выглядит кристалл MASKROM секция OPLx чипа под микроскопом. Они сняли точные данные с таблицы FM синтезатора и эмуляция стала намного точнее.

PS Я с цитатами напартачил и не проверил, отсюда закралась ошибка у тебя - цитата моя, но написано как от GManiacа.

Нет, я имел в виду другое, я говорил вообще про любые задачи, не только эмуляцию.
Вообще-то, на самом нижнем уровне наш мир считается дискретным (по крайней мере, частота колебаний или длина волны точно квантуются: формулы Рэлея-Джинса, постоянная Планка и т.д.), но его "разрешение" настолько высокое, что можно считать физические величины непрерывными.
Цифровые устройства - подмножество "аналоговых". За счёт превращения непрерывных величин в дискретные (в частности, целые, это отображение обратимое) можно применять свой математический аппарат (например, теория чисел) и решать соответствующие задачи. Ну и такие, где точное решение просто необходимо.
Аналоговые устройства быстрее, цифровые - точнее.
Но есть одно НО. Из-за дискретизации приходится платить невозможностью решения некоторых задач (про "подмножество" выше написано).
Возьмём для примера обработку сигналов. Разложить сигнал на спектр можно с дискретнвм преобразованием Фурье. Ничего лучше нет, ДПФ - это просто частный случай ПФ, вывод у него один-единственный. Но само ДПФ устроено так, что НЕЗАВИСИМО ОТ ЧАСТОТЫ ДИСКРЕТИЗАЦИИ для получения разрешения полосок в 1 Гц нужна 1 секунда сигнала. Т.е. при частоте 48000 Гц для получения разрешения в 1 Гц (т.е. 24000 полос) нужно окно, по длине в два раза большее числа полос - 24000*2 = 48000 семплов = 1 секунда.
Всё окно семплов отображается в один столбик спектра. А сигнал ведь за это время может меняться. Идеальный случай - когда все частоты постоянны. ДПФ очень хорошо можно использовать для управления (добавления/удаления) отдельными полосками спектра, естественно, изменения затрагивают всю длину окна. В аналоговых схемах такое почти нереально или нужна очень сложная схема.
Для всех других случаях ДПФ можно использовать только с натяжкой. В частности, в случае модулированной частоты другой частотой (ну т.е. СПЕКТР выглядит как синусоида) ДПФ вообще неприменим - при низком разрешении минусы ясны, при высоком - спектр размывается в одну толстую полосу. Причём ясно, что чем выше частота модуляции, тем хуже.
А аналоговые решения с этим справятся. Это палка о двух концах: аналоговые решения более грубые, программные - более точные, но менее универсальные.
Ну, для фильтров, скажем, есть и другие программные способы - FIR-фильтры, ещё какие-то, но у всех свои недостатки.


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


Буфер для звука можно сделать относительно маленьким, так что задержка не будет заметным. Если звук не подвергается постобработке. А вот какая задача передо мной встала, когда я думал о временнОм мультиплексировании каналов и ресемплировании: лучший алгоритм ресемплинга основан на Фурье, я его составил и проверил, результат был лучше, чем в звук. редакторах (кроме Саньки, с ним совпало)... но, видимо, в них это всё косяки плохих просчётов и универсальности - например, Адуба точно использует Фурье.
Но вот незадача: для нормального ресемплинга нужно большое окно = буфер. Т.е. звук ВСЕГДА будет запаздывать. В случае с VGM это можно решить, т.к. в VGM заранее известно, что будет дальше. А в эмуляторе - нет.
Ну есть компромиссное решение - длину окна оставить большой, но пересчитывать всё окно заново при появлении ЧАСТИ новых семплов, например 1/4 - й. Но и вычислений будет в 4 раза больше.



90 баксов стоит ТОЛЬКО декап, авторы фоток писали, что Мефас были willing to сделать фотки сами, но это выходило очень дорого.

Неверно. Смотри, аналоговый фильтр работает непрерывно (ну в условиях твоей теории), а для ДПФ нужно использовать буфер, причем загонять туда весь период нужной частоты. Получается, чтобы сделать аппаратный анализатор спектра от 1Гц до 20Гц нужно 20 фильтров, с достаточной добротностью. При этом выходная АЧХ будет непрерывной (ее можно дискретизировать по уровням и времени, например). А вот ДПФ позволяет сделать за раз практически анализ всех 20 полос из одного буфера, но результат будет очень дискретизирован. Чтобы приблизится к дискретизированному результату, снятому с аналогового фильтра, нужно "прогонять" те же самые данные, смещаясь на 1 сэмпл. Количество требуемых расчетов возрастает неимоверно, а мы просто приближаемся к тому, что в аппаратном виде получается само собой...

Я помню была такая формула: чтобы эмулировать какую-либо систему на скорости 1х, нужна целевая система, с вычислительной мощностью минимум в 10 раз превышающую эмулируемую систему. Теперь подумайте, какой нужен процессор, чтобы заэмулировать, например, 2ГГц?

При этом, более слабый комп автоматом будет делать дропы. И это суровая правда жизни.

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

Ах да, я совсем забыл. Ну если есть микроскоп, то проблем нет. А если сложится куча народа - то непроблема и заводские качественные фотки сделать. Все же, самое трудное - это сама декапсуляция.

Дело совсем не в этом. Все цифровые спектроанализаторы так и делают - смотрят, сколько у тебя точек на экране, для каждой точки вычисляют смещение и от него вычисляют окно. 800 точек - 800 раз вычисляют окно. Вычисления на самом деле несложные. Если масштаб слишком большой, окна будут пересекаться. Они специально вычисляют ВСЕ окна, т.е. для всех точек на экране, чтобы можно было видеть спектрограмму во времени.
Например, для 16384 полос нужно окно в 32768 семпла (из-за симметричности ДПФ половина полос не несёт информации). Это 0.7 секунды. Т.е. цельное окно в 0.7 секунды преобразуется в один столбик из 16384 точек. Ты же не будешь смотреть на столбики с разрывами в 0.7 с, поэтому следующее окно будет считаться не через 0.7 секунды, а с того семпла, который лежит на следующем пикселе на экране. Есессно, на значения столбика влияют значения предыдущего (если масштаб большой), это непрерывная картина.

Дело в другом. Вот для примера картинки: Адуба 3, 48000 Гц, базовая частота 2000, модулирующая - 250, частота модуляции 3 Гц, длительность 2 с.
С разрешением 1024 полос видна нормальная синусоида, но и "квадратики" (из-за никзкого разрешения).
На 4096 совсем другая картина: квадратики исчезли и базовую частоту можно увидеть точнее, но синусоида стала очень толстой.
Это и есть недостаток ДПФ: для более точных вычислений частоты нужно более длинное окно, но на столбик частот влияют ВСЕ семплы окна. А если частота в пределах окна меняется, получается каша.
Отступление: есть такое понятие - оконные функции, они давят лепестки. Этот косяк тоже позволяют чуть сгладить, но несильно. ОФ - это предобработка исходого сигнала перед ДПФ. Sound Forge поддерживает их тоже, Rectangular - это "умножение на 1", т.е. считай нет ОФ. Ты можешь сам проверить, как выглядят частоты-делители частоты дискретизации (например, 6000 Гц для 48000 Гц ЧД) и НЕделетили с ОФ и БЕЗ них. А также как выглядит модулированная частота.


В случае же с "аналоговым миром", его сущности реагируют на изменение частоты мгновенно, им не нужно никакое окно. Ты же слышишь модулированную частоту правильно с большой точностью, и тебе не надо "заглядывать вперёд" на 32к семплов. Тебе достаточно 0.1 с, скажем. Аналоговым схемам, я думаю, тоже. А ДПФ с этим не справится никогда.
Ну, собсна, ты говорил, что программные EQ - сакс, ну причина опять в том же.

---- добавлено ----


Формула не имеет под собой основания. Помимо скорости растёт производительность устройства. Если у M68000 отношение MIPS/MHz составляет 1/8, у каких-нибудь Core i7 - раз 5-10. Это во-первых.
Во-вторых, растёт и сложность. Что там было у старых процев? Блок выборки адреса, АЛУ, регистры, УУ и всё по сути. Потом появляются интерпретатор, кэши, конвейеры, асинхронность, многоядерность и т.д. Конечно, можно эмулировать это на том же абстрактном уровне - взял команду, исполнил, увеличил Cycle Count и пошёл дальше. Но здесь есть куча подводных камней. Надо либо делать хаки, либо переходить на более низкий уровень.
Собсно, лично я именно в усложнении аппаратуры и вижу ухудшение эмуляции, а даже не в "недостатке информации".