Я лично вынес 2 момента для себя: 1 - Теперь я понимаю, почему NES/SNES картриджи занимали такой объем - для будущих расширений (сопроцессоры и DSP). 2 - Правильный путь - эмуляция на "железе", то есть на специально обученной ПЛИС, в которую можно грузить прошивку. Это, как раз, и будет компромиссом между "подгоном" под набор игр и точностью.
Да, автор вобщем уперся в x86 архитектуру. Со своей стороны он тоже решает задачу в лоб "написано 100 тактов, значит будет 100 тактов". Вполне может быть, что появятся технические решения на программируемых матрицах, которые часть проблем возьмут на себя.
Если не стремиться к правильным временам, то это будет игра whack-a-mole. Убил суслика - на его месте появилось трое. Починил 1 баг -вылезло 5. Только гляньте на changelog'и за последние 15 лет
Хитом для эмо-любов должен стать подключающийся по USB процессор от NES. Я конечно утрирую, но суть ясна - обработку всего-всего вы будете отдавать не виртуальной копии железа, а реальной. Я не представляю, насколько это реализуемо, но это самый бескостыльный способ точной эмуляции. ИМХО
Это так и это реализуемо. Был такой проект Commodore One где на плату можно было вставлять физические процессоры. С моей точки зрения это реальный прорыв если плата сама по себе будет эмулировать, но иметь слоты под реальное железо (CPU, GFX CPU и аудио) - особенно для аудио. В этой ситуации никакие споры о теплоте лампового звука будут невозможны.
Слушайте, а я вот тут задумался о насущном. Вот есть некий процессор A, процессор B старше A, С старше В и так далее. И дело происходит в 5000г нашей эры. И получилось у меня смоделировать на уровне транзисторов процессор В в процессоре А, на виртуальном В - процессор С и так далее. Что интересно меняется при увеличении числа итераций? Что происходит со временем внутри всей этой мутоты, если запустить пинг-понг на самом глубоком процессоре Z? Не что мы увидим на мониторе, а что реально происходит со временем там? Что происходит с КПД всей системы? Что будет, если смоделировать обычный комп на квантовом? Квантовый на обычном? Поочередно? В случайном порядке? Обширнейшая куча вопросов, а ответов нету
Запуск эмуляторов в эмуляторах - давняя народная забава. Если эмуляторы достаточно точные, то всё работает, но медленно. То есть КПД системы очень значительно падает.
Эмуляторы не работают в реальном времени. Эмулируется кадр так быстро, как это возможно, и потом эмулятор просто ждёт, чтобы синхронизировать вывод с реальным временем. Каждый вложенный эмулятор будет ждать своей виртуальной синхронизации, и этот процесс будет просто понижать КПД системы ещё больше.
Comments 25
1 - Теперь я понимаю, почему NES/SNES картриджи занимали такой объем - для будущих расширений (сопроцессоры и DSP).
2 - Правильный путь - эмуляция на "железе", то есть на специально обученной ПЛИС, в которую можно грузить прошивку. Это, как раз, и будет компромиссом между "подгоном" под набор игр и точностью.
Да, автор вобщем уперся в x86 архитектуру. Со своей стороны он тоже решает задачу в лоб "написано 100 тактов, значит будет 100 тактов". Вполне может быть, что появятся технические решения на программируемых матрицах, которые часть проблем возьмут на себя.
Reply
Если не стремиться к правильным временам, то это будет игра whack-a-mole. Убил суслика - на его месте появилось трое. Починил 1 баг -вылезло 5. Только гляньте на changelog'и за последние 15 лет
Я так понимаю речь про тайминги?
Reply
Reply
Reply
Reply
Reply
Reply
Эмуляторы не работают в реальном времени. Эмулируется кадр так быстро, как это возможно, и потом эмулятор просто ждёт, чтобы синхронизировать вывод с реальным временем. Каждый вложенный эмулятор будет ждать своей виртуальной синхронизации, и этот процесс будет просто понижать КПД системы ещё больше.
Reply
Reply
Leave a comment