![]() |
Интересная мысль
─ Обсуждение железа (500:4232/0) ──────────────────────────────── HARDWARE.ZX ─
Сооб : 1000 из 1000 -999 От : Ivan Kuvshinov 500:95/462.35 03 Июн 05 11:43:22 Кому : All 05 Июн 05 11:24:50 Тема : Ускоритель видеологики. ────────────────────────────────────────────────── ───────────────────────────── Если уж делать расширенный экран для Спектрума, то почему бы его не поместить в адресное пространство ПЗУ? Это же 16 Кб чистого экрана да ещё и с освобождением адресного пространства, что весьма прилично! Аргументы такие - экран редко читается и можно обойтись без этого, в ПЗУ не требуется писать, так что можно разделить чтение и запись: чтение - из ПЗУ, а запись - в экран по одним и тем же адресам. Видеоконтроллер может читать на прямую. С совместимостью никаких проблемм, ведь запись на чтении никак не отражается, и по барабану какое ПЗУ подсунуто, главное что это ПЗУ, да и банками не надо щёлкать. > А как один бит в байт добавить (линию pисуем)? Для этого >надо читать или всёже не надо? А если надо, копию этого >байта следует где-то ещё заpанее делать? Может быть, >аппаpатно сделать возможность записи не всех бит в байт для >сохpанения тех, что писать не надо (тогда станет возможным >ставить\снимать один бит без чтения)? А как тогда быть с >совместимостью и быстpодействием? Подумаши пришёл к такому выводу - всё будет чики-чики, если для того что бы поставить точку не надо будет ничего читать, а это значит байт (или несколько) на точку или расположить там только цветовые аттрибуты. Для 16Кб имеем где-то 128*128 или 160*102 при 256 цветах (как раз видео клипы смотреть :-) ). Или одни аттрибуты (байт на байт) для разрешения 512*240 - как раз уложимся (15360). По большому счёту видеопамять требуется только для записи, если рассматривать её с точки зрения программ. Конечно, речь идёт только о количественной оценке, а не о абсолютном утверждении, но тем не менее это может оказаться полезным. Итак была приведенна идея о том как использовать выгоду одностороннего чтения, но.. - она не учитывает ОСОБОЙ структуры экрана на Спектруме, благодаря которому, что бы поставить обычную точку следует, произвести логическую операцию со значением в видеопамяти, что не мыслимо без чтения. Однако сами принципы работы с экраном не меняются и если бы такие логические операции могли проводиться без чтения, то всё очень хорошо бы легло в предложеннную идею. Hо решение лежит на поверхности - ведь логические операции элементарны их очень мало и очень просто реализуются в железе, а непосредственное значение ячеек видеопамяти программам не нужно, то есть можно сделать переключаемые режимы работы с видеопамятью, которые будут осуществлять логические операции с копируемыми туда данными. Это может существенно увеличить скорость работы с графикой на Спектруме и даёт возможность применить и основную идею изложенную в самом начале. Вопрос к опытным программистам: на сколько быстрее (приблизительно.. так - на вскидку) стала бы работа с видео обладающим такими режимами? Или игра не стоит свеч? КИА * Origin: < Hardware.ZX > (500:95/462.35) |
чтобы решить проблему с чтением - а если ориентироваться на адрес цикла М1 ? образно говоря - если было выполнение команды в пзу, то на время следующих нескольких тактов чтение из экрана отключается. а если выборка команд идёт из озу то чтение из пзу вызывает чтение из экрана. имхо проблема будет только с программами использующими пзу-шный шрифт.
|
Сколько помню, только более менее новые демонстрашки
и наши игрушки не используют чтение экрана, а почти весь багаж западных игрушек читает экран.. Нарпимер наложение изображения поверх имеющегося по AND или }{OR - часто используемая операция.
А вот идея насчёт адреса цикла запроса по M1... С другой стороны опять же как быть с программами которые запускают п/п из ПЗУ, ведь тогда получается что первая строчка ПЗУ будет оттранслирована как экранная область (т.е. произойдёт не чтение из ПЗУ а чтение из экранной области)... З.Ы. А методика очень хороша, не будь в ней сложности... |
Насчёт ускорения - насколько сильно оно будет -
от 100% до 0%, всё зависит от того, какой контент.
Вот тот же пример приводился, в небезызвестной Awaken процедура копирования из буфера/обновления экрана занимает порядка 30-40%% процессорного времени, да и почти в любой игрушке или демке основное время процессор тратит именно на закрученные выводы - те же "хитрые" конструкции типа {Pop HL Ld (экран), HL 16 раз подряд} или там {LDI 32 раза подряд} тоже не от высокой скорости вывода придуманы были. Использования аппаратной части для указанных операций кроме того позволит сэкономить не только процессорный ресурс, но и ресур памяти. |
Часто новое, это очень хорошо забытое старое
Размещение дополнительного экрана в нулевой страничке (под ПЗУ) реализовано в расширенном экране ZX-Next. Там размещалась память экрана 640*200 (CGA). Плюсом такого решения было сохранение обычного экрана 256*192, в который (из которого) можно было переключаться в расширенный.
Были и некоторые тонкости: при работе TR-DOS (и бейсика) в нижнюю память происходила запись (в экране возникали точки и полоски). Для предотвращения этого использовался порт управления нижней областью ОЗУ (блокировка записи и возможность отключения ПЗУ, для чтения из экрана). |
Quote:
|
Quote:
|
ukms[z]: M1 не подходит - нельзя будет прочитать шрифты/таблицы кнопок/адресов (любые данные) из ПЗУ. вообще, лучше порт присобачить в добавок к M1
|
доступ под нижними 16к (под ПЗУ) к памяти через шину реализован в Nemo-bus => люая видеокарта, ибо она будет именно слотовая, просто обязана будет заюзать эту возможность.
|
А что, если добавить ускоритель вывода 2д графики в данной области. Т.е. хард копировщики и спрайто-выводители итп? Прям как на амиге и спринтере ;) Скорость значительно увеличиться, не надо будет ухищрений с пушами и лди - просто указываешь адрес в озу спека, ее размер, что с этой областью делать и старт блиттеру =)
Полноценная карта будет =) |
Дык что, мысль интересная, но остается по прежнему - просто интересной?
|
не, неинтересная она.
|
Вы все больные и не лечитись , одна я красивая , в платье белом !!!
:v2_eek: 16 k видео write only буга-га-га ! |
| All times are GMT +4. The time now is 22:55. |
Powered by vBulletin® Version 3.8.3
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.