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

[ZXMAK]

Каким методом ты синхронизируешься с лучом?

                // wait VBlank
                while (!_isCancel)
                {
                    var state = D3D.RasterStatus.InVBlank;
                    var change = state != _vblankValue;
                    _vblankValue = state;
                    if (change && _vblankValue)
                    {
                        break;
                    }
                }

кроме свойства InVBlank, других способов узнать момент начала развертки в MDX Direct3D не нашел И насколько помню в нативном API с этим тоже вроде проблемы были. В unreal тоже тупой цикл из-за этого сделали

[Titus]

кроме свойства InVBlank, других способов узнать момент начала развертки в MDX Direct3D не нашел И насколько помню в нативном API с этим тоже вроде проблемы были. В unreal тоже тупой цикл из-за этого сделали

Это что же, у тебя вечный цикл до смены вбланка?
Я тоже искал для своего эмулятора хоть какой-нибудь способ усыпить приложение до прихода VBlank, но не нашел. Пришлось так же отслеживать состояние пока оно не изменится.

[psb]

Это что же, у тебя вечный цикл до смены вбланка?

а как в пц демах делают? и почему тут нельзя так же?

[ZXMAK]

Это что же, у тебя вечный цикл до смены вбланка?
Я тоже искал для своего эмулятора хоть какой-нибудь способ усыпить приложение до прихода VBlank, но не нашел. Пришлось так же отслеживать состояние пока оно не изменится.

Да, если включить VBlank, то при вызове IHostVideo.WaitFrame работает тупой цикл, пока не прийдет VBlank. Пробовал сделать высокоприоритетный поток из которого кидать ивенты, но он как-то не стабильно работает, если его усыплять на 5-10 мс в момент ивента, то работает более менее, если усыплять на меньшее время, он начинает отбирать время у потоков эмуляции, если на большее, то пропускает кадры. Короче работает менее стабильно чем тупой цикл, а процессор жрет еще больше...

---------- Post added at 01:44 ---------- Previous post was at 01:29 ----------

а как в пц демах делают? и почему тут нельзя так же?

в демках не нужно узнавать когда бланк пришел, они просто вызывают Present, который при включенной настройке VBlank у девайса блокирует выполнение и крутит такой-же цикл уже внутри системы...
Тут есть загвоздка в том что в эмуляторе Present вызывается из UI потока. А синхронизировать нужно поток эмуляции, т.е. не из UI...
Хм.. Можно попробовать настроить девайс на Present с ожиданием VBlank и кидать после Present'а ивент для потока в котором выполняется WaitFrame...

[Titus]

Да, если включить VBlank, то при вызове IHostVideo.WaitFrame работает тупой цикл, пока не прийдет VBlank. Пробовал сделать высокоприоритетный поток из которого кидать ивенты, но он как-то не стабильно работает, если его усыплять на 5-10 мс в момент ивента, то работает более менее, если усыплять на меньшее время, он начинает отбирать время у потоков эмуляции, если на большее, то пропускает кадры. Короче работает менее стабильно чем тупой цикл, а процессор жрет еще больше...

А этот 'тупой цикл' не отбирает все быстродействие системы?

В своем эмуле я просто засыпаю на 1мс, потом проверяю не пришел ли вбланк, и так по кругу (если очень упрощенно говорить).
Хотя на самом деле я делаю чуть хитрее. Я не жду вбланк, а жду некой линии развертки, примерно линий за 100 до вбланк'а (с отдачей квантов другим задачам по 1мс кусочкам), после чего забираю все быстродействие на себя, таким образом могу очень точно отловить приход вбланка. Кроме того, такой подход позволяет избежать случайного пропуска момента вбланка, если в данное время какое-то приложение забрало на себя кванты времени, и не хочет отдавать.
Экспериментально тестировал в разных условиях, работает весьма стабильно даже если на фоне начался жуткий свап или другое безобразие.

[ZXMAK]

Хотя на самом деле я делаю чуть хитрее. Я не жду вбланк, а жду некой линии развертки, примерно линий за 100 до вбланк'а (с отдачей квантов другим задачам по 1мс кусочкам), после чего забираю все быстродействие на себя, таким образом могу очень точно отловить приход вбланка.

У Windows Sleep работает на аппаратных прерываниях 10 мс. Так что вызвав Sleep(1), назад управление можно получить и через 10 мс. А это практически время развертки целого кадра (1/75=13мс), о каком отслеживании VBlank в таких условиях можно говорить?

[Advertiser]

[Titus]

У Windows Sleep работает на аппаратных прерываниях 10 мс. Так что вызвав Sleep(1), назад управление можно получить и через 10 мс. А это практически время развертки целого кадра (1/75=13мс), о каком отслеживании VBlank в таких условиях можно говорить?

По умолчанию может и 10мс, но я устанавливаю предварительно принудительно 1мс, и действительно оно переключается каждую мс. Проверял тестами на всех машинах.

Можешь запустить у себя EmuStudio, он в консольном окне напишет измеренный минимальный интервал, уверен на 99.9%, что там будет написано Timer Period Min - 1ms.

[Faster]

А можно поподробнее как это обрабатывает реальная вг93? Зачем тут принудительное прерывание?

Итак, *****код процедуры торможения диска в лоадере Satisfaction находится по адресу #6084.

xor a
out (#1f),a
ld a,#d0
out (#1f),a
ret

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



Далее выполняется код:

xor a - гасим лампочку, bit 3 загрузки головки h выставляем в 0
out (#1f),a

Здесь выполняется команда "Восстановление" 0000hvxx - обеспечивает переход МГ на нулевую дорожку ГМД. Команда имеет следующие параметры:
h - бит определяет положение магнитной головки дисковода во время выполнения команды. Если он обнулен, то головка поднята, если установлен - находится в рабочем положении (опущена на дискету). Следует учитывать, что при h=0, контроллер не выдает сигнал на включение двигателя дисковода. Выход на нулевую дорожку подтверждается состоянием входного сигнала TR00 который поступает с НГМД. Если сигнал TR00 = 0, это означает, что МГ находится в исходном состоянии. Если сигнал TR00 = 1 (наш случай) микроконтроллер генерирует не более 255 шаговых импульсов STEP. Если после генерации 255 импульсов устанавливается низкий уровень сигнала TR00, то в бит состояния "Ошибка поиска" в регистр состояния записывается единица. Другими словами, физический дисковод на реале никуда головку перемещать не будет, но ВГ-93 отработает 255 шаговых имульсов. А в эмуляторе это не учитывается. После этого:



Далее, чтобы прервать эти шаговые импульсы выполняется код:

ld a,%11010000 - принудительно прерываем выполнение команды
out (#1f),a
ret

Здесь выполняется команда "Принудительное прерывание" 1101i3i2i1i0 - задается для завершения какой-либо выполняемой команды. В отличии от других команд она может быть записана в регистр команд в любой момент. Однако, исполнение команды может определяться состоянием младших битов i0 - i3. Если биты i0 - i3 в состоянии "0" (наш случай), то немедленно прекращается выполнение текущей команды и сигнал подтверждения завершения команды INTRQ не вырабатывается. После этого:



Затем, когда загрузчик пытается загрузить новую часть демо, то turbo loader виснет в цикле при чтении сектора на ошибке "сектор не найден".
Обрати внимание на номер трека и статус на последнем скрине, по идее значения должны быть такими (если я правильно понимаю):

STATUS: #80
TRK: #03
beta: #00

Ну, в общем, как-то так.

[ZXMAK]

Итак

Спасибо, очень помогло бы расписать что именно не так и как должно быть (например - вот тут делаем то-то, должно получиться то-то, а получается то-то), потому что пока кроме того, что чтото c восстановлением работает неправильно (если я правильно понял), суть проблемы не очень ясна

[ZXMAK]

пока без поддержки звука и джойстиков (видео, клавиатура, мышь)



Вроде в XNA уже встроен механизм синхронизации, когда окно активно, то кушает ядро на 100%, кактолько убераешь фокус - падает до обычных 5-8%. Причем что интересно, почемуто XNA4 сам вызывает обновление с частотой 50 Гц, как Game.Update, так и Game.Draw. Но фреймы скипает криво - похоже на синхронизацию от звука, даже чуть менее точно, плавные скролы подергиваются раз в несколько секунд.
Код полностью реюзает существующий MainPresenter, для XNA версии написана только реализация интерфейсов IHost (IHostVideo, IHostKeyboard, IHostMouse) и подключен референс на ZXMAK2.exe
Синхронизация по видео, т.к. IHostSound пока нету

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

Пока не комиттил. Подумываю о полном переходе на .NET 4.0. Но есть опасения что на каких-то системах он не поддерживается.