Сколько помню, только более менее новые демонстрашки
и наши игрушки не используют чтение экрана, а почти весь багаж западных игрушек читает экран.. Нарпимер наложение изображения поверх имеющегося по AND или }{OR - часто используемая операция.
А вот идея насчёт адреса цикла запроса по M1... С другой стороны опять же как быть с программами которые запускают п/п из ПЗУ, ведь тогда получается что первая строчка ПЗУ будет оттранслирована как экранная область (т.е. произойдёт не чтение из ПЗУ а чтение из экранной области)...
З.Ы. А методика очень хороша, не будь в ней сложности...
Насчёт ускорения - насколько сильно оно будет -
от 100% до 0%, всё зависит от того, какой контент.
Вот тот же пример приводился, в небезызвестной Awaken процедура копирования из буфера/обновления экрана занимает порядка 30-40%% процессорного времени, да и почти в любой игрушке или демке основное время процессор тратит именно на закрученные выводы - те же "хитрые" конструкции типа {Pop HL Ld (экран), HL 16 раз подряд} или там {LDI 32 раза подряд} тоже не от высокой скорости вывода придуманы были.
Использования аппаратной части для указанных операций кроме того позволит сэкономить не только процессорный ресурс, но и ресур памяти.
Часто новое, это очень хорошо забытое старое
Размещение дополнительного экрана в нулевой страничке (под ПЗУ) реализовано в расширенном экране ZX-Next. Там размещалась память экрана 640*200 (CGA). Плюсом такого решения было сохранение обычного экрана 256*192, в который (из которого) можно было переключаться в расширенный.
Были и некоторые тонкости: при работе TR-DOS (и бейсика) в нижнюю память происходила запись (в экране возникали точки и полоски). Для предотвращения этого использовался порт управления нижней областью ОЗУ (блокировка записи и возможность отключения ПЗУ, для чтения из экрана).
