Интересная мысль

[CityAceE]

─ Обсуждение железа (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)

[Advertiser]

[ukms[z]]

чтобы решить проблему с чтением - а если ориентироваться на адрес цикла М1 ? образно говоря - если было выполнение команды в пзу, то на время следующих нескольких тактов чтение из экрана отключается. а если выборка команд идёт из озу то чтение из пзу вызывает чтение из экрана. имхо проблема будет только с программами использующими пзу-шный шрифт.

[GriV]

и наши игрушки не используют чтение экрана, а почти весь багаж западных игрушек читает экран.. Нарпимер наложение изображения поверх имеющегося по AND или }{OR - часто используемая операция.

А вот идея насчёт адреса цикла запроса по M1... С другой стороны опять же как быть с программами которые запускают п/п из ПЗУ, ведь тогда получается что первая строчка ПЗУ будет оттранслирована как экранная область (т.е. произойдёт не чтение из ПЗУ а чтение из экранной области)...

З.Ы. А методика очень хороша, не будь в ней сложности...

[GriV]

от 100% до 0%, всё зависит от того, какой контент.

Вот тот же пример приводился, в небезызвестной Awaken процедура копирования из буфера/обновления экрана занимает порядка 30-40%% процессорного времени, да и почти в любой игрушке или демке основное время процессор тратит именно на закрученные выводы - те же "хитрые" конструкции типа {Pop HL Ld (экран), HL 16 раз подряд} или там {LDI 32 раза подряд} тоже не от высокой скорости вывода придуманы были.
Использования аппаратной части для указанных операций кроме того позволит сэкономить не только процессорный ресурс, но и ресур памяти.

[Conan]

Размещение дополнительного экрана в нулевой страничке (под ПЗУ) реализовано в расширенном экране ZX-Next. Там размещалась память экрана 640*200 (CGA). Плюсом такого решения было сохранение обычного экрана 256*192, в который (из которого) можно было переключаться в расширенный.

Были и некоторые тонкости: при работе TR-DOS (и бейсика) в нижнюю память происходила запись (в экране возникали точки и полоски). Для предотвращения этого использовался порт управления нижней областью ОЗУ (блокировка записи и возможность отключения ПЗУ, для чтения из экрана).

[Максагор]

Размещение дополнительного экрана в нулевой страничке (под ПЗУ) реализовано в расширенном экране ZX-Next. Там размещалась память экрана 640*200 (CGA). Плюсом такого решения было сохранение обычного экрана 256*192, в который (из которого) можно было переключаться в расширенный.

Были и некоторые тонкости: при работе TR-DOS (и бейсика) в нижнюю память происходила запись (в экране возникали точки и полоски). Для предотвращения этого использовался порт управления нижней областью ОЗУ (блокировка записи и возможность отключения ПЗУ, для чтения из экрана).

Наверное из-за блокировки записи, которую мы, по видимому, просто не отключили, нам тогда, когда у Романа пивко пили, не удалось заполнить байтами экран ZX-NEXT...

[Conan]

Наверное из-за блокировки записи, которую мы, по видимому, просто не отключили, нам тогда, когда у Романа пивко пили, не удалось заполнить байтами экран ZX-NEXT...

Думаю ключевое слово все же "пиво". Надо поискать, где то был конвертор .PCX-ов, вьювер и насройщик под это дело. Только бы у Ромки ПЗУ-шки скопировались.

[SMT]

ukms[z]: M1 не подходит - нельзя будет прочитать шрифты/таблицы кнопок/адресов (любые данные) из ПЗУ. вообще, лучше порт присобачить в добавок к M1

[Ronin]

доступ под нижними 16к (под ПЗУ) к памяти через шину реализован в Nemo-bus => люая видеокарта, ибо она будет именно слотовая, просто обязана будет заюзать эту возможность.

[acidrain]

А что, если добавить ускоритель вывода 2д графики в данной области. Т.е. хард копировщики и спрайто-выводители итп? Прям как на амиге и спринтере Скорость значительно увеличиться, не надо будет ухищрений с пушами и лди - просто указываешь адрес в озу спека, ее размер, что с этой областью делать и старт блиттеру =)
Полноценная карта будет =)