Это точно. А ведь достаточно всего-то подпрограмме ReadWord передать адрес, а она уже пусть по адресу решает - резать младший бит, читать из ОЗУ, ПЗУ или с внешнего устройства.

Нет у меня используются разные обработчики)

---------- Post added at 01:27 ---------- Previous post was at 01:26 ----------

Еще бы) Но за универсальность обработчиков платить приходится скоростью эмулятора. Так что у меня разнесено по разным обработчикам для убыстрения.

Это плохо. Команды для чтения или записи поступают в операционный блок процессора, а он не различает, что это - команда или данные. Ему сказали - прочитать/записать, он и выполнил.

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

Какое падение скорости? Главное время занимает рендеринг экрана.
Кстати, где алгоритм рендеринга лучше - в UKNCBTL или в EmuStudio?

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

И ГЛАВНОЕ!!! ЖДЕМ ВЕРСИЮ 0.05d!!!

Не знаю, как у вас, а у меня главное время занимает эмуляция трех процессоров) А экран рендерится не более 20% от их времени.
И что значит лучше? Быстре - скорее всего у меня, а правильный ли у вас - не знаю. У меня экран рендерится целиком каждый кадр, а должен в идеале в синхронно с работой всей системы, чтобы каждое изменение памяти в процессе хода луча отражалось на изображении.

VT200 вроде заработал, только зависает при входе в Калькулятор. Впрочем, он зависает и на UKNCBTL.

УРА !!! Заработало !!!
По процессорам счет 1:1. С вашей стороны счетчик сдвига в ASH/ASHC, с нашей - нечетный счетчик команд.
А по рендерингу хотелось бы сравнить алгоритмы. В UKNCBTL почти правильный, даже учитывает графический курсор, нет только учета интенсивности для одиночной видеостроки, которая устанавливается через регистр отображения (но это покоцали уже и в реальных УКНЦ поздних выпусков).
А синхронно с работой системы сложно - выборка данных происходит каждые 640 нс. Надо одновременно с эмуляцией строить и образ экрана. Быстродействия не хватит.

Что за графический курсор?
У меня тоже нет яркости для конкретной строки, т.к. я не знаю, как она делается.

Можно сделать, и скорости хватит, только много возни.

Кстати, с яркостью UKNCBTL тоже, похоже, не так себя ведет. Замечал на реальной УКНЦ, что при загрузке системы с диска, который я прикладывал к первой версии эмулятора, экран вспыхивал ярким цветом, а на UKNCBTL этого замечено не было.

Нормально он работает и там, и там. Просто калькулятор строковой.

---------- Post added at 02:02 ---------- Previous post was at 01:57 ----------

Делается через регистр отображения, в документации все есть.
UKNCBTL выводит изображение 25 раз в секунду, а не 50, как надо. Поэтому может вспышка и не подпадает. А с яркость поддерживается как для основного изображения через регистр управления цветом, так и для курсора через регистр управления отображением.

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

Вспышка там на секунду, наверное, так что прозевать ее было бы сложно.

А как так получается, что на позндних УКНЦ якрость для конкретной строки не работает, а для всего экрана работает? Что там убрали?

Проверим попозже. Хотя графический курсор вроде нигде не употребляется.
Хотелось бы увидеть.
Яркость всего экрана управляется выводом Y видеоадаптера, а яркость одной строки через регистр управления отображением регулируется выводами P0, P1, P2. Все дело в том, что для отдельной видеостроки можно было регулировать яркость каждого канала (R, G, B), а с помощью Y - либо все каналы яркие, либо нормальной яркости. А так как регулировка яркости для отдельной видеостроки не применялась, то и ее убрали. В поздних модификациях выводы P0, P1, P2 просто висят в воздухе, а в "КВАНТ"-овской схемотехнике просто не запаивали одну микросхему и кучу резисторов (в качестве примера - второй УКНЦ у hobot-а.).