Soviet Union ZX Spectrum CommunityСреда, 18.10.2017, 23:17
Вы вошли как Гость | Группа "Гости" | RSS
 [ · Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 212»
Soviet Union ZX Spectrum Community » ZX-строительство » Концепции » Стандартизация принципов развития видеопроцессора (Продолжение)
Стандартизация принципов развития видеопроцессора
Black_CatДата: Вторник, 03.07.2007, 04:15 | Сообщение # 1
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Стандартизация принципов развития видеопроцессора (продолжение*).

* - начало см.: http://www.zx.pk.ru/showthread.php?t=5027

3.0 Развитие структуры растра и его размер.

3.1 Критерии и ограничения.

Наиболеее критическим ограничением в реализации того или иного видеорежима является соотношение объёма видеопамяти и быстродействия процессора. При этом под быстродействием понимается не только тактовая частота процессора, но и то, сколько времени он затрачивает на выполнение наиболее часто употребимых типовых операций с видеопамятью (например перемещение на одну строку или столбец растра). Но т.к. изменить сами процессорные команды не представляется возможным, то единственным путём ускорения выполнения типовых видео операций является оптимизация соответствия между адресацией растра и адресацией в экранной памяти. Для Спектрума естественными критериями ограничения размера растра являются объём страниц памяти, (т.е. 16Kb), а так же критерий эволюционного масштабирования - кратность исторически установившемуся объёму видео памяти (т.е. 6Kb для растра и 0,75Kb для атрибутов). Т.к. при адресации растра большего чем 16Kb объёма потребуются переходы между страницами (а это операция довольно медленная, а потому и неоптимальная), то её желательно исключить. В соответствии с выбранными критериями получаем максимальный объём экранной памяти укладывающейся в 16Kb > 13,5Kb=2 х 6,75Kb. Такой объём видео ОЗУ позволяет увеличить размер адресуемого растрового пространства сохраняя при этом преемственность с общим объёмом видео ОЗУ ZX Spectrum 128. Для заданного объёма памяти наиболее оптимальное с точки зрения удобства вычисления адресов и максимально близкое к соотношению сторон 4:3 разрешение растра будет 384х256.

3.2 Оптимизация структуры растра.

Целью оптимизации структуры растра является ускорение растровых операций за счёт более рациональной его структуры. Результатом оптимизации должен быть растр удобный для видеопрограммирования при работе именно с восьмиразрядными процессорами. Реализовать это возможно за счёт линейной адресации экранной памяти и вариациями горизонтальной или вертикальной её раскладки. Для растра 384х256 наиболее оптимальна вертикальная раскладка, когда номера ячеек памяти растут по колонкам. В этом варианте, благодаря линейной адресации для перемещения адреса «по вертикали» не нужно громоздких проверок, достаточно элементарных команд INC и DEC, а перемещение по горизонтали осталось таким же простым, как и в оригинальной раскладке растра Спектрума.

Вертикальная раскладка растра 384х256:

Колонки знакомест |__0 _ |__1__|__2 _ | ... | _47_
Строки пикселов _ |
________0________| 0000 | 0100 | 0200 | ... | 2F00
________1________| 0001 | 0101 | 0201 | ... | 2F01
________2________| 0002 | 0102 | 0202 | ... | 2F02
_______ ... ______ |_ ... _ |_ ... _|_ ... _| ... |_ ..._
_______255_______| 00FF | 01FF | 02FF | ... | 2FFF

Колонки атрибутов |__0 _ |__1__|__2 _ | ... | _47_
Строки атрибутов _|
________0________| 3000 | 3020 | 3040 | ... | 35E0
________1________| 3001 | 3021 | 3041 | ... | 35E1
________2________| 3002 | 3022 | 3042 | ... | 35E2
_______ ... ______ |_ ... _ |_ ... _|_ ... _| ... |_ ..._
_______31________| 301F | 303F | 305F | ... | 35FF

3.3 Есть ли жизнь за 16Kb?

Основными препятствиями для увеличения разрешения растра является сегментация памяти по 16Kb, а так же соблюдение пропорциональности между объёмом экранной памяти и производительностью процессора для сохранения динамичности изображения. Последнее ограничение можно обойти установкой более быстрого процессора и/или его разгоном. Теоретически такой разгон должен быть возможен вплоть до 28MHz для 20MHz процессора, т.е. в восемь раз по сравнению с номинальной рабочей частотой Спектрума. Таким образом теоретически такой процессор без потери динамического быстродействия может обслуживать экранную область ОЗУ размером 6,75 х 8 = 54Kb. Сегментацию памяти по 16Kb теоретически тоже можно обойти с помощью особых аппаратных механизмов, (например, что бы при обращении к стандартной области видео ОЗУ происходило переключение в видеорежим с расширенной видеоадресацией, а переключение обратно осуществлялось при обращении к определённому адресу в пространстве неиспользуемых 10Kb, или каким другим доступным методом, при этом неиспользуемые 10Kb видео ОЗУ могут служить программным буфером, связующим работу программы в режиме с расширенной видеоадресацией и стандартном режиме доступа к памяти).
Возможные растровые разрешения в режиме 64Kb видеоадресации:

1. Графические режимы:

1) TV=384х256 (1 расширенный с вертикальной раскладкой растра, в режиме TV);
2) SVGA(800x600)=[384x2]х[256x2](1 расширенный с вертикальной раскладкой растра, в режиме SVGA);
3) VGA(640x480)=512x384 (1 расширенный с горизонтальной раскладкой растра, в режиме VGA);
4) SVGA(800x600)=768x512(2 расширенный с вертикальной раскладкой растра, в режиме SVGA);
5) XGA(1024x768)=[512x2]x[384x2] (1 расширенный с горизонтальной раскладкой растра без бордюра, в режиме XGA);

2. Текстовые режимы:

1) TV=512х192 (1 расширенный с горизонтальной раскладкой растра, в режиме TV);
2) VGA(640x480)=512x[192x2] (1 расширенный с горизонтальной раскладкой растра, в режиме VGA);
3) XGA(1024x768)=[512x2]x[192x4] (1 расширенный с горизонтальной раскладкой растра без бордюра, в режиме XGA);
4) XGA(1024x768)=1024x[384x2] (2 расширенный с горизонтальной раскладкой растра без бордюра, в режиме XGA);

Прим.: в [ ... ] указано удвоение или учетверение одной и той же строки по вертикали;

Примеры возможных раскладок растра:

1. Графический режим с горизонтальной раскладкой растра 512x384:

Колонки знакомест |__0__|__ 1__|__2__| ... |_ 63_
Строки пикселов _ |
________0________| 0000 | 0001 | 0002 | ... | 003F
________1________| 0040 | 0041 | 0042 | ... | 007F
________2________| 0080 | 0081 | 0082 | ... | 00BF
_______ ... ______ |_ ... _ |_ ... _|_ ... _| ... |_ ..._
_______383 ____ _ | 5FC0 | 5FC1 | 5FC2 | ... | 5FFF

Колонки атрибутов |__ 0__|__1__|__2__| ... |_ 63 _
Строки атрибутов _|
________0________| 6000 | 6001 | 6002 | ... | 603F
________1________| 6040 | 6041 | 6042 | ... | 607F
________2________| 6080 | 6081 | 6082 | ... | 60BF
_______ ... ______ |_ ... _ |_ ... _|_ ... _| ... |_ ..._
_______47 _____ _ | 6BС0 | 6BС1 | 6BC2 | ... | 6BFF

2. Графический режим с вертикальной раскладкой растра 768x512:

Колонки знакомест |__ 0__|__1__|__2__| ... |_ 95_
Строки пикселов _ |
________0________| 0000 | 0200 | 0400 | ... | BE00
________1________| 0001 | 0201 | 0401 | ... | BE01
________2________| 0002 | 0202 | 0402 | ... | BE02
_______ ... ______ |_ ... _ |_ ... _|_ ... _| ... |_ ..._
_______511_______| 01FF | 03FF | 05FF | ... | BFFF

Колонки атрибутов |__ 0__|__1__|__ 2__| ... |_ 95_
Строки атрибутов _|
________0________| C000 | C040 | C080 | ... | D7C0
________1________| C001 | C041 | C081 | ... | D7C1
________2________| C002 | C042 | C082 | ... | D7C2
_______ ... ______ |_ ... _ |_ ... _|_ ...__| ... |_ ..._
_______63________| С03F | C07F | C0BF | ... | D7FF

3. Текстовый режим с горизонтальной раскладкой растра 1024x[384x2]:

Колонки знакомест |__0__|__1__|__ 2__| ... |_127_
Строки пикселов __|
________0________| 0000 | 0001 | 0002 | ... | 007F
________1________| 0080 | 0081 | 0082 | ... | 00FF
________2________| 0100 | 0101 | 0102 | ... | 017F
_______ ... ______ |_ ... _ |_ ... _|_ ... _| ... |_ ..._
_______383_______| BF80 | BF81 | BF82 | ... | BFFF

Колонки атрибутов |__ 0__|__1__|__ 2__| ... |_127_
Строки атрибутов _|
________0________| C000 | C001 | C002 | ... | C07F
________1________| C080 | C081 | C082 | ... | C0FF
________2________| C100 | C101 | C102 | ... | C17F
_______ ... ______ |_ ... _ |_ ... _|_ ...__| ... |_ ..._
_______47_______ | D780_| D781 | D782 | ... | D7FF

3.4 Старые видеорежимы, "линейный" и "64Kb" режим.

Режимы "64Kb" и "линейный" отличаются от существовавших линейной адресацией и возможностью видеоадресации в пределах всего доступного адресного пространства процессора. При желании любой из существующих режимов может быть эволюционно преобразован в "64Kb" и/или "линейный" режим.

Например:

- для режима Gigascreen+ потребуется изменение раскладки растра на линейную, а изменением старших адресных разрядов можно переходить с одной экранной плоскости на другую;
- для режима 16 color потребуется изменение раскладки растра на линейную и объединение 4х экранов в один непрерывный;

3.5 Mono Resolution Mode.

В работе ParaScreen specs v4.4.2 by Lethargeek’2007 кроме режима линейной адресации рассматривалось как перспективное развитие структуры растра переход к режиму единого разрешения. Суть предложения заключается в автоматической переадресации, т.е. преобразовании выставленного процессором адреса в видеобуфере Спектрума по определенным правилам (разным для области растра и атрибутов стандартного экрана) и смещении полученного нового адреса по обоим координатам для сдвига отображаемого окна в центр нового «большого» экрана. Хотя в принципе сдвигать именно в центр необязательно, можно выбрать любые смещения по строке и столбцу, только нужно помнить, что при чрезмерном сдвиге по вертикали произойдет «заворачивание» картинки, а по горизонтали – наложение на неотображаемую часть видеостраницы. Целесообразность обуславливается установлением единообразия в программировании для такого режима, а так же возможностью получения большинства имеющихся на Спектруме режимов как частных случаев этого единого режима.

3.6 Заключение.

Выводы:

1) При эволюционном развитии структуры растра применимо эволюционное масштабирование разрешения и объёма экранного ОЗУ, а так же революционные методы линейной адресации и расширения адресного пространста видео ОЗУ;
2) Наличие большого количества исторически возникших не систематизированных видеорежимов, а так же большое количество критериев их изменения не позволяет легко и сразу понять структуру развития видеопроцессора, что приводит к таким негативным результатам как попытки прикручивания чуждых Спектруму архитектур таких как v9990, ATM EGA и т.д.

Рекомендации:

1) Революционная модель развития - одномоментный отказ от дальнейшей поддержки и развития всех видеорежимов кроме двух стандартых и переход к поддержке Mono Resolution Mode.
2) Модель эволюционного минимализма - ограничение количества поддерживаемых видеорежимов режимами получившими наибольшее развитие и отказ от поддержки остальных.
3) Модель системного эволюционирования - систематизация имеющихся видеорежимов по порождающим их критериям, что позволит понять структуру их возможного развития, и позволит зарезервировать для каждой ветви отдельное пространство её развития не пересекающееся с другими ветвями, без опасения конфликтов. Такое прозрачное разделение ветвей развития позволит развивать отдельные ветви не отбрасывая остальные сразу, т.е. развивать систему в целом по принципу - что не жизнеспособно - отомрёт само.

4.0 Развитие структуры отображения цветов и их количества.

Структура формирования цветов ZX Spectrum 48 мало чем отличается от других компьютеров того времени. Единственной её особенностью является максимальная упрощённость и как следствие - наличие всего одного видеорежима. Второй видеорежим - Gigascreen, нечаянно ставший стандартным, появился уже на модели ZX Spectrum 128, да и то скорее от безисходности программистов, пытавшихся хоть как-то расширить графические возможности на тот момент уже далеко не топовой модели компьютера. Поэтому при рассмотрении эволюционного развития системы цветоформирования следует исходить из этих двух базовых режимов. Критерии развития могут быть количественные и качественные.

Количественные критерии:

N1 - изменение размера массива атрибутов (с 768 на 6144 байт);
N2 - изменение пропускной способности канала видеовывода (2 или 4 байт на строку одного знакоместа, для одного кадра);
N3 - изменение горизонтального разрешения;

Качественные критерии:

Q1 - изменения структуры атрибутов или растровых данных;
Q2 - изменение назначения массива атрибутов;

Сводная таблица возможных режимов цветоформирования по критериям N1,N2,N3,Q1,Q2.

№ | N3 | N2 | N1Q2 | Q1 | Режим_____________________
00 | 0 _| 0 _| _ 0 _ | _0 | Стандартный 256х192
01 | 0 _| 0 _| _ 0 _ | _1 | Flashcolor
02 | 0 _| 0 _| _ 1 _ | _0 | W&3Greyscale per pixel*
03 | 0 _| 0 _| _ 1 _ | _1 | Hardware Multicolor
04 | 0 _| 1 _| _ 0 _ | _0 | Gigascreen+
05 | 0 _| 1 _| _ 0 _ | _1 | DoubleFlashcolor*
06 | 0 _| 1 _| _ 1 _ | _0 | 16 color per pixel
07 | 0 _| 1 _| _ 1 _ | _1 | DoubleMulticolor*
08 | 1 _| 0 _| _ 0 _ | _0 | х
09 | 1 _| 0 _| _ 0 _ | _1 | х
10 | 1 _| 0 _| _ 1 _ | _0 | W&B 512х192
11 | 1 _| 0 _| _ 1 _ | _1 | х
12 | 1 _| 1 _| _ 0 _ | _0 | Стандартный 512х192*
13 | 1 _| 1 _| _ 0 _ | _1 | Flashcolor 512х192*
14 | 1 _| 1 _| _ 1 _ | _0 | W&3Greyscale per pixel 512х192*
15 | 1 _| 1 _| _ 1 _ | _1 | Hardware Multicolor 512х192*

Критерии N1,Q2 объединены ввиду возможности вариантов их взаимопересечения.
х - нереализуемые режимы.
* - не реализовывавшиеся режимы.

4.1 Эволюционное развитие системы цветоформирования.

4.1 Flashcolor

Цветовая структура байтов атрибута и растра оригинальная и цветоформирование при выключенном бите Flash происходит стандартным образом. При включённом Flash, цвет фона всегда черный, а цвет тона формируется из семи бит атрибута, при этом цвета формируются с помощью трёх 3х-битных ЦАПов. Структура разрядов ЦАП R(G,B): D2=I, D1=R(G,B)paper, D0=R(G,B)ink. Таким образом получаем 64 цвета тона на знакоместо из палитры 128 цветов, при чёрном фоне. Изменения по критерию Q1. Режим реализовывался как любительская доработка и включался тумблером.

4.1 W&3G*

W&3G - безатрибутный монохромный режим c тремя оттенками серого на пиксел. Используются экранные области памяти: #4000-57FF и #6000-77FF. Изменения по критериям N1 и Q2. Режим не реализовывался. Возможна его эмуляция в режиме Gigascreen при значениях атрибутов соответствующих чёрному или белому цвету.

4.1 Hardware Multicolor (атрибут на байт).

Цветоформирование почти стандартное (нет мигания), но каждый растровый байт строки знакоместа имеет свой атрибут. Используются экранные области памяти: #4000-57FF - растр, и #6000-77FF - атрибуты. Адрес альтернативного экрана: #C000-D7FF - растр, и #E000-F7FF - атрибуты. Биты 6 и 7 в атрибутах отвечают соответственно за яркость бумаги и чернил. Изменения по критериям N1 и Q1. Режим реализовывался как любительская доработка. Управление: #EFF7 D0=1 - вкл., 0 - выкл.

4.1 Gigascreen+

Режим представляет из себя эволюционное развитие режима Hardware Gigascreen. Изображение формируется арифметическим суммированием данных и атрибутов из двух альтернативных экранных областей в разных страницах памяти (критерий N2). Значения цветовых составляющих вычисляются по формуле:

R,G,B,I=(R1+R2)/2, (G1+G2)/2, (B1+B2)/2, (I1+I2)/2;

Суммирование может быть как по амплитуде, так и интегрированием по времени (например при мигании с частотой 14 MHz). Режим позволяет получить 4 цвета на знакоместо из палитры 102 цвета. Такой режим предполагает аппаратное включение, и в отличии от оригинального режима Gigascreen не мерцает, что не создаёт усталости зрения. Режим легко реализуется в системах с двумя аппаратными банками памяти или удвоением обращений видеопроцессора к быстродействующей памяти. На данный момент режим реализован только в программных эмуляторах. Управление: #EFF7 D4=1 - вкл., 0 - выкл.

4.1 DoubleFlashcolor*

Режим представляет из себя эволюционное развитие режима Flashcolor и устраняет такие недостатки оригинального режима как один цвет на всё знакоместо и единственный цвет для фона. В этом режиме пара растровых бит пиксела определяет одну из 4х палитр: 00 - палитра фона, 01-11 - три палитры чернил. Каждая палитра позволяет задавать 16 цветов. Распределение памяти аналогично режиму Gigascreen. Изменения по критериям N2 и Q1. Режим не реализовывался. Может быть полностью сэмулирован в режиме Gigascreen.

4.1 DoubleMulticolor*

Режим представляет из себя эволюционное развитие режима Hardware Multicolor и устраняет такие недостатки оригинального режима как два цвета на строку знакоместа. В этом режиме пара растровых бит пиксела определяет одну из 4х палитр: 00,01 - палитры фона, 10,11 - палитры чернил. Каждая палитра позволяет задавать 16 цветов. Распределение памяти аналогично режиму Gigascreen. Изменения по критериям N1,N2,Q1,Q2. Режим не реализовывался. Может быть полностью сэмулирован в режиме Gigascreen.

4.1 B&W 512х192

Режим удвоенного разрешения по горизонтали за счёт сплющивания пикселов. При выводе байт атрибута заменён вторым байтом растровых данных. Изображение чёрно-белое. Используются две экранные области памяти: #4000-57FF - четные байты в строке, и #6000-77FF - нечетные байты. Альтернативный экран адресуется аналогично и размещается: #C000-D7FF и #E000-F7FF. Изменения по критериям N3 и Q2. Режим реализовывался как любительская доработка. Управление: #EFF7 D1=1 - вкл., 0 - выкл.

Не реализовывавшиеся режимы 512х192:

12. Стандартный 512х192
14. W&3G 512х192
15. Hardware Multicolor 512х192

Все эти режимы аналогичны по цветоформированию режимам 256х192. Ни один из нереализованных режимов 512х192 не может быть сэмулирован в другом режиме.

4.2 Революционное развитие системы цветоформирования.

4.2 16 color per pixel.

Режим 16 цветов на пиксель в разрешении 256х192. В отличии от эволюционного способа увеличения количества цветов путём увеличения количества экранных плоскостей имеющих стандартную организацию - байт на строку знакоместа, в этом режиме применён революционный метод развития, когда в памяти адресуется каждая пара 4х битных пикселов. Структура байта - IiGRBgrb, при этом чётные пикселы имеют организацию igrb, а нечётные IGRB. Такой способ адресации позволил в некоторых случаях меньше тормозить работу, т.к. для изменения 2х соседних пикселов необходима запись только одного байта в ОЗУ, в то время как при эволюционном методе развития потребовалось бы записать сразу четыре байта. В то же время при записи больших объёмов информации оба метода дают одинаковые результаты быстродействия. Видеоизображение формируется путём циклического считывания по одному байту, (определяющему значение пары соседних пикселов) из четырёх экранных областей: pixel 0, 1 - #C000-D7FF, pixel 2, 3 - #4000-57FF, pixel 4, 5 - #E000-F7FF, pixel 6, 7 - #6000-77FF (раскладка дана для случая когда 4 или 6 страница стоят в 3м окне адресного пространства CPU). Структура знакоместа при этом:

#C000 #4000 #E000 #6000
#C100 #4100 #E100 #6100
.................................
#C700 #4700 #E700 #6700

RAM page structure (default / alternative):

CPU 1: page5/7
CPU 3: page4/6

Изменения по критериям N2, Q1, Q2. Режим реализован в Pentagon 1024SL v2.2. Управление использовалось такое же как и для режима Hardware Multicolor : #EFF7 D0=1 - вкл., 0 - выкл .

4.3 ParaScreen - перспективное развитие систем цветоформирования.

ParaScreen - перспективная комплексная система видеоформирования предложенная Lethargeek’ом, включающая как эволюционный, так и революционные методы развития. Её основа - видеопамять с «параллельной» организацией. Это значит, что каждому адресу поставлен в соответствие не один байт, а несколько (в нашем случае – сразу шесть), именуемых «параллельный байт», кратко – парабайт. Аналогично байту парабайт делится на восемь «параллельных бит» (парабит). Все адресуемое пространство видеопамяти разделено на пронумерованные базовые (видео)страницы размером 16Кпб (килопарабайт). Вместо двух байт для каждой группы из восьми точек считывается два парабайта. Сканер компьютера может работать или в атрибутном режиме, или в специальном симметричном режиме. «Симметричным» он называется потому что считывание парабайта подобно режиму Hardware Multicolor. Видеоформирователь получает от сканера на каждые восемь точек два парабайта, то есть всего 96 бит. Более подробно с предложенной Lethargeek’ом системой можно ознакомиться скачав документацию на прототип спектрумовской видеокарты "ParaScreen specs v4.4.2 by Lethargeek’2007" : http://www.zx.pk.ru/showpost.php?p=30853&postcount=242 .

4.3.1 «Атрибутный» режим.

Первый парабайт рассматривается как информация о восьми пикселях растра (как на Спектруме), один пиксель кодируется одним парабитом, то есть шестью «параллельными» (находящимися в одном разряде) битами всех шести байт данного парабайта. Очевидно, что всего потенциально доступно 26=64 «цвета» на каждый пиксель. Цвета либо выбираются из программируемой палитры (разрядность регистров палитры 12 бит, то есть по 4 бита на цветокомпоненту), либо палитра отключается, и цвет получается напрямую из соответствующего парабита (рассматриваемого как код «GRBgrb») в формате «GRBgrbGRBgrb - цвет на входе ЦАП».
Второй парабайт трактуется как расширенный атрибут. Для наглядности вот побитовая раскладка (парабиты - столбцы), одна из возможных:

paperflash | paper1bright | paper1G | paper1R | paper1B | ink1G | ink1R | ink1B
inkflash___| ink1bright___| paper1g | paper1r_| paper1b_| ink1g | ink1r_| ink1b
altpflash__| paper2bright | paper2G | paper2R | paper2B | ink2G | ink2R | ink2B
altiflash__| ink2bright____| paper2g | paper2r_| paper2b | ink2g | ink2r_| ink2b
hide1lo___| hide1hi_______| pxorG__ | pxorR__ | pxorB___| ixorG_| ixorR_| ixorB
hide2lo___| hide2hi_______| pxorg___| pxorr___| pxorb___| ixorg_| ixorr_| ixorb

Назначение битовых групп:

1) paper1 (paper1G…paper1b) – определяют цвет в формате «GRBgrb». Если paper1bright=1, то цвет на входе ЦАП «GRBgrbGRBgrb», иначе «GRBgrb000000». Аналогично для групп ink1, paper2, ink2.
2) paperflash, inkflash – аналогично биту FLASH стандартного атрибута, определяют (только теперь – раздельно для INK и PAPER), будет ли цвет PAPER меняться на INK (и наоборот). Если altpflash=1, то PAPER меняется на ink2 вместо ink1. Аналогично altiflash=1 для изменения INK на paper2 вместо paper1.
3) pxor, ixor – определяют, какие из 64 возможных цветов считаются в контексте текущего знакоместа PAPER и INK, но не напрямую, нужный код цвета получается после операции XOR по всем шести соответствующим разрядам для PAPER, а для INK – еще и инвертированием конечного результата. Зачем понадобились такие сложности, см. ниже.
4) hidelo, hidehi – определяют, нужно ли «прятать» при совпадении INK и PAPER остальные 62 цвета (в таком знакоместе на Спектруме естественно всегда получается однотонный квадрат вне зависимости от состояния растра). Если hide1lo=hide2lo, то «прячем» все цвета, коды которых меньше INK=PAPER (аналогично при hide1hi=hide2hi – все цвета, коды которых больше).

4.3.2 «Двухслойный» режим.

Оба парабайта рассматриваются как информация о восьми пикселях растра заднего и переднего планов (или слоев) для первого и второго соответственно. Если палитра отключена, один (выбираемый) из 64 фиксированных цветов на переднем плане считается «прозрачным», и вместо него на экран выводится цвет соответствующего пикселя заднего плана (во всех остальных случаях - переднего плана). То есть видеоформирователь для каждого из восьми пикселей просто делает выбор из двух цветов.
Если палитра включена, все немного сложнее. Дело в том, что каждый регистр палитры кроме 12 бит информации о цвете хранит еще 4 бита «относительной прозрачности» (альфа-коэффициент). Модер складывает взвешенные с учетом этого коэффициента 12-битные цвета обоих пикселей покомпонентно по формулам:

G := (G1 * (16-alpha) + G2 * alpha)/16;
R := (R1 * (16-alpha) + R2 * alpha)/16;
B := (B1 * (16-alpha) + B2 * alpha)/16;

Прим.: G, R, B обозначают четырехбитные числа, а не отдельные биты.

4.3.3 «Сцепленный» режим.

Цвет каждого пикселя определяется двумя парабитами одного и того же соответствующего разряда обоих парабайт. То есть две разные видеостраницы фактически объединяются в один «слой», и никакой палитры здесь уже быть не может - сразу получается прямой 12-битный код цвета в формате «GRBgrbGRBgrb» (старшие шесть бит вытаскиваются из первого парабайта, младшие – из второго), то есть всего доступно 4096 цветов на точку.

4.3.4 «Сплюснутый» режим.

Аналог режима 512х192, сканирование симметричное из разных базовых страниц (атрибутный режим здесь совершенно бесполезен), первый считанный парабайт определяет цвета 8 четных сплющенных пикселей из 16, второй – нечетных, доступны 64 цвета на точку (использовать две разных палитры здесь очевидно бессмысленно), прозрачность не обрабатывается. То есть имеем обычный графический однослойный режим.

5.0 Развитие видеопроцессора методом системного эволюционирования.

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

5.1 Нормализованная* таблица видеорежимов для порта #EFF7.

* - т.е. приведённая к исторически принятой раскладке назначения битов D0, D1, D5, D6 порта #EFF7.

Представленная в п. 4.0 "Сводная таблица возможных режимов цветоформирования" построена по принципу соответствия каждому выделенному критерию отдельного управляющего бита, при этом видеорежим может формироваться сочетанием нескольких критериев. Но к сожалению исторически установившиеся соответствия между управляющими битами порта #EFF7 и соответствующим им видеорежимам возникли стихийно, без какого-либо инженерного обоснования и не удовлетворяют принципу соответствия каждому выделенному критерию отдельного управляющего бита. Такое положение привело к тому, что для управление видеорежимами требуется более сложная логика, что выливается в необходимость более изощрённой схемотехники и ставит под сомнение саму возможность широкого применения такой схемы управления. Это можно было исправить переделав тот немногочисленный софт, использующий новые видеорежимы, но такое предложение не встретило понимания и поддержки.
Ниже приведён вариант "Нормализованной таблицы видеорежимов" в котором за счёт усложнения логики выбора видеорежима предпринята попытка увязать исторически сложившуюся бессистемность в рамки некоего подобия масштабируемой системы. Одинаковым цветом выделены видеорежимы, между которыми в угоду "историчности" произведена рокировка.

№ | N3 | N2 | N1Q2 | Q1 | Режим_____________________
00 | 0 _| 0 _| _ 0 _ | _0 | Стандартный 256х192
01 | 0 _| 0 _| _ 0 _ | _1 | Noncens Modes 384х304(256x224, 320x200, 256x256)
02 | 0 _| 0 _| _ 1 _ | _0 | 16 color per pixel
03 | 0 _| 0 _| _ 1 _ | _1 | Gigascreen+
04 | 0 _| 1 _| _ 0 _ | _0 | Hardware Multicolor
05 | 0 _| 1 _| _ 0 _ | _1 | DoubleFlashcolor*
06 | 0 _| 1 _| _ 1 _ | _0 | W&3Greyscale per pixel*
07 | 0 _| 1 _| _ 1 _ | _1 | DoubleMulticolor*
08 | 1 _| 0 _| _ 0 _ | _0 | х W&B 512х192
09 | 1 _| 0 _| _ 0 _ | _1 | х Flashcolor
10 | 1 _| 0 _| _ 1 _ | _0 | Text Modes*
11 | 1 _| 0 _| _ 1 _ | _1 | х Linear Graphics Modes 384x256 (512х384, 768х512)*
12 | 1 _| 1 _| _ 0 _ | _0 | Стандартный 512х192*
13 | 1 _| 1 _| _ 0 _ | _1 | Flashcolor 512х192*
14 | 1 _| 1 _| _ 1 _ | _0 | W&3Greyscale per pixel 512х192*
15 | 1 _| 1 _| _ 1 _ | _1 | Hardware Multicolor 512х192*
... |512|HM |16color| 384|
... |bit1|bit5| _bit0_| bit6|

Критерии N1,Q2 объединены ввиду возможности вариантов их взаимопересечения.
х - нереализуемые режимы.
* - не реализовывавшиеся режимы.
**** - цветом отмечены режимы поменявшиеся местами.

D6 #EFF7 = Q1 - критерий изменения структуры атрибутов или растровых данных;
D0 #EFF7 = Q2 - критерий изменения назначения массива атрибутов;
D0 #EFF7 = N1 - критерий изменения размера массива атрибутов (с 768 на 6144 байт);
D5 #EFF7 = N2 - критерий изменения пропускной способности канала видеовывода (2 или 4 байт на строку одного знакоместа, для одного кадра);
D1 #EFF7 = N3 - критерий изменения горизонтального разрешения;

Прим: D5=1 #EFF7 отвечал за включение режима Soun Blaster'a, который по мнению его автора изжил себя морально и поддерживаться не будет. В дальнейшем D5 предлагается использовать как альтернатива для режима Hardware Multicolor.

5.1 Noncens Modes 384х304(256x224, 320x200, 256x256)

Разрешение 384х304 выделяется среди других когда либо создававшихся видеорежимов для Спектрума своим исключительным неудобством адресации растра, не говоря уже о том, что ни по каким имеющимся критериям развития экрана он не проходит. Этот режим может быть использован для включения не только разрешения 384х304, но и для других графических НЕ спектрумовских видеорежимов, отсюда и название.

5.1 Text Modes (reserved)*

Незанятый режим 10 зарезервирован под текстовые режимы.

5.1 Linear Graphics Modes 384x256 (512х384, 768х512)*

Незанятый режим 11 отведён под графические режимы с линейной адресацией видеопамяти (см. п.п. 3.2 "Оптимизация структуры растра" ).

5.2 Бордюр.

Исторически, необходимость бордюра была обусловлена ориентацией на использование в качестве системы видеоотображения бытового телевизора, имевшего по краям экрана значительные нелинейные искажения растра, фокусировки и сведения лучей, что соответствует телевизионным стандартам. В отличии от телевизоров все мониторы имеют более жёсткие стандарты на линейность, сведение и фокусировку, и поэтому при использовании мониторов возможно использование безбордюрных режимов. В порту бордюра #FE имеются незадействованные разряды D5-D7, которые можно использовать в новых видеорежимах для их расширенной адресации. Особо оговорюсь - только в новых, т.к. под старые видеорежимы зачастую эти разряды использовались (как правило из-за криворукости программистов). Под новыми понимаются режимы ещё не реализовывавшиеся, либо поддерживаемые малым количеством программ, в которых можно исправить ошибки если они есть. При этом непременным правилом на будущее при написании программ под новые видеорежимы должна быть корректная работа с этими разрядами. Аппаратно разрешение на запись в эти разряды будет выдаваться только в новых видеорежимах, а для старых режимов запись будет блокироваться. По сбросу D5-D7 должны обнуляться, т.к. в стандартном видеорежиме никаким другим образом инициировать их невозможно. В новых видеорежимах не имеющих бордюра значение разрядов D0-D2 так же может быть использовано для расширенной селекции в таких безбордюрных видеорежимах.

5.3 Периодическая таблица видеорежимов ZX Spectrum.

При выводе изображения существуют две группы видеорежмов - TV и VGA выбор которых есть смысл осуществлять аппаратно с помощью переключателя, т.к. на одном и том же мониторе их всё равно не воспроизвести. Внутри этих групп переключение видеорежимов может осуществляться программно, управлением соответствующими регистрами.
В приложении дана сводная периодическая таблица возможных видеорежимов. В таблице приведена раскладка возможных видеорежимов при которых поток данных в видеопроцессор составляет 1, 2 или 4 байта на строку знакоместа (кроме режима 11). В ячейках таблицы указаны TV и VGA режимы и даны соответственно экранные разрешения и разрешения VGA видеорежимов, в которых они отображаются. При отображении в VGA видеорежимах возможно удвоение или учетверение разрешения по горизонтали или по вертикали, в этом случае экранные разрешения записаны с соответствующим умножением (Пр.: (256х2)х(192х2)*2 640х480 - экранное разрешение 256х192 отображается с удвоением по обоим координатам в VGA видеорежиме 640х480 и поток данных в видеопроцессор составляет 2 байта на строку знакоместа). При старте компьютера в TV или VGA режиме изначально устанавливается стандартный видеорежим, из которого уже можно программно перейти в любой из возможных видеорежимов.

Схему и описание селектора видеорежимов см. здесь: http://www.zx.clan.su/forum/8-35-1#188

Прикрепления: 80776851.rar(3Kb)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
ЯйцыДата: Вторник, 03.07.2007, 08:13 | Сообщение # 2
08h
Группа: Пользователи
Сообщений: 10
Статус: Offline
Quote (Black_Cat)
...завтра видеопроцессоров разных навесим и будем их переключать, а послезавтра и куски архитектур целиком прикрутим... ..останется ещё немного (именно немного, долго противопоказано) подумать - "а нафиг тут вообще этот Спек нужен?" и выкинуть его нафиг чтоб не сдерживал творческий полёт фантазии
 
Black_CatДата: Вторник, 03.07.2007, 10:32 | Сообщение # 3
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Не путай "разобраться с системой цветоформирования" и "прикрутить что не попадя". Здесь нет рекомендаций прикрутить к Спеку видеоконтроллер от "Денди" или MSX. Прежде чем что-то прикручивать надо разобраться каким законам подчиняется развитие, и в соответствии с этими законами посмотреть что можно сделать для получения положительного результата, не потеряв при этом преемственности с оригиналом. Чужого Спектруму не надо, своё бы довести до ума.

"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
ЯйцыДата: Вторник, 03.07.2007, 13:50 | Сообщение # 4
08h
Группа: Пользователи
Сообщений: 10
Статус: Offline
БОльшая часть из перечисленного никакой "преемственности с оригиналом" не имеет. Представь, что будет, когда прога, написаная для навороченого режима будет запущена на оригинале (в котором 48К ОЗУ и нет даже 2го экрана).
Трудно найти пьющего чёрный кофе негра в угольной шахте, особенно их там двое!!!!!111адинадин
 
Black_CatДата: Вторник, 03.07.2007, 14:31 | Сообщение # 5
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Под преемственностью понимается преемственность развития, т.е. его эволюционная постепенность/поэтапность. Этот вопрос уже неоднократно обсуждался.

Quote (Яйцы)
в котором 48К ОЗУ и нет даже 2го экрана

Если программист нормальный - всё будет хорошо, а криворукому что ни дай - испортит..


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
wd2Дата: Среда, 04.07.2007, 00:14 | Сообщение # 6
08h
Группа: Пользователи
Сообщений: 11
Статус: Offline
Quote (Black_Cat)
Режим 16 цветов на пиксель в разрешении 256х192

В пентагоне 2.2 248x192 в силу его аппаратных особенностей

Quote (Black_Cat)
при этом чётные пикселы имеют организацию IGRBink, а нечётные FGRBpaper

На самом деле IiGRBgrb, где IGRB - правый пиксель, igrb - левый

Quote (Black_Cat)
Видеоизображение формируется путём циклического считывания по одному байту, (определяющему значение пары соседних пикселов) из четырёх экранных областей: #C000-D7FF, #4000-57FF, #E000-F7FF, #6000-77FF

В пентагоне 2.2 в этом режиме есть еще и второй экран
Вот что получится: * - бит 3 7ffd=0; ** - бит 3 7ffd=1

*** "Адреса" обозначает диапазон адресов в процессорной памяти, занимаемых
данной страницей.

Прикрепления: 35202663.png(3Kb)


не верю в сказки про черных кошек ;)
 
Black_CatДата: Среда, 04.07.2007, 00:30 | Сообщение # 7
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Quote (wd2)
На самом деле IiGRBgrb, где IGRB - правый пиксель, igrb - левый

smile на самом деле то же самое, только обозначения разные FIGRBpaperGRBink, IGRBink чётный - левый, FGRBpaper нечётный - правый.

Quote (wd2)
В пентагоне 2.2 в этом режиме есть еще и второй экран

А он как-то используется в режиме 16 соlor?


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
wd2Дата: Среда, 04.07.2007, 00:41 | Сообщение # 8
08h
Группа: Пользователи
Сообщений: 11
Статус: Offline
Quote (Black_Cat)
А он как-то используется в режиме 16 соlor?

Не знаю. Надо спрсить у тех, кто под него программирует. Вообще, по-моему, никто кроме меня до сегодняшнего дня не знал о существовании второго экрана в этом режиме... Хотя, может, AlCo и знал, но т.к. в своем описании он этот вопрос умолчал, видимо, не знал.

Quote (Black_Cat)
а самом деле то же самое, только обозначения разные FIGRBpaperGRBink, IGRBink чётный - левый, FGRBpaper нечётный - правый.

ну дык писать надо по-человечески, без поллитра не разберешься biggrin инков и паперов в режиме 16colour нет, а яркость правого/левого пиксела - 2 старших бита.


не верю в сказки про черных кошек ;)

Сообщение отредактировал wd2 - Среда, 04.07.2007, 00:43
 
Black_CatДата: Среда, 04.07.2007, 00:46 | Сообщение # 9
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Quote (wd2)
В пентагоне 2.2 248x192 в силу его аппаратных особенностей

А кстати всё хотел спросить чем вызвано такое обрезание и оно симметричное? (т.е. по пол знакоместа справа-слева)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
wd2Дата: Среда, 04.07.2007, 00:51 | Сообщение # 10
08h
Группа: Пользователи
Сообщений: 11
Статус: Offline
Quote (Black_Cat)
кстати всё хотел спросить чем вызвано такое обрезание

убогим движком пентагона

Quote (Black_Cat)
и оно симметричное

нет, по-моему 3 слева и 5 справа, уже не помню точно


не верю в сказки про черных кошек ;)

Сообщение отредактировал wd2 - Среда, 04.07.2007, 00:54
 
Black_CatДата: Среда, 04.07.2007, 00:51 | Сообщение # 11
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Quote (wd2)
инков и паперов в режиме 16colour нет, а яркость правого/левого пиксела - 2 старших бита.

Эт понятно, я относительно к стандартной раскладке атрибутов писал, хотя причём она к этому режиму? Вобщем инерция мышления, переправлю.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
wd2Дата: Среда, 04.07.2007, 00:59 | Сообщение # 12
08h
Группа: Пользователи
Сообщений: 11
Статус: Offline
Quote (wd2)
Вообще, по-моему, никто кроме меня до сегодняшнего дня не знал о существовании второго экрана в этом режиме...

Но LVD догадывался wink


не верю в сказки про черных кошек ;)
 
copypastaДата: Среда, 04.07.2007, 12:24 | Сообщение # 13
04h
Группа: Пользователи
Сообщений: 4
Статус: Offline
Quote (Black_Cat)
А он как-то используется в режиме 16 соlor?
Используется ровно так же, как и второй экран в ZX128. И не только для мерцания. AlCo по своей схеме присобачил 2й экран месяца через два после того, как схема "заработала". т.е полтора года назад, а вы до сих пор "только догадывались".
 
white_dogДата: Среда, 04.07.2007, 13:30 | Сообщение # 14
10h
Группа: Пользователи
Сообщений: 28
Статус: Offline
Quote (copypasta)
Используется ровно так же, как и второй экран в ZX128. И не только для мерцания. AlCo по своей схеме присобачил 2й экран месяца через два после того, как схема "заработала". т.е полтора года назад, а вы до сих пор "только догадывались".

Уф... Давненько я тут не писал =)

Так вот, алкино описание в ЫГ вообще не отличается какой-либо понятностью. Это же просто бред - описывать схему словами, да ещё причём "вот у вас стоит уже атрибут на байт, так вот - отпаяйте проводки там и там, а тут и тут - припаяйте другие" и в таком же духе. Про ВТОРОЙ ЭКРАН же там ни слова нет - желающие могут прочитать оригинал. Резюме - схемы надо рисовать картинками и никак иначе. Причём не 256х192.

Насчёт точек - алко сделал просто - в режиме 16ц он даёт бусрк на проц, в результате ВК начинает читать подряд байты из памяти. Ну там естественно адресочки как надо меняются и данные как надо отображаются. Непродуманными остались следующие вещи: 1. Реальное отрубание процессора происходит через неопределённое время после бусрк (в пределах 1 цикла памяти). 2. видимо, в конце строки адреса уже неправильные начинают идти. Резюме - алко сделал всё через (|). =) А кое просто повторил то же самое в плмке.


Вы не любите кошек? Да вы просто не умеете их готовить!
 
Black_CatДата: Среда, 04.07.2007, 14:14 | Сообщение # 15
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Quote (white_dog)
1. Реальное отрубание процессора происходит через неопределённое время после бусрк (в пределах 1 цикла памяти).

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


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
copypastaДата: Среда, 04.07.2007, 14:21 | Сообщение # 16
04h
Группа: Пользователи
Сообщений: 4
Статус: Offline
Вообще, для относительно правильной работы схемы за раз видеосистема должна читать 2 байта (т.е либо 16-битная память, либо две линейки по 8 бит). 2 байта в момент, когда в обычном режиме читаются пиксели и 2 - когда атрибуты (4 байта, 8 точек 4bpp, от проца ничего не отбирается).
Второй момент - в обычном режиме считаный байт пикселей задерживается до считывания своих атрибутов. Алко, по видимости, задержку не делал и как результат - экран начинает выводится "не в то время", и чтобы сгладить эту фигню, его обрубили с обеих сторон (суксЬ).
 
Black_CatДата: Среда, 04.07.2007, 14:37 | Сообщение # 17
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Quote (copypasta)
и чтобы сгладить эту фигню, его обрубили с обеих сторон

Эт врядли. Чтение происходит разнофазно на всём экране. Почему тогда обрубили только края, если разнофазность проявляется на всём экране.. Скорее эт всё же кривизна из-за захвата шины. Одно не понятно - зачем так сделано в Pentagon 1024, в старых клонах - понятно - чтоб меньше переделывать.. Зачем было в новый клон, где всё можно было сделать по уму, тащить кривые реализации "доработок"? Короче, как копнёшь - так кривизна и попёрла..


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
wd2Дата: Среда, 04.07.2007, 20:05 | Сообщение # 18
08h
Группа: Пользователи
Сообщений: 11
Статус: Offline
Quote (Black_Cat)
Короче, как копнёшь - так кривизна и попёрла..

Ну сделайте не криво, все исходники выложены. Почему-то как всякий флуд писать - так все на ура, а как дело сделать - так никто нифига не делает.

Флудите дальше на здоровье


не верю в сказки про черных кошек ;)
 
Black_CatДата: Среда, 04.07.2007, 22:46 | Сообщение # 19
Координатор
Группа: Координаторы
Сообщений: 518
Статус: Offline
Ни я, ни кто другой не собирались никого обижать, да и тема вообще не об этом, а о цветоформировании, хотя если чесно уже прям страшно вообще чего-то касаться из того что производится, везде за что не возьмёшся начинают выпадать свои скелеты из шкафов - будь то GS, ZX-MC, и вот щас ещё и Пент-1024 sad . Дык что звыняйтэ, если чё не так..

Возвращаясь к сабжевому обсуждению интересует вопрос а нужно ли вообще включать режимы Flashcolor, Hardware Multicolor аппаратно. Есть мнение, что ввиду того что под режимы атрибут на байт включаемые ПО ПОРТУ, есть всего одна программа Hexagonal Filler, и она прекрасно обходится без такого включения, а также что под аппаратный гигаскрин - есть только пара номеров IzhNews, и они тоже прекрасно обходятся без порта, а режим flashcolor есть только в CSC Deja Vu, причём картинки нисколько не хуже выглядят и без этого режима, то этим режимам порты и даром не надо, а некоторые режимы (Hardware Multicolor), дык и вообще можно выбросить ввиду того что под него написана всего одна прога за десятилетие его существования.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
RomanichДата: Пятница, 06.07.2007, 03:39 | Сообщение # 20
20h
Группа: Пользователи
Сообщений: 44
Статус: Offline
шо удаляем посты?
модерилка зачесалась???


Ресурс, посвящённый созданию игровых консолей:
http://www.newgameconsole.narod.ru
 
Soviet Union ZX Spectrum Community » ZX-строительство » Концепции » Стандартизация принципов развития видеопроцессора (Продолжение)
Страница 1 из 212»
Поиск:

Copyright MyCorp © 2006Сайт управляется системой uCoz