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

[Dima Bystrov (2:5029/77.48)]

FromNet: Ryazan (Ryazan_Net)

Hello Дмитрий!

14 Oct 05 21:52, Дмитрий Малычев wrote to All:

(исключения крайне редки). AY-чип вообще следует считать частью
Спектрума (хоть его и "испанцы придумали")

dk'tronics в 1984 году продавала девайс с "popular AY-3-8912 sound chip",
правда, в рекламе (Crash 8 p.108) не написаны порты.

- A.Coder [Wolf3d2004 InfoGuide7 ACEdit96 ACN42 PT3695 Chip13 HexFill HDDoct6]
[Ansi04 8col12 ZXRar27UnR59 Jpg042 CacVox1 Dbs07 Gluk61R PC21 Alasm5.01 Sts70i]

... ZX Spectrum today

[Danil Davydov (2:5050/151.11)]

FromNet: Izhevsk_Russia (Kama_river_net)

Привет Дмитрий!

16 Окт 05 21:52, Дмитрий Малычев -> All:

И это вовсе не "нечто подобное" моему предложению. У меня большую
часть времени работы код будет обращаться к одному битплану, как и для
обычного видеорежима. И HИКАКИЕ АППАРАТHЫЕ УСКОРИТЕЛИ HЕ HУЖHЫ!

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

И так нужен, что ли, этот режим "каждая точка своим цветом"? Зачем?

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

Для хентаев всяких гигаскрина не хватает?

гигаскрин в топку.

Просто порисовать - так
есть ПЦ.

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

А софт писать исключительно под этот режим - то есть обычной
спековской версии уже не будет (сил не останется)? И по ходу освоения
наворота снова придется "изобретать велосипеды"...

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


С рулезами, Danil aka Merlin/ULG


 Ay_Emul: MT35 - 07-Watchin_Clouds
---

[Conan]

dk'tronics в 1984 году продавала девайс с "popular AY-3-8912 sound chip",
правда, в рекламе (Crash 8 p.108) не написаны порты.

А еще годом раньше был выпущен TS 2068. И кстати одно из производств Timex находилось в Португалии. А схема включения AY в ZX Spectrum 128 очень напоминает (объединение звуковых выходов и использование порта) схему TS 2068. Хотя и адресация портов отличается, команды бейсика для управления звуком в Timex и ZX, ну очень похожи.

P.S. Разыскать программное обеспечение поддерживающее DK'Tronics 3 Channel Sound Synthesiser мне не удалось, не говоря уже о том, что SRL не использовала решения сторонних производителей (вспомнить хотя бы KempstonJoystick), а вот Timexбыл партнером, тесно связанным в том числе и разработками.

[ASDT]

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

[icebear]

Думаю надо ориентироваться на программеров игр.
Что они считают нужным?

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

[Lethargeek]

SAM style> А уже полюбил - для твоей идеи надо сменить составление адреса при чтении
' байта атрибутов, причем для горизонтального деления бокса это очень легко (вплоть до
' мультиколора), а для вертикального - придется в 2 раза чаще читать память, а значит,
' отвлекаться от выполнения программы (это уже будет медленнее).

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


SAM style> велосипеды всегда приходится изобретать - без этого нет прогресса.
' Ты тоже свой маленький самокатик изобретаешь.

Я имел в виду - "изобретать велосипед" в смысле приемов программирования
того же самого, но на новом железе.


SAM style> Ты еще спрашивал, много ли надо на системной шине для видеокарты...

Это был полуриторический вопрос. Про шину SMT лучше меня объяснил...


SAM style> не надо на меня вешать ярлык главного производителя хентая на спеке - скоро завяжу

Все так говорят - завяжу, завяжу... а потом все равно "срываются"
А кроме шуток, я без всякой задней мысли упомянул, почему вдруг такая реакция?

[Advertiser]

[Lethargeek]

SMT> ну, для эмуля это легко пофиксить - где к битам не закреплены цвета,
' там атрибуты не игнорировать

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

А PAPER все равно ни на что не влияет - просто считается прозрачным, и все. А в том же
Thanatos, помимо всяких заливок, используется синий PAPER для земли и черный - для неба.
И нельзя эту проблему просто background-ом решить, потому что там еще и вода есть на
том же синем фоне - и тогда с цветами background-а не разгуляешься. Опять же, в других
игрушках смена цвета PAPER может чего-то важное означать.

Вот и выходит, что в общем случае игрушку надо сначала "монохромить",
(перепрограммировать), а уж потом раскрашивать.


SMT> ... в самопальный вставь ... и так ковыряю все время

Блин, да он же у меня 48-й, причем так написан, что практически надо все
переделывать. Меня от одной мысли плющит Это же не игрушку переделать,
здесь недостаточно поверхностно "влезть", надо кучу всего помнить. А времени нет.

Да и вообще, я уже свою идею переработал. Ищи ниже.


SMT> посмотрел только Leviathan, не понял, что нужно, если не chunk 2x2 (не о них же речь)

Ну если чанками считать, тогда 2x1 - ну как точки Атаривские... К тому же чанки
в UnrealSpeccy расплывчатые (и на весь экран), а здесь просто цвет получается по
двухбитному "номеру" (и для окна). А размытие можно потом и отдельно включить.

SMT> выложи скриншоты, тогда сразу станет ясно

На.
Spy vs Spy выглядит почти как оригинал, а над Flying Shark я просто от скуки изгалялся.
Поверь, в движении это выглядит гораздо лучше. И цвета можно поменять.
Обрати внимание, что накладывается не на весь экран, а только там, где это необходимо.
У меня-то окна определяются примитивно - ищу в строке атрибутной X повторяющихся байт,
потом смотрю, сколько вниз таких строк (должно быть больше, чем Y). На случай
перекрывающихся окон - заполняется типа "маска" знакоместная 32x24, и потом уже
в каких-то знакоместах байт "по-спековски" выводится, в каких-то "по-атаровски".
"Маску" можно в принципе и каким-нибудь алгоритмом заливки... Только медленно это

Ну и конечно, юзер может задать, для каких атрибутов искать окна, их размер, цвета
палитры четырехцветной, да и "маску" атрибутную вручную ввести, в конце концов.
Для простых случаев и автоматически неплохо работает.

[Lethargeek]

A.Coder> Это не игрушки, это вообще-то подпись ...

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


A.Coder> Hасчёт видеорежимов: ...bla-bla-bla...

Ага, и чтобы что-то быстро переслать на видюху, надо сначала это что-то быстро
считать из "памяти компьютера". А в 256 цветах это будет... ух!
И памяти еще надо... короче, наворачивайте сам комп, чтобы он потянул видеокарту.
Или тогда придется байт масштабировать в 8 с выбором цвета/цветов и переключаемой
прозрачностью (см. дальше). И либо цветность, либо скорость теряется

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

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

И вообще, я все уже переработал, и насчет состыковки с прочими режимами поразмышлял,
читай сразу ниже, короче.


A.Coder> Весь обсосанный комплекс идей уже был отослан CHRV,
' а сюда его кидать нет смысла. Кидалось тому, кто МОЖЕТ реализовать.

А чего он тогда так в v9990 вцепился? Или это оно и есть? Странно


A.Coder> dk'tronics в 1984 году продавала девайс с "popular AY-3-8912 sound chip"...

Так я же "испанцы придумали" в кавычки взял, типа цитата (выступал тут один товарищ)
- видимо, в смысле внутренней интеграции. А про Fuller box тот же, я думаю, все знают

[Lethargeek]

ВНИМАНИЕ! СЕНСАЦИЯ! ТОЛЬКО ДЛЯ ВАС!

...короче, встряхнулись и читаем "на понимание"

Вот сидел я и думал: если уж все равно реально что-то можно сделать только "снаружи",
может, ну их нафиг, стандартные спековские экраны со сложным анализом атрибутов? Да и
народ здесь в массе своей жить не может без всяких EGA-режимов, хотя я не представляю,
что они с ними делать будут. Мне же (ну и паре людей - из тех, кто высказался)
важнее совместимость (на уровне мышления прежде всего) и простота адаптации софта.
Ну ладно, сказал я себе, не буду подобно другим зацикливаться исключительно на своих
интересах, а проявлю гибкость и постараюсь угодить "и вашим, и нашим".

Короче, ниже даю сначала новый (творчески переработанный) вариант своей идеи, а затем
- пример ее интеграции в какой-нибудь "EGA/VGA-режимный" мегадевайс. И не просто путем
примитивного "приклеивания" одного к другому, а так, чтобы эти режимы не только не
конфликтовали, но и работали друг на друга.

(Кстати, что в старом, что в этом варианте субъективно получится не два плана, а три
- уж передний-то план без клэшинга имитировать на Спеке давным-давно научились. )

[Lethargeek]

Так вот, оставив пока в стороне всякие атрибутные четвертушки (для простоты изложения),
спросим себя: в чем заключалась (в двух словах) моя первоначальная идея избавления от
надоевшего "клэшинга"? Фактически, в ВЫБОРЕ по ходу луча следующего отображаемого пиксела
из одного или другого стандартного спековского экрана. Причем этот выбор осуществлялся
путем сравнительно сложного анализа значения атрибута, требовал жесткой специализации
экранов и позволял в конечном итоге иметь только три цвета на знакоместо.

Но тогда я еще имел в виду возможность "внутренней" реализации наворота (даже, возможно,
полной замены существующей схемы формирования видеосигнала), что предъявляло повышенные
требования к программной совместимости самой модели со стандартным видеорежимом.
Реализация в виде внешней видеокарты эти ограничения снимает.

(Далее везде "видеопамять" означает именно память, расположенную на внешней видеокарте!)

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

Значения битов "вентильного" экрана и определяют, с какого из двух графических экранов
будет отображаться следующий пиксел. Практически можно считать, что в "вентильный" экран
будет печататься маска спрайта, а фон теперь не портится вообще.

Больше того, теперь некорректно даже называть графические экраны "фоновым" и "спрайтовым",
фактически они равноправны, просто "маска" для одного - это нули, а для другого - единицы
(но и это можно подправить - см. ниже).


ПЛЮСЫ:

- Совместимость с оригиналом полная - все атрибуты работают
' точно так же - даже спрайты смогут flash-ем мигать
- "Cпрайты" будут изначально двухцветные, то есть теперь имеем четыре
' независимых (а не как в Gigascreen!) цвета на знакоместо;
- "Фон" не портится - соответственно реальная скорость графики выше
' (и программный скролл "фона" без проблем!);
- Не надо сложную логику паять (и придумывать)

МИНУСЫ:

- Нужно больше памяти на видеокарте (уж такая ли это прблема?);
- В рабочем цикле надо уже из трех линеек памяти читать (это уже серьезнее);
- Полностью "прозрачно" уже не получится, понадобится порт управления;
- Еще страница собственно спековской памяти под третий экран нужна

Попытаюсь избавиться от последних минусов (или хотя бы обнаружить в них плюсы)


"Отвязавшись" от стандартных спековских экранов (то есть страниц 5 и 7), сразу возникает
мысль повесить отображаемое пространство на адрес #C000 (то есть куда на 128-х стандартно
впечатываются страницы), что позволит без проблем использовать любые страницы расширенной
памяти под копию видеопамяти. При этом видеокарте пофиг, по какому стандарту реализована
эта самая расширенная память и каким портом она переключается - просто копируется все,
что проц пишет в память в адреса #C000-#FFFF. Ну и конечно, заполнение видеопамяти можно
будет запрещать, если мы просто хотим записать данные в какую-то другую страницу.

Но останется та же проблема, что и на обычном Sp-128 - впечатана может быть только одна
страница дополнительного ОЗУ, что и мешает ему эффективно использовать второй экран, если
графики много и она тоже расположена в расширенной памяти. Да и при адаптации фирменных
игрушек, чтобы не перетряхивать распределение памяти, надо использовать стандартный экран.
И вообще, пусть видеопамять можно будет отображать на любой 16-киловый участок обычного
ОЗУ, то есть #4000-#7FFF, #8000-#BFFF, ну и #С000-#FFFF. Кроме того, бывают ситуации,
когда копия страницы видеопамяти не нужна - например, один раз вывели неподвижный фон,
и больше он никак не меняется (кроме как полностью на другой фон). То есть читать его
незачем, а хранить "мертвую" страницу - расточительно. Поэтому видеопамять надо отображать
и на адрес #0000 (в ПЗУ то есть). И спокойно "писать" туда все, что угодно, не потратив
ни байта спековского ОЗУ. При этом запрет заполнения видеопамяти по этим адресам тоже
надо предусмотреть, так как многие программы пытаются мусорить в ПЗУ (да что там, даже
Basic-48 пишет туда, по крайней мере в ПЗУ Турбо-90 так и было).

Для адаптации большинства фирменных игрушек этого достаточно, так как они решают те же
проблемы с переключением страниц (а для 48-х версий все еще проще). А вот для нового
(или радикально переписанного старого ) софта возникают любопытные варианты...
Например, такой трюк: имеем в ОЗУ копию фона, выведенного в видеопамять. Потом читаем
его оттуда, и, сдвигая на 4 пиксела при помощи команд rld/rrd, снова пишем в видеопамять,
только теперь уже через ПЗУ - это будет "медленный кадр", причем копия фона в ОЗУ осталась
нетронутой. Следующий - "быстрый кадр" - уже обычный побайтоваый сдвиг фона в ОЗУ и
видеопамяти одновременно, с заполнением края экрана. Причем всю остальную логику работы
программы (вывод спрайтов, обсчет препятствий...) можно повесить на "быстрый кадр".


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


Теперь посмотрим, хватит ли одного порта для управления устройством. Требуется:
1 бит -- инверсия вентиля (то есть байт, прочитанный логикой из "вентильного" экрана,
' инвертируется операцией not) - необходимо для полного равноправия графических экранов.
3 бита - запрет/разрешение заполнения соответствующих страниц видеопамяти
4 бита - запрет/разрешение заполнения с адресов #0000 (ПЗУ), #4000, #8000, #C000

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

Не знаю, как удобней, и нужен ли вообще этот свободный бит. Может, и ему найдется
применение, если я чего проглядел...

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

Кое-какие размышления на эту тему читайте в следующем сообщении.

...ау, любители EGA-режимов! вам это интересно?