Speccy - наш выбор!

Speccy - наш выбор! (http://zx-pk.ru/index.php)
-   Unsorted (http://zx-pk.ru/forumdisplay.php?f=13)
-   -   Интересная мысль (http://zx-pk.ru/showthread.php?t=915)

CityAceE 5th June 2005 05: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)

ukms[z] 5th June 2005 10:07

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

GriV 5th June 2005 10:21

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

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

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

GriV 5th June 2005 10:27

Насчёт ускорения - насколько сильно оно будет -
 
от 100% до 0%, всё зависит от того, какой контент.

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

Conan 5th June 2005 13:25

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

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

Максагор 5th June 2005 16:52

Quote:

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

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

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

Conan 5th June 2005 17:16

Quote:

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

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

SMT 5th June 2005 18:07

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

Ronin 6th June 2005 16:05

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

acidrain 6th June 2005 23:21

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

acidrain 8th June 2005 12:58

Дык что, мысль интересная, но остается по прежнему - просто интересной?

Ronin 8th June 2005 20:45

не, неинтересная она.

Orionsoft 21st May 2006 16:00

Вы все больные и не лечитись , одна я красивая , в платье белом !!!
: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.