Планировалось надевание на системный разъем.Сообщение от SMT
Панелькой в процессор не обойдешься - где тогда брать h0..v7? К тому же по идее на карте стоит свой собственный счетчик, а это уже позволяет получать свой brd' прямо на месте, а не брать его с платы.
Меня одно только мучает - перехват чтения-записи в экран. Вот тут точно ни слотом, ни тем более панелькой не обойдешься.
Все любят гипножабу
(на 27-10-2005)
ASDT> А разработка внешних видеокарт - это надо другую тему...
Ну, начиналось-то не с внешних, к такой постановке вопроса пришли по ходу дискуссии.
Я тоже вот думаю - а не убрать ли в архив все написанное до 19-10-2005 @20:26 (то есть до
моего сообщения с заголовком "Attention!", сразу после которого идет описание последнего
варианта SCF-mode (это надо оставить, чтобы дальнейшее понятно было). И сменить название
у темы на что-нибудь вроде "Планирование спецификаций внешней видеокарты для Спека, их
обоснование и эксперименты с ними" - ну или кто предложит лучший вариант.
Лично я не против, а остальные? И что на это скажут модераторы?
(на 27-10-2005)
SAM style> Товарищ, а не прыгаешь ли ты выше головы в данный момент, ась? Сразу сделать
' монстроподобную навеску на спек никто не решится. Начинаем с малого (моего режима)
' и уж потом потихоньку раскручиваем его до нужной кондиции.
Насчет "выше головы" - это вопрос к схемотехникам. Монструозность, по-моему, до GS
не дотягивает.А "с малого" начать не получится, точнее можно, но нерационально.
СНАЧАЛА ПРОЧИТАЙ НИЖЕСЛЕДУЮЩЕЕ И КОЕ-ЧТО ОСОЗНАЙ, потом отвечу подробнее:
SAM style> управление ведется через один порт, ориентированый на запись. через него
' выбирается: активный слой (00-B, 01-R, 10-G, 11-яркость), режим перехвата обращения
madcore> Уточнение: для записи можно включать сразу несколько слоев. Чтение из выбранного
одного, плюс нужен режим, когда адаптер при чтении всегда выдает 0 (или 255, щас не
сообразить) - поможет для переделки старой векторной графики. Еще нужен режим записи,
когда байт проц выступает маской, а цвет берется из соответствующего регистра видеокарты.
SAM style> а мы ничего не потеряли и не приобрели - ZX работает как обычно, только
' где-то на стороне делается другое изображение и остается только выбирать, что на
' экране показывать.
В том-то и дело, что потеряли в скорости - в таком виде твой вариант годится только для
просмотров немерцающих 3-колоров и игрушек с ну очень маленькими спрайтами, потому что
они будут печататься в 8 (!) раз медленнее - в каждом слое надо сначала сделать AND с
маской (ручками!), а потом OR с соответствующим слоем спрайта. Надо, как я предлагал,
как пишет madcore (и как сделано в EGA, если уж на то пошло) - возможность параллельной
записи PUT/OR/AND/XOR в выбранные слои (фактически цвет). Просто не получится.
Вообще печать спрайта в моем варианте выглядит так: сначала разрешаем для записи все слои
и за один проход печатаем маску по AND, затем (допустим, спрайт трехцветный - красного,
желтого и зеленого цвета) разрешаем только красный слой экрана, печатаем красный слой
спрайта, разрешаем только зеленый слой экрана и печатаем зеленый слой спрайта и... все!
Желтый цвет получился слиянием зеленого и красного - преимущество битплановых режимов
(можно раскладывать на спрайт на цветосоставляющие для любого числа слоев).
Насчет режима записи madcore: "соответствующий регистр" - это просто тот же самый
регистр разрешения записи/чтения слоев. Просто в разрешенные слои запись идет по OR,
а в запрещенные - по NOT+AND. Для чтения я уже предлагал нечто подобное (перечитай specs!).
При записи такой режим даст реальный выигрыш только для одноцветных спрайтов - буквы на
фоне рисунка, что ли, печатать собрался? Не лучше ли это сделать по-моему, когда в
APA-mode тоже есть "спрайты". 5 режимов записи (а не 4) - это плохо, бит повиснет
Хотя я подумаю, как это сделать, чтобы во всех режимах больше пользы было.
SAM style> к памяти #4000-#57ff (1-вкл, 0-выкл) и режим вывода на экран
' (1-с видеокарты, 0-с ZX экрана).
madcore> Что мешает видеокарте выводить zx-экран? Просто настроить запись/чтение на одну
' плоскость, астольные либо заполнены 0, либо палитра установлена так что их не видно.
' И почему не 5aff? ИМХО, под это дело не грех выделить и 16К - для быстрого копирования
' спрайтов. Конечно, перекроет системные переменные и бэйсик, но во время вывода спрайтов
' оно нам не надо.
Что мешает? Атрибутов нет! Либо все равно удваивать цикл чтения, либо читать их с другого
слоя. И писать тогда тоже в два слоя одновременно. То есть опять просто не получится.
madcore> Палитра нужна! Что там говорил Lethargeek про фоновые экраны я толком не понял,
' но этого можно добиться просто настройкой палитры! Можно сделать количество 1-битных
' экранов по количеству плоскостей, можно передний план 1-битный, задний - 3-битный и т.д.
' любые комбинации. Постораюсь показать на примере 2-х плоскостей: Допустим, 0-я плоскость
' - передний план, 1-я - задний. Настраиваем палитру так, что цвет 01=11 и все! Изображение
' с 0-й плоскости будет "затирать" 1-ю.
SMT> не понял. для каждой плоскости своя палитра? а как смешивать?
' насчёт палитры на выходе схемы SAM style согласен. маленькую (на 64 цвета) можно сделать
' по схеме ATM - всего 2 16-ти ногих мелкосхемы, не считая логики дешифрации порта палитры
Уж лучше сразу 6 цветовых слоев и 64 цвета, как я предлагаю. С возможностью сквозной записи
в несколько слоев на скорости это отражается мало, а качество значительно возрастет. Не
стоит экономить на спичках!
А то, что предлагает в данном случае madcore - убожество, получается, мы сознательно
урезаем цветность. Я же этот вопрос досконально продумал - главное, что логику чтения
контроллером из видеопамяти менять не надо, просто в определенный момент происходит выбор
из двух пикселов. Читайте дальше, я там подробно объяснил схему "смешивания" экранов
и в SCF-mode, и в APA-mode.
SMT> а если поставить не 2 РУшки, а 3, то можно сделать палитру из 4096 цветов
' (4 независимых бита на каждую цветовую компоненту). только нужно 3 порта, поэтому
' ещё доп. мелкосхема типа 555ид7
Не нужно три порта, нужно сразу ориентироваться на два - выбор регистра и данные.
Потому что если мы хотим расширять "с малого", пусть даже пока в эмуляторе, потом портов
не напасешься. Насчет палитры - перечитай мое вложение. Если есть ЦАП с 4 битами на
цветосоставляющую, лучше уж сразу сделать 4096-цветный режим путем сложения данных
с двух APA-экранов - ведь все равно с каждого слоя читается по два байта.
А палитру тогда применять в 64-цветном "основном" APA-режиме
ТЕПЕРЬ ОТВЕТ НА ЗАГЛАВНЫЙ ВОПРОС SAM style:
Вот видишь, чтобы твой вариант "довести до ума", ВСЕ РАВНО надо добавлять и сквозную
запись в несколько слоев, и параллельную логику для стандартного режима, и ЦАП расширять...
Иначе режим только для рассматривания картинок и годится. А с другой стороны, если уж нам
все равно придется вносить столько доработок, использовать их только в одном режиме
- это как из пушки по воробьям, ведь их очень просто поставить на службу нескольким
режимам, добавив не так много железа в процентном отношении.
и отлаживать функциональные блоки схемы все равно можно будет по отдельности.
Понятно, обкатывая в эмуляторе, можно каждый режим отдельно проверять, но когда дело дойдет
до реализации в железе, мы уже должны иметь цельную схему, каждый узел которой
будет задействован "на полную катушку". И уже в этом варианте надо предусмотреть
возможность расширения в будущем - примерно то, о чем я писал - спрайтер, ускоритель...
P.S. Все-таки как хреново, несмотря на инет, что все спектрумисты разбросаны по разным
городам. Могли бы встретиться лично, уже давно бы "на пальцах" все объяснил. А представьте,
если бы мы, как требовал Nemo, переписывались по обычной почте! :sick:
Распределенные НИОКР, блин.
(на 27-10-2005)
SMT> ещё неясно, как суммируются фоновый/спрайтовый/вентильный экраны
madcore> А эту идею я вообще не понял...
Значит, так: представим, что на каждой битовой плоскости (линейке памяти) "сидит" некоторое
подобие ULA, точнее, ее кусок. Точно так же, как в стандартном видеорежиме, в цикле по
отображению строки читается по два байта - пикселы и атрибут - ПАРАЛЛЕЛЬНО ДЛЯ ТРЕХ
"ЭКРАНОВ" (плоскостей). (Я здесь скролл пока не учитываю, чтоб понятней было.)
Для вентильного экрана прочитанный байт "пикселов" сразу же складывается по and
с прочитанным байтом "атрибута" и еще инвертируется (not), если включен режим
"инверсия вентиля". Получили окончательный вариант вентильного байта.
Ну и теперь аналогичный ULA цикл по 8 битам, только сначала анализируем соответствующий
вентильный бит, и если он равен нулю, то в определении цвета используется одна пара
байт "пикселы-атрибут", а если единице - другая. Полученный номер цвета отправляется
в ЦАП и пиксел выводится на экран. То есть две "юлы" стараются, работают, каждая выдает
готовый пиксел, и вот тут вмешивается вентиль и решает, какой из них отправить
на экран в текущую позицию луча.
Пример: какое-то знакоместо, из "фона" (экран-1) прочитаны байт графики 01111100
и атрибут 00-000-111 (серый INK, черный PAPER), то есть в стандартном режиме видим
07777700. Из "спрайтовой" плоскости (экран-0) прочитаны байт графики 00001110 и
атрибут 00-010-110 (желтый INK, красный PAPER), то есть в стандартном режиме 22226662.
Из вентильной плоскости прочитан байт "пикселов" 11100011 и "атрибут" 11111111
при отключенной "инверсии вентиля", следовательно итоговый вентиль 11100011.
Что получим в SCF-mode в соответствующих восьми точках?
экран-0 - 22226662 - ---266--
вентиль - 11100011
экран-1 - 07777700 - 077---00
в результате имеем - 07726600
То есть вентильный экран с точки зрения программиста работает аналогично маске спрайта,
если "спрайтом" считать весь экран-0 (фоном, соответственно, экран-1). При адаптации
игрушек так и поступаем - печатаем те же самые спрайты в экран-0, а их маски - в
экран-1 - фон не портится. И это только один из вариантов - а еще можно испортить
фон (раз он в оригинале все равно восстанавливается), но получше раскрасить спрайт.
Как хотим, так и извращаемся.
Ну если и ЭТО непонятно, придется мне скриншоты драть и раскрашивать...
А в APA-mode все еще проще, там точно так же из каждого слоя читаются по два байта,
только второй не из области атрибутов, а по тому же адресу с другой страницы линейки
(например, если первый из адреса #4013, то второй из адреса #8013 - это именно внутренние
адреса видеопамяти). Дальше прогоняем аналогичный ULA цикл по восьми битам, получаем
два номера цвета и сравниваем один из них с "прозрачным" (с точки зрения железа проще,
если "прозрачными" цветами могут быть только 000000 и 111111 - проще проверять). Если
он непрозрачный, его и выводим, иначе другой (фоновый) берем.
Пример:
(Без палитры, по два бита на цветосоставляющую, то есть Gg, Rr, Bb. Специально взял
простые цвета, чтобы обозначать одной буквой, как на Спеке, а черный - прочерком)
страница> - 1-фон - 2-спрайты
слои
0 - b -- 00000000 - 01000000
1 - r '-- 00000000 - 01000000
2 - g -- 01000000 - 00000000
3 - B -- 00000000 - 00001000
4 - R -- 10000100 - 00001000
5 - G -- 10000000 - 00001000
цвета ` Yg---R-- ` -m--W---
допустим, прозрачный черный, тогда
---это будет фон `` Yg---R--
-----а это спрайт ` -m--W---
на экране увидим ` Ym--WR--
(на 27-10-2005)
Валера> ... такое нововведение позволило бы решить проблемы с клэшингом атрибутов во
' многих играх, где требуется плавный попиксельный (2-х, 3-х, 4-х пиксельный) скроллинг
' фона (к примеру, Ikari warrior, robocop 2, многие космические стрелялки).
SMT> трудно будет сделать в железе. гораздо проще иметь 2 3х-битных регистра сдвига всего
' изображения относительно центра экрана. таким образом, при пиксельном скролле, фон в
' памяти двигается раз в 8 пикселей (если использовать 2 экрана, можно вообще готовить
' сдвиг аж 8 кадров, не теряя плавности анимации). спрайты сдвигаются на каждом шаге,
' чтобы казалось, что они стоят на месте (их всё равно каждый игровой цикл обновлять,
' ради анимации или если под ними фон двигается)
Дело даже не в этом. Спрайты-то все равно клэшить будут, так что нужно два экрана.
Причем именно в SCF-mode теоретически можно сделать хоть циклический скролл экрана на
любую величину с перерисовкой только краев (понятное дело, такую штуку надо внимательно
программировать). Спрайты тогда можно и не сдвигать, хотя в действительности по логике
игры наверняка все равно придется.
А вот в APA-mode скорее всего возникнут проблемы (из-за схемы чтения "спрайтового" экрана).
И придется делать как советует SMT. Хотя фиг знает, может, с точки зрения схемотехники и
не такая это проблема - несинхронное чтение пары байт с фоновой и "спрайтовой" плоскостей
и их побитовая прогонка. А может, проблема даже и в SCF-mode.
(на 27-10-2005)
SMT> атрибуты описаны непонятно. что значит верхний/нижний...
То и значит. От "четвертушек" в чистом виде я решил отказаться, поскольку они требуют
чаще читать видеопамять при выводе строки, но их все еще можно имитировать, заполнив весь
вентильный экран байтом #F0 или #0F и включая режим одновременной записи в оба графических
экрана при выводе (только!) пикселов. Для этого требуется только аппаратно разбить атрибуты
по вертикали на две половинки (ну это как мультиколор, только с разрешением в четыре строки,
а не в одну). По умолчанию все как в Спектруме - один атрибут на знакоместо, но можно
включить учет нижней половины - элементарно. Ну и поскольку видеопамять все равно внешняя,
не нужны регистры-указатели областей атрибутов, как в первоначальной идее "четвертушек".
Все сидит так, как удобнее адресовать.
И еще замечание: если для пиксельной части видеопамяти удалось обойтись без сегментации,
то для атрибутов увы... два сегмента - иначе в 16К не влезало. Но все равно адресация
атрибутов проще, чем в стандартном режиме, и работать будет быстрее. Ну и конечно,
можно включить автоматичский пересчет адреса для совместимости.
SMT> для начала неплохо бы поинтересоваться, есть ли доступные чипы памяти с and/or/xor
' вместо put. я таких не видел. если нет, придётся отказаться
Я не знаю, может, уже и есть такие, но это не принципиально - читай доки по EGA (madcore,
очевидно, их читал). Там при обращении к плоскости байт копируется сначала в специальный
регистр-защелку, потом происходит and/or/xor с байтом, полученным от проца, и результат
записывается обратно в эту плоскость. Понятно, что требуется сначала чтение из памяти,
(и все равно так будет быстрее, чем вручную выполнять and/or/xor пусть даже с копией
видеопамяти в ОЗУ компа), кроме случая просто перезаписи (put). Но только-то put и важен
для совместимости по скорости со стандартным видеорежимом. Да и вообще, смотря какие
мелкосхемы взять - может, эта "медленная" операция все равно будет быстрее, чем z80
способен писать в память. Разве что когда-нибудь сделают Spectrum на 100+ MHz.
А доки эти EGAшные - просто ужас, лишнего до фига. Для 8-битных компов уж точно.
Так что просто копировать нет смысла, но вот кое-что взять можно.
SMT> imho больше возможностей, если задавать не яркость каждой цветовой плоскости, а по 4
' бита r,g,b каждого 4-х битного значения цвета. скажем, на экране могут быть одновременно
' ярко-зелёные и тёмно-зелёные цвета, что не сделаешь в твоём варианте
Сделаем 64 цвета и не будем фигней страдать!! Для игрушек этого за глаза хватит, а картинки
красивые или диффузией размывать, или добавить режим 4096 цветов, немного доработав логику
APA-mode. Ведь все равно ЦАП для палитры пришлось бы расширять...
SMT> а ты думал, как формируется бордюр на твоей карте? дублируется порт #FE или подаются
' rgb с оригинального порта бордюра (во втором случае zx-bus недостаточно)
Ориентируемся на ZX-bus! Не "доделка" же очередная планируется, а нормальная видеокарта.
Для полной совместимости достаточно дублирования порта #FE (трех бит из него вообще-то,
но можно предусмотреть дополнительно и BRIGHT, и вообще любой цвет).
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
ZX Ultimate Video specs v1.01
Вот, я перепаковал свое прошлое вложение и добавил туда файл для SMT с инструкциями
по реализации в эмуле своего варианта (в урезанном пока что виде) - "_emul1.txt".
Надеюсь, на той неделе я таки снесу вынь-98 и попробую сконвертить какую-нибудь игруху
под SCF-mode. А SAM style пускай тем временем на 64-цветный режим переучивается!
(Кстати, SMT, а чего мне ставить, win2k хватит, или уже XP необходим?)
(30-10-2005 вложение удалил, последняя версия дальше)
Последний раз редактировалось Lethargeek; 30.10.2005 в 15:50.
Я в своей песочнице, ты в своей.А SAM style пускай тем временем на 64-цветный режим переучивается!
Ittekimasu, чуваки. Как сделаю себе девайс на скорп - вернусь (может быть).
Все любят гипножабу
а на чём планируешь делать? альтера, микроконтроллер, или рассыпуха? схему SAM style я без труда представляю в железе, а вот твой режим сделаю, не раньше, чем схема будет. по виртуальным (например, 256-цветным) режимам, это Кладов специалист
p.s. с вентилем понял. а зачем ему атрибут? чтобы в 8 раз быстрее заполнить переход на один из экранов?
если хочешь полюбоваться на триколоры SAM style, 2000-й хватит
вот только воплощать в эмуляторе то что будет сотворено, я стану не раньше, чем появится софт, который это железо юзает и сам при том востребован (неважно, демы или игры). 256 я делал не на пустом месте. Хоть 12 игрушек но уже были.по виртуальным (например, 256-цветным) режимам, это Кладов специалист
Вообще-то если ставить вопрос как тут ставился (где-то в начале обсуждения), то нельзя вообще ничего делать НОВОГО. Надо лишь сделать так, чтобы тот софт, что уже есть, с МИНИМАЛЬНЫМИ изменениями (ИЛИ ВООБЩЕ БЕЗ ИЗМЕНЕНИЙ - этого не было, но об этом все подумали) шел в новом режиме и радовал глаз. Как минимум - отсутствием клэшинга.
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)
Ваши права
Ответить с цитированием
