Идея простого расширения стандартного видорежима

[SMT]

PLZ... внутри viewer, пара триколоров, *.Y и *.888.

сделал скриншот и применил фильтр "blur more" в paint-shop-pro. получается почти фотографическое качество, закрыть глаза на низкое разрешение

[Advertiser]

[SMT]

А что, если сделать два порта, запись в которые давала бы возможность "сдвига" атрибутов соответственно на 1-7 пикселей по горизонтали и на 1-7 по вертикали. При этом монохромная часть экрана оставалась бы на месте

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

для начала, неплохо бы поинтересоваться, есть ли доступные чипы памяти, с and/or/xor вместо put

А чипам памяти зачем это делать?

это уже другой вопрос, и не ко мне. просто, как я понял из описания, Lethargeek хочет такую функцию в видеоплате, ну и интересно, как он видит аппаратную реализацию сей фичи...

не грех выделить и 16К - для быстрого копирования спрайтов

уже хочешь аппаратный блиттер видео->видео

Что мешает видеокарте выводить zx-экран? Просто настроить запись/чтение на одну плоскость, астольные либо заполнены 0, либо палитра установлена так что их не видно

не понял. для каждой плоскости своя палитра? а как смешивать?

насчёт палитры на выходе схемы SAM style согласен. маленькую (на 64 цвета) можно сделать по схеме ATM - всего 2 16-ти ногих мелкосхемы, не считая логики дешифрации порта палитры

[SMT]

маленькую (на 64 цвета) можно сделать по схеме ATM - всего 2 16-ти ногих мелкосхемы, не считая логики дешифрации порта палитры

а если поставить не 2 РУшки, а 3, то можно сделать палитру из 4096 цветов (4 независимых бита на каждую цветовую компоненту). только нужно 3 порта, поэтому ещё доп. мелкосхема типа 555ид7

[SAM style]

насчёт палитры на выходе схемы SAM style согласен. маленькую (на 64 цвета) можно сделать по схеме ATM - всего 2 16-ти ногих мелкосхемы, не считая логики дешифрации порта палитры

Палитре - да.
Пока с работы домой ехал, придумал следующее (насколько здравая мысль, не знаю) - три регистра видеокарты, каждый отвечает за интенсивность цвета (r,g,b соотв). Если каждому цвету по 256 значений, то это уже все из TrueColor-а можно получить (правда, одновременно опять же только 16).
Единственное непродуманое - вывод. По идее все 8 сигналов с МС регистра смешиваются в один через весовые резисторы и выдаются, если в соответствующем экране пиксел установлен. Да и "среднее" значение должно быть 128 (устанавливается по reset'у).
Насчет портов - можно взять тот же #DF за основу и наделать на нем #xxDF работающие на вывод (и регистр управления, и интенсивность и еще чего-нибудь).
А вообще нехилые аффекты так получить можно - плавное затухание экрана или появление картинки из темноты...

Схема обрастет кучей резисторов, дешифратором и тремя восьмибитными регистрами.

PS: блин, пока это сочинял, SMT уже подобное выдвинул!

[SMT]

три регистра видеокарты, каждый отвечает за интенсивность цвета

imho больше возможностей, если задавать не яркость каждой цветовой плоскости, а по 4 бита r,g,b каждого 4-х битного значения цвета. скажем, на экране могут быть одновременно ярко-зелёные и тёмно-зелёные цвета, что не сделаешь в твоём варианте

а ты думал, как формируется бордюр на твоей карте? дублируется порт #FE или подаются rgb с оригинального порта бордюра (во втором случае zx-bus недостаточно)

[SAM style]

imho больше возможностей, если задавать не яркость каждой цветовой плоскости, а по 4 бита r,g,b каждого 4-х битного значения цвета. скажем, на экране могут быть одновременно ярко-зелёные и тёмно-зелёные цвета, что не сделаешь в твоём варианте

А вообще да... Насколько я понял, работает оно так - номер цвета IGRB (0..15) интерпретируется как адрес, который подается на 3 МС памяти палитры, с которых снимаются 4 бита R с одной, 4 бита G с другой и 4 бита B с третьей, после чего каждая четверка мешается в свой сигнал (R,G,B) и эти три уже подаются на вывод. Соответственно, у нас три порта для записи 4-битных значений в палитру. Номер цвета можно задавать в верхнем полубайте (он пойдет в адрес МС), а значение - в нижнем (это в данные).
Так вроде... В итоге 4096 цветов.

а ты думал, как формируется бордюр на твоей карте? дублируется порт #FE или подаются rgb с оригинального порта бордюра (во втором случае zx-bus недостаточно)

Бордюр стандартный, т.е вывод с карты блокируется когда brd`=0.

[SMT]

Бордюр стандартный, т.е вывод с карты блокируется когда brd`=0

ты хочешь карту в слот (или минимум - панелька вместо процессора), или обвешать весь видеоконтроллер соплями к новой карте? стандартный бордюр можно только во втором случае

[SMT]

а на чём планируешь делать

движок настолько завязан на эмуляцию именно железа, что ему обязательно схему сигналов подавай?

для эмулятора, понятное дело, всё равно. просто интересно, какие схемотехнические приёмы будут использованы, и во сколько килограмм выйдет этот монстр ведь для карты SAM style схема вырисовывается в уме средним спектрумистом-железячником и спаять не проблема, у 9990 CHRV, я думаю, есть схема типового включения, описанная разработчиками кристалла. а доберётся ли третья карта до стадии схемы - вопрос

зачем ему атрибут

спрайтом мигать можно быстро

хорошо, прям как на денди только для игр плохо тем, что нельзя, чтобы в атрибутном квадратике мигания были другие спрайты, (напр., в играх типа golden axe чтобы так умирали монстры на игровом поле). для SCF атрибутный клешинг с фоном ты разрулил, но между спрайтами конфликты так и остались. так что вариант CHRV качественнее (и кажется, по цене и корпусам компактнее)

[Ewgeny7]

Тема перемещена из "Железа" по просьбе Black Cat'a