Просмотр полной версии : 16 colors - roxxx!
SAM style
18.01.2006, 00:50
Я разобрался. Попробую на пальцах описать:
имеются 4 экранных области - #4000, #6000, #c000 и #e000 в банке 0.
Структура каждой - как у ZX-экрана (та же адресация).
Первая область отвечает за левые 2 пикселя, 2я - за следующие 2, 3я - еще правее и наконец последняя - за правые 2 пикселя в отображаемой полоске из 8 точек.
Каждый байт в каждой из областей - цвет тех точек, за которые он отвечает. Цвет представлен в формате IiRGBrgb. IRGB - цвет левой точки в этой паре, irgb - правой
Режим хороший, но вроде лучше было сделать цвет на полубайт (т.е. IRGBirgb), так кодить удобней было бы...
captain cobalt
18.01.2006, 01:22
А вот цитата из IG#8/hard/Цвет на точку:
Адресация аналогична АТМовской (#c000+, #4000+, #e000+, #6000+ и т. д.), но со стандартной разлиновкой, как в обычном спектрумовском режиме. Внутри байта раскладка битов такая же, как в АТМ (%IiGRBgrb, где IGRB - правый пиксель)
Вообще, имхо, "черезстолбцовый интерлейс" всех продвинутых видеорежимов серъёзно препятствует программированию динамической графики. Лучше бы память имела более линейное строение.
Лучше бы память имела более линейное строение.
Что значит "более линейной строение"?
Что значит "более линейной строение"?
Ну например, поскольку в таком режиме выходит 128 байт на строчку (просто сумма битов), то можно было бы сделать так: первая строчка по адресам $4000-$407f, вторая - по $4100-417f$ и так до 96ой, а с 97ой - строчки по адресам $4080-$40FF, $4180-$41FF и так далее. Ну это конечно грубо (24кило ибо на 1 экран), но идея примерно такая если бы была - было бы здорово.
SAM style
18.01.2006, 15:08
мдяяяяяя................ :o память транжирится не по детски :( если я правильно понял то I это интенсивность ? то есть яркость ? отсюда и 16 цветов. и атрибуты у нас теперь не 768 байт, а 768 * 8 = 6144 (#1800) ?
#4000 - 5800 - 1я часть
#5800 - #7000 - атрибуты ? или как ? что т тут неувязочка ?
поскольку с #6000 уже экран 2й ... :rolleyes:
Атрибутами там не пахнет. Для каждой пары точек в байте записаны их цвета. Т.е если у тебя (#4000)=%10111111, то в самом верху слева у тебя будут светиться два пиксела - один белый, другой ярко-белый.
(блин, кривое представление цвета в байте - сразу и не скажешь, какой байт за какие цвета отвечает. Куда удобнее #7F - сразу видно, что один цвет 7 - белый, а другой F - ярко белый).
Память жрется - это еще ладно, а вот то, что на реале эта схема отнимает процессора его кровное время - это пипец. AlCo говорил, что процесс тормозится на треть.
PS [самореклама]: если разочаруешься в этом режиме, переходи на мой. Те же 16 цветов на точку, проц не тормозится, а память вообще внешняя. (кто б мне его в железе помог реализовать)
Ну например, поскольку в таком режиме выходит 128 байт на строчку (просто сумма битов), то можно было бы сделать так: первая строчка по адресам $4000-$407f, вторая - по $4100-417f$ и так до 96ой, а с 97ой - строчки по адресам $4080-$40FF, $4180-$41FF и так далее. Ну это конечно грубо (24кило ибо на 1 экран), но идея примерно такая если бы была - было бы здорово.
Я правильно понимаю, что таким способом достигается линейность в смысле расположения в памяти (нет деления на куски с "провалами"), но не линейность пикселей (или строк пикселей)? Такой способ удобнее действительно линейного расположения пикселей в памяти и если да, то чем?
Я правильно понимаю, что таким способом достигается линейность в смысле расположения в памяти (нет деления на куски с "провалами"), но не линейность пикселей (или строк пикселей)? Такой способ удобнее действительно линейного расположения пикселей в памяти и если да, то чем?
Почему не достигается линейность строк? Каждая строка - это 128 байт подряд (а не как у АлКо). В байте пиксели можно расположить как угодно (IRGB.IRGB), всё равно такая раскладка потребует полного переделывания спека =))
Преимущества: переход на следующие 2 пиксела - inc l, на следующую строку - inc h.
Почему не достигается линейность строк? Каждая строка - это 128 байт подряд (а не как у АлКо).
Ну как, по адресу #4000-#407F стоит строка номер 0, по адресу #4080-#40FF cтоит строка номер 97 (согласно твоему описанию). Потом идёт строка номер 1 и строка номер 98 и т.д. Какая же это линейность? По-сравненю с предложением AlCo - да, отдельные пиксели находятся "рядом".
Преимущества: переход на следующие 2 пиксела - inc l, на следующую строку - inc h.
До определённого момента. Что будет, если в HL будет скажем #407F и ты сделаешь INC L? Куда попадёшь? Я так думаю на новую строку, только вот не следующую "по списку".
SAM style
18.01.2006, 19:32
ну вот эт другое дело, я тож подумал что лучше б была внешняя (видео) память, а кромсать и без того малую часть 48к имхо изврат :sleep: Моя режимина есть в unreal0.32b5 (0.33 надо перекомпилять чтоб была), если есть желание ознакомиться - вышлю доку и программу для конвертилки bmp. Пока руки доходят - делаю редактор спрайтов для него.
ps. так а в чём загвозка-то ? неужто здесь нету ассов хардварестроения ?Асы быстро охладели. Хотя, если мне память не отморозило, CHRV кажется говорил, что подумает над его реализацией в ATM3 если будет софт.
Ну как, по адресу #4000-#407F стоит строка номер 0, по адресу #4080-#40FF cтоит строка номер 97 (согласно твоему описанию). Потом идёт строка номер 1 и строка номер 98 и т.д. Какая же это линейность? По-сравненю с предложением AlCo - да, отдельные пиксели находятся "рядом".
Очень даже линейность, сравни с родным режимом.
До определённого момента. Что будет, если в HL будет скажем #407F и ты сделаешь INC L? Куда попадёшь? Я так думаю на новую строку, только вот не следующую "по списку".
А ты что же предлагаешь, делать строки по 128 байт друг за другом? И как ты будешь на следующую строку переходить (код)? Хуже только у АлКо получилось... =)
а чего в 0.33 убрали ?поигрались, и хватит. всё равно софт никто не пишет
Очень даже линейность, сравни с родным режимом.
Определение твоей линейности в студию.
А ты что же предлагаешь, делать строки по 128 байт друг за другом? И как ты будешь на следующую строку переходить (код)? Хуже только у АлКо получилось... =)
Я ничего не предлагаю, я хочу понять, какого типа линейность ты нашёл в предложеном варианте. Мало того, надо будет каждый раз проверять выход за границы строки (LD HL,#407F; INC L). То, что это лучше предложения AlCo я согласен был с самого начала.
Определение твоей линейности в студию.
Вот ещё =)
Я ничего не предлагаю, я хочу понять, какого типа линейность ты нашёл в предложеном варианте. Мало того, надо будет каждый раз проверять выход за границы строки (LD HL,#407F; INC L). То, что это лучше предложения AlCo я согласен был с самого начала.
Сразу видно, что ты на спек ничего никогда не писал. Да будет тебе известно, что выход за границы строки никто никогда не проверяет! А если и проверяет, то делает это далеко не с адресами!
На спеке основную проблему при рендеринге в экран составляет шаг на следующую строку, и выполняется следующим кодом:
inc h
ld a,h
and 7
ret z
ld a,l
add a,32
ld l,a
ret c
ld a,h
sub 8
ld h,a
ret
В предложенном мною варианте останется только inc h, с проверкой на достижение середины экрана, которая будет проскакивать куда как реже. Ну или не середины экрана, а трети (чтоб по маскам проверять).
ЗЫ: объяснять очевидные вещи завязываю...
Вот ещё =)
Ну значит нелинейна :)
Сразу видно, что ты на спек ничего никогда не писал.
Я последний раз на Спектрум писал 12 лет назад :)
Да будет тебе известно, что выход за границы строки никто никогда не проверяет!А если и проверяет, то делает это далеко не с адресами!
Это был простой пример, что бы не писать много. А как понять игру слов "никто не проверяет... а если и проверяет...". Так проверяют или нет? И что будет, если не проверять выход за границу строки в описаном тобою режиме (только об этом режиме речь идёт).
Я последний раз на Спектрум писал 12 лет назад :)
Ну и вот, прежде чем обсуждать строение экрана, хорошо бы себе представлять, как пишется код под дефолтный экран.
Это был простой пример, что бы не писать много. А как понять игру слов "никто не проверяет... а если и проверяет...". Так проверяют или нет? И что будет, если не проверять выход за границу строки в описаном тобою режиме (только об этом режиме речь идёт).
Итак - ЗАЧЕМ проверять выход за границу строки?
Ну и вот, прежде чем обсуждать строение экрана, хорошо бы себе представлять, как пишется код под дефолтный экран.
Я не обсуждаю, я спрашиваю. Знаки вопроса ни о чём не говорят?
Итак - ЗАЧЕМ проверять выход за границу строки?
Незачем, ты прав :)
хорошо! а где тогда взять версию что поддерживает
ручками откомпилировать. ну, или у дядюшки Сэма попросить из старых запасов ;-)
SAM style
19.01.2006, 18:04
ну, или у дядюшки Сэма попросить из старых запасов ;-)Зачем из запасов? Она же тут на форуме лежит:
http://zx.pk.ru/attachment.php?attachmentid=1852
пока работает только в filter=double, driver=ddraw/gdi
SAM style
25.01.2006, 16:49
всё-таки хотелось бы иметь хардварную версию, поскольку эмуль, это конечно гуд... но...Всю логику моей схемы могу на пальцах об'яснить - какие сигналы с чем AND-OR-XOR'ить и для чего что нужно. Вероятно, какой - нить хардварщик покруче меня и вделает ее себе в комп.
А вот если бы хардварщики на пару с программерами работали, то можно былобы получить что-то стоящее! Как-то давно пытался я придумать графический режим, чтоб z80 смог его РЕАЛЬНО осилить. Экран был в формате 3color - т.е 6144-RED + 6144-GREEN + 6144-BLUE
Вот например:
Вывод байта по маске на стандартный экран
LD A,(DE)
INC DE
AND (HL)
LD A,(DE)
INC DE
OR (HL)
LD (HL),A
INC L
Вывод на 3color экран
LD A,(DE)
LD (HL),A *
LD A,(DE)
LD (HL),A *
LD A,(DE)
LD (HL),A *
LD A,(DE)
LD (HL),A *
INC E
INC L
А дело тут в организации видеопамяти и видеоустройства!!!!!!!!!!!!!!!!!!!!
Видеостраницы размером 16Кб располагаются вместо ПЗУ (всего их минимум 6 - для двух экранов):
RedPage0,GreenPage0,BluePage0
RedPage1,GreenPage1,BluePage1
В приведенном примере используется так называемый MaskReg, при помощи которого задаётся
маска!
Сначала в управляющем видеопорту включаем бит "дополнительного управления командами z80"
Изначально вместо памяти по всем адресам 0..16384 подключен регистр маски MaskReg
Видеоустройство после команд отмеченных звёздочкой переключает страницы!
LD A,(DE) - из той-же видеопамяти (выше 6144 Кб) берем предварительно записанные по страницам данные
LD (HL),A * - Записали в MaskReg, сработала логика видеоконтроллера, переключились на страницу RegPage0 (или RedPage1 - в зависимости от текущего экрана 0 или 1 :-)
LD A,(DE) - Считали часть спрайта из RegPage0
LD (HL),A *- Записали в RegPage0, сработала логика видеоконтроллера, переключились на страницу GreenPage0
LD A,(DE) и так далее...
LD (HL),A *
LD A,(DE)
LD (HL),A *
INC E
INC L
На самом деле получая в руки только простейшие команды от Z80, надо использовать их со стороны железа по своему.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot