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

[Lethargeek]

Сразу поясняю, что SCF значит "Spectrum Coder Friendly" (или просто Spec-friendly), а APA,
как известно - "All Point Addressable", в вольном переводе "каждая точка своим цветом"

Допустим, имеется "EGA"-видеорежим с линейной адресацией пикселов - то есть в байте два
пиксела, 4 бита на каждый (для режима 8 бит на пиксел рассуждения будут аналогичны). Также,
опять для простоты изложения, подразумевается, что экрани имеет тот же размер 256x192.

Как же можно "помирить" Spec-friendly и APA режимы, причем чтобы они не просто могли
сосуществовать, а еще и пользу друг из друга извлекли. Короче, пока идея такая:

Видеопамять хранит два графических экрана именно в "своем" формате - 4 бита на точку.
Плюс отдельно два комплекта спековских атрибутов и "вентильный" экран - те же 6 кб.
В "чистом" APA-mode все атрибуты имеют значение INK=111, PAPER=000, BRIGHT=1, а при
выборке значения пиксела для отображения на дисплее номер цвета получается по формуле:

color = ((pixel) and (ink)) or ((not pixel) and (paper)),

то есть в данном случае просто значение четырех бит пиксела. Разумеется, значения INK и
PAPER должны тоже расширяться до 4 бит (до 8 для VGA) по "спековским" правилам, то есть
INK расширяется битом BRIGHT, а PAPER - только если ненулевой, иначе нулем (для VGA
варианта 4 старших бита всегда 0). Ну и конечно, в "чистом" APA-mode "вентильный" экран
обнулен, хотя все равно учитывается при выборке пикселов (следовательно, переключать два
APA-экрана можно тем же битом "инверсия вентиля").

Если включен SCF-mode, то атрибуты и байты для "вентильного" экрана так и записываются
в видеопамять, а вот "графические" байты надо "промасштабировать" - то есть из одного
байта получить 4 - каждый исходный бит расширяется в 1111 или 0000 (ясно, что тут встает
вопрос о скорости видеопамяти). Взглянув выше на уже знакомую формулу, понятно, что
все будет отображаться по-прежнему правильно, в "спектрумовском" стиле.

Самое приятное, что оба режима прекрасно можно смешивать на одном экране - то есть делать
SCF-окно, APA-окно, плюс еще "вентильный" экран позволяет смешать произвольной формы
кусками два APA-экрана и/или APA-окна (то бишь иметь подобие APA-спрайтов). А в SCF-mode
можно будет использовать плавный скролл аппаратный (есс-но, желательно, чтобы при этом
учитывался и "сдвиг" атрибутов при расчете формулы) - для фона, прежде всего.

Понятно, что реализации APA-режимов могут быть совершенно разными - например, где-то
выгоднее не хранить значения атрибутов, а при их перезаписи напрямую менять значения
в блоке 8x8 пикселов (кто знает, какие там блиттеры-шмиттеры стоят ). Да и скролл
аппаратный разный бывает - или действительно инфа пересылается, или просто сдвигается
"левый верхний угол" закольцованного во все стороны видеобуфера.

Структура памяти может быть не линейная, а битплановая - в этом случае все даже, наверное,
проще, хотя будут свои нюансы и/или ограничения (да и влом уже было это обдумывать, если
честно ). Универсальных рецептов дать нельзя - я просто привел небольшой пример, чтобы
показать: никакого антагонизма не существует.

P.S. А про четвертушки я специально ничего не сказал... а то только их все и запомнили.
Но в принципе ничего не мешает добавить их и в последний предложенный вариант видеокарты.

[SMT]

есть одна труднорешаемая проблема - идентификация второго экрана

почему? завести ещё RD, раз D0-D7 и логика дешифрации порта на запись уже есть, просто читать из порта сигнатуру устройства - плюс одна мелкосхема. но и ручной сетап вполне хорош

Сразу поясняю, что SCF значит "Spectrum Coder Friendly" (или просто Spec-friendly), а APA

жаль только, в железе будет 1-2 устройства, поэтому софт будет лишь демонстрационный. а плату с 9900 можно серийно (и без убытков!) выпускать

[jtn]

почему? завести ещё RD, раз D0-D7 и логика дешифрации порта на запись уже есть, просто читать из порта сигнатуру устройства - плюс одна мелкосхема. но и ручной сетап вполне хорош

/rd как раз не причем (наличие /wr /m1 /iorq самодостаточно). я про то, что сколькоу нас различных клонов с >128k. а сколько еще всяких блокировок самопальных, ограничивающих 128к. внешняя плата должна в точности повторять дешифрацию на мамке как #7ffd, так и 1ffd/dffd/fdfd... портов. более менее приемлемый вариант - закатать логику в плис, и сделать разные прошивки для разных клонов, но и это, имхо, не панацея.

[Vladimir Kladov]

опять 25. ЕСЛИ ВЫ СОБИРАЕТЕСЬ заставлять ПРОГРАММИРОВАТЬ ВИДЕОВЫВОД заново, то нафига заставлять кодера сдвигать спрайты ПРОГРАММНО перемещая байты и биты в экранной области??????? У вас отдельный девайс предлагается, здорово. Ну и добавьте в него счетчик сдвига относительно верхнего левого угла - для слоя заднего плана хотя бы. А дальше - хочет вася сдвигать, пусть сдвигает. Хочет быстрее чтобы пахало - меняет смещение в порту.

[Spectre]

опять 25. ЕСЛИ ВЫ СОБИРАЕТЕСЬ заставлять ПРОГРАММИРОВАТЬ ВИДЕОВЫВОД заново, то нафига заставлять кодера сдвигать спрайты ПРОГРАММНО перемещая байты и биты в экранной области??????? У вас отдельный девайс предлагается, здорово. Ну и добавьте в него счетчик сдвига относительно верхнего левого угла - для слоя заднего плана хотя бы. А дальше - хочет вася сдвигать, пусть сдвигает. Хочет быстрее чтобы пахало - меняет смещение в порту.

Насколько я понимаю автора данной ветки, основная идея не "программировать видеовывод заново", а при помощи отладчика изменение существующей процедуры вывода на экран. Например:

LD HL,MASK
LD DE,SCREEN
LD BC,SPRITE
LD A,HIGH
CALL OUTSPRITE
...
OUTSPRITE
LD A,(BC)
AND (HL)
LD (DE),A
INC HL,D,BC
DEC A
JR NZ,OUTSPR
RET

Заменить на:

OUTSPRITE
PUSH DE,AF
CALL OUTSPRITE2
POP AF,DE
LD H,B
LD L,C

OUTSPRITE2
;переключаем на страницу с другим экраном
LD A,(HL)
LD (DE),A
INC HL,D
DEC A
JR NZ,$-5
RET

И на этом изменения завершаются! Разумеется для каждой программы изменения будут индвидуальными, но цель сделать их как можно менее трудоемкими.

[icebear]

/rd как раз не причем (наличие /wr /m1 /iorq самодостаточно). я про то, что сколькоу нас различных клонов с >128k. а сколько еще всяких блокировок самопальных, ограничивающих 128к

Поддержать только схему включения страниц 128-го Спектрума - не вариант? Всё равно же программы, использующие нестандартные блокировки, так же в этом роде нестандартны. А значит можно попробовать их переписать.

[Lethargeek]

Danil Davydov> Вот только лозунгов типа "Обойдемся без железа, даешь чисто
' программную поддержку!" не нужно. Вы бы, господа железячники, сначала техзадание
' бы сформулировали, а то каждый тянет одеяло на себя.

Ура, меня обозвали железячником!!


Danil Davydov> Hужен однозначно. А вот какой вариант будет взят на вооружение,
' еще большой вопрос. А вот на второй вопрос сам себе ответь, подсказывать не буду.
' ...гигаскрин в топку.

Ага, сначала до основанья все разрушим и выбросим, а уж затем...


Danil Davydov> Вот только про калькуляторы грузить не надо, да? А то можь еще Амигу
' вспомним или Корвет какой-нибудь, у которого с графикой тоже получше, чем у Спектрума?

А кто мешает спековские картинки на Спеке рисовать? А вот пытаться всякие труколорные
и ЕЖА с ними - просто мазохизм какой-то. Особенно если учесть, что и стандарта нет.
Даже если и появится...


Danil Davydov> Все-таки начните с техзадания, может тогда и изобретать и извращаться
' придется гораздо меньше. Можно начать с первого требования к новой графической карте
' - никакой переделки старых программ! Все старое должно работать так же, как и раньше.

А выступая по теме, все-таки можно начать с ее внимательного прочтения. Где сказано,
что старое работать не будет? Старый видеовыход никто не отменял. (Неужто появится клон
с видеослотом, но без интегрированного видеоконтроллера? И в каком году...) Да и на
внешнем устройстве это легко предусмотреть.

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

[Lethargeek]

ASDT> "господа железячники, сначала техзадание бы сформулировали"
' Думаю надо ориентироваться на программеров игр. Что они считают нужным?

icebear> Где-то месяца полтора назад я поднимал подобный вопрос в разделе
' "Программирование". Были вполне конкретные ответы.

Чего же раньше ссылку не дал! (А то у меня архив старше).
А так забавно получилось - я это прочитал уже после того, как запостил последний вариант.
Ну что сказать... ТАК БЫ И ВСТАВИЛ В СВОЮ ТЕМУ В КАЧЕСТВЕ ПРЕДИСЛОВИЯ!!!
Особенно сейчас

А CHRV еще отвечал, что "в основном они заходят". И где эти люди?! Был один Максагор,
и то, почитав его посты там и здесь, я заподозрил, что это два разных человека.

К чему я это? Там были пожелания сделать супернавороченную видеокарту, но чтобы она
и стандартный режим поддерживала (видимо, таки подразумевается, что новый Спек будет
(если будет) с несколькими слотами, но без внутреннего видеоконтроллера). А я предлагаю
не просто стандартный режим поддерживать, а его расширенную версию, причем так, чтобы
ее можно было сделать и отдельно в виде более простого девайса, не дожидаясь, пока
монстростроители сваяют нам наконец "идеальный" наворот. И он не окажется совсем уж без
софта, когда (если) появится. Свои размышления насчет "увязки концов" изложил в прошлый раз.

А то что же получается? Все попытки улучшить графику Спека пока губятся неумеренными
аппетитами - и то хочу, и это, и блиттеры, и спрайты аппаратные. В итоге за десять лет
не сделано НИЧЕГО - не считая всякого убожества, подходящего в лучшем случае для системных
целей. (Да и то было реализовано только потому что случайно оказалось легко приделывать к
существующему железу.) Такими темпами не только подохнут все Спектрумы, но и сами
спектрумисты перемрут естественной смертью, но не дождутся.

Потому что чуть-чуть улучшить типа "неинтересно", сразу супер-пупер-мегадевайс подавай.
А его сделать не могут. Или "чуть-чуть" тоже не могут на самом деле? Все эти навороты
аппаратные ведь тоже не сразу придумывались, а постепенно развивались. И когда их
"сразу все и немедленно" хотят спектрумисты, это напоминает попытки "сразу прыгнуть
из феодализма в социализм, минуя капиталистическую стадию" - (c) наша училка истории.
(Это она так про Монголию. Побывайте в Монголии!).


P.S. А насчет полной совместимости SCF-mode со стандартным режимом - можно и это устроить.
В принципе, весь 48-й софт и так будет работать правильно при надлежащей настройке режима.
А под совместимость со 128-м можно высвободить один бит в порту управления. Тогда если он
включен, то вне зависимости от остальных управляющих битов вся запись с адреса #4000
копируется в один графический экран на видеокарте, а запись с адреса #C000 - в другой
(но только при впечатанной 7-й странице ОЗУ!). То есть надо следить за состоянием
системного порта Sp-128. Стандартное переключение экранов - путем копирования бита
"активный экран" из системного порта при его изменении в бит "инверсия вентиля".
Ну а "вентильный" экран для правильной работы можно в принципе и ручками обнулить
(если он использовался после включения/сброса компа).

[Lethargeek]

icebear> Поддержать только схему включения страниц 128-го Спектрума - не вариант? Всё равно же программы, использующие нестандартные блокировки, так же в этом роде нестандартны. А значит можно попробовать их переписать.

Да карте будет пофиг, как и куда они переключаются, она "видит" только обращения
в адресное пространство #0000-#FFFF.

Ну кроме "режима совместимости", конечно, где за вторым экраном надо следить.

[Lethargeek]

Vladimir Kladov> ...заставлять кодера сдвигать спрайты ПРОГРАММНО перемещая байты и биты в экранной области??????? У вас отдельный девайс предлагается, здорово. Ну и добавьте в него счетчик сдвига относительно верхнего левого угла - для слоя заднего плана хотя бы. А дальше - хочет вася сдвигать, пусть сдвигает. Хочет быстрее чтобы пахало - меняет смещение в порту.

А что мешает добавить? Только, по-моему, это опять "неумеренные аппетиты" и неоправданное усложнение базовой схемы. Я ориентируюсь на разумный минимум. Даже если и сделать, всяким любителям наворотов и этого будет мало...

Хотя бы такой вариант осилить.