ZXMAK2 - Виртуальная машина ZX Spectrum

[CodeMaster]

так ведь и эмуляция идет не на уровне кода, а ближе к эмуляции схемы.

Т.е. если взять проект спектрума на FPGA и проэмулировать его софтово, то вот такая система это минимум требуемого?

Основные пожиратели процессора - это графика и звук.

Надо использовать возможности GPU видеокарты по распределённым вычислениям.

[Eltaron]

Надо использовать возможности GPU видеокарты по распределённым вычислениям.

Толку-то, алгоритмы непараллелящиеся.

[Titus]

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

Ну да, 5 секунд - ниче так скорость)

---------- Post added at 23:06 ---------- Previous post was at 23:03 ----------

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

В ZXMak'е явно не на уровне транзисторов эмуляция)
Скорее на уровне циклов.

У какого 'такого' процессора?
Уведомление у видеокарты о начале кадра есть, но без коллбека, а посредством простого опроса ручками. Что многократно обсуждалось.

Графика - понятно. Но звук-то чего занимает?

---------- Post added at 23:08 ---------- Previous post was at 23:06 ----------

Т.е. если взять проект спектрума на FPGA и проэмулировать его софтово, то вот такая система это минимум требуемого?

Если эмулировать FPGA в реальном времени - это никакой бытовой комп не справится.

[ZXMAK]

Ну да, 5 секунд - ниче так скорость)

---------- Post added at 23:06 ---------- Previous post was at 23:03 ----------



В ZXMak'е явно не на уровне транзисторов эмуляция)
Скорее на уровне циклов.

в ZXMAK на уровне тактов (а кое-где и глубже), все операции которые происходят в риале на каждом такте эмулируются.

У какого 'такого' процессора?
Уведомление у видеокарты о начале кадра есть, но без коллбека, а посредством простого опроса ручками. Что многократно обсуждалось.

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

Графика - понятно. Но звук-то чего занимает?

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

На worldofspectrum указали на то, что при частоте дисплея 60 Гц, VBlank Sync не помогает и скролы всеравно дрожат. Пишут что в Unreal при такой частоте скролы плавные.
Однако у меня на Unreal скролы дрожат не меньше чем в ZXMAK2 без VBlank
Мы тут когда-то разбирались в чем может быть причина, пришли к выводу что видимо это из-за того, что у меня относительно современный процессор, а на них используется Intel® Turbo Boost Technology, которая динамически меняет частоту процессора. А Unreal синхронизируется TSC счетчику, который зависит от частоты процессора.

Потестил Spectaculator, в нем синхронизация ведет себя точно также как и VBlank в ZXMAK2, т.е. используется привязка к видеокарте с ресэмплингом.

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

Получились интересные картинки, думаю многим будет любопытно на них взглянуть:

Дисплей 60 Гц, синхронизация VBlank (с ресэмплингом фреймов):


Дисплей 60 Гц, синхронизация от звуковой карты:


Данные на графе отражают время.
Красная полоса - это время регенерации дисплея.

Желтый цвет - это время между рендерингом фреймов изображения.

Зеленый цвет - время затраченное на эмуляцию фрейма, включая рендеринг в текстуру видеокарты и микширование звуковых потоков и запись результата в буфер драйвера звуковой платы

А вот какая картина на дисплее 75 Гц:

Дисплей 75 Гц, синхронизация VBlank (с ресэмплингом фреймов):


Дисплей 75 Гц, синхронизация от звуковой карты:



Выводы: ресэмплинг работает корректно и на 60 и на 75 Гц дисплеях. А при синхронизации от звуковой карты система кидает уведомления о достижении позиции проигрывания звука пачками, т.е. старается удерживать большой размер заполненного аудиобуфера. Из-за этого часть видео кадров обновляется быстро, а потом возникает пауза, пока не освободится достаточно много места в аудиобуфере. Отсюда и дрожание на плавных скролах

[Titus]

Как ты вычисляешь точное время, по какому таймеру?

---------- Post added at 02:38 ---------- Previous post was at 02:37 ----------

А Unreal синхронизируется TSC счетчику, который зависит от частоты процессора.

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

Но кроме него вроде и нет мелкозернистых таймеров.

[ZXMAK]

Как ты вычисляешь точное время, по какому таймеру?

---------- Post added at 02:38 ---------- Previous post was at 02:37 ----------



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

Но кроме него вроде и нет мелкозернистых таймеров.

в ZXMAK2 время замеряется по системному таймеру (тот что у материнской платы), на моей системе он работает с частотой 2742900 Гц. Т.е. точность измерения 0,000000365 сек (365 наносекунд) или 36572 тиков между кадрами на 75 Гц дисплее

[Titus]

в ZXMAK2 время замеряется по системному таймеру (тот что у материнской платы), на моей системе он работает с частотой 2742900 Гц. Т.е. точность измерения 0,000000365 сек (365 наносекунд) или 36572 тиков между кадрами на 75 Гц дисплее

Это как к нему обращаться корректно через винду?

[ZXMAK]

Это как к нему обращаться корректно через винду?

QueryPerformanceCounter / QueryPerformanceFrequency

[daniel]

+2 ну как бы по определению с магнитофоном, а +3 - там вовсе не тырдос.
а так да, не работает, хоть и заявлено +3

я не про встроенную ос веду речь, контроллер tr-dos подключается к +3 ровно как и к другим фирменным машинам
http://zx-pk.ru/market/viewtopic.php?f=7&t=790
цитирую:
/Конструктор BDI 2.0
Печатная плата и набор деталей для сборки контроллера BDI ( TR-DOS ) с разъемом ZX-BUS
Контроллер подходит:
1. Для всех фирменных компов ( Sinclair ZX-Spectrum 48, 48+, 128, +2, +2A/B, +3 )
/
на форуме есть люди которые пользуются.

и ещё есть DivIDE с поддержкой trdos и, о чудо, тоже работает на +2A, +3.

---------- Post added at 11:39 ---------- Previous post was at 11:36 ----------

Помоему TRDOS не совместим с +2A/+3, поэтому он никак не будет там работать

ну в общем выше ответил уже

---------- Post added at 11:41 ---------- Previous post was at 11:39 ----------

лично использую trdos на +2A хоть и в составе DivIDE (тоже не мешало бы прикрутить). Пользователь ZX NOVOSIB, на сколько я помню использует +2B c аппаратным контроллером TR-DOS.

[Eltaron]

А фирменный BDI с +3 по идее не работает там свой дос.

А что ему помешает работать? Порты не пересекаются, а при обращении к нужным адресам контроллер BDI подключит свой ром и всё.
По-моему главная и единственная причина того, что TR-DOS не пашет в эмуляции +2/+3, это то, что ром с TR-DOS вообще не предусмотрен в их маппинге. Тут бы какую-нибудь возможность для устройств добавлять свои ромы сделать. Без этого ни DivIDE, ни даже мультифейс проэмулировать не выйдет.