Вид для печати
Цитата:
Сообщение от Titus
кроме свойства InVBlank, других способов узнать момент начала развертки в MDX Direct3D не нашел :) И насколько помню в нативном API с этим тоже вроде проблемы были. В unreal тоже тупой цикл из-за этого сделалиКод:// wait VBlank
while (!_isCancel)
{
var state = D3D.RasterStatus.InVBlank;
var change = state != _vblankValue;
_vblankValue = state;
if (change && _vblankValue)
{
break;
}
}
Это что же, у тебя вечный цикл до смены вбланка?Цитата:
Сообщение от ZXMAK
Я тоже искал для своего эмулятора хоть какой-нибудь способ усыпить приложение до прихода VBlank, но не нашел. Пришлось так же отслеживать состояние пока оно не изменится.
а как в пц демах делают? и почему тут нельзя так же?Цитата:
Сообщение от Titus
Да, если включить VBlank, то при вызове IHostVideo.WaitFrame работает тупой цикл, пока не прийдет VBlank. Пробовал сделать высокоприоритетный поток из которого кидать ивенты, но он как-то не стабильно работает, если его усыплять на 5-10 мс в момент ивента, то работает более менее, если усыплять на меньшее время, он начинает отбирать время у потоков эмуляции, если на большее, то пропускает кадры. Короче работает менее стабильно чем тупой цикл, а процессор жрет еще больше...Цитата:
Сообщение от Titus
---------- Post added at 01:44 ---------- Previous post was at 01:29 ----------
в демках не нужно узнавать когда бланк пришел, они просто вызывают Present, который при включенной настройке VBlank у девайса блокирует выполнение и крутит такой-же цикл уже внутри системы...Цитата:
Сообщение от psb
Тут есть загвоздка в том что в эмуляторе Present вызывается из UI потока. А синхронизировать нужно поток эмуляции, т.е. не из UI...
Хм.. Можно попробовать настроить девайс на Present с ожиданием VBlank и кидать после Present'а ивент для потока в котором выполняется WaitFrame...
А этот 'тупой цикл' не отбирает все быстродействие системы?Цитата:
Сообщение от ZXMAK
В своем эмуле я просто засыпаю на 1мс, потом проверяю не пришел ли вбланк, и так по кругу (если очень упрощенно говорить).
Хотя на самом деле я делаю чуть хитрее. Я не жду вбланк, а жду некой линии развертки, примерно линий за 100 до вбланк'а (с отдачей квантов другим задачам по 1мс кусочкам), после чего забираю все быстродействие на себя, таким образом могу очень точно отловить приход вбланка. Кроме того, такой подход позволяет избежать случайного пропуска момента вбланка, если в данное время какое-то приложение забрало на себя кванты времени, и не хочет отдавать.
Экспериментально тестировал в разных условиях, работает весьма стабильно даже если на фоне начался жуткий свап или другое безобразие.
У Windows Sleep работает на аппаратных прерываниях 10 мс. Так что вызвав Sleep(1), назад управление можно получить и через 10 мс. А это практически время развертки целого кадра (1/75=13мс), о каком отслеживании VBlank в таких условиях можно говорить? :)Цитата:
Сообщение от Titus
По умолчанию может и 10мс, но я устанавливаю предварительно принудительно 1мс, и действительно оно переключается каждую мс. Проверял тестами на всех машинах.Цитата:
Сообщение от ZXMAK
Можешь запустить у себя EmuStudio, он в консольном окне напишет измеренный минимальный интервал, уверен на 99.9%, что там будет написано Timer Period Min - 1ms.
Итак, *****код процедуры торможения диска в лоадере Satisfaction находится по адресу #6084.Цитата:
Сообщение от ZXMAK
Непосредственно после загрузки первой части мегадемо, до выполнения процедуры торможения диска, имеем следующую ситуацию в эмуляторе:Код:xor a
out (#1f),a
ld a,#d0
out (#1f),a
ret
http://x-bytes.net/pic1.jpg
Далее выполняется код:
Здесь выполняется команда "Восстановление" 0000hvxx - обеспечивает переход МГ на нулевую дорожку ГМД. Команда имеет следующие параметры:Код:xor a - гасим лампочку, bit 3 загрузки головки h выставляем в 0
out (#1f),a
h - бит определяет положение магнитной головки дисковода во время выполнения команды. Если он обнулен, то головка поднята, если установлен - находится в рабочем положении (опущена на дискету). Следует учитывать, что при h=0, контроллер не выдает сигнал на включение двигателя дисковода. Выход на нулевую дорожку подтверждается состоянием входного сигнала TR00 который поступает с НГМД. Если сигнал TR00 = 0, это означает, что МГ находится в исходном состоянии. Если сигнал TR00 = 1 (наш случай) микроконтроллер генерирует не более 255 шаговых импульсов STEP. Если после генерации 255 импульсов устанавливается низкий уровень сигнала TR00, то в бит состояния "Ошибка поиска" в регистр состояния записывается единица. Другими словами, физический дисковод на реале никуда головку перемещать не будет, но ВГ-93 отработает 255 шаговых имульсов. А в эмуляторе это не учитывается. После этого:
http://x-bytes.net/pic2.jpg
Далее, чтобы прервать эти шаговые импульсы выполняется код:
Здесь выполняется команда "Принудительное прерывание" 1101i3i2i1i0 - задается для завершения какой-либо выполняемой команды. В отличии от других команд она может быть записана в регистр команд в любой момент. Однако, исполнение команды может определяться состоянием младших битов i0 - i3. Если биты i0 - i3 в состоянии "0" (наш случай), то немедленно прекращается выполнение текущей команды и сигнал подтверждения завершения команды INTRQ не вырабатывается. После этого:Код:ld a,%11010000 - принудительно прерываем выполнение команды
out (#1f),a
ret
http://x-bytes.net/pic3.jpg
Затем, когда загрузчик пытается загрузить новую часть демо, то turbo loader виснет в цикле при чтении сектора на ошибке "сектор не найден".
Обрати внимание на номер трека и статус на последнем скрине, по идее значения должны быть такими (если я правильно понимаю):
Ну, в общем, как-то так.Код:STATUS: #80
TRK: #03
beta: #00
Спасибо, очень помогло бы расписать что именно не так и как должно быть (например - вот тут делаем то-то, должно получиться то-то, а получается то-то), потому что пока кроме того, что чтото c восстановлением работает неправильно (если я правильно понял), суть проблемы не очень ясна :)Цитата:
Сообщение от Faster
пока без поддержки звука и джойстиков (видео, клавиатура, мышь) :)
http://savepic.org/5246854.png
Вроде в 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. Но есть опасения что на каких-то системах он не поддерживается.