такой вариант проверялся, желаемого результата он не дает, т.к. часто пропускает кадры, хоть и не все, но пропускает
Так что всетаки за процессор?
Вид для печати
А вот у меня вообще стабильно работает как часы, если в принципе процессор тянет эмуляцию данной системы. А если ставлю RealTime приоритет (я не ставлю, ибо если зависнет, то до пересброса машины), то еще стабильнее. Единственное, что может повлиять при таком подходе на задержку возврата из Wait - это какое-нибудь жирное рисование другим процессом чего-нибудь на экране. Например, когда пользователь ожесточенно таскает окно. Но при realtime приоритете и в этом случае было стабильно.
У меня проц T2300 1.6ГГц с одним ядром (второе отключено). Это ноутбучный проц, но стоит в десктопе.
ZXMAK, спасибо за новую версию.
копирайт бы поправить на 2014. ;)
Обновил до версии 2.8.1.37646: https://zxmak2.codeplex.com/releases/view/574338
По функционалу больших изменений нет, т.к. изменения в основном в структуре кода.
Но кое-что пофиксил:
- исправлены подвисания на однопроцессорных системах при включении VBlank или Max Speed;
- исправлена обработка ошибок для XNA платформы;
- исправлена ошибка приводившая к крешу в окне настройки (заодно ускорилось открытие окна настроек);
- добавлены библиотеки XNA, чтобы не было ошибок если не установлен XNA;
- MACHINES.PAK заменен на machines.config, который содержит сразу все модели, для удобства редактирования;
- Немного переименованы файлы с раскладками клавиатуры;
- В конфигурации логгера теперь по дефолту включен вывод ошибок во всплывающую консоль (всплывает если возникнет ошибка), лог по дефолту также пишется в С:\Logs\ZXMAK2.log;
- Добавлена возможность задавать modelId, который будет использоваться при сохранении SZX снэпшотов. Пока можно задать только вручную в VMZ файле, дописав modelId="Sinclair128" у элемента Bus. Но модель для стандартных конфигураций уже устанавливается автоматом, см. machines.config;
- Проведен объемный рефакторинг кода по разрезке эмулятора на составные части, правда пока не до конца - engine и контролы в отдельную сборку пока не вынесены
Ну и вернул назад XNA реализацию, если не доступен WinForms, то будет предпринята попытка запуститься в XNA. Порядок, в каком производится попытка запуска можно задать в unity.config, в 52 строке. По дефолту стоит "WinForms, XNA", что значит вначале пробовать WinForms, а затем XNA. Можно прописать просто "XNA", тогда запуск всегда будет в режиме "XNA"
Нет, похоже эта дема определяет атм1 как атм2, но почему пока сложно сказать, загрузчик в ней тяжелый. Усугубляет ситуацию то, что точной информации по атм1 практически нет. Все что есть - это твоя страничка с кратким описанием. Но в ней не все сходится. Например нет информации как именно происходит выборка портов, например #FE и #7FFD, зависит ли это от режимов и в каких режимах они доступны. Разбирал декодировку портов в unreal, но там такая каша, что я удивлен что это вообще работает :)
По коду демы, там все грузится до 40-го вызовова в трдос, после возврата из которого в памяти нули вместо данных, отсюда и зависание
Отловить проблемное место можно так:
Ставим брейкпоинт на #80EF, запускаем дему, ждем точки останова.
Тут будет проблемный CALL #8144, заходим в него и шагаем до #816D, там будет CALL #3D13 в трдос.
Этот вызов назад уже не возвращается, т.к. в процессе его работы на одном из вызовов в озу, по адресу #5CC2 будут нули вместо кода.
Это както связано с перепутыванием памяти, т.к. если его выключить, то дема работает. Почему палитра не работает не разбирался, вероятно причина одна и таже - машина определяется как атм2, а не атм1, а там палитра уже по другому работает