Чето Вы господа в какие-то "дебри" ушли удалившись максимально от практической стороны вопроса (естественно 100% эмуляция тут ненужна для доводки УКНЦ версии до "рабочего" вида).
По сути:
на сколько я понимаю, для нормально работающей игры, при формировании нового кадра изображения, важен момент 100%-го обновления всех обновляемых фрагментов экранного ОЗУ ДО! высвечивания этих самых фрагментов. Т.е. в нашем случае нужен пример кода в котором ПП обрабатывает прерывание возникающее ВСЕГДА в один и тот же момент формирования кадра. А далее нужно проанализировать ВСЕГДА ли успеет ПП выводить нужные изменнеия на экран до того как "луч монитора" их покажет. Если не успевает то может стоит подобрать другой видеорежим? Может ли УКНЦ показать графику "в текстовом" режиме путем замены знакогенератора по ходу луча? (по сути быстрый режим "графики" у ПК8000,MSX,ATARI8bit,C64,NES,SEGA... всего-то ускоритель "текстового режима" реализованного в стиле КР580ВГ75). Кроме того ход самой игры а значит и работа ЦП долны быть синхронизированны с выводом графики, возможно ли генерировать с помощью ПП прерывание для ЦП? ну или от видеоадаптера? (впрочем если нет, то ЦП может poll механизмом опрашивать память и ждать сигнала от ПП).
Блин, ну всем давно известно что УКНЦ это "просранные полимеры" Научного Центра, но все же... интересна ЦИФРА! на сколько процентов он хуже того же спекки в играх? Неужели 2-й хоть и более медленный процессор + видеоконтроллер с кучей режимов никак нельзя применить?
Ответить с цитированием