ZXNet эхоконференция «hardware.zx»

Hello, Lethargeek Какой отсюда вывод? А такой, что спрайты можно теперь хранить прямо в видеопамяти, и выводить на любой фон со скоростью, сопоставимой со скоростью работы обычной спековской графики - и это все в 64 цветах! Причем маску можно (нужно!) хранить в обычном ОЗУ, что сэкономит место в видеопамяти под сами спрайты. Даже если в APA-режиме используются все четыре базовых страницы (два переключаемых задних и два передних плана), все равно в каждой странице остается 6*4K, что с учетом масок в обычном ОЗУ составит эквивалент 16-32К обычной спековской графики. Да еще и в неотображаемых (отсекаемых бордюром) областях можно чего-нибудь хранить. Плюс менее важные спрайты/тайлы можно по-прежнему печатать из ОЗУ за несколько проходов. Процедура вывода "спрайта" в APA-режиме будет выглядеть примерно так: out... ; (установка базовых страниц чтения и записи видеопамяти) out... ; (вывод по AND во все плоскости) ld hl,^маска ; в неперехватываемых адресах ld de,^экран ; в видеопамяти (базовая страница для записи) push de ЦИКЛ - ld a,e - call "цепочка ldi" - ld e,a - inc d ПОВТОРИТЬ pop de ld hl,^спрайт ; в видеопамяти (базовая страница для чтения) out... ; (вывод по OR во все плоскости) ЦИКЛ - ld a,e - call "цепочка ldi" - ld e,a - inc d ПОВТОРИТЬ out... ; (восстановили базовые страницы, если нужно) Можно попытаться еще "упихать" все это в один цикл (с некоторыми аппаратными доработками), но не уверен, что получим существенное ускорение.

Hello, Lethargeek Размышляя на тему реализации "внутренних" ldir-ов, я подумал: что, собственно, происходит в разных ситуациях при таких пересылках? Hапример, ldi из ОЗУ в видеопамять - сначала байт читается из обычной страницы ОЗУ, потом записывается в перехватываемую страницу - и одновременно в видеопамять через логическую операцию с регистрами-защелками. И наоборот, для ldi из видеопамяти в ОЗУ сначала в защелки читаются байты, потом они суммируются какой-то логической операцией и полученный байт через процессор отправляется в ОЗУ. А при "внутреннем" ldi (то есть когда обращение к обоим адресам источник/приемник перехватывается видеокартой) что произойдет? То и другое - читаются байты, суммируются, полученный байт процессором отправляется в ОЗУ - и одновременно обратно в видеопамять. То есть во все слои попадают одинаковые байты, что очень плохо. Очевидно, что от проца требуются только адреса приемника и источника, а данные не нужны - и если байт данных при записи проигнорировать, то в адрес-приемник в видеопамяти попадет содержимое защелок, полученное перед эти при чтении, то есть произойдет параллельная пересылка, чего мы и добивались! Спрашивается, как понять, когда игнорировать данные при записи, а когда нет? Hе делать же анализатор кода на видеокарте с отловом нужных команд... ;) Можно поступить так: если сразу после попытки чтения происходит попытка записи (то есть между ними не было выборки новой команды - сигнал M1 не появлялся), тогда игнорируем. А если после выборки сразу идет запись, тогда безусловно пишем, что на шине. Понятно, что такой ldi годится только для параллельного копирования данных в видеопамяти, то есть прежде всего для "побайтных" прокруток изображения. Вот если бы можно было делать такие пересылки с учетом логических операций! А для этого нужно просто ввести "второй комплект" регистров-защелок (то есть теперь имеем отдельные для чтения и для записи) и распараллелить схему выполнения логических операций. А заодно дать возможность отдельно выбирать базовые 16K страницы видеопамяти для чтения и записи. То есть запись происходит так: байт, поступивший от проца, распределяется по Ч-защелкам, одновременно заполняются данными из видеопамяти З-защелки, выполняются логические операции и результат из З-защелок записывается обратно в видеопамять. А вот при выполнении "внутреннего" ldi прочитанные из видеопамяти байты сначала попадут в Ч-защелки, суммируются "на выход" (результат отдается процу) и остаются в Ч-защелках. Теперь, когда придет запрос на запись, Ч-защелки байтом, поступившим по шине, не заполняются, а сразу производятся логические операции с заполненными из адреса записи З-защелками и собственно запись в видеопамять. Добавить к этому возможность записи "со сдвигом" и "зеркальной" записи, как раньше.