Рецептов конечно под каждый конкретный клон никто сочинять не будет .
Тады уж лучше DMA контроллер прицепить или какуюнить хрень выполняющую его функцию . Ибо цеплять такую штуку можно к любому спеку (так же как и видео контроллер :D ).
Вид для печати
о какой поддержке речь? Принцип подключения к Pentagon 1024SL v2.2 уже продуман, шикарная палитра выбрана.. правда не до конца пока ясно как сгруппировать биты в байте, чтоб было удобней считать при необходимости цвет - активность кодеров не очень высокая в предложении наиболее оптимальных и быстрых процедурок расчёта цвета.. :(
Но палитра просто классная, и главное - интуитивно понятная.
Модель представления предложенной Lethargeek'ом равномерной палитры.
1) берём две плоскости 8х8 и располагаем одна над другой;
2) на нижней по двум координатам откладываем значение R и B, на верхней - по обеим координатам значение G.
В результате получаем на обеих плоскостях из самых тёмных в самые светлые углы две диагонали равных уровней интенсивности, снизу RB - диагональ, а сверху аналогичную G - диагональ. При их сложении получим 8 оттенков серого, которые располагаются строго по диагонали, а с обеих сторон от диагонали будут цветные поля - с одной стороны с преимуществом красного, а с другой стороны от диагонали - с преимуществом синего, зелёный же распределён симметрично-равномерно в обеих половинах. Всё просто и интуитивно понятно. Правда если посчитать разрядность такой палитры, то она будет превышать на один бит палитру, которую можно адресовать байтом, т.е. фактически на плоскость RB отдаётся 64 комбинации из 32 возможных комбинаций ограниченных разрядностью 8bit-3bitG=5bitRB. Чтоб это выправить в плоскости RB равномерно сделаны 32 дырки - теперь количество оставшихся ячеек соответствует разрядности 5bit. Посколько дырки распределены равномерно на плоскости, то при конвертации полноцветного изображения даже если цвет попадает на дырку - всегда можно взять взамен любой из соседних вокруг дырки восьми оттенков, что позволяет максимально приблизить результат к оригиналу.
Сами места дырок автоматически формируются с помощью элементов жёсткой логики схемы цифро-аналогового преобразователя. Формулы вычисления разрядов r0, b0 в зависимости от композитного разряда rb0 и значений r2r1, b2b1 приведены ниже:
r0=((r2+r1)&rb0)+(rb0¬(r2+r1+b2+b1));
b0=((b2+b1)&rb0)+(rb0¬(r2+r1+b2+b1));
или:
r0=rb0&((r1+r2)+not(b1+b2));
b0=rb0&((b1+b2)+not(r1+r2));
Ниже слева RB плоскость из 64 ячеек, а справа - та же плоскость после выкалывания 32 дырок:
А побитовая раскладка - отдельный вопрос, мож правда кому нагляднее GGGRRBB(rb), хотя GRBGRBG(rb) удобнее, если например надо быстро яркость оценивать.
Добавлено через 3 минуты
Я ваще не смог представить, зачем на верхней плоскости по обеим осям G откладывать??? :v2_wacko:
Добавлено через 5 минут
Кубик нагляден, если просто 8 квадратиков рядом нарисовать ;)
во-во-во.. с этого места, и с примерами максимально быстрого кода пожалуйста.. при каккой раскладке можно сочинить наиболее быструю процедурку..
..господа программеры-демописатели примените свои навыки к пользе дела - выдайте варианты наиболее оптимального кодинга!!
Добавлено через 2 минуты
в верхней G плоскости имеем две одинаковые половины, расположенные симметрично относительно диагонали. Т.е. над более красной и над более синей половинками RB плоскости фактически находятся идентичные G палитры, а суммируя нижнюю и верхнюю плоскости получаем результирующий цвет :)
Ответ на мыло (на счёт DMA для 16ц/256ц).
Готовая схема как не странно есть , и даже есть хоть какая то поддержка . Тема уже была в железе , Velesoft предлагал юзать уже стандартную примочку из MB02+ http://velesoft.speccy.cz/data-gear.htm . Подключение в стиле муз сопра , без всякой резни . Ацкий компаратор можно заменить на рассыпуху . Пулять можно хоть в мозг , хоть в порт .
Итого 865 килобайт за кадр (1/50) !!!
Кстати там уже появились не убитые ацким пожатием ролики всяких дёмок и сами дёмки , а так же есть куча портретов Z80-DMA .
865 кб за секунду, за фрейм всего лишь 17, но все равно круто.Цитата:
Итого 865 килобайт за кадр (1/50) !!!
сайт внимательно не читал, но вдруг там возможно составлять списки для DMA, типа
а не трансферить по-очереди, типаКод:ld hl, dmaList
call loadListToDma
call waitDma
dmaList: db 1: dw A1, B1 ; db 1 - copy mem , dw A1,B1 - from A1 to B1
db 1: dw A2, B2
....
db 1: dw AN, BN
db 0 ; db 0 - list end
...Код:ld hl,A1 : ld de,B1 : call dmaTransfer : call waitDma
ld hl,A2 : ld de,B2 : call dmaTransfer : call waitDma
....
ld hl,AN : ld de,BN : call dmaTransfer : call waitDma
то в общем можно было бы делать всяко-разно фреймовые скроллы и еще кучу полезностей
хотя я наверное опять мечтаю...
Упс , опять я разбежался :D
Добавлено через 2 минуты
Значит с турбой на DMA уже жить можно :)
Добавлено через 5 минут
Думаю верно мыслишь , качни ролики , там явно ван фрем .
Добавлено через 7 минут
Единсственный облом -
В www.chip-dip.ru Z84C1008PEG
Норма отпуска: 10 шт.
Цена в розничной сети, руб.: 290.00
И ещё ждать хе зе сколько...
Ну вообще-то написано, что инкремент и декремент у источника или цели возможен, то есть перекинуть заранее сгенеренную табличку в порт вроде можно.
Вот только (кажись) дма ни в одном эмуляторе на данный момент не эмулируется.. Хотя мне кажется что применение ей найдётся и без расширенных экранов..
А на счёт фреймовости.. Даже при скорости 17кб/фрейм сложновато перекинуть 24 кб (размер экрана при режиме 256 цветов) за этот же фрейм..
Собсно есть DMA контроллеры более доступные 8237 82C37 (КР1810ВТ37) (Более древний вариант I8257 (КР580ВТ57 , КР580ИК57)) , но не совместимые с зилоговскими .
В www.chip-dip.ru
P8237A-5_____________- 19,00 (на заказ)
(8257P-5 (КР580ВТ57) ____ - 75,00)
Иифа по 8237 82C37 (КР1810ВТ37) на русском есть в нете , а так же в описании DMA USC .
Добавлено через 3 минуты
Думаю это скорость для не разогнаного DMA , если юзать клок на 7(8)мгц , то как раз получится в два раза больше .
DMA transfer speed of my DATA-GEAR interface is 17kB/sec for Z80 CPU at 3.5MHz. Clock for DMA chip is used from Z80CPU socket. If turbo mode is used, DMA transfer speed is accelerated too. In 7MHz turbo mode (if your ZX support turbo) can be transfer 34kB/frame. But ZX Spectrum and other ZX clones slow-down CPU when memory operations is used with videoram.
Если ещё учитывать что при данной реализации 16ц/256ц проц стоит , то пулучается ещё веселей %)
Случйно наткнулся на дизи в 128х192 - http://www.cpczone.net/index.php?game=286
Раскраска жудкая (но веселей чем на С64), но спраты нормально смотрятся .
Ещё за компанию -
http://www.lemon64.com/?mainurl=http...php%3FID%3D671 Demon's Kiss и спратики и задники не плохо сделаны
http://www.lemon64.com/?mainurl=http...php%3FID%3D669 Demon Blue не чё так задники нарисованы (палитра шибко кислотная)
http://www.lemon64.com/?mainurl=http...php%3FID%3D693 Defenders of the Earth чисто для сравнения с
http://www.simcoupe.org/images/scree...oftheearth.png (тут цвета конечно повеселей)
http://www.lemon64.com/?mainurl=http...php%3FID%3D618 Dan Dare III: The Escape Спрайты не плохо сделаны .
..да уж.. картинки лучше не увеличивать.. режим явно не приспособлен для мелких изображений
If R,G,B,BRIGHT signals from ULA is connect to adress bus A0-A3 on sram memory with palette, data output from SRAM is possible use as new ZX palette. SAM COUPE use same resolution 256x192/16 colours, but each ZX colour can be set as 7bit RGB value. This palette interface can be used on any ZX clone.:v2_yahoo:
I can make this palette interface.
examples of SAM COUPE graphics(256x192/16 colour per pixel with palette):
http://www.worldofsam.org/flexinode/termstable/3/5
http://www.worldofsam.org/files/acti...TPOTRMmain.png
http://www.worldofsam.org/files/active/0/DoEboss.jpg
http://www.worldofsam.org/files/active/0/klax.jpg
http://www.worldofsam.org/files/active/0/lemrun.png
http://www.worldofsam.org/files/active/0/snap0024.png
http://www.worldofsam.org/files/acti...g%20screen.png
http://www.worldofsam.org/files/active/0/snap0087.png
SAM COUPE: ZX mode with hardware multicolour + palette:
http://www.worldofsam.org/files/active/4/snap0005.png
videos:
http://www.youtube.com/results?searc...e&search_type=
VELESOFT
Вопрос по палитре 256 цветов RGB 773.
Как правильно изменять яркость цвета в такой палитре?
Есть цвет, например 050, нужно получить цвет ярче или темнее него.
тут проблема что один цвет 2-х битный
и лучший результат будет ручками
второй вариант забить на младшие биты 3 битных цветов
и делать
+2 +2 +1
-2 -2 -1
по таблице проще всего
при этом не будет меняться оттенок
но количество градаций весьма сократиться
если нужно плавное затемнение\осветление
можно попробовать затемнять осветлять как то так
*-1 *** **
*** *-1 **
*-1 *** **
*** *-1 **
*** *** -1
*-1 *** **
*** *-1 **
*-1 *** **
*** *-1 **
*** *** -1
опять же
проще будет по 3-м таблицам
оттенки будут слегка играть при этом в процессе
но градаций получиться много
и если делать быстро (думаю не больше 2\3 фреймов на каждую "якрость")
то должно прокатить
для большей скорости можно 4 таблицы (если не палитра а 1 байт на пиксель например)
*-1 *** ** таблица 2
*** *-1 ** таблица 3
*-1 *** ** таблица 2
*** *-1 ** таблица 3
*** *** -1 таблица 4
*** *-1 ** таблица 3
*-1 *** ** таблица 2
*** *-1 ** таблица 3
*-1 *** ** таблица 2
*** *** -1 таблица 1
а так еще нужно смотреть как интерпретируется младший (3-й хардварный бит (если он есть))
2-х битного цвета
тк вариантов может быть много
NEO SPECTRUMAN, Вроде нашел решение, но заточенное под мой случай.
У меня кроме палитры 8bpp (rgb 773) есть исходная палитра 24bpp. Цвет из палитры 24bpp переводим в формат YCbCr, изменяем яркость и переводим обратно в RGB.
Но решение считаю частичным, так что продолжаю поиск изменения яркости внутри палитры 8bpp.
Минусом данного решения является необходимость наличия палитры 24bpp, и более того если необходимо последовательное изменения цвета, то цвет в палитры 24bpp должен оставаться оригинальным (незатронутый конверсией в 8bpp).
так же обращу внимание, что в "идеальном" случае получается только 9 шагов смещения. "Идеальным" случаем это когда составные R и G равны. А вот если внести поправку = 16 в 24bpp в одну из составляющих, получиться 18 шагов (в 8 Bpp).Код:
Y=Trunc( 0.299 * rrr + 0.587 * ggg + 0.114 * bbb) /* канал яркости */
Cb=Trunc(-0.1687 * rrr - 0.3313 * ggg + 0.5 * bbb + 128.0)
Cr=Trunc( 0.5 * rrr - 0.4187 * ggg - 0.0813* bbb + 128.0)
if ?bright=1 then Y=Y+36 /* Светлее */
else Y=Y-36 /* Темнеее */
rrr=Trunc(Y + 1.402 * (Cr - 128.0))
if rrr>255 then rrr=255
else if rrr<0 then rrr=0
ggg=Trunc(Y - 0.34414 * (Cb - 128.0) - 0.71414 * (Cr - 128.0))
if ggg>255 then ggg=255
else if ggg<0 then ggg=0
bbb=Trunc(Y + 1.772 * (Cb - 128.0))
if bbb>255 then bbb=255
else if bbb<0 then bbb=0
rrr8=format(rrr*(7/255),,0) /* 24bpp в 8bpp */
ggg8=format(ggg*(7/255),,0) /* format - округление до целого */
bbb8=format(bbb*(3/255),,0)
раз у тебя есть 24 бит цвет
проще тогда повышать понижать яркость просто умножением каждой компоненты на один и тот же коэфициент...
можно просто отнимать\прибавлять к каждой компоненты одно и то же число
тоже интересный эффект
а так я думал тебе нужно яркостить прям на спектруме...
Это тоже нужно. Но уже как самостоятельная задача. Например, изменение освещения "на лету". Здесь можно выделить особенность в том, что "шагов" в будет мало (1 или 2). И эту задачу можно решать "в лоб".
Хотя универсальный вариант всё равно буду подбирать и внедрят в программах (пока хочу вставить в свой вьювер "sea").
Кроме того появилась возможность на основе карт изменения цветов при работе с 24bpp (получается несколько вариантов), подбирать значения для решения узких задач.