CityAceE
05.06.2005, 04:29
─ Обсуждение железа (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)
Сооб : 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)