Идея простого расширения стандартного видорежима [Архив] - Speccy

Lethargeek

08.09.2005, 18:21

ВНИМАНИЕ! СЛЕДУЮЩИЕ ИДЕИ СЧИТАТЬ УСТАРЕВШИМИ. НОВЫЙ
ВАРИАНТ ИСКАТЬ НА СТР. 14-15 ПОД ЗАГОЛОВКОМ "NEW SCF-MODE"

А ЕЩЕ ДАЛЬШЕ ИСКАТЬ ПОСЛЕДНЕЕ ВЛОЖЕНИЕ С ОРИЕНТИРОВОЧНЫМИ
СПЕЦИФИКАЦИЯМИ ВИДЕОКАРТЫ.

ВCТУПЛЕНИЕ

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

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

Нет, что-то уже появлялось, какие-то режимы делались новые (каждый производитель
так и норовил выдумать свой вариант) - высокое разрешение, EGA-режим (на 32 кб!),
мультиколор аппаратный (от которого проку нуль), гигаскрин (который и не видеорежим
вовсе, а так, хитрость); даже целый Денди запихивали в несчастный Спек. В сети
иногда на такое наткнешься - народ мечтает о Truecolor'е и 3D-ускорителях! Нда.

Не хочу сказать, что все реализованные идеи так уж плохи. Только выглядит все это
как-то уж совсем инородно, к собственно Спектруму никаким боком. Расширенные экраны
или совсем по-другому устроены, или для телевизора не годятся, или еще что. Причем
отношение производителя/автора приблизительно такое: ну вот же есть режим без всяких
там ограничений, которые так напрягали раньше - чего вам еще нужно? А почти весь
софт так и пишут под "голый" 128-й Пентагон. Ну под GS там еще. Ну память лишнюю
используют иногда. Но другие видеорежимы - неееет!

Есть, конечно, какие-то программы. Системные. Или вообще под CP/M. И для чего они?
Для профессионального применения? Еще кто-то профессионально юзает Спек? Флаг им в
руки, конечно, но все же знают, что для подавляющего большинства Спек уже только
хобби и не более того. 90% нового софта - демы и игрушки (если не считать новым
софтом очередную 'надцатую версию асма или редактора) - которые пишутся под тот же
"голый" 128-й с тем же экраном. И никто их переделывать не будет, и так рады, что
закончили. Ну разве что поддержку GS добавят.

У меня Спека живого нет. Но вот тут слухи ходят, что новые модели Спеклонов все
еще разрабатываются и даже планируется их выпускать. И видеорежимы дополнительные
в них, наверное, будут. Такие же от Спека далекие.

В связи с этим не могу молчать!! ;)

И главное, что хочу сказать: Спектрум сейчас нуждается в улучшении именно обычного,
всем до боли знакомого видеорежима, причем в улучшении, логически вытекающем из
уже давно существующей стандартной архитектуры. Ничего не имею против реализации
нестандартных "профессиональных" видеорежимов, но говорить о том, что они РЕШАЮТ
графические проблемы СПЕКТРУМА - неправильно.

Попробую сформулировать основные требования к новому прибамбасу:

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

2) (Скорее первое). Все это дело должно бать поддержано софтом, иначе какой смысл.
Софта есс-но нет. Писать софт трудно, лениво и неблагодарно. Значит, надо сделать
так, чтобы писать было как можно легче (а в особенности переделывать, что все же
проще - иначе не было бы на Спеке такого количества конверсий).

3) (Снова скорее первое ;) Минимальная несовместимость со стандартной машионй.
Пусть даже со стандартным клоном.

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

1. УВЕЛИЧЕНИЕ ЦВЕТОВОГО РАЗРЕШЕНИЯ

Небось, все помнят игрушки с атрибутно-красочной графикой вроде Savage, Extreme,
Dan Dare 3, Shadow Warriors... Astro Marine Corps - самый яркий пример. Вот чего
можно добиться, с умом распорядившись ограниченными цветовыми возможностями
стандартного экрана! Но все-таки заметно, что спрайты довольно-таки угловатые
(и слишком большие), а анимация дерганая.

Вот если бы увеличить цветовое разрешение в два раза (то есть поделить знакоместо
на четвертушки - и для каждой свой атрибут) - качество картинки сразу резко
улучшится, угловатость практически сойдет на нет, мелкие спрайты можно раскрасить.
И чанки цветные сделать! => и видеоролики типа Worms c удвоенным разрешением.

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

Понятно, что понадобится больше видеопамяти (ровно 9 килобайт на весь экран); и
залезет он на область системных переменных и Васика. Этого можно избежать, если
использовать этот режим только для дополнительного экрана на 7 странице. Хотя
вообще-то безобразие - ULA для разных экранов в разном режиме должна работать,
что ли (и возможно ли это)? А если они переключаются на разных там моргалках?
Мы пойдем другим путем.

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

Комбинация атрибутных областей может быть любая:
11 12 11 12 12
11 12 22 31 34
(соответственно стандартный атрибут; поделенный по вертикали - для мелкого шрифта;
поделенный по горизонтали - для вертикальных скроллеров; извращенный вариант -
например, у буквы левый нижний угол темнее, а правый верхний бликует; полностью
расчетверенный атрибут). Это и по памяти дает экономию, если что-то излишне. Можно
и совсем уж сэкономить: читать атрибуты из третьего сегмента экрана, а его забить
цветом бордюра. Получаем ужатый экран с улучшенной цветностью - всего 7 кб).

Почему указатели только в пределах страницы? Чтобы можно было их использовать и для
второго экрана (с поправкой на страницу); да и регистров лучше все-таки поменьше
иметь. А если располагать их только по ровным (кратным 256) адресам, то можно вообще
обойтись одним 8-разрядным портом (то есть посылаем байт, в котором 2 бита - номер
четверти, а 6 бит - номер 256-байтного куска - как раз 16 килобайт получается).

Правда, Васик пострадает, ну да фиг с ним - если уж так приперло использовать все
это из Васика, в крайнем случае можно загнать атрибуты в REM-строку).

Lethargeek

08.09.2005, 18:22

2. "ФОНОВЫЙ" И "ПРОЗРАЧНЫЙ" ЭКРАНЫ

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

Над FLASH'ем уже не раз издевались пытливые синклеристы - достаточно вспомнить так
называемые "доработки" FLASH-color и BRIGHT2. Все это не было стандартизовано,
по-разному переключалось (а то и вообще не переключалось), а толку было немного.
Все-таки действовать надо осторожнее, и обязательно с оглядкой на существующий софт.

Что если второй экран сделать фоном, а основной - чем-то вроде прозрачной пленки, на
которой будут изображаться "спрайты" (так раньше мультфильмы делали). Теперь бит
FLASH будет обозначать прозрачность PAPER в данном знакоместе. На самом деле FLASH
можно оставить почти как есть, что хорошо для старых программ, а для наших целей
использовать только "бессмысленные" значения атрибута, у которых при включенном FLASH
INK=PAPER. То есть в этом случае для каждого байта графики нулевые биты - прозрачные
(отображается фон), а единичные - этот самый цвет INK=PAPER. Особый случай - когда
FLASH=1, BRIGHT=1, INK=PAPER=0 (то есть "ярко-черный" цвет) - здесь лучше считать все
знакоместо прозрачным, чтобы спрайты не стирать ручками, тратя время. А при запуске
старых программ в 99% случаев ничего и заметно не будет, даже если этот режим вообще
не выключается.

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

Вспомним также, что признак FLASH использовался разве что в старых "48-киловых"
программах, а на втором экране и подавно оказался не нужен (лично я видел только
одну интру, где FLASH мешался на фоне multicolor'ной картинки). На втором экране
FLASH заменим на упомянутый BRIGHT2 - для плотно закрашенного ФОНА это важно.
Здесь есть нюанс - если считать, что FLASH (теперь BRIGHT2) и простой BRIGHT,
равные 0, означают пониженную яркость, а 1 - повышенную, то можно использовать
ранее невидимый "ярко-черный" цвет, но совместимость со старым софтом пострадает.
Иначе лучше считать, что BRIGHT2=1 означает, что яркость PAPER НЕ СОВПАДАЕТ с
яркостью INK, равной обычному BRIGHT.

Очень легко сделать быстрый знакоместный скролл (и вертикальный, и горизонтальный)
всем известными методами извращений со стеком - спрайты-то стирать не надо. Даешь
фреймовые скрольные игрушки на Спеке! Да и плавно тоже прокручивать будет проще.

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

3. СОВМЕСТНОЕ ИСПОЛЬЗОВАНИЕ

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

Совместимость с 48-киловыми программами почти 100%. Всякие X-колоры/моргалки и
прочие гигаскрины как работали, так и будут работать. Если крайне редко и будут
наблюдаться мелкие глюки, так только графические, а не программные. Но главное!
Уже существующий софт (игрушки прежде всего ;) очень легко переделывается под новые
возможности (48-е - вообще элементарно для тех, кто ломать умеет, большинство
изначально 128-х - тоже). Я уж не говорю, что если кто-нибудь что-то новое пишет,
то очень легко сделать сразу две версии - обычную 128-ю и расширенную. Так что
без софта данные примочки, будь они реализованы в железе, точно не останутся - уж
курочить игрушки у нас в стране научились давно, почему бы и не сделать что-то
более полезное, нежели всякие интры для дисковок и cheats. Да и чего ждать-то?
Почему бы не...

ЭМУЛЯЦИЯ

...встроить поддержку вышеописанного (надеюсь, не полного ;) бреда в эмулятор?
Глядишь, и софт появится раньше, чем железяка. Я понимаю, конечно, что матерый
спектрумист ехидно ухмыльнется на эти слова, дескать, этот софт будет не под
железо, а под конкретные глюки конкретного эмулятора. С учетверенными атрибутами
оно может и так, но если предположить, что включаться будет через один порт
уже описанным способом, то потом софт легко исправить. Хотя, конечно, невредно бы
сначала выслушать мнение товарищей железячников - как бы оно могло быть реализовано.
А вот насчет фона со спрайтами - ну какие там могут быть глюки? Прога будет просто
подразумевать, что "бессмысленные" атрибуты с включенным FLASH работают именно
таким образом, и что этот режим в момент загрузки включен (если он даже навечно
включен - большой беды не будет). Особо мнительные могут пока не трогать BRIGHT2.
Я же говорю, основная идея была - простота написания и переделки софта.

Засим заканчиваю (наконец-то!). Благодарю нашедших в себе силы дочитать до конца.
Буду очень рад увидетьть серьезные отклики и мнения профессионалов. Только ногами
сразу не бейте. :)

fan

09.09.2005, 17:53

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

1) Максимальный эффект при минимуме изменений. Как завещал дедушка Синклер - все
должно быть дешево и сердито.
Как раз все нынешние видео режимы и вышли из "дешево и сердито"...
(и кстати из всего написаного мне представилась ечередная кучка мелкосхем ;) )

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

Короче - не вижу смысла в рассыпушной реализации видео режимов, "даёшь однокристалки!". Собсно нынче есть достаточно много линеек однокристалок совместимых с предшественниками (внутри своей линейки). Остаётся выбрать конкретную разновидность. Собсно почему именно однокристалки - потому что лучше оставить поле для свободного творчества , чем нагородить очередную тучу нафиг нужных видео режимов. ИМХО оптимальный выбор для извращений MCS-51 (практически такойже стандарт как Z80 в сваей области), к тому же присутствует в виртуальном виде (можно круто разогнать).

PheeL

09.09.2005, 20:18

ASDT

09.09.2005, 20:44

"свои 5 копеек" :)
Я ещё толком не обумывал эту тему, но расширение
до вга-свга имеет смысл с применением внешних (иса) видеокарт.
Их цена - 0, только надо продумать интерфейс.

fan

10.09.2005, 00:47

Я таки вставлю свои 5 копеек. Моя ИМХА такова, что лучший Спек с расширенной графикой - это Sam Coupe. Не поленитесь, скачайте эмуль и посмотрите демки той же ESI, например. Я считаю, что это лучше чем MSX.
Ещё бы не лучше , каждая точка своим цветом ;) Но насколько я помню в качестве видео контроллера используется спец мелкосхема которую фиг повториш (хотя если есть эмуляторы и исходники кним, то и этот чип вполне реально "запихнуть в матрицу"). Кто возьмёт флаг в руки? :D

Кстати ктонить знает сайт где есть крупные фотки платы и схемки сэма ? (на одном нашёл, но блин все переглюченные...)

Shaos

10.09.2005, 05:47

Я таки вставлю свои 5 копеек. Моя ИМХА такова, что лучший Спек с расширенной графикой - это Sam Coupe. Не поленитесь, скачайте эмуль и посмотрите демки той же ESI, например. Я считаю, что это лучше чем MSX.

Ну вабчета лучший спек с расширенной графикой - это Спринтер :rolleyes:

А по поводу четвертушек в знакоместе - уж лучше делить на "восьмушки", т.е. горизонтальные блоки по 8 пикселов, которые имеют цветовой описатель в 1 байт - 4 бита соответствуют биту 0 и 4 соответствуют биту 1 - ну то есть как в компьютере "Орион" :smile:

Vladimir Kladov

11.09.2005, 18:49

Мое мнение такое что нафиг не надо ничего делить ни на восьмушки ни на четвертушки, а лучший способ избежать клэшинга причем дешевый и сердитый - это 2 или 3 экрана, и для каждого - свое собственное смещение в пикселах по x и y. 0-й экран перекрывается 1-м, 0-й и 1-й - 2-ым, и т.д. Тогда прокрутку или к примеру движение заднего плана (когда игровой объект все время в центре экрана, а движется фон) можно выполнять одной командой вывода в порт, и даже герцов добавлять не надо. И наоборот, можно чуть сдвигать экран со спрайтами, если используется неподвижная комната и движущиеся по нему спрайты. Я впрочем уже говорил об этом в этом форуме, вспоминая Ямаху. В идеале - один экран, и "массив спрайтов", в порядке Z-order.

SMT

11.09.2005, 21:09

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

CHRV

11.09.2005, 23:44

Ребята уже делался СПринтер у которыго было все практически что тут написано - токо где он сейчас?
Так что не надо писать бестолковые спецификации - реализовано всеравно не будет!

Ronin

12.09.2005, 10:30

а из ямахи нельзя открутить видеопроцессор
не, он туда запаян - нужен паяльник ;)

Ronin

12.09.2005, 17:54

Вообщето у меня сейчас есть пяток видеопроцессоров V9990, осталось за малом заняться ими .
а че молчишь что они уже пришли :)

CHRV

12.09.2005, 19:07

а че молчишь что они уже пришли :)
СЕгодня приехали!

Lethargeek

16.09.2005, 18:36

Наконец-то (14.09) выбрался в i-net поглядеть на реакцию народа на свой пост - и что я вижу?
Полтора ответа по существу (thanx, fan!), остальное - оффтопик или выдержки из общей теории
монстростроения. Ужасть! То ли ничего не поняли, то ли до конца не дочитали...

Вот например:

Shaos> "...А по поводу четвертушек в знакоместе - уж лучше делить на "восьмушки", т.е.
горизонтальные блоки по 8 пикселов, которые имеют цветовой описатель в 1 байт
- 4 бита соответствуют биту 0 и 4 соответствуют биту 1 - ну то есть как
в компьютере "Орион"

Так это же обычный hardware multicolor :( Как я уже говорил, толку с него нуль, тот же
клэшинг, только "сплюснутый по горизонтали". Почти так же заметно будет.

Vladimir Kladov> "...нафиг не надо ничего делить ни на восьмушки ни на четвертушки,
а лучший способ избежать клэшинга причем дешевый и сердитый - это 2 или
3 экрана, и для каждого - свое собственное смещение в пикселах по x и y.
0-й экран перекрывается 1-м, 0-й и 1-й - 2-ым, и т.д."

Блин, я же ровно это самое и писал во второй части (про два экрана).
А четвертушки - это не совсем способ избежать клэшинга, это "параллельный" режим, то есть:
1) цветные чанки (=> и видеоролики не такие "квадратные")
2) прилично раскрашенные спрайты, а во многих случаях - способ избежать порчи фона
печатанием на нем маски спрайта, т.к. его "сердцевину" можно сделать непрозрачной
(двухцветной), а для краев маска не нужна.
...и с перекрывающимися экранами прекрасно сочетается.

CHRV> "Ребята уже делался Спринтер у которыго было все практически что тут написано
- токо где он сейчас? ..."

Вовсе НЕ ТО, ЧТО ТУТ НАПИСАНО, было на Спринтере. Там совершенно другая раскладка
видеопамяти, очень навороченная (и не битплановая!). И, как следствие, тормоза без турбы.

PheeL> "...лучший Спек с расширенной графикой - это Sam Coupe."

Sam Coupe - это не Спек с расширенной графикой, а совсем другой компьютер с довольно
кривой (судя по буржуйским воспоминаниям) аппаратной эмуляцией ZX. Да и графика там
"расширена" скорее, по типу 8-битной Atari (своя палитра из 4/16 цветов из 128 для каждой
пиксельной строки, насколько я знаю) Может, даже примитивней, чем на Atari - там в каждой
строке мог быть свой видеорежим (в том числе текстовый), правда, только по 4 цвета из 128
и low-res (ну еще и спрайты аппаратные), конец 70-х все-таки.

SMT> "а из ямахи нельзя открутить видеопроцессор? ..."

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

И как апофигей всего:

ASDT> "...но расширение до вга-свга имеет смысл с применением внешних (иса) видеокарт."

Нет слов. Я плакал.

(Занавес)

Lethargeek

16.09.2005, 18:38

Теперь серьезно. Я понимаю, что здесь все матерые спектрумисты собрались, которым просто
интересно друг с другом общаться, и им давно все ясно и понятно по всем вопросам, а посты
они читают "по диагонали", особенно не вникая (все равно junior member ерунду напишет). Но
все-таки постарайтесь дальнейшее прочитать внимательно и до конца, а? (Заранее благодарен)

Напомню, название темы - "Идея ПРОСТОГО расширения СТАНДАРТНОГО видеорежима"

Повторяю ключевые слова: "ПРОСТОЙ" и "СТАНДАРТНЫЙ". Ну почему, когда синклерист начинает
задумываться об улучшении графики, все сводится к лозунгу "побольше аппаратных наворотов,
цветов и пикселей"? Какой-то вульгарно-математический подход к проблеме. Ясно же, что

(много цветов + много пикселей) / (мало мегагерц) = (тормоза страшные)

Правильный лозунг такой: "поменьше изменений, но чтоб стало наконец нормально и красиво".
(А тут прямо - VGA, SVGA. Хорошо хоть не True Color.)

В общем, на любые умеренные разумные предложения ответ сногсшибательный:
"А ВОТ ТАКОЙ-ТО НАВОРОТИСТЫЙ НАВОРОТ Л-У-Ч-Ш-Е!!!"

Да кто спорит-то? Конечно, лучше - АБСТРАКТНО лучше. Ямаха лучше Спека, SVGA лучше
Ямахи, GeForce лучше, чем SVGA... (что там еще?) Сразу представляю себе велосипед,
к которому присобачен реактивный двигатель - то-то зверь-машина была бы! Get real, men!!

Прекрасно, если спрайты аппаратные, плавная прокрутка, палитра и т.д. и т.п. Прекрасно,
но ПОЗДНО. Спектрум сейчас - только хобби.

И для него все еще создаются энтузиастами новые железки. Только вот какие? Ага, для винта
интерфейсы, метр памяти, звук улучшают, ось очередная под это дело... В итоге получится,
может быть, отличная машина, но снова - с убогой стандартной графикой. Хотя нет, возможно,
будет еще какой-то очередной сто первый "профессиональный" видеорежим, никакого отношения
к СПЕКТРУМУ не имеющий, и который благополучно проигнорируют (как и все предыдущие попытки).

Никто из вас не задумывался, почему из всех реально существовавших графических примочек и
наворотов (FLASH-color, Hardware multicolor, Gigascreen, Bright2, Widescreen) только
под Gigascreen существует хоть какой-то софт (то есть демы и игры)?

Потому что:
1) Визуальный эффект действительно неплохой и КАЧЕСТВЕННО отличный
2) Полная "совместимость" с базовой 128-й машиной. Даже если нет железки (очень простой),
можно программно имитировать, пусть с мерцанием, но программа БУДЕТ РАБОТАТЬ.
3) Собственно кодить под гигаскрин легко. Те же два до боли знакомых экрана, только
используемых совместно. А то, что просто сделать - будет сделано! И это главное ;)

Поясняю на примере:

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

И результат - продуманно, интересно, но графика... не Ямаха, одним словом. Нет, красиво,
но технически - начало 80-х. Все друг об друга красится, плохо видно и сильно раздражает.
Зря, что ли, фон делал? То ли вообще его убрать, то ли все в монохром...

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

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

Подобным же образом фирменный софт ЛЕГКО переделать, серьезно повысив качество. А что?
Ведь кучу игрушек наши люди дисковали, переводили, исправляли, дорабатывали. Даже под
General Sound переделывали - а ведь это наверняка было сложнее. Команда маньяков нужна?
Обычные синклеристы (даже одиночки), которые не разучились делать все то, что раньше
они могли делать "левой ногой". И в эмуле желательно предварительно обкатать.

Пока все.

P.S. Оперативно отвечать не могу, т.к. нет домашнего интернета (читаю и пишу ответы
в офлайне - потом SaaB кидает, или в салоне за отдельные бабки). Но забрасывать эту тему не
собираюсь, пока не добьюсь внятной реакции от знающих людей - так что плиз, проверяйте
тему время от времени. Только не снова надо мне объяснять, как оно должно быть "в идеале".
А то я не знаю - как оно должно быть "в идеале"!
Спектрум, слава богу, никогда идеальным компом не был и не будет.
Феномен Спектрума - это СОФТ, а не матчасть, которая у него с самого начала была смешной.
Поэтому все графические навороты должны делаться так, чтобы прежде всего было УДОБНО
ПРОГРАМЕРУ, который "всю жисть" как кодил ИМЕННО ПОД СТАНДАРТНЫЙ режим, так и будет это
делать в дальнейшем.

Хоть кто-нибудь это поймет наконец?

CHRV

16.09.2005, 19:12

И для него все еще создаются энтузиастами новые железки. Только вот какие? Ага, для винта
интерфейсы, метр памяти, звук улучшают, ось очередная под это дело... В итоге получится,
может быть, отличная машина, но снова - с убогой стандартной графикой. Хотя нет, возможно,
будет еще какой-то очередной сто первый "профессиональный" видеорежим, никакого отношения
к СПЕКТРУМУ не имеющий, и который благополучно проигнорируют (как и все предыдущие попытки).

СМотри внимательно спецификацию АТМ, увидишь несколько видеорежимов :). Я вот тоже думаю что их так все игнорируют, изобретают все чегото :).

Никто из вас не задумывался, почему из всех реально существовавших графических примочек и
наворотов (FLASH-color, Hardware multicolor, Gigascreen, Bright2, Widescreen) только
под Gigascreen существует хоть какой-то софт (то есть демы и игры)?
Больше десятка под расширенные режимы АТМ, столько же под Спринтер.

Хоть кто-нибудь это поймет наконец?
Да понимаем токо не нужно никому это к сожалению.

SAM style

16.09.2005, 19:27

Из СТАНДАРТНОГО режима сложно выжать больше чем я выжал в nocturne - сделалось практически все, чего чел так хочет плюс чередование строк экранов (но последнее сильно зависит от компа)

Наложением 2х экранов друг на друга можно получить 4 цвета на знакоместо, но не любых: один будет черным, а другой - результатом сложения первого цвета со вторым.

rajdee

16.09.2005, 21:27

Вообщето у меня сейчас есть пяток видеопроцессоров V9990, осталось за малом заняться ими :).
Даешь gfx9000 на speccy ;)

CHRV

16.09.2005, 21:37

Даешь gfx9000 на speccy ;)
Пока идея следующая повесить его на порты и дать возможность программно переключать выход, т.е. вывод идет или с видеопроцессора или со стандартного выхода.
Плату сделать в ZX-BUS и на плате реализовать RGBS вход и RGBS выход.
Вот только осталось найти небольшое количество свободных портов :).

Ronin

17.09.2005, 11:17

Хоть кто-нибудь это поймет наконец?
ты сам НЕПРАВИЛЬНО понимаешь ПРОБЛЕМЫ Спектрума. это мысли образца 95-98г.
Пойми, твои разрешения 1. требуют аппаратного вмешательства
2. требуют новый софт
3. их "стандартность" - 0!!! работающих экземпляров.
4. вся твоя простота в свете этих пунктов НЕВАЖНА!!!
5. любые другие режимы - Спринтера, АТМ, Профи - БОЛЕЕ СТАНДАРТНЫ чем твой потому что они ХОТЯ БЫ РЕАЛИЗОВАНЫ.
6. ну возьми И РЕАЛИЗУЙ САМ - сделай Спекктрум с ними, наладь производство, напиши софт - покажи пример! вот на этом пункте все изобретатели начинают лепить отмазки, я начинающий, не железячник - вот вы умные возьмите и сделайте (за свои деньги) что я хочу. И не слушают когда эти умные говорят - это не нужно.

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

и насчет прикручивания - тогда откручивай дисковод, винт - это все от ПЦ, AY, 128к - испанцы какието выдумали, EGA монитор - тоже от ПЦ...

DVS

17.09.2005, 18:21

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

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

Lethargeek

17.09.2005, 20:45

Все ты правильно понял, DVS. (ну хоть кто-то!)

Остальным подробно отвечу завтра (салон, блин, закрывается).

CHRV

17.09.2005, 22:08

Все ты правильно понял, DVS. (ну хоть кто-то!)

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

ПОэтому предлагая реализацию, готовся к тому что кроме тебя ее реализовывать мало кто будет (DVS кстати об этом очень хорошо знает). ;) .

А нас железянчиков понять очень легко - просто дофига всего хотят, но нифига никто ничего не покупает. А работать чисто для себя - так у меня Спринтер есть, мне под него программить больше нравится чем под мифическую железку.

DVS

18.09.2005, 09:58

А работать чисто для себя...
Вот автор и предлагает поработать для себя тем у кого напряг с идеями :-)

Поэтому предлагая реализацию, готовся к тому что кроме тебя ее реализовывать мало кто будет

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

CHRV

18.09.2005, 17:27

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

Lethargeek

18.09.2005, 20:24

Отвечаю на вчерашнее:

Ronin> "ты сам НЕПРАВИЛЬНО понимаешь ПРОБЛЕМЫ Спектрума..."

А кто их все правильно понимает, у Спектрума в целом проблем выше крыши. Зато я прекрасно
понимаю одни, отдельно взятые проблемы и недостатки ИСПОЛЬЗОВАНИЯ СТАНДАРТНОГО ВИДЕОРЕЖИМА
для программирования динамической графики. А под стандартный видеорежим (даже больше - под
базовый 128k клон) делалось, делается и, видимо, будет продолжать делаться почти все, что...
ээээ... еще ДЕЛАЕТСЯ!

Ronin> "...это мысли образца 95-98г."

Ты меня убил наповал ;) А я-то, наивный, надеялся, что это мысли образца 1985 года! Я так
думаю, все это могло было (и должно было) быть реализовано сразу на Spectrum-128 еще тогда.
И не спорили бы сейчас, а кому оно надо, те спокойно занимались бы монстростроением.

Ronin> "Пойми, твои разрешения 1. требуют аппаратного вмешательства..."

Еще бы не требовали! А что их не требует? Это только гигаскрин можно программно
имитировать, и то - не на телеке довольно погано выглядит.

Ronin> "... 2. требуют новый софт..."

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

Ronin> "... 3. их "стандартность" - 0!!! работающих экземпляров."

Мимо.
Во-первых, я же не предлагаю совершенно новый навороченный супер-пупер видеорежим,
которому "суждено сделаться стандартом". Еще раз перечитай название темы:
"Идея простого РАСШИРЕНИЯ СТАНДАРТНОГО ВИДЕОРЕЖИМА". Это видеорежим стандартный, а
не предлагаемые расширения. Они-то "стандартны" только в смысле распределения памяти,
адресации, вообще общих навыков кодинга именно под Спектрум. Во-вторых... смотри ниже.

Ronin> "... 4. вся твоя простота в свете этих пунктов НЕВАЖНА!!!"

В свете моих ответов на пункты 1-3 этот пункт отпадает :)

Ronin> "5. любые другие режимы - Спринтера, АТМ, Профи - БОЛЕЕ СТАНДАРТНЫ чем твой
` потому что они ХОТЯ БЫ РЕАЛИЗОВАНЫ."

Я еще помню, как раньше говорили, что СССР - страна стандартов, причем их так много,
что не хватает стандартизуемых объектов :) Со всякими бытовыми компами ситуация была
особенно патологической. Движемся в том же направлении?

Ronin> "6. ну возьми И РЕАЛИЗУЙ САМ - сделай Спекктрум с ними, наладь производство,
` напиши софт - покажи пример! вот на этом пункте все изобретатели начинают
` лепить отмазки, я начинающий, не железячник - вот вы умные возьмите и сделайте
` (за свои деньги) что я хочу..."

Так уж сразу и производство? Я ж не зря упоминал эмуляцию в самых первых постах. Вообще
считаю, что все планируемые навороты сначала должны проходить обкатку на эмулях. Ну и что,
что в реале "этого нету". Там и всяких Chunky modes, например, нету, и никого не колышет.
А если так уж коробит, сделать плагином.

Слышу, слышу - "вот и сделай". Увы. Моих способностей пока хватило на упомянутый ранее
DOS-эмуль 48-го компа, который я, кстати, использую именно для издевательств на игрушками.
Но выглядит он ужасно и выпускать его нельзя - никто под него ничего делать не будет.
А интерфейс и до 128-го дорабатывать плющит - сетевое изобилие развратило.

А в железе - если кто заинтересуется - спаяет, нет - все равно спаяет что-нибудь другое.
Да и рано паять-то (и эмулить тоже) - сначала обсудить надо. Может, кто и получше
конкретную реализацию предложит. Пока правда, почти никто не понял даже, ЧТО обсуждается.

Ronin> "... И не слушают когда эти умные говорят - это не нужно."

Как говорится, если мы такие умные, то почему такие бед... невнимательные! Или и я
тоже так же хреново излагаю, как ты читаешь? В итоге каждый второй ухитряется понять
превратно - "Ехала деревня мимо мужика, вдруг - из-под собаки лают ворота". Отсюда
критика на пустом месте.

Ronin> "насчет ямахи - по сравнению с твоим режимом она более стандартна (по крайней мере
` она в кремнии), ее проще подключать и проще схемотехника - в разработке и настройке,
` и она к тому же мощнее функционально."

Ура! Подключить проще! Делаем из несовершенного Спектрума ухудшенную Ямаху! И теперь точно
без особых перспектив на софт. Может, Спектрум оставим Спектрумом, просто устранив его
недостатки? И уступать он Ямахе будет не сильно - какие там были самые рулезные игрушки
- Vampire Killer, например? Такую графику можно будет на 99% повторить. И вообще: любишь
Ямаху - ну и пожалуйста, люби САМУ Ямаху, которую к самой себе вообще подключать не надо :).
А люди любят Спек, за то, что он Спек. И спековский софт тоже.

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

Lethargeek

18.09.2005, 20:26

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

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

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

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

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

Тут меня почти все воспринимают как очередного изобретателя лошади, причем паршивой.
Зачем она, мол, когда и те красавцы, что уже есть, никому не нужны.

ДА НИ ФИГА ПОДОБНОГО! Я не выдумываю новую лошадь - и не призываю вообще отменить
лошадей, пусть кому нравится, тот их и разводит. Я всего лишь предлагаю оборудовать
обоих ишаков седлом и уздечкой и запрячь их парой в телегу, на которую и перегрузить
без особых проблем наиболее любимые вязанки. И ехать себе дальше спокойно, закрыв
этот вопрос (заодно расслабляясь созерцанием бредущего параллельно лошадиного табуна).

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

Всю спину уже ему стерли. И себе одно место.

Lethargeek

18.09.2005, 20:28

CHRV> "СМотри внимательно спецификацию АТМ, увидишь несколько видеорежимов . Я вот тоже
` думаю что их так все игнорируют, изобретают все чегото ."

Лошади, лошади... (сдержанное ржание)
IMHO их воспринимают, как атрибут именно компьютера АТМ, а не Спектрума.
И для динамической графики они вряд ли пригодны (все-таки 32k).

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

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

Я ничего не имею против компьютеров, подобных АТМ, и их наворотов. Но если уж они
могут работать как Спек реально существующий, почему бы не реализовать в них режим
такого Спектрума, каким он мог бы быть (быть, а не стать!).

CHRV> "Больше десятка под расширенные режимы АТМ, столько же под Спринтер."

Так ведь системки, поди. А это за сколько лет? А сколько из них параллельно имеют
версии для обычных клонов? Или все это машинно-специфичный софт?

CHRV> "Да понимаем токо не нужно никому это к сожалению."

У нас никто не знает, что нужно, зато каждый знает, что не нужно. Более того, каждый
уверен, что всем остальным на самом деле ничего не нужно. Вот и топчемся на месте. :(

P.S.
Меня терзают смутные сомнения... а в тот ли раздел я пихнул тему? Железячники вообще
народ скептический. Вообще-то на вопрос "Нужно или Не Нужно" должны отвечать люди,
плотно занимающиеся софтом, а железячники - только на вопрос "Можно Ли и Сложно Ли"
(если это не одно лицо). Может, сюда народ из софтверных разделов и не заходит?
Как их сюда заманить, не заводить же точно такую же тему в другом разделе...

Lethargeek

18.09.2005, 20:30

SAM style> "Из СТАНДАРТНОГО режима сложно выжать больше чем я выжал в nocturne - сделалось
` практически все, чего чел так хочет плюс чередование строк экранов (но последнее сильно
` зависит от компа)
` Наложением 2х экранов друг на друга можно получить 4 цвета на знакоместо, но не
` любых: один будет черным, а другой - результатом сложения первого цвета со вторым."

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

И моргательные эффекты это не исключает, т.к. предлагаю, чтобы второй экран, если он
активен, безусловно забивал первый. Кстати, интересные эффекты могут получиться при
совместном использовании.

Я согласен, что из стандартного нельзя больше выжать ПРОГРАММНО. Потому и предлагаю
идею несложной аппаратной доработки именно для стандартного режима. А не нового монстра.

Lethargeek

18.09.2005, 20:39

(На последнее)

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

А подробнее? Или это опять про аппаратный гигаскрин?

CHRV> ПОэтому предлагая реализацию, готовся к тому что кроме тебя ее реализовывать
` мало кто будет (DVS кстати об этом очень хорошо знает).

CHRV> ... Но ведь автор судя по всему заниматься этим
` особо не горит .

Я пока обсудить предлагаю.

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

CHRV

18.09.2005, 21:11

Я пока обсудить предлагаю.

Мне важен именно принцип, то есть заметное улучшение графики при сохранении адресации
и раскладки видеопамяти, обеспечении работоспособности старого софта и легкости его
адаптации, простоты обкатки идеи на эмуляторах. Что до конкретных спецификаций - было
бы весьма интересно услышать и другие предложения, может кто лучше придумает. И как
удобнее реализовывать разные нюансы с позиции удобства программирования...
Я же типа только пример привел, хотя и подробный.
Ты пока смотришь с точки зрения программиста. А я смотрю с точки зрения железячника. Например тоже аппаратное сложение экранов , требует чтобы у спека было две раздельных линейки памяти хотябы - т.е. простого решения не будет :( .Я имею ввиду для реализации на любых машинах.
Поэтому исходя из задачи, с моей точки зрения будет проще дополнить машину видеопроцессором (кстати V9990 более мощный проц чем применялся на MSX и MSX2) и аппаратно переключать вывод. Получим более легкую интеграцию в компьютер (ибо в этом случае идет как довеска на ZXBUS). Да конечно программисту это неудобно, но что делать.
А так я могу перечислять целую кучу доработок и решений но они как правило шли для КОНКРЕТНОГО компьютера (GMX для скорпа, Giga для Пентагона, АТМовские режимы, Спринтеровские, ZXNEXTовские...). Мне конечно как производителю вынгодно чтобы народ "упал" на АТМовские режимы (хотя бы потомучто это линейка будет продолжаться, пока мне все это не надоест :) ). Но я понимаю что в основном народ уходит на эмулятор, а не на реал. Ну а в эмуляторе - исходники лежат от Unreal и можно придумать любой свой режим и проэмулировать его (конечно если позволяет квалификация).

Ronin

19.09.2005, 10:14

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

вообще: любишь
Ямаху - ну и пожалуйста, люби САМУ Ямаху, которую к самой себе вообще подключать не надо

я не люблю ямаху, у меня ее даже нету. я просто вижу чип - неважно что его юзали на MSX, может еще какой и покруче чип раскопаем - просто его ставим в Спек - и с какой он стати превращается в ямаху ? что за галлюцинации такие, мания преследования другими платформами - что за "свой спековский путь все_на_россыпи_так_подохнет _скорее" ?.. Поставили в Спектрум Ay8910 - он что, превратился в ямаху ???

зы// я не отрицаю твоих идей, просто их реализация самих по себе в контексте сегодняшнего дня - нереальна.
Я всего лишь предлагаю оборудовать
обоих ишаков седлом и уздечкой и запрячь их парой в телегу

да но седла, уздечки и телеги по-прежнему не будет у других пользователей :) и чем их отсутствие отличается от "отсутствия лошади" :D

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

Dexus

19.09.2005, 10:26

Ну а в эмуляторе - исходники лежат от Unreal и можно придумать любой свой режим и проэмулировать его (конечно если позволяет квалификация).
К сожалению в имплементации именно 4х4 аттрибутной сетки будут большие проблемы в Unreal, поскольку SMT сделал все режимы на основе байт+аттрибут.

DVS

19.09.2005, 11:28

А если попытаться смоделировать идею с помощью наложения картинок, т.е. написать отдельно прогу на VC, Builder или Delphi ?

Spectre

19.09.2005, 11:49

CHRV

19.09.2005, 20:12

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

SMT

19.09.2005, 20:21

К сожалению в имплементации именно 4х4 аттрибутной сетки будут большие проблемы в Unreal, поскольку SMT сделал все режимы на основе байт+аттрибутпросто не надо боятся всё сломать и переделать, уж тем более сетовать на лень :). а представь, каково железячникам? или разносить альтернативные аттрибуты в другие линейки памяти (сложно. размер оторванного от аттрибутов куска #4000-#5800 (6 кб) не очень кратен степени двойки) или удваивать частоту памяти и переделывать всю синхронизацию. уж куда больше работы.

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

Splinter

19.09.2005, 20:48

CHRV

19.09.2005, 20:57

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

captain cobalt

19.09.2005, 21:29

Основная идея мне понравилась.
Предлагаю всё-таки резать не на четыре, а на восемь частей с возможностью установить разбиение знакоместа в 1х8, 2х4, 4х2, 8х1 (hardware multicolor) с точно такой же возможностью алиасинга и превращения в стандартный. И разделение на четвертушки будет частным случаем.

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

P.S. Кстати софт под нестандартные видеорежимы пишется, вон, tasis поддерживает экран АТМ, а acedit - режимы Alco384 и Pentagon512. Активисты часто пытаются всякие опросы, неплохо бы опросить народ и по поводу видеорежимов "какой лучше".

icebear

19.09.2005, 21:36

Да , абсолютно согласен с Вами, и веду как раз в этом направлении работы. Как уже говорил будет изучаться чип v9990 (так как он доставаем и хорошо документирован).

Он доставаем у каких-нибудь дистрибьютеров? И что он позволяет вообще?

CHRV

19.09.2005, 22:39

P.S. Кстати софт под нестандартные видеорежимы пишется, вон, tasis поддерживает экран АТМ, а acedit - режимы Alco384 и Pentagon512. Активисты часто пытаются всякие опросы, неплохо бы опросить народ и по поводу видеорежимов "какой лучше".
Ну этот опрос не даст никаких результатов ибо тот же народ не станет тут же губить свои спека реализуя эти режимы. Жалко Дима не может показать фотку своего пентагона - чудное зрелище я Вам скажу :).
Атм конечно хорош что эти режимы изначально схемно реализованы.

DVS

20.09.2005, 09:48

Ну типа я из своего GeForce Quadro FX4400 тоже могу чип выдернуть, а там не только спрайтовый движок... :p

CHRV

20.09.2005, 10:56

Ну типа я из своего GeForce Quadro FX4400 тоже могу чип выдернуть, а там не только спрайтовый движок... :p
Выдернуть то можешь, но прикрутить не сможешь :). А уж тем более софт писать (я имею вижу под него на 8битке).

Ronin

20.09.2005, 11:14

мне только чего не нравится - он под DRAM заточен и цикл 100нс - вроде неплохо что уже все готово - только устарело ведь уже немного это...
потому как хочется подключить видеопамять как память, а не общаться с ней через порты - а эти закидоны с мультиплексированием такому подключению не способствуют...
в то же время стандартное подключение через порты, с обычными ДРАМ от симмов - получится дешево и сердито.

а как там насчет ygv729 ? или уже на v9990 ориентируемся ?
все равно, один чип (v9990) я у тебя возьму.

nyuk

20.09.2005, 17:27

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

Ronin

20.09.2005, 18:35

ygv не доставаем
:-(((((((((((((((((( обидно однако

Lethargeek

22.09.2005, 20:22

Ronin> а ты софт спрашивал ? ему и так как есть неплохо живется между прочим.

Не скажи. Лично меня клэш здорово раздражает, особенно когда спрайт с фоном сливается
(из последних - Crime Santa Claus, например) или красит все зверски (игры про Wally)
Да, много игрушек сделаны аккуратно, но и буржуи часто халтурили, особенно под конец
коммерческого существования платформы.

Ronin> новое железо в подавляющем большинстве случаев = новый софт!

Это как раз НЕ ТОТ случай!

Ronin> ну просто фанат Спектрума, борющийся за чистоту рядов и непущения ямахи...

А я не фанат Спектрума. Спектрум ужасный компьютер ;) Я, скорее, фанат Спековского софта
(и вообще 8-битного софта, но Спековского в особенности). Для него, родимого, и стараюсь.

И вообще, некорректно сравнивать прикручивание звукового и графического процессора. Это
сейчас все меряется на мегагерцы и на вопрос "какой комп?" пц-шники отвечают "пент 4-й"
или "Атлон 2500+". А в 80-е ГЛАВНОЙ мелкосхемой во всех этих "домашних" компах была именно
видюха - под нее вся архитектура затачивалась, проц тормозился и т.п. А это означало,
что графика на одной платформе в разных играх была несколько... однотипна, что ли. А чуть
что не так сделать пытались, не как видеопроц хочет - вставало колом.

Спек являлся тогда редким исключением - он почти никак не регламентировал программиста.
Игрушки на Спеке по графике ОЧЕНЬ РАЗНЫЕ - что меня и привлекает. Да, конечно, качество
похуже из-за примитивности видеорежима - но это я и хотел бы исправить.

А звук какой бы ни ставили - сути и духа платформы это не меняет.
(Я и от AY не в восторге. Мне звук плавный нравится, как на SID'е, а на Спеке почти все
- сплошное дилимбомканье. Или это музакеры виноваты? Отвлекся чего-то.)

А реакция такая у меня была не на прикручивание ямаховских чипов как таковое, а на попытки
некоторых людей ;) выдать его за решение проблем СПЕКОВСКОЙ ГРАФИКИ и нахождение связанного
с этим офтопика в данном треде. По-моему, прикручивание всяких готовых (цитирую тебя:
"может еще какой и покруче чип раскопаем") наворотов решает только одну прблему - проблему
прикручивания данных наворотов.

Ну это я сейчас отдельно CHRV выскажу.

Lethargeek

22.09.2005, 20:23

ОБРАЩЕНИЕ ЛИЧНО К CHRV:

Уважаемый CHRV! Не сочти за наезд (я в курсе, что модератор пока еще ты, а не я ;) ), но
не пора ли выделить все связанное с установкой v9990 в отдельную тему? Тем более там
у тебя подробности пошли. Обещаю честно ее просматривать ;)

Достаточно много народу заинтересовались как тем, так и другим, да и ясно уже должно быть,
что сабжи - НЕ КОНКУРЕНТЫ, так как предложены для решения разных задач (то есть графических
возможностей навороченных клонов вообще и прблем стандартной графики с ориентацией на софт)
Я думаю, они даже не взаимоисключают реализацию друг друга на одном компе (конкретные мысли
по реализации ниже), если ты хочешь делать через вентиль.

А твое профессиональное мнение по моей теме меня по-прежнему будет интересовать.

Спасибо.

Lethargeek

22.09.2005, 20:26

Lethargeek

22.09.2005, 20:27

captain cobalt> Предлагаю всё-таки резать не на четыре, а на восемь частей с возможностью
установить разбиение знакоместа в 1х8, 2х4, 4х2, 8х1 (hardware multicolor) с точно такой же
возможностью алиасинга и превращения в стандартный. И разделение на четвертушки будет
частным случаем.

Нифига не понял. Тогда вообще надо на "шестнадцатушки" делить, чтобы учесть все возможные
частные случаи. И памяти сколько на это. И визуально не слишком заметно будет.

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

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

Lethargeek

22.09.2005, 20:28

nyuk> ...Ну а минус как обычно один - заинтересуется в конечном итоге всего несколько
человек. А значит, никакой массовости, икакого софта, ничего...

У народа за столько лет уже выработалось отношение, что все равно сделают, как
производителю удобнее, а не как потребителю. Уже и хотят то, что их приучили хотеть
железячники. Поэтому всем заинтересованным надо не лениться, а четко высказаться.

newart

22.09.2005, 20:57

У народа за столько лет уже выработалось отношение, что все равно сделают, как
производителю удобнее, а не как потребителю. Уже и хотят то, что их приучили хотеть
железячники. Поэтому всем заинтересованным надо не лениться, а четко высказаться.
Может я проглядел, но так и не уловил сути, для чего это все надо?
Новый спек едвали будет произведен с новым режимом, старые мало
кто будет дорабатывать, и даже не в это проблема.
Старый сфот никто под новый режим адптировать не будет,
а писать новый... тоже не просто, для банальных 8 цветов (зачасту
просто ЧБ) графику нарисовать не могут, что уже про такие
навороты говорить.
Кроме того не надо сравнивать музыкальные навороты с графическими.
Музыка это всегда вторично по сравнению с графикой...
но с другой стороны имхо музыка спека более самоценна чем
графика. Хотя шедевры и тут и там творят.
При желание можно и без новых режимов обойтись, вот простейший пример.

CHRV

22.09.2005, 23:59

Теперь к делу.

CHRV> Ты пока смотришь с точки зрения программиста. А я смотрю с точки зрения железячника.

Что значит "пока"? Смотрел, смотрю и буду смотреть с точки зрения програмера! Долой диктат
железячников! Нет, прада, очень грустно, что софтеры и хардеры друг друга не понимают.
Есть такая вещь как разумность подхода. Так вот твой подход в смысле железа не разумный, т.е. в результате мы получаем глючный клубок проводов (эх надо Максову АТМ1 щелкнуть как пример или Пентагоны АлКо). Я бы рад тебя понимать, но даже простая доработка она АБСОЛЮТНО не универсальна. А покупать новый комп у нас даже по себестоимости не хотят (АТМ конструктор продается по себестоимости, желающие могут посчитать).

Одним знают, чего хотят, но не знают, как сделать, а другим изобретать ничего неохота, лишь
бы готовое присобачить и поставить галочку - ТАКИЕ-ТО ВОЗМОЖНОСТИ ТЕПЕРЬ ЕСТЬ, а там хоть
трава не расти. И почему такое сразу пренебрежительное отношение к рассыпухе, сейчас всем
только готовые блоки подавай, делать, что ли, разучились? Можно хотя бы подумать, а как
это могло быть реализовано, а там, глядишь, и свежие мысли появятся.
Речь идет не о рассыпухе а обрастнии проводами, и я могу сказть те кто сами попытаются сделать то в лучшем случае один человек из пяти получит результат. А причины следующие:
- Клоны разные даже внутри одной модели, вот у меня сейчас лежат ЧЕТЫРЕ разные разновидности Пентагона128 (один правда я на детали спустил) у которых разные платы. Представляешь что сделает любитель с паяльником, я вот точно знаю после таких доработок появится еще больше ПЦшников :).
- Доработку может сделать профессионал, но он за бутылку пива делать не будет, как говорил Нэмо "это денег стоит". И еще второй фактор а будет ли он вообще возиться со спектрумом. В Питере есть Кирил Фролов, в Москве есть я, ну а что делать человеку из Устьперепердюйска (а пересылка стоит уже гораздо больше бутылки пива).
Отсуда вывод нужно думать только в новом компьютере, а это как показывает практика выброшенные деньги в общем случае.

CHRV> Например тоже аппаратное сложение экранов , требует чтобы у спека было две
раздельных линейки памяти хотя бы - т.е. простого решения не будет. Я имею ввиду для
реализации на любых машинах.

А на АТМ экран использует не две линейки памяти (или больше)? И хорошая ведь машина, да ? ;)
Да так оно и есть использует две раздельные линейки памяти - за счет этого мы собственно получили неплохие новые графические возможности (кстати полностью не реализованы, заложена возможность получения еще четырех режимов программно, но железом пока не реализовано). И микросхем у нее меньше чем у Профи например, при больших возможностях. Да кстати у Кая оснащенного возможностями АТМ или у ZXNext микросхем тоже побольше будет :).

CHRV> Поэтому исходя из задачи, с моей точки зрения будет проще дополнить машину
видеопроцессором (кстати V9990 более мощный проц чем применялся на MSX и MSX2)...

ИЗ КАКОЙ ЗАДАЧИ? Ты решаешь другие задачи (см. выше). По моему, тут уже многие поняли,
какую задачу я ставил. (Кстати, я в буржуйских доках по MSX читал, что v9990 был глючной
по сравнению с более ранними и там был у них какой-то скандал еще в те годы...)
Задача совершенно четкая и формализованная: при минимальных доработках, на наибольшем спектре разновидности клонов получить новые графические возможности при максимальной совместимости со старыми режимами и между друг другом (среди клонов).
MSX тут совершенно не при чем. Ну я Опен Леттерс читал там например написано про АТМ и СПринтер, что они чуть ли не исчадья ада и проделки Сороса :), но тем не менее они остаются самыми мощными и развитыми клонами Спектрума.
Т.е. ко всему относится аккуратно особено к тому что пишут сторонние или заинтересованные в своих целях источники. :).
Чип от МСХ не совместим по некоторым операциям с младшими моделями. Ну об этом наверно наш ТОВАРИЩ Адриан Оборок с Канадщины лучше расскажет - он самый крутой реальщик которого я знаю :). Ему я верю больше чем всяким изданиям ;).

CHRV> Да конечно программисту это неудобно, но что делать.

И снова ДОЛОЙ ДИКТАТ ЖЕЛЕЗЯЧНИКОВ! :) Отношение такое - жри, что дают, что ли?
Я же все понимаю, тебе это ломотно делать, голова другим занята, но не отвергай с порога,
подумай... может, что и возникнет.
Дело в том что я подумавши отвергаю, часть аргументов изложил выше. Но тебя критиковать не буду, ты же не первый и не последний. Возможно в будущем АТМ чкакието идеи реализуются (Хотя уже сейчас можно находу менять палитру, у АТМ это возможно, а это уже 64 цвета на один экран - писатели почемубы не использовать).

Проблема, насколько я понимаю, в объемах реально читаемой в кадре информации.
Спековская юла читает 64 байта в строке, стало быть, 12 кб в кадре.

Если делать отдельно четвертушки, то в строке надо читать 96 байт - 18 кб в кадре.
Если отдельно накладные экраны - 128 байт в строке - 24 кб в кадре - но можно
одновременно, если из разных мелкосхем, так, что ли?

Если все вместе, то в кадре надо читать 36 килобайт. А что - в АТМ 32 кб. Не понял,
сколько там реально в кадре читается и, похоже, из разных линеек, но наверняка объем
близкий, да? С точки зрения програмера - пофиг, как это реализовано, если успевает.
Ну почему пофиг, почитай доки по программированию и устройству АТМ - они свободно лежат на atmturbo.nedopc.com . Я думаю что это будет полезным для дальнейшего измышления на своими идеями. ;).

А вообще, конечно, пока мысли смутные. Извини, если пишу глупости. Хотелось бы
ПОБОЛЬШЕ РАЗНЫХ знающих людей послушать. И поконкретнее.
Нет просто у тебя чисто любительский подход - идея показалась вроде простой и легкой и дальнейшее ты обдумывать не стал. А это самое главное. Когда доходит да чисто практических решений, то идея оказывается не такой уж замечательной (но в одном случае из 1000 случается наоборот :) ). А у профессиональный подход как правило подразумевает полнейшей продумывание задачи, продумывание ее решений и расчет потенциальных затрат (имеется ввиду сложность а не стоимость).

С Уважением!

vaz

23.09.2005, 15:32

2 Уважаемый АЛЛ.

мож конечно не в тему. но у корвета к примеру было не 2 экрана а один из 3 независимых страниц... монохромных. это к вопросу о реализации сего в железе. кому надо сходите на сайт Сергея Ерохина. там есть и доки и эмуль и проч., но. все красиво слов нет. но я не видел красивых игрух с использованием этих наворотов. в виду их монохромности. из того что помню - jamper.

C Уважением.,

Василий К.

Spectre

02.10.2005, 13:22

А не пора ли честно признаться что за последние годы вышло новых игрушек меньше десятка? Кому нужен прикрученный видеопроцессор с тучей возможностей если за следующие n лет под него напишут 1-5 игр? Я как программист на спеке с многолетним стажем напишу, что переделать любую игру моей юности (Exolon, R-Type, Laser Squad, Dizzy,...) хотя-бы под расширенный экран Profi или ATM (не говоря уже про видеопроцессоры) по времени и трудозатратам сравнимо с написанием этих игр с нуля. И я не буду даже браться за такие проекты. А вот если хотя-бы чисто теоретически я мог бы переделать тот же Exolon за 1-2 месяца несколько улучшив графику при помощи STS+Sprite Tools, я бы уже всерьез обдумал такой вариант.

Сложно реализовать в железе? Безусловно. Но держал например я в руках SMUC, и даже инструкцию к нему с описанием доработок многих моделей до скорпиона с целью подключения SMUC'а. Разумеется Nemo, Frolov, CHRV абсолютно правы про процент вышедших из строя машин после таких доработок. Но надо выбрать или 1-5 игр (теоретически) под существующие расширенные режимы, или (тоже теоретически) многократно больше?

Lethargeek

03.10.2005, 20:32

Во! Только я появился после долгого перерыва злой-презлой, глядь - а тут Spectre, добрый и отзывчивый :D ...немного поднял настроение.

Но все равно, раз принес - читайте.

Lethargeek

03.10.2005, 20:35

newart> Может я проглядел, но так и не уловил сути, для чего это все надо?

Похоже, ты ВСЕ проглядел, если судить по твоим дальнейшим замечаниям :(

newart> ...не в этом проблема. Старый софт никто под новый режим адаптировать не будет,

Так уж никто? Не всем же только паять интересно ;)
Ну вот я например - я и так Спековские игрушки регулярно терзаю, исправляю всякие баги
графические и аляповатости (ну люблю я это дело). И всего делов-то - поставил в эмуле
перехват на запись в экран или в буфер (отыскивемый элементарно) --> обнаружил процедуры
вывода, работаю только с ними (а это небольшой кусок), совершенно не вникая в остальной
код. Поправил - запустил, поправил - запустил... Это если в логику лезть - да, это
геморрой еще тот (хотя и такое делали же наши умельцы), а здесь просто все.
А если переделывать под новый экран, то у меня стойкое впечатление, что работы будет
МЕНЬШЕ на самом деле, так как меньше думать над кодом, только память, возможно,
перераспределить, чтобы 7-ю страницу юзить без проблем.

Вообще, народ, мучить софт - это хороший отдых, не то что лет пять тянуть какой-нибудь
суперпроект :) Голову забивать особо не надо, а результат - вот он, сразу! Тем более
что халтурщики-буржуи оставили достаточно недоделок.

newart> ...а писать новый... тоже не просто, для банальных 8 цветов (зачастую просто ЧБ)
` графику нарисовать не могут, что уже про такие навороты говорить.

Смешно такое слышать от гейммейкера! Перечитай тему, а?
Если софт "с нуля" пишется, то все ЕЩЕ ЛЕГЧЕ - у автора-то все исходники под рукой.
Причем версия для нового видеорежима будет ПРОЩЕ - графика почти та же самая, только
ПРОБЛЕМ МЕНЬШЕ с ее выводом. Уж если сумел сделать в обычном режиме (а только это все
и умеют, судя по вышедшему софту) - то что уж говорить про новый.
...И где ты увидел сумасшедшие навороты?

newart> При желании можно и без новых режимов обойтись, вот простейший пример.

Да уж, ОБОШЛИСЬ... Ну пробовал я нечто подобное, ессно - и остался результатом недоволен.
В окошке мигает - уродство, на весь экран - не лучше. Такое только в эмуле в Noflic будет
смотреться. А скорость? Плюс маску обязательно надо печатать, но и это не спасает - если
PAPER у фона не черного цвета - тут же проблемы, это прекрасно видно на первом снапшоте,
если погонять спрайт по дереву :)
Зато второй снапшот хорошо иллюстрирует, зачем я предлагал четвертушки - не сами по
себе, а в сочетании со спрайтовым экраном они позволят обойтись без маски, просто сделав
"сердцевину" спрайта двухцветной.
И еще - быстрое стирание, опять же повешенное на "глупое" значение атрибута. Вот оцени
скорость графики в Fast & Furious и Astro Marine Corps... А теперь запусти их в
каком-нибудь эмуле, принудительно отключив обработку атрибутов - увидишь, сколько там
спрятанного мусора на экране. На оригинальном Спеке это проходит только для сплошного
одноцветного фона - а здесь можно будет иметь картинку!

А моргалками лучше делать что-нибудь специфическое, типа конверсий с других платформ,
и цвета тщательно подбирать, чтобы мерцало поменьше. Ну, об этом я в теме "Preliminary
Monty" еще напишу.

newart> Кроме того не надо сравнивать музыкальные навороты с графическими. Музыка это
` всегда вторично по сравнению с графикой... но с другой стороны имхо музыка спека более
` самоценна чем графика. Хотя шедевры и тут и там творят.

Дык я и не сравниваю, это Ronin вообразил, что я "для чистоты Спека" должен выбросить AY ;)
Наоборот, пишу, что графика - это почти сам комп и есть, говоря о "восьмибитках". А насчет
самоценности музыки - по-моему, единственная в этом плане машина - пресловутый Commodore64
- и сам чип отличный, и к тому же "эксклюзивный" был - собственныя продукция! А остальное...
AY куда только не пихали, так что это "серый стандарт", POKEY на Atari тоже свой - но там
музыки с гулькин нос, по крайней мере в игрушках крайне редко.

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

Lethargeek

03.10.2005, 20:41

CHRV> эээ... (а неохота цитировать... на все последнее, короче)

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

А ведь недаром буржуи утверждают, что Software is what the Spectrum was all about.
Sure other machines were faster, had better graphics and sound, but for every game
available for them the humble Speccy had two (at least). Many weren’t good enough,
others were and some are all time classics.
...потому я и предлагаю - сохранить количество, но резко улучшит качество, чтобы
масса уже имеющегося и того заслуживающего софта стало "good enough".

И смешно сегодня рассматривать Спек с точки зрения "технологичности", по-моему. То есть
пока действительно не появится модель (обязательно обеспеченная качественным софтом),
которую действительно захотят купить (а хотят сейчас что-то вроде ноутбука, насколько
я понял, почитав разное). И насчет надежности - так это смотря как сделать, вот у меня
48-й "Ленинград" до сих пор жив (ему уже 15 лет), и он изначально был весь на рассыпухе
и проводках. А ведь его и кот ронял со стола, исправляли и порты в нем, и инверсию
видеосигнала (куча пайки по разным поводам), и даже я в свое время толстенным паяльником
отводил Sinclair Joystick прямо от клавиатуры проводками :eek: И ничего...

Спек - это хобби, кому надо - тот что угодно сделает, если уверен, что новый наворот
не пропадет зря. Что, компов с "левыми" графчипами сильно много будет, без софта-то?
Все равно, что и не было бы их. Вот где "выброшенные деньги". Или люди должны получать
моральное удовлетворение только оттого, в их комп-де вмонтированы "новые графические
возможности"? Нет, все-таки мы говорим о РАЗНЫХ ЗАДАЧАХ. Ну представь, что Лев Толстой
написал корявый черновик первой части "Войны и мира", да и помер (или рукопись продал).
И вот новый владелец думает: чем начало до ума доводить, да еще продолжение придумывать,
возьму-ка я под видом второй части поставлю перевод из какого-нибудь хорошего француза
на ту же тему. Ну и что, что герои разные и сюжет не стыкуется? Писатели-то хорошие,
что один, что другой. И легко реализуемо. :D

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

А "человек из Устьперепердюйска" и так, поди, на эмуляторе сидит...

P.S. Не, ну все-таки процитирую:

CHRV> (Хотя уже сейчас можно на ходу менять палитру, у АТМ это возможно,
` а это уже 64 цвета на один экран - писатели, почему бы не использовать).

Ну опять подмена понятий! Это же снова все статика, это даже не моргалки. :( Кто будет
возитья, делать autodetect АТМ-а, новую процедуру вывода, только чтобы добавить в игру
или дему неподвижную картинку, которую, кстати, тоже надо перерисовать. А железячники
потом удивляются, оперируя цифрами и "голыми" техническими возможностями - почему не
используют. НЕУДОБНО.

Другое дело, если бы на АТМ было прерывание, зависимое от позиции луча (да и другим компам
не помешало бы). Тогда было бы реально быстро переделать даже некоторые игрушки.

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

CHRV

03.10.2005, 23:15

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

Задачу я формализовал.

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

Максагор

04.10.2005, 02:44

Ну опять подмена понятий! Это же снова все статика, это даже не моргалки.

Ну ты не торопись с выводами. Палитру в 64 цвета (при 16-ти одновременно) можно на АТМе применять и в стандартном экране. И при 2BIT-plan'овыхизображениях (моргание раз в прерывание экранными страничками) можно на каждый экран ставить свою собственную палитру, получая довольно значительно число цветовых оттенков.

Spectre

04.10.2005, 11:01

К сожалению CHRV и Lethargeek говорят на разных языках. С одной стороны легкость подключения, с другой легкость переделки программ. Как показывает практика последних лет, победу обычно одерживают железячники и очередной мегадевайс благополучно подключается и забывается. Почему так происходит? Здесь я полностью согласен с Lethargeek'ом что целью среднестатического железячника является не улучшить спектрум, а просто подключить очередной высокотехнологичный наворот. А то что этот наворот никто не использует, здесь вроде как железячник не при чем.

Успехов, господа. Подключайте очередной видеопроцессор.

Ronin

04.10.2005, 12:07

Ну опять подмена понятий! Это же снова все статика, это даже не моргалки. Кто будет
возитья, делать autodetect АТМ-а, новую процедуру вывода, только чтобы добавить в игру
или дему неподвижную картинку, которую, кстати, тоже надо перерисовать. А железячники
потом удивляются, оперируя цифрами и "голыми" техническими возможностями - почему не
используют. НЕУДОБНО.

ты сам-то много программировал ?
с определенного момента все что ты описал просто становиться не важно.

Ronin

04.10.2005, 12:16

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

проблема - в том что нет ОС ! а не в том кто де хочет чего мегаподключить.

icebear

04.10.2005, 12:34

хооршо, где толпы программ под флеш-колор, аппаратный мультиколор и тд - все это элементарно адаптируется от стандартного экрана ?

проблема - в том что нет ОС ! а не в том кто де хочет чего мегаподключить.

Проблема в том, что всё вышеперечисленное - убогость.

ASDT

04.10.2005, 15:46

Некоторые соображения:
Если скорость "вывода на экран" 4 Мб/сек., то
получается 4.57 бита на точку ...
А как их использовать - это вопрос к программерам игр.

Dima Bystrov (2:5029/77.48)

07.10.2005, 03:16

Hello Андрей!

02 Oct 05 20:59, Андрей Богданович wrote to vaz:

АБ> А не пора ли честно признаться что за последние годы вышло новых
АБ> игрушек меньше десятка?

пересчитай внимательно :)

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

... ZX Spectrum today

ASDT

07.10.2005, 05:01

Так вот писателям ... нужно ли изменение стандартного экрана?

Максагор

09.10.2005, 04:19

Так вот писателям ... нужно ли изменение стандартного экрана?

Нафиг! Покупайте ATMы, и будут у вас различные дополнительные экраны. А то сейчас трое из пяти допаяются до сизого дымка на своих платах своих бывших (с этого момента) спектрумах.

Не надоело-то рукосуцйством заниматься? Понимаю еще, если какой баг исправить, подпаяв лишнюю микросхемку, или к сигналам проца слот подпаять, чтобы без проблем периферию подрубать. А то, что предлагается, ИМХО, извращение...

ASDT

09.10.2005, 07:12

Интересует мнение тех, кто реально пишет игру(ы) ...
И кому может это расширение принести пользу.
Если такие есть.

Lethargeek

09.10.2005, 20:15

dhau> Короче по этому Lethargeek-у надо всем сесть и во имя светлой памяти былого быстро
` умереть. И не сметь ничего нового неортодоксального придумывать, ибо наши деды и без
` этих наворотов ВОВ выиграли. Ура, дорогой летаргик. Награда Орден Почётного Троля
` Первой Степени с полочки на грудь гип-гип-ура. А теперь валите батенька подальше.
` Тут ортодоксов-староверов не любят.

ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА!!!!!!! РЖУ-НЕ-МОГУ-У-У! :D :D :D :eek:

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

Какая-то извращенная логика. Ну просто dhau-из-Зазеркалья... :D

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

Если бы я был таким старовером, то был бы доволен существующими характеристиками Спека
и темы не возникло бы. И не запрещал я ничего прикручивать и придумывать, я просто
выступил против попыток выдать поспешные формальные решения за панацею от всех Спековских
графических проблем.

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

Lethargeek

09.10.2005, 20:16

Ronin> ты сам-то много программировал ?
` с определенного момента все что ты описал просто становиться не важно.

Ты сам-то понял, что хотел сказать?

Ronin> хорошо, где толпы программ под флеш-колор, аппаратный мультиколор и т.д. - все
` это элементарно адаптируется от стандартного экрана?

icebear> Проблема в том, что всё вышеперечисленное - убогость.

Во-во, причем я об этом уже высказывался гораздо раньше. Зациклило, что ли, товарища?

Ronin> проблема - в том, что нет ОС ! а не в том, кто де хочет чего мегаподключить.

Хе-хе, а что же даст новая ось в плане улучшения графики Спектрума и облегчения ее
программирования? Или весь вывод на экран должен будет идти через какой-нибудь DirectZX,
или того хлеще - через GDI (на Спектруме должно произноситься как "жди-и-и-и-и-и...")
посредством отдельно устанавливаемых драйверов для каждого наворота? :D
На восьмибитном процессоре в 3.5-7 MHz!

P.S. Это на пц нужна новая ось...

упс... не успел я набрать эти строки, как немедленно выскочило окошко с посланием от
пресс-секретаря компании Microsoft. Мне было настоятельно рекомендовано заменить слова
"новая ось" на "следующая версия"... :rolleyes:

Бойтесь, спектрумисты, Большой Билл смотрит и на вас!

Lethargeek

09.10.2005, 20:18

И вот снова критика на пустом месте:

Максагор> Ну ты не торопись с выводами. Палитру в 64 цвета (при 16-ти одновременно) можно
` на АТМе применять и в стандартном экране. И при 2BIT-plan'овыхизображениях (моргание раз
` в прерывание экранными страничками) можно на каждый экран ставить свою собственную
` палитру, получая довольно значительное число цветовых оттенков.

Охо-хо. Ну че делать с вами, приходится снова давать ту же цитату из CHRV.

CHRV> (Хотя уже сейчас можно на ходу менять палитру, у АТМ это возможно,
` а это уже 64 цвета на один экран - писатели, почему бы не использовать).

Итак, речь идет о смене палитры "на ходу", то есть посреди кадра, что становится совершенно
ясно из дальнейшего "64 цвета на один экран". То есть имеется в виду фактически вариант
программного мультиколора = статическая картинка, съедающая все ресурсы процессора.

В связи с этим ПРОШУ ВНИМАНИЯ всех нуль-критиков! Данный тред только что породил первый
полезный результат, а именно:

ПЕРВЫЙ ЗАКОН ДЛЯ ОТВЕЧАЮЩИХ ЛЕТАРГИКУ.
Если хочешь пнуть Летаргика за "торопливость" и "невнимательность" - трижды перепроверь,
о чем пишешь! Возможно, именно ТЫ САМ поторопился и кое-чего не заметил.

В настоящее время ведутся исследования по вопросу обобщения данного закона, помимо
Летаргика, на прочих обитателей форума. ;)

Lethargeek

09.10.2005, 20:19

И вот чтобы не уподобляться нуль-критикам, на заявление Максагора "не по делу" я тем не
менее даю подробный ответ "по делу":

А что мы имеем, если совместить моргалку со сменой палитры "раз в прерывание", как ты
предлагаешь? Теоретически моргалка на стандартной палитре дает 15*15=225 "цветов", сразу
уберем моргающие "симметрично", получим (15*15+15)/2=120 "цветов" одновременно (считая,
что множитель BRIGHT не равен точно двум). Если убрать еще "одинаковые", но по-разному
разложенные на компоненты "цвета", получаем в итоге число 102.

В общем случае со сменой палитры получаем 16*16=256 цветов, причем при тех же самых
ограничениях - 4 цвета на знакоместо. А это значит, что для конверченных картинок более
плавные цветовые переходы возможны только для очень крупных деталей. Да на Спеке всего-то
256*3=768 знакомест! Наверняка в каждом отдельном случае цветов будет куда меньше 256.
Единственный плюс - "общая палитра" картинки будет несколько более "естественной". Причем
все эти красоты требуют, чтобы в двух палитрах было поменьше одинаковых цветов (в идеале их
не должно быть вообще), а это значит, что картинку опять-таки придется полностью
переделывать/переконвертировать, то есть опять двойная работа (и двойной расход памяти,
пусть даже дисковой). Это что касается статичных картинок - ну-ка, кто будет возиться,
вставляя избыточные данные в игрушки и демы "общего назначения"? Реально, если что и
получится, так это снова машинно-специфичный софт, демонстрирующий возможности АТМ.

Для динамической "моргательной" графики (вроде той, что я описывал в разделе "Игры" в теме
"Preliminary Monty") фактически реально можно использовать еще меньше цветов. В общем, все
сводится опять-таки к использованию 8-16 цветов из палитры в 256 вместо 64, которые должны
быть еще достаточно контрастны между собой. Эффект ничтожный - опять-таки, несколько другой
колорит (не худшего можно добиться кручением настроек у телевизора ;) ).

P.S. Вот видишь, в отличие от некоторых я не просто заявляю "невозможно", "трудно" или
"не стоит", но и конкретно объясняю, почему (а не потому что "я это обдумал, так что верьте
мне"). А также стараюсь не пользоваться таким дешевым трюком, как опровержение самого
слабого аргумента собеседника (при этом благоразумно "не замечая" остальных, более сильных).

Lethargeek

09.10.2005, 20:20

Тут я собирался кинуть заготовленный для CHRV ответ, но передумал. Мысли разные свежие
полезли в голову, и вообще... Короче, завтра-послезавтра будет готов более дельный
развернутый вариант (а не бессмысленное продолжение спора слепого с глухим ;) ).

Кстати, CHRV, а чего это вдруг на "Вы", уж продолжим на "ты", все-таки в сети под никами
общаемся, а не на официальном приеме... Да и "тыкать" не я первый начал. ;)

CHRV

09.10.2005, 20:21

Бойтесь, спектрумисты, Большой Билл смотрит и на вас!
Давайте лучше как люди взрослые, поговорим о деле.
Я до сих пор не увидел Ваших решений, если они возможны то я с интересом их рассмотрю!

Кстати рассматриваемый процессор никакого отношения к БГ не имеет. Он использовался азиатских "родственниках" - компьютерах MSX. Паранойя очень опасное заболевание ;)

CHRV

09.10.2005, 20:25

Кстати, CHRV, а чего это вдруг на "Вы", уж продолжим на "ты", все-таки в сети под никами
общаемся, а не на официальном приеме... Да и "тыкать" не я первый начал. ;)
Если я человека уважаю но не знаком с ним, я к нему обращаюсь на ВЫ. Уважаю культуру, а тыкание это как всеравно "что писать мимо писуара" ( (с)профессор Преображенский из "Собачье сердце" ).

А вообще это оффтопик и не имеет отношение к теме, в дальнейшем если чтото не устраивает в моем стиле, то пишите мне лично! Тут буду стирать!

CHRV

09.10.2005, 20:30

Тут я собирался кинуть заготовленный для CHRV ответ, но передумал. Мысли разные свежие
полезли в голову, и вообще... Короче, завтра-послезавтра будет готов более дельный
развернутый вариант (а не бессмысленное продолжение спора слепого с глухим ;) ).
Кстати по поводу слепоты и глухости... только честно, у Вас реальный спектрум есть? Вы им пользуетесь или хотя бы включаете? Какая модель?

ASDT

09.10.2005, 23:40

"Сообщение от Lethargeek"
Раз такое дело ...
Напишите ув.Lethargeek, что за игру Вы собираетесь писать?
Или кто-что собирается ... ?
Тогда есть предмет разговора.

CHRV

10.10.2005, 00:30

"Сообщение от Lethargeek"
Раз такое дело ...
Напишите ув.Lethargeek, что за игру Вы собираетесь писать?
Или кто-что собирается ... ?
Тогда есть предмет разговора.
Пожалуй я понял следующее. Lethargeek рассматривает именно метод улучшения существующих игр путем добавления некой дополнительной аппаратной возможности (ну например складывания двух экранов рассположенных в разных местах памяти), улучшающей глубину цвета или разрешения.
Причем он предлагает не готовое решение, а именно как идею для обсуждения.
А я, такой плохой ;), рублю эту идею. Ну соответственно привожу какие-то доводы, почему это не стоит делать (по крайней мере на существующих реалах).

ASDT

10.10.2005, 04:51

"не готовое решение, а именно как идею для обсуждения"
Обсуждать можно с теми, кто будет(хочет) эти "улучшения"
использовать. А желающих нет ...

Ronin

10.10.2005, 10:46

Ronin> ты сам-то много программировал ?
` с определенного момента все что ты описал просто становиться не важно.

Ты сам-то понял, что хотел сказать?

Ronin> проблема - в том, что нет ОС ! а не в том, кто де хочет чего мегаподключить.

Хе-хе, а что же даст новая ось в плане улучшения графики Спектрума и облегчения ее
программирования? Или весь вывод на экран должен будет идти через какой-нибудь DirectZX,

все понятно, уважаемый. ваш предел - это линейные алгоритмы на асме, максимум с call-ами. потому и считаете байты и такты.

Напишите ув.Lethargeek, что за игру Вы собираетесь писать?

"реала нет, сам свой суперэкран делать не буду, да и софт сам писать тоже не буду" - поправь, я в чем-то неправ ?

Lethargeek

10.10.2005, 20:43

CHRV> Кстати, рассматриваемый процессор никакого отношения к БГ не имеет. Он использовался
` азиатских "родственниках" - компьютерах MSX. Паранойя очень опасное заболевание.

Рассеянный склероз тоже ;) В рассматриваемом отрывке речь шла только об осях, никаких
видеочипов и рядом не лежало. И вообще - смотреть ПЕРВЫЙ ЗАКОН ДЛЯ ОТВЕЧАЮЩИХ ЛЕТАРГИКУ.

CHRV> Кстати по поводу слепоты и глухости... только честно, у Вас реальный спектрум есть?
` Вы им пользуетесь или хотя бы включаете? Какая модель?

Кстати, по поводу слепоты и глухости... ;) Я же его уже описывал в прошлый раз, что-то
непонятно? Включаю теперь довольно редко, так как старый телевизор не держит картинку,
а к новому я его подключал сам лет 7 тому назад методом тыка из 5-штырькового RGB выхода
в композитный посредством монохромного декодера системы "канцелярская скрепка" (чтобы цвета
правильно распределились по яркости, надо скрепкой между проводов пошуровать). В основном
- для из(м)учения Z80. Когда эмуль писал из интереса без всякой документации, включал чаще :)

Ну вот к Saab-у теперь хожу, у него Profi; скоро еще АТМ будет. И что? Это что-то
доказывает? Что я должен там увидеть? Единственный результат - убедился, что эмули все
еще очень хреново воспроизводят AY-звук, но не настолько, чтобы я вдруг сразу полюбил
оригинал.

P.S. Нет, ответ еще не готов, я, собственно, зашел по другой теме и не удержался ;)

CHRV

10.10.2005, 20:56

P.S. Нет, ответ еще не готов, я, собственно, зашел по другой теме и не удержался ;)
Ну у меня вопросов тоже нет, как бы странно обсуждать чтото с человеком который реал то не особо юзает :(.
Лично я эту дискусию для себя завершаю, если конечно не появится чтото достойное внимания.

Spectre

10.10.2005, 22:45

Ну у меня вопросов тоже нет, как бы странно обсуждать чтото с человеком который реал то не особо юзает :(.
Лично я эту дискусию для себя завершаю, если конечно не появится чтото достойное внимания.

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

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

CHRV

10.10.2005, 23:41

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

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

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

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

Ronin

11.10.2005, 11:14

но не настолько, чтобы я вдруг сразу полюбил
оригинал
ржунимагу :biggrin: :v2_lol:

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

Lethargeek

12.10.2005, 20:14

Вот и обещанный мега-пост. ;) Разбитый на части для удобочитаемости.

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

Кроме того, некоторые цитаты взяты не из данной темы, а из архива форума или из файлов с
сайта АТМ. В которых я провел некоторые изыскания для лучшего уяснения взглядов и позиций
своих оппонентов.

Понеслось.

Lethargeek

12.10.2005, 20:18

CHRV> А взять что-то лучшее с других платформ - а почему бы нет. Пользуются сейчас же
` АТ-клавиатурой, мышью, жестким диском - в этом же Вы ничего плохого не видите. А ведь
` этого на спеке не было.

Ну, положим, на АТ-клаву спектрумисты перешли не от хорошей жизни, а что до мыши, винта
и прочих периферийных устройств - ну я же уже высказывался об этом, могу и сейчас повторить:
для домашних компьютеров видео"адаптер" - это совсем не то, что другие устройства (даже
звук). Ну-ка, сколько процентов кода "средней" программы на Спеке (а "средняя" программа -
это игра или дема) занимает обслуживание экрана, а сколько - диска, мыши, клавы и прочего?
А сколько процентов времени разработки занимает написание процедур вывода графики, и сколько
- опроса мыши, подгрузки с диска и так далее? Сколько игрушек у нас адаптировали под диск?
Около 100%, я думаю. ;) Под мышь? Ну, тех, где это имело смысл, конечно, меньше 50%, но
тоже немало. А СКОЛЬКО АДАПТИРОВАНО ПОД ЭТИ ЧУДЕСНЫЕ НОВЫЕ ВИДЕОРЕЖИМЫ? Цифра стремится
к нулю... если не точный ноль. Так что "с точки зрения программиста", с которой я "пока
смотрю", новый видеорежим = новый компьютер.

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

И тем не менее у большинства спектрумистов (в первую очередь - железячников) отчетливо
просматривается некий "комплекс неполноценности" по поводу недостатков и ограничений
стандартной спектрумовской графики. Иначе откуда бы взялись все эти по сути своей
механические попытки перенесения на ZX "лучшего с других платформ". После которых
по-новому начинаешь понимать поговорку "лучшее - враг хорошего" :D :D
На этом фоне, действительно, прикручивание видеочипа от все-таки 8-битного компьютера
выглядит явным прогрессом по сравнению с "EGA-режимом", годящимся только для статичных
картинок, по большому счету.

CHRV> А остальное - это попытки того же творчества-радиолюбительства.

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

CHRV> Задачу я формализовал.

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

Что означает на самом деле (см. выше): и заставить кодить под новый компьютер.

CHRV> Специализированных видеопроцессоров пока не подключали

(Поздно, я уже успел это увидеть! ;) )

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

Lethargeek

12.10.2005, 20:20

CHRV> как бы странно обсуждать что-то с человеком, который реал то не особо юзает

Oh, yeah! Наконец-то! :) Я все ждал, когда же появится этот "убийственный" аргумент.
Действительно, чего с ним обсуждать. Хорошо еще, не спросили, где я был в апреле 1982 года. ;)

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

Отчего такое презрение к "программистам"? А что для Спектрума, за всю его историю, сделали
"программисты" и что - "железячники"? Начать с того, что "спек 48 с точки зрения как
фирменной прошивки, так и с железной стороны - полный урод. А вот софт под него все
недостатки прощает". Это некогда заявил dhau, который тут недавно попытался меня
уничтожить. :rolleyes: Да и у Conan-а на сайте много интересного можно про это почитать.

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

А что же наши железячники? Произвели кучу схем различной степени кривости. Приняли за
стандарт роковой TR-DOS (который "гробовой плитой и стал" - Conan) - видимо, первым
из дисковых интерфейсов достался в руки и был "легко реализуем" на отечественных компонентах.
И дружно ударились в монстростроение.

Да, конечно, многие покупатели в середине 90-х выбирали Спектрум-клоны по принципу "у кого
навороты наворотистей". Но вот убери Спектрум-режим, и кто бы посмотрел на эти навороты?
Были бы очередные CP/M или "самосовместимые" компы, вроде тех, что недавно разрабатывались
(пост)советскими радиолюбителями. И распространены были эти по-своему неплохие компьютеры
(я сейчас имею в виду "второй" компьютер внутри клона) только благодаря "подпорке" в виде
Спектрум-режима, что позволяло "играть в игрушки".

Так что "такой плохой" CHRV "рубит" не мою идею, а сук, на котором сидит.
Любые навороты имеют смысл, если только они работают на Спектрум (то есть на спековский
софт), а не на "второй компьютер в одном флаконе". Особенно сейчас, когда Спек (и именно
Спек) - это исключительно хобби.

Максагор> Нафиг! Покупайте ATMы, и будут у вас различные дополнительные экраны.

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

Ага, и тот же самый Максагор в "истории АТМ" пишет:
"...И это было сделано неспроста. Как я уже говорил, в начале 90-х еще очень многие питали
надежды на более серьезное, чем хобби, использование Спектрума. А для этого, казалось,
нужно всего чуть-чуть – немножко добавить скорости, графики, памяти, расширить периферию
и написать побольше профессионального софта..." И там же - о проблемах и тормозах,
частично решаемых турбо-режимом. То есть расчет изначально был на "профессиональное
применение". И очень скоро стало понятно, что он не оправдался.

И, похоже, именно эти АТМ-овские (и не только АТМ-овские) "схемные" реализации лежат "мертвым
грузом" на плате, только затрудняя какое-либо вмешательство с паяльником.

Не пора ли отбросить личные амбиции, "профессиональную" гордость и тому подобные
факторы и начать наконец РАБОТАТЬ СООБЩА над улучшением и развитием
Спектрума - всех его аспектов. Я понимаю, что "разбираюсь" в железе "широко", а не "глубоко",
но ведь и железячники, если судить по опыту прошедших лет, слабо представляют
себе софтверные проблемы применения своих графических наворотов.

Иначе зачем вообще существует форум? Готовыми схемами хвастаться?
Или все-таки восполнять пробелы в знаниях друг друга, поддержать советом,
подкинуть идею... Много говорилось о "профессиональном подходе".
По-моему, почти во всех сообщениях уважаемых железячников
слово "профессиональный" надо заменить на "УЗКОпрофессиональный".

Я считаю, что как "программист", со своей стороны задачу в значительной степени выполнил -
сформулировал проблемы и пути их решения (конечно, допускающие улучшения) с софтверной точки
зрения. И теперь хотел бы услышать, как это может быть реализовано. А пока получаю
примеры, как (именно "как", не "ПОЧЕМУ"!) это не может быть реализовано.

Lethargeek

12.10.2005, 20:26

Мега-пост. Часть 3.

Ну вот дошло и до "конкретных предложений", которыми я НЕ ХОТЕЛ заниматься. Но приходится.

Интересно, а почему уважаемые железячники сводят проблемы реализации прежде всего к опасности
"рукосуйства", то есть вмешательства с паяльником наперевес в худо-бедно, но работающую плату?
При этом рисуются апокалиптические картины "сизого дыма" из "развороченных внутренностей"
"теперь уже бывших" Спектрумов. Вообще-то, вмешательство с паяльником - это личное дело
каждого, "уже лет как 50 изготовители электроприборов и электроники пишут в инструкциях:
«Самостоятельный ремонт или внесение изменений в конструкцию лишает вас гарантии
производителя». А в журналах типа «Сделай сам», публикуют схемы всяческих доделок.
И мир не скатился из-за этого к катастрофе и небесные хляби не разверзлись" - Conan.

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

Итак, почему возможность внешней реализации нашими профессионалами-АТМ-щикам даже не
рассматривается? Не потому ли, что на всех моделях АТМ, кроме 2++, системный разъем
отсутствует? Или в будущих не планируется? Хотя несколько страниц тому назад читаем:

Splinter> Спек уже оброс подобием Аудиокарты, я про GS, конечно. По моему видео нужно если
` и расширять, то несомненно при помощи видеоадаптера. Тут необходимо лишь определить- что
` лучше: Какая-нибудь видюшка от пц из каменного века, или сколотить абсолютно индивидуальный
` девайс, как в случае с GS.

CHRV> Да, абсолютно согласен с Вами, и веду как раз в этом направлении работы. Как уже
` говорил будет изучаться чип v9990 (так как он доставаем и хорошо документирован).

...

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

Оппа! Значит, v9990 можно сделать как внешнюю видео"карту" (с GS же сравнивается), а что-то
новое - не только (допускаю, кому-то) неинтересно, но и НЕЛЬЗЯ. А как v9990 собирается со
Спеком общаться - только через порты? Или все-таки память будет отображаться?

Что требуется от внешней карты?

Два порта для "четвертушек". Памяти 2*16 кб (или даже 2*8?). Обеспечить перехват
обращений к двум "экранным" страницам памяти. Лучше даже только перехват записи,
причем пусть проц пишет и в реальные страницы (чтобы не было потом чтения с
видеоплаты), и даже пусть "старый" видеосигнал по-прежнему вырабатывается - нам же
лучше, сможем подключить второй монитор. Ну и конечно схема выбора (подчеркиваю,
не "смешивания", а ВЫБОРА) следующего пиксела из того или другого экрана... (да
кстати и смешивание заодно можно реализовать - раз уже и так своя видеопамять -
чтобы получился "настоящий" гигаскрин, как No-flic в эмуляторе).
Уж наверное девайс получится проще, чем General Sound ;)

Или я чего-то (вполне допускаю) не понял и системный разъем для этого не годится?
Так тогда надо не пустыми разговорами о вреде "рукосуйства" заниматься, а
договориться о едином стандарте на самый разъемистый разъем, позволяющий подключать самые
немыслимые девайсы, опубликовать схемы доработок и/или переходников для основных клонов,
выработать соглашения насчет потенциальных наворотов (да, это значит много болтовни, но совсем
не пустой болтовни), да кстати предусмотреть возможность каскадного подключения устройств, не
конфликтующих по ресурсам, чтобы не все через тройники. И вся проблема "рукосуйства" отпадет
сама собой. "Сунуть руки" и рискнуть компом тогда понадобится ТОЛЬКО ОДИН РАЗ, при
монтаже/доработке разъема.

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

Lethargeek

12.10.2005, 20:32

ну и по мелочи:

ASDT> Интересует мнение тех, кто реально пишет игру(ы) ...
` И кому может это расширение принести пользу.
` Если такие есть.

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

Вот присутствую в одной из тем раздела "Игры" - и совсем там другой народ (кроме упомянутого
Newart-а). Ладно, попытаюсь их сюда заманить...

Lethargeek

12.10.2005, 20:33

АБ> А не пора ли честно признаться что за последние годы вышло новых
АБ> игрушек меньше десятка?

пересчитай внимательно :)

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

А это че, типа все игрушки? Ну если в самом общем смысле, тогда конечно... :D

Lethargeek

12.10.2005, 20:34

(чуть не забыл)

Ronin> все понятно, уважаемый. ваш предел - это линейные алгоритмы на асме, максимум с
` call-ами. потому и считаете байты и такты.

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

А насчет "байтов и тактов" - ну-ка, уважаемый, давайте сюда пример какой-нибудь крутой
среды программирования на ZX, где для эффективного вывода графики их не надо считать.
Чего-чего? Laser Basic? Ах, мне послышалось... :D :D :D

Ronin> "реала нет, сам свой суперэкран делать не буду, да и софт сам писать тоже не буду"
` - поправь, я в чем-то неправ?

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

ASDT

12.10.2005, 21:28

"Нужно - не нужно... " Ясно. Вся тема - пустой гон.

SAM style

12.10.2005, 21:37

я думаю вы тут еще долго воду лить будете... У меня года полтора назад была подобная идея, но я хотел смешивать три экрана, получив при этом 16 цветов на пиксел при стандартном 256*192.

Дело было примерно так: имеем 4 куска внешней памяти по 8кБ (в каждой используется по 6кБ, где лежат спековские экраны по #1800 и каждая отвечает за свой цвет - R,G,B и яркость). В моменты, когда в обычном режиме выбирается байт из экранной области, в моей схеме одновременно выбираются 4 байта. Далее идет аналог обычного спека, только в четырехкратном исполнении - в нужные моменты вместо сигнала INF (в стандартном спеке) получаем 4 сигнала - R,G,B,I (яркость). Остается ввести сигнал, отвечающий за то, что будет пропущено в тракт за КП11 - i,r,g,b с нее (стандартный экран) или I,R,G,B с нашей схемы (естественно, на бордюре это стандартные сигналы).

Потом я столкнулся с проблемой - нужны 4 порта для "общения" с видеопамятью и потом: как их делать - так ли необходимо что-то оттуда читать? И как конкретно формировать адрес выборки - по H0..7, V0..7 или как-то из MA0..7?

Я не так хорошо шарю в железе как CHRV но и не так уж плохо! Посему к нему вопрос - можно ли память 8Кбайт организовать в одной микросхеме, чтоб число корпусов не достигало огромного количества и как бы поэкономнее организовать запись в эту память (по моим скромным подсчетам нужен 13-разрядный адрес памяти [два 8-битных порта] и 4 порта для записи байтов в 4 области экрана)

Если мою идею не засыпят землей, а помогут с решением пары проблем,попробую воплотить ее в моем скорпиЁне.

CHRV

12.10.2005, 22:12

Я как и обещал больше не встреваю в спор. Дай бог родиться какой нить интересный режим, и скорпион Sam останется в живых :) (но он наверно припас опять какую нить игру на следующий игру чтобы побораться за некислый приз ;) ). 8kb SRAM это любая 6264.

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

CHRV

13.10.2005, 10:50

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

Может все таки поинтересуемся тем что уже реализовано в железе, ну пожалуйста посмотрите хоть одним глазом доку по программированию АТМ :). Она лежит абсолютно открыто atmturbo.nedopc.com

Конкретно http://atmturbo.nedopc.com/inf/books/nedopc/atm_hard.zip

icebear

13.10.2005, 12:26

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

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

Так тогда надо не пустыми разговорами о вреде "рукосуйства" заниматься, а
договориться о едином стандарте на самый разъемистый разъем, позволяющий подключать самые
немыслимые девайсы, опубликовать схемы доработок и/или переходников для основных клонов,

В простонародье разработать шину. Сколько лет её уже разрабатывают? Сколько было здесь попыток поднять этот вопрос? Кстати, западные друзья в основном ориентируются на системный разъём оригинального Спектрума, которым в советских клонах и не пахнет.

"Сунуть руки" и рискнуть компом тогда понадобится ТОЛЬКО ОДИН РАЗ, при монтаже/доработке разъема.

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

TomCaT

13.10.2005, 17:42

2 Lethargek

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

Чтобы поднять Speccy, надо его уважать. Такого, какой есть. Поэтому без совместимости ничего не выйдет...

Вы говорите, Васик может пострадать. Почему? Если аппаратные указатели таблиц аттрибутов (очнь хорошая идея, имхо!) будут указывать КУДА УГОДНО в первой странице, хотя бы на одно и то же место -- чем страдает Васик? И неужели в сиспеременных так мало резервных мест, что эти сиспеременные нельзя использовать как для смены указателей, так и для управления всем нововведением (вкл./выкл. -- для совместимости ;) )

fan

13.10.2005, 19:55

Дело было примерно так: имеем 4 куска внешней памяти по 8кБ (в каждой используется по 6кБ, где лежат спековские экраны по #1800 и каждая отвечает за свой цвет - R,G,B и яркость). В моменты, когда в обычном режиме выбирается байт из экранной области, в моей схеме одновременно выбираются 4 байта. Далее идет аналог обычного спека, только в четырехкратном исполнении - в нужные моменты вместо сигнала INF (в стандартном спеке) получаем 4 сигнала - R,G,B,I (яркость). Остается ввести сигнал, отвечающий за то, что будет пропущено в тракт за КП11 - i,r,g,b с нее (стандартный экран) или I,R,G,B с нашей схемы (естественно, на бордюре это стандартные сигналы).
Чёто я не вижу смысла во "внешней" памяти, какя разница что где находится если выводом занимается контроллер а зашвыривать картинки(графику) всё равно куда .
R,G,B,I (яркость) - экономия на спичках , никто не мешает прикрутить по ЦАПу на каждый цветовой(RGB) канал (как в спринтере), при этом R,G,B,I (яркость) привратится в нормальный четырёх бытный экран , те же 16 цветов но с произвольной палитрой . Самый попсовый вариант - трёх битный экран (8 цветов) с произвольной палитрой . Можно ещё сделать разрешение по попсовей 128*192 , да и ваще по всякому извращаться . Но лучше это переложить на плечи однокристалки , а не рассыпухи .

SAM style

13.10.2005, 20:41

Чёто я не вижу... bla-bla-bla...
Жду ТВОЮ схему - какие сигналы куда, сколько корпусов, что делают,а также процессорные и денежные затраты на это. А сопли "о том что-де вон там так сделано а мы тут так никак не..." нахрен мне не нужны. Даю неделю. После истечения срока - ко мне в штаб с докладом о проделаной работе. А теперь кру-у-у-гом и дуй разрабатывать новый видеорежим.

PS: у меня другая стратегия - сделать и предложить сделаное, а не мазать сопли на хлеб и ничего не делать

fan

14.10.2005, 03:50

Зачем так резко реагировать ??? Здесь вполне мирная дискуссия, ну почти мирная :D

Готовое решение как бы есть http://zx.pk.ru/showthread.php?t=1597
И кто чтобы ни говорил , из реально реализуемых вариантов только тот , если так можно сказат (учитывая желание народа покупать и программировать ;) ), хотя бы по той причине что уже всё готово и подключается мягко говоря попроще чем любой рассыпушный вариант + разновидность клона не имеет значения .

Spectre

14.10.2005, 10:27

Готовое решение как бы есть http://zx.pk.ru/showthread.php?t=1597 И кто чтобы ни говорил , из реально реализуемых вариантов только тот , если так можно сказат (учитывая желание народа покупать и программировать ;) ), хотя бы по той причине что уже всё готово и подключается мягко говоря попроще чем любой рассыпушный вариант + разновидность клона не имеет значения .

Это изначально мертвый вариант. Вот например найду я сейчас исходник любой своей игрушки, пускай это будет Clickmania. Так вот хоть там и мало используется динамической графики, но переделать ее под V9990 весьма проблематично (даже имея исходник на руках!). И как думаешь сколько еще народу будет рассуждать как я?

А попробуй переделать Wolf...

ASDT

14.10.2005, 14:49

Vladimir Kladov

14.10.2005, 16:33

"Вот например найду я сейчас исходник любой своей игрушки"
А может "Добрый и отзывчивый" Spectre скажет своё веское слово?
Каким он видит расширение ... которое может пригодиться для игр ...
а можно я скажу? я с года полтора уже назад повторил (и немного усовершенствовал) идею испнских товарищей, так называемый Spec256. Лезть в код и переделывать его чтобы код работал на заполнение дополнительной видеопамяти "не так как это было" в мире 48-128 - не надо. Программирование не требуется. Начнем с этого. И этим собственно надо бы заканчивать, изобретая новый видеорежим. В эмуляторе реализовать удалось. Есть два десятка игр уже переделанных. Дело за железячниками - повторить в реале. Кто первый? Объем памяти - реальный, кстати. Надо не забыть придумать способ для заполнения цветной памяти только - при загрузке снапшота с дика. Например, эта память может быть доступна линейно через море дополнительных банков. Я подозреваю, что придется поставить в ряд 8 штук Z80, а в некоторых случаях выполнять операции на ППЛМ (или как они там называются). Но ведь вполне реализуемо. Только если найдется кто действительно желающий. Ладно, проехали... Были бы - уже давно бы воплотилось.

fan

14.10.2005, 17:05

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

ИМХО - с Wolf вполне можно извратиться на V9990 (будет выглядеть аля цитадель, хотя я не очень помню как она выглядела) . В "софтовых" расширенных режимах (от трёх бит и выше ;) ) Wolf просто впадёт в кому .

Spectre

14.10.2005, 17:19

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

Проблема в инерционности мышления. Если кодер Вася Пупкин в совершенстве знает систему команд Z80 и архитектуру Spectrum 128K, то должен быть очень существенный повод чтобы он изучил (и начал использовать!) что-то принципиально новое. За деньги это один разговор, когда же это просто хобби желающих нет.

ИМХО - с Wolf вполне можно извратиться на V9990 (будет выглядеть аля цитадель, хотя я не очень помню как она выглядела) . В "софтовых" расширенных режимах (от трёх бит и выше ;) ) Wolf просто впадёт в кому .

То как будет выглядеть представить очень даже легко. Нарисовать картику в BGE (Photoshop) не проблема, написать весь код игры (программы) совсем другая песня.

SMT

14.10.2005, 17:22

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

Spectre

14.10.2005, 17:23

а можно я скажу? я с года полтора уже назад повторил (и немного усовершенствовал) идею испнских товарищей, так называемый Spec256. Лезть в код и переделывать его чтобы код работал на заполнение дополнительной видеопамяти "не так как это было" в мире 48-128 - не надо. Программирование не требуется. Начнем с этого. И этим собственно надо бы заканчивать, изобретая новый видеорежим. В эмуляторе реализовать удалось. Есть два десятка игр уже переделанных. Дело за железячниками - повторить в реале. Кто первый? Объем памяти - реальный, кстати. Надо не забыть придумать способ для заполнения цветной памяти только - при загрузке снапшота с дика. Например, эта память может быть доступна линейно через море дополнительных банков. Я подозреваю, что придется поставить в ряд 8 штук Z80, а в некоторых случаях выполнять операции на ППЛМ (или как они там называются). Но ведь вполне реализуемо. Только если найдется кто действительно желающий. Ладно, проехали... Были бы - уже давно бы воплотилось.

Очень давно хотел спросить суть раскрашивания в Spec256? Я думал это что-то вроде anti64 в US, то есть перехватываем вывод на экран спрайтов и подставляем уже готовые перерисованные, а значит на реальный спектрум идея не портируется. Но похоже я был не прав?

icebear

14.10.2005, 17:35

Только если найдется кто действительно желающий. Ладно, проехали... Были бы - уже давно бы воплотилось.

Я прям боюсь спросить о принципе действия этого расширения до 256 цветов.

SMT

14.10.2005, 17:40

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

icebear

14.10.2005, 18:39

к каждому биту спектрумовской памяти

Это понял, давай посчитаем. 6144х8 = 49152 => 48К. Сходится с расходом для разрешения 256х192х8. Т.е. грубо говоря 48К отдельной памяти.

и к каждому биту регистра z80 приклеивается дополнительный байт. когда биты пересылаются, этот байт тоже.

А это зачем? В смысле зачем мониторить _биты регистров_ (или всё же сами регистры)?

при арифметических/логических операциях применяются свои действия (сходу не скажу, какие). нужно всего лишь узнать,

Ну да, что бы например вычислить правильную результирующую при наложении двух цветов, так? Только вот как узнать, где спрайты лежат? Хак?

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

Хм, медленно. И сложно. Но выход. :)

SMT

14.10.2005, 19:04

Это понял, давай посчитаем. 6144х8 = 49152 => 48К. Сходится с расходом для разрешения 256х192х8. Т.е. грубо говоря 48К отдельной памятида, но каждый z80 работает со своим 6144 (или эмулятор гоняет не 8-битные регитры, а 8-байтные mmx-регистры), так что скорость не страдает
и к каждому биту регистра z80 приклеивается дополнительный байт. когда биты пересылаются, этот байт тоже
А это зачем? В смысле зачем мониторить _биты регистров_ (или всё же сами регистры)?чтобы не вносить изменения в код игры. когда байт читается из памяти, где лежит спрайт, в регистр, приклеенные цвета читаются в этот же регистр. при сдвигах или иной обработке данных, считанных из спрайта, приклеенные байты цвета перемещаются вместе с битами спрайта. в итоге они попадут на экран и пофиг, как над ними извращался программёр, хоть писал через стек
Только вот как узнать, где спрайты лежат? Хак?есть тулзы, как на пц, так и спектруме, для просмотра памяти в графическом виде. спрайты выцепляются визуально
Хм, медленно. И сложно. Но выходна реале - чушь собачья. если уж и ставить 8 процессором (да что там - 8 спектрумов), то лучше, чтобы они не обрабатывали синхронно одну и ту же программу, отличаясь содержимым памяти только в местах спрайтов, а сделать так, как я написал 17:22

Lethargeek

14.10.2005, 19:31

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

Могло создаться впечатление, что я грубо наезжаю вообще на компьютер АТМ и его производителя
(упаси меня! тем более, он последний "живой" остался). Это не совсем ( ;) ) так.

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

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

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

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

Пусть и дальше совершенствуется "расширенная часть" Спектрум-клонов - приделыванием ли
внешних наворотов или их интеграцией в схему - желаю успехов. Но только не следует забывать,
что совершенствоваться она должна ВМЕСТЕ со Спектрум-частью. А не ВМЕСТО нее.

Lethargeek

14.10.2005, 19:42

Хм, чего-то опять в монстрологию ударились. Ну хоть оживление какое-то....

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

Кстати, как насчет переделки в такую видеокарту старых 48К Спектрумов, пылящихся на антресолях, и тому подобного барахла?

P.S. CHRV, а что, последнее предложение недостаточно конкретно...
Или только и можем, что чайников "сизым дымком" пугать?

Какие проблемы будут при внешней реализации, например, для того же ATM Turbo 2++ ?

И вообще, будет ли в дальнейших АТМ системная шина (сколько слотов) и какая?

P.P.S. Не отступать и не сдаваться! ( Пошел домой отвечать остальным... )

icebear

14.10.2005, 20:13

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

Идея не нова и очень хороша (тем, что оформлена отдельным самостоятельным модулем). Немцы например таким образом создали контроллер LCD дисплея в 96-97 годах для ZX-81. С собственным Z80 (ну тогда просто всякие матрицы не особо были распространены среди мирного населения).

Vladimir Kladov

14.10.2005, 22:59

да, правильно, это должно быть именно 8 спеков, примерно одинаковых по конфигурации. Лучше брать именно 48К или 128К без дополнительных наворотов. (и переделывать тогда - как и сейчас делается - игры сделанные для этих режимов). Я уже представляю себе этого реального монстра (вообще реально, без шуток) - 8 параллельно установленных плат, на 7 отрезаются входы инта, wait'а, и clk, и протягиваются соответствующие провода от 1-го - ведущего - спека на 7 прочих. Чтобы в итоге все 8 пахали как один. Видеовыходы со всех компов собираются в один композитный сигнал 256 цветов и идут на обычный ibm-ный моник (в цифре или аналоге, это уже не суть - как спаяется). Но нужно еще кое-что. Там есть ряд операций, которые несколько отличаются от того, что делал бы проц с обычным байтом из 8 бит. Обычно это дело касается работы с регистром L, и есть еще одна фишка. Некоторые спек-проги для естественной экономии крупные спрайты хранят один раз, а для выполнения операции сдвигов, отображений, маскирования таких спрайтов при выводе на экран держат в памяти несколько (штук 7) 256-байтных таблиц. Так вот, по сигнатурам я в эмуляторе определяю, что прога делает сейчас именно такое действие, и маленько кое-что делаю, чего проц сам бы не сделал. (Собственно, это и есть мое главное усовершенствование против Spec256, хотя есть еще парочка фишек. Ну, не считая тулзы для раскраски). В общем если кто загорится, я подробно выделю все эти операции, и детально расскажу. Но тогда - чур - не отверчиваться: паяльник в зубы - и вперед :) В общем, для таких операций надо действительно отслеживать содержимое регистров, и смотреть на память, и это должна делать какая-то дополнительная плата.

А насчет 6144 - это вы неправильно поняли. КАЖДОМУ биту оперативки соспоставляется байт расширенной граф-памяти. Итого 48Кх8=384К или 128Кх8=1024К=1М. SMT-то понял... он-то правильно объясняет :)

Тулза для переделки есть у меня в эмуляторе, достаточно мощная, чтобы выполнять поиск спрайтов и их раскраску почти всю. Проще посмотреть на уже переделанные игры (опять же лучше под EmuZWin - Spec256 не имеет тулзы, и не поддерживает некоторые преобразования - не все переделки под ним правильно пойдут. Может потому испанцы и забили в 2000 году на это дело. А жаль - идея классная, просто немножко опередила время. Мне-то намного проще было, с ММХ, я действительно гоняю 64-битные байты через ММХ-регистры, скорость вообще практически не падает).

Да, чуть не забыл. Там еще может подрисовываться фон. Например, каменный или травянистый фон в knight lore, или облачка в BruceLee. В эмуляторе для этого используется набор сигнатур из экранной области, при прорисовке по определенным правилам вместо пикселов, которые считаются прозрачными в экране спека, подставляются 256-цветные пикселы из текущего бакграунда. По сигнатуре в экране, бакграунд может переключаться. Сигнатуры естественно задает тот, кто графику раскрашивает, для подготовки бэкграундов в нужном формате 320х200х256 есть отдельная тулза. Вот и вся техника. В эмуляторе действительно просто. И игры действительно переделывать несложно - нужно лишь уметь пользовать паинтбрашем.

fan

15.10.2005, 16:14

Восемь спеков :v2_eek: и каждый по ~20у.ё. :v2_eek:
(и всё это взамен десятибаксовой фентифлюшки :v2_unsur: )

Lethargeek

16.10.2005, 20:17

ASDT> "Нужно - не нужно..." Ясно. Вся тема - пустой гон.

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

Lethargeek

16.10.2005, 20:18

TomCaT> ...чем страдает Васик?

Васик страдает, если кому-то приспичит из Васика четвертушки переадресовывать. Просто экран
может максимум потребовать 9 килобайт - линейно это делать нельзя, так как "залезет" и на
сиспеременные, и на Бейсик-область. Надо либо сдвигать ее, либо в REM-строке отводить
место (опять же с учетом, что Бейсик-область может быть сдвинута тем же Тыр-Досом).
А если из Васика не использовать эту фичу - то и не надо об этом думать, конечно, имеем
стандартный экран с точки зрения юзера.

И вообще, вторая часть (про спрайтовый и фоновый специализированные экраны) гораздо важнее.

Lethargeek

16.10.2005, 20:19

icebear> Потому что большинство не имеет возможности этого сделать "снаружи" (читай
системного разъёма нет), а если и имеют, то "снаружи" у всех нестандартное (не в пределах
одной модели конечно). Надеюсь я понятно выразился?

Ну меня же здесь затоптали, как будто я призываю в самые кишки лезть. Кто-то, может, и
залезет, кто-то снаружи сделает. Ну, разные разъемы - так на то переходники есть. Или они
еще и электрически разные? Чего сложного-то? Надеюсь, у всех выведены A0-A15, D0-D7,
WR, INT, что там еще надо... Ну, будут варианты схем для разных клонов, ну и что, не
крупносерийное же производство намечается.

icebear> В простонародье разработать шину. Сколько лет её уже разрабатывают? Сколько было
здесь попыток поднять этот вопрос? Кстати, западные друзья в основном ориентируются на
системный разъём оригинального Спектрума, которым в советских клонах и не пахнет.

(Хм, а сколько было попыток?)
Вот я и говорю, в этом контексте все разговоры о вреде "рукосуйства" - ПУСТЫЕ.

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

icebear> Тебя не наводит на мысль, что это будет уже другой компьютер?

И называться будет не "клон советский, условно совместимый", а "почти фирменный Спектрум".
Побольше бы нам таких других компьютеров... :D :D :eek:

Lethargeek

16.10.2005, 20:21

SAM style> Если мою идею не засыпят землей, а помогут с решением пары проблем,
` попробую воплотить ее в моем скорпиЁне.

CHRV> Может все таки поинтересуемся тем что уже реализовано в железе, ну пожалуйста
` посмотрите хоть одним глазом доку по программированию АТМ

Хоронить однозначно! SAM, ну если так хочется попаять, полюби мою идею, а? ;)
Уж на что я "разругался" с CHRV, но тут полностью согласен - это все есть на АТМ, причем
с куда менее жуткой адресацией (хотя тоже не подарок). Но для системных применений пойдет.

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

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

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

Lethargeek

16.10.2005, 20:23

Vladimir Kladov> а можно я скажу? я с года полтора уже назад повторил (и немного
усовершенствовал) идею испанских товарищей, так называемый Spec256. Лезть в код и
переделывать его чтобы код работал на заполнение дополнительной видеопамяти
"не так как это было" в мире 48-128 - не надо. Программирование не требуется.
Начнем с этого. И этим собственно надо бы заканчивать, изобретая новый видеорежим.
В эмуляторе реализовать удалось. Есть два десятка игр уже переделанных. Дело за
железячниками - повторить в реале. Кто первый? Объем памяти - реальный, кстати. Надо не
забыть придумать способ для заполнения цветной памяти только - при загрузке снапшота с
диска. Например, эта память может быть доступна линейно через море дополнительных банков.
Я подозреваю, что придется поставить в ряд 8 штук Z80, а в некоторых случаях выполнять
операции на ППЛМ (или как они там называются). Но ведь вполне реализуемо.

Сначала небольшие уточнения (исключительно относительно моей идеи):
-- Конкретно у меня код не работает "на заполнение дополнительной видеопамяти". Как писал
в спековские экраны, так и пишет, все это "прозрачно" для программиста. Просто при внешней
реализации удобнее дублировать эти данные на видеокарте и там над ними издеваться.
-- "Лезть в код" - не проблема (как я уже высказывался ранее). В самом простом случае
достаточно только адреса поменять и значения атрибутов. И вообще сложность адаптации
можно в начале работы выбрать индивидуально "под себя". Все-таки четвертушки - это больше
для новых проектов и для дем, для адаптации "спрайтовый экран" важнее. А в этом случае
основное отличие моего предложения от всех остальных - изменяется не то, ЧТО выводится,
а то, КУДА выводится. Маска (если нужна) - на фоновый экран, спрайт - на другой.
Раскрашивать фон атрибутами - по желанию. По моему, по трудоемкости это меньше, чем
искать и раскрашивать кучу графики, даже если "программирование не требуется". О том,
как оно "не требуется", смотрим ниже.

Теперь общие замечания:

1. Уж больно устройство монструозное вырисовывается... прямо чудовище Франкенштейна :)
Меня тут АТМ-щики за куда меньшее уничтожали. ;) Хотя удачи, конечно, если кто возьмется.
И в связи с этим -

2. "А будет ли это Спектрум?" Вечный вопрос, задаваемый по любому поводу. :D Но я здесь
имею в виду несколько другое. Конечно, 256 цветов в эмуляторе - это прикольно, интересно
же, "как это могло бы быть". Но для меня лично Спектрум (или даже сверхнавороченный клон,
но в спектрум-режиме) прежде всего ценен именно как ретро-машина, позволяющая вновь ощутить
"вкус эпохи", так сказать. Я не против наворотов, работающих "на Спектрум", даже если они
собраны из современных железок - важно, чтобы девайс в принципе был реализуем тогда,
в середине 80-х (и по разумной, опять же тогда, цене). Хотя по этому вопросу могут быть
мнения самые разные, и я на этом пункте не настаиваю.

Но это все про железки, ладно, это не мой конек. Что мне понравилось - наконец-то
предложенный наворот работает на Спектрум). Но дело в том, что не стоит
хвататься за паяльник, пока сам принцип действия недопродуман и имеет очевидные
изъяны. Вот какие проблемы возникнут "с точки зрения программиста":

3. Запускать из снапшота на диске? Фэ! Гадость какая! Перед глазами встают
страшные картины программ, изуродованных кнопкой Magic. :mad: Ну ладно, нормальный снап
можно сделать и в эмуляторе, но загружать-то его надо будет в реал, а это "две большие
разницы". И всегда будут подозрения по поводу странного поведения игрушек в случае
затыков. Аркады-то еще ладно, а вот если что-то типа Heavy on the Magic?

4. Все-таки большие сомнения по поводу универсальности метода, пусть даже математические
операции особым образом обрабатываются (тем более, что виденные мной игрушки глючат).
А если спрайты распаковываются и дорисовываются в начале каждого уровня, как в Renegade?
А в Spy vs Spy, например, так и вообще спрайты без маски хранятся, как будто они
четырехцветные, да еще и низкого разрешения, то есть по два бита на "широкий" пиксел.
И потом хитрой процедурой (забыл подробности) выводятся на экран. Вообще, трудно судить
без знания особенностей алгоритма, но спрайты в принципе могут такими способами
распаковываться... тот же сдвиг, например, может производиться командой add... А если
пара комманд ccf+adc ? А если вообще при дорисовке спрайта используется что-нибудь типа
res и set (то есть биты берутся "ниоткуда"). Изврат, конечно, но мало ли?

5. Вот сейчас гоняя игрушки на EmuZWin, почувствовал: что-то "не так". Пригляделся.
Ну вот, например, Cybernoid - все одинаковые дроиды одинаково раскрашены. А ведь в
оригинале не так. Вот те на! А что, атрибуты совсем не обрабатываются? :( Или из
попыток их учесть и получаются глюки, вроде как в главном меню? Так, теперь запускаем
Jetpac... того хуже - ракета не красится, когда на нее топливо сбрасываешь!!
Ну ладно, Jetpac - простая игра, и можно догадаться, когда "заправка окончена" (хотя
несколько секунд промедления могут оказаться фатальными). Но возможны и более серьезные
случаи, когда одинаковый спрайт выводится разным цветом, и это важно для логики игры.
В эмуле я 256-режим временно отключу и посмотрю (и то неудобно), а на реале? Два монитора
подключать? Или тумблером щелкать то и дело, мучая кинескоп? Можно, наверно, исправить,
но в железе это будет еще тот геморрой - своя палитра для разных атрибутных цветов одного
спрайта. И вообще, как эмулятору-то понять (не то что железу), что раньше выводится -
атрибут или сам спрайт? Да еще наложенный на фон, возможно... А если вообще как угодно
в разном порядке - например, в одно и тоже знакоместо последовательно выводятся атрибут А,
спрайт А, спрайт Б, атрибут Б - как с этим бороться? :(
А вот еще есть замечательная игрушка Thanatos, не так давно ее ковырял-исправлял, и многое
еще помню. Там дракон рисуется из отдельных кусков "морда-шея-крылья-пузо-лапы-хвост".
Причем сначала проверяется атрибут в соответствующем месте экрана (буфера вообще-то, но
не суть важно), и для определенных цветов знакоместо сначала вычищается, а уж потом
печатается спрайт. А еще там иногда используется векторная графика (при подлете
к городской стене), причем и с попиксельной, и с атрибутной заливкой (что я и
исправлял, ибо сделано было криво ;) ). Ну вот как ТАКОЕ предусмотреть?

Вот и выходит, что в общем случае ВСЕ РАВНО БЕЗ ПРОГРАММИРОВАНИЯ НЕ ОБОЙТИСЬ.
Предлагаемый метод в полной мере годится только для монохромных игрушек. В связи с чем
приходит на ум приснопамятный проект ZM-Polyhedron, он же ZX-Fenix (почему-то именно так
- а не Phoenix) - там изначально говорилось об автоматическом раскрашивании спековских
монохромных игрушек. (Интересно, что имелось в виду под "автоматическим"?)

Буду рад получить от VK разъяснения, если я чего-то недопонял...

Lethargeek

16.10.2005, 20:25

К слову, раз уж был упомянут Spy vs Spy, и раз уж тут бывает SMT, хочу подкинуть простую
идейку видеофильтра для эмулятора. Мож не в тему, конечно, но...

Совесть Летаргика> Ай-яй-яй, в собственной теме офтопик разводишь!

Летаргик> Всем можно, а мне нельзя? Ну один-то раз?

Ну так вот. Помимо Spy vs Spy, существует еще несколько подобных игрушек (навскидку
могу вспомнить еще Leviathan и Out of this World), где вертикальной штриховкой
имитируется четырехцветная "Атаровско-Комодуровская" графика низкого разрешения (сама
графика, соответственно, вся напрямую передранная). Но выглядит как-то не очень...

Почему бы для таких игрушек не добавить соответствующий фильтр "fake low-res" - или
с четырьмя задаваемыми цветами, или добавить два средних между INK и PAPER. Только
накладывать не на весь экран, а в начале кадра автодетектить все "двухцветные" окна,
большие заданных размеров по ширине/высоте, и только к ним применять.

Собственно, слово "фильтр" надо взять в кавычки, это просто режим вывода, он может
использоваться одновременно с другими фильтрами. Также можно попробовать включить
и для обычных "монохромных" игр (типа Flying Shark, например) или на весь экран для
"цветных" игр (Cybernoid). Я уже пробовал на своем самопальном эмуле. Результат
интересный. ;)

SAM style

16.10.2005, 22:25

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

И так нужен, что ли, этот режим "каждая точка своим цветом"? Зачем? Для хентаев всяких гигаскрина не хватает?Чем красивше, тем лучшее. и не надо на меня вешать ярлык главного производителя хентая на спеке - скоро завяжу

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

Ты еще спрашивал, много ли надо на системной шине для видеокарты. Кроме a0..a15, d0..7, iorq, memrq, wr, rd для "общения" с видео надо еще h0..h7,v0..v7 (и brd,Hsync,Vsync?) для вывода на экран. Есть ли где-нибудь шины с этими сигналами, мне неизвестно (сомневаюсь что есть)

PS: а без вмешательств в схему спека все равно не обойтись, хотя бы для того чтоб поменять адрес нахождения атрибута, надо оторвать 16 сигналов!

SMT

16.10.2005, 23:11

в общем случае ВСЕ РАВНО БЕЗ ПРОГРАММИРОВАНИЯ НЕ ОБОЙТИСЬну для эмуля это легко пофиксить - где к битам не закреплены цвета, там атрибуты не игнорировать
Ты еще спрашивал, много ли надо на системной шине для видеокарты. Кроме a0..a15, d0..7, iorq, memrq, wr, rd для "общения" с видео надо еще h0..h7,v0..v7 (и brd,Hsync,Vsync?) для вывода на экран. Есть ли где-нибудь шины с этими сигналами, мне неизвестно (сомневаюсь что есть)
PS: а без вмешательств в схему спека все равно не обойтись, хотя бы для того чтоб поменять адрес нахождения атрибута, надо оторвать 16 сигналовбыла же идея сделать независимый девайс, с копией видеопамяти. нужно-то всего SRAM 62128 на 16kb/7mhz и одна ПЛМ-ка,куда упихаются счётчики и мелкая логика - обвеска счётчиков, V/H sync, сдвиговый регистр. так что от шины надо a0-a15, mreq, wr, d0-d7, iorq, m1 (для порта) и ничего не резать

для обычных "монохромных" игр (типа Flying Shark, например) или на весь экран для "цветных" игр (Cybernoid)пока посмотрел только Leviathan, не понял, что нужно, если не chunk 2x2 (не о них же речь)
Я уже пробовал на своем самопальном эмуле. Результат интересныйвыложи скриншоты, тогда сразу станет ясно
Эх, была бы поддержка в нормальном эмуле, уже начал бы софт адаптироватьв самопальный вставь :)
и так ковыряю все время

Dima Bystrov (2:5029/77.48)

17.10.2005, 07:13

From: Ryazan (Ryazan_Net)<hr>
Hello Дмитрий!

12 Oct 05 22:03, Дмитрий Малычев wrote to All:

пересчитай внимательно :)

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

А это че, типа все игрушки? Hу если в самом общем смысле, тогда
конечно... :D

Это не игрушки, это вообще-то подпись :) Я за последние годы (а точнее, за
прошлый год) выпустил всего 2 игрушки. Hо есть такой конкурс "Твоя игра" и был
такой ЦЦ'2004 - покопайся там. Также были товарищи Tasman и SAM Style,
выпустившие энное кол-во игр. И ещё энное кол-во игр выпущено отдельно.

Hасчёт видеорежимов: использование памяти компьютера неэффективно с точки
зрения скорости. Больше потеряешь на пересчёте координат. Устройство должно
висеть на портах (с 8-разрядным адресом), координаты должны передаваться
координатами, а при передаче байтов координата X должна автоинкрементироваться.
Должен быть один "прозрачный" цвет (отключаемый). Должны быть функции
скроллинга и заливки прямоугольника. В этом и только в этом случае ZX может с
ветерком прокачать 320*240 экран в 256 цветах с ЛЮБЫМ содержимым (без
ограничения на геометрию, кол-во спрайтов и т.п.).
Весь обсосанный комплекс идей уже был отослан CHRV, а сюда его кидать нет
смысла. Кидалось тому, кто МОЖЕТ реализовать.

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

... ZX Spectrum today

Dima Bystrov (2:5029/77.48)

17.10.2005, 07:13

From: Ryazan (Ryazan_Net)<hr>
Hello Guest!

12 Oct 05 22:03, Guest from forum zx pk ru wrote to All:

я думаю вы тут еще долго воду лить будете... У меня года полтора назад
была подобная идея, но я хотел смешивать три экрана, получив при этом
16 цветов на пиксел при стандартном 256*192.

Hе спеши паять, подожди, когда я свою схему того же самого допаяю и первую
софтинку напишу. У меня никакой внешней памяти не нужно, всего-навсего
формируются управляющие сигналы взамен существующих.

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

... ZX Spectrum today

jtn

17.10.2005, 07:34

была же идея сделать независимый девайс, с копией видеопамяти. нужно-то всего SRAM 62128 на 16kb/7mhz и одна ПЛМ-ка,куда упихаются счётчики и мелкая логика - обвеска счётчиков, V/H sync, сдвиговый регистр. так что от шины надо a0-a15, mreq, wr, d0-d7, iorq, m1 (для порта) и ничего не резать
есть одна труднорешаемая проблема - идентификация второго экрана

Dima Bystrov (2:5029/77.48)

18.10.2005, 06:35

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)

19.10.2005, 06:05

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

19.10.2005, 07:07

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

19.10.2005, 16:57

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

icebear

19.10.2005, 19:08

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

Где-то месяца полтора назад я поднимал (http://zx.pk.ru/showthread.php?t=1171) подобный вопрос в разделе "Программирования". Были вполне конкретные ответы.

Lethargeek

19.10.2005, 20:16

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

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

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

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

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

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

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

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

Lethargeek

19.10.2005, 20:17

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

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

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

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

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

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

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

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

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

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

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

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

Lethargeek

19.10.2005, 20:23

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

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

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

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

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

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

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

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

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

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

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

Lethargeek

19.10.2005, 20:26

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

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

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

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

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

Lethargeek

19.10.2005, 20:27

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

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

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

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

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

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

ПЛЮСЫ:

- Совместимость с оригиналом полная - все атрибуты работают
' точно так же - даже спрайты смогут 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-режимов! вам это интересно?

Lethargeek

19.10.2005, 20:29

Сразу поясняю, что 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

19.10.2005, 22:46

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

Сразу поясняю, что SCF значит "Spectrum Coder Friendly" (или просто Spec-friendly), а APAжаль только, в железе будет 1-2 устройства, поэтому софт будет лишь демонстрационный. а плату с 9900 можно серийно (и без убытков!) выпускать

jtn

20.10.2005, 07:57

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

Vladimir Kladov

20.10.2005, 09:19

Spectre

20.10.2005, 15:57

опять 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

20.10.2005, 19:38

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

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

Lethargeek

20.10.2005, 19:46

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

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

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

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

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

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

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

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

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

Lethargeek

20.10.2005, 19:49

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

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

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

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

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

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

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

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

Lethargeek

20.10.2005, 19:52

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

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

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

Lethargeek

20.10.2005, 20:00

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

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

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

CHRV

20.10.2005, 20:41

"свои 5 копеек" :)
Я ещё толком не обумывал эту тему, но расширение
до вга-свга имеет смысл с применением внешних (иса) видеокарт.
Их цена - 0, только надо продумать интерфейс.
У каждого СВГА своя реализация карты регистров, а это значит надо писать драйвра, ес-но кто никто не будет этим заниматься, и это не годится для серии.
А вообще купи себе писюк и не мучайся! ;)

CHRV

20.10.2005, 20:44

ASDT

20.10.2005, 22:24

"имеет смысл с применением внешних (иса)"
Здесь будет поболее смысла ...

"люди никакого отношения не имеющие"
Проще говоря - гон.

Ewgeny7

21.10.2005, 00:05

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

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

P.S. Добавлю свое ИМХО насчет схемотехники. При увеличении глубины цвета на квадратный дюйм возрастает время на "заполнение" поля памяти процессором. Кроме того, жалко тратить основную память Спека под расширенный экран. Поэтому предлагаю сделать видеопроцессор на отдельной плате, вставляемой с СТАНДАРТНЫЙ слот ZX-BUS (он же Scorpion&Kay), предусмотреть два переключаемых поля памяти (экрана) для спокойной перерисовки "теневого" экрана перед выводом его на монитор. И, наверное, не стоит делать большую глубину цвета, а остановиться на тех же "четвертушках". Чтобы понять глубину этой мысли, можно умножить время перерисовки обычного экрана например на четыре, или просто посмотреть эмулятор "ОРИОН-128". Там это очень наглядно показано :)

hardy

21.10.2005, 00:17

Лично от себя скажу - будет готовая схема, доступная по цене комплектующих и их доступности, я готов заняться мелкосерийной сборкой для тех, на ком собственно, и держится платформа Спека - тех самых кодеров, художников и иже с ними.ПОЛНОСТЬЮ С ТОБОЙ СОГЛАСЕН И ПОДДЕРЖИВАЮ ТВОЮ ИДЕЮ, БУДУ РАД ПОМОЧЬ ТЕМ КОМУ ЭТО ДЕЙСТВИТЕЛЬНО ПОТРЕБУЕТСЯ...
"Я тоже готов заняться сборкой для тех, на ком собственно, и держится платформа Спека - тех самых кодеров, художников и других Спектрумистах"
ТОЛЬКО ТАК, МЫ СМОЖЕМ ПРОДЛИТЬ ЖИЗНЬ СПЕКТРУМА.

ИЛИ Я НЕ ПРАВ ???

Alexandre Korjushkin (2:5033/21.19)

21.10.2005, 16:35

FromNet: Pskov (Pskov_Net)

Здpавствyйте, Владимиp!

[15 Oct 05][01:15] Владимиp Кладов(2:5057/56.380) -> All:

да, пpавильно, это должно быть именно 8 спеков, пpимеpно одинаковых по
конфигypации. Лyчше бpать именно 48К или 128К без дополнительных
навоpотов. (и пеpеделывать тогда - как и сейчас делается - игpы
сделанные для этих pежимов). Я yже пpедставляю себе этого pеального
монстpа (вообще pеально, без шyток) - 8 паpаллельно yстановленных

А зачем так сложно? Почемy бы не сделать по пpинципy ПЦ-шного ЕГА, pазбить видеопамять на битовые плоскоти? Т.е., напp для 16-цветов 4 плоскости, в каждой r,g,b и яpкость соответсвенно. Есть несколько pежимов записи, пpи котоpых байты, записываемае пpоцом всячески могyт комбиниpоваться с данными видеопамяти и pегистpами видеоадаптеpа, заодно над ними пpоизводятся некотоpые логические опеpации. Hапpимеp, в одном pежиме записи данные пpоца записываются как есть во "включенные" битовые плоскости. В дpyгом сpазy все битовые плоскости yстанавливаются в соответствии pегистpом цвета адаптеpа(байт от цпy выполняет pоль маски) и тд. Еще есть 8 pегистpов-защелок, пpи этом можно пеpесылать память-память сpазy 8 полноцветных точек(кстати, количество плоскостей(цветов) тyт может быть любым) - все действия и скоpость бyдyт как пpи стандаpтном спековском pежиме. Атpибyты можно было б использовать для выбоpа своей палитpы для отдельного знакоместа - полyчится кpyче, чем ЕГА/ВГА. В данном слyчае некотоpые игpyхи можно "апгpейднyть" пpактически не меняя кода, лишь пеpеpисовав их спpайты и поместив их в нyжнyю область памяти. Окошка в 16Кб хватит для для цветного экpана со стандаpтным pазpешением и еще останется 37Кб(пpи 4-х плоскостях) для хpанения спpайтов, стpаниц.

Alexandre

... np: silence
---

Lethargeek

21.10.2005, 19:30

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

Пока китайцы не забьют на v9990 ;)

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

Какой сейчас год? Никто в условиях всеобщей халявы этим заниматься не будет!
Программы для Спека пишут энтузиасты, у которых не хватает ни времени, ни терпения.
Да к тому же они окажутся перед выбором: продолжать писать под хорошо освоенный
стандартный режим с уверенностью, что плод их усердия по крайней мере все смогут увидеть,
либо тратить время сначала на освоение, а потом (и все равно дольше с непривычки) на
программирование совершенно несовместимого наворота - и уже без всякой уверенности,
приживется ли он или останется редким рудиментом в некоторых эмуляторах. А вопрос
"приживется ли" тесно связан с наличием софта. Замкнутый круг.

Я же специально избегал слишком усложнять свою идею и перегружать девайс дополнительными
возможностями, чтобы собрать его мог каждый (когда схемы появятся ;)) на любой элементной
базе - от Альтер всяких до рассыпухи а-ля конец 80-х. И потом: если будет 1-2 работающих
устройства, то поддержку оного не стыдно (и несложно ;)) вставить и в эмулятор, а это
значит, что заценить появляющийся софт и писать новый смогут (действительно смогут) многие,
и они будут уверены, что их время не будет потрачено зря (по крайней мере всегда останется
"обычная" спековская версия). Плюс энное количество адаптированного фирменного софта.

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

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

Lethargeek

21.10.2005, 19:35

Оказывается, в новом варианте SCF-mode таятся такие возможности, которые даже я (!) не
сразу замечаю. Вот например: как без всякого программирования переделать "покадровую"
моргалку в чересстрочную? Элементарно, Ватсон! - заполняем четные строки "вентильного"
экрана нулем, а нечетные - байтом #FF, и пожалуйста - во всех программах, моргающих
экраном через прерывание, значительно улучшается качество изображения.

Но это еще что (тем более что была схема аппаратного гигаскрина) - а вот если заполнить
четные строки "вентильного" экрана байтом #55, а нечетные соответственно байтом #AA
(то есть точки в шахматном порядке), получим нечто, еще не существовавшее в природе
- черезпиксельную моргалку!!!

Мож еще чего обнаружится. Настоящие спектрумисты всегда отличались пытливыми умами. ;)

SMT

21.10.2005, 20:59

Пока китайцы не забьют на v9990ну на YM2149 всё ещё не забили...

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

Оказывается, в новом варианте SCF-mode таятся такие возможности, которые даже я (!) не сразу замечаювот! а сколько в чипе будет недокументированных возможностей. да тот же стандартный AY раскрывал свой потенциал сколько лет...

SfS

22.10.2005, 06:54

А зачем так сложно? Почемy бы не сделать по пpинципy ПЦ-шного ЕГА, pазбить видеопамять на битовые плоскоти? Т.е., напp для 16-цветов 4 плоскости, в каждой r,g,b и яpкость соответсвенно.

Я уже както писал об этом. Только почему 4 ? Сделать 8 битовых плоскостей и никаких палитр!

Lethargeek

22.10.2005, 19:55

В принципе, если уж есть три экрана, можно и на отдельной SCF-видеокарте 8-цветный APA
режим (битплановый) сделать. (ремарка для CHRV: "разве что этого" и не хватало Касику для
полного счастья). Но тогда надо добавить дополнительную логику на формирование видеосигнала.
Плюс управляющий бит в порту еще нужен.

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

Может, еще добавить второй порт, и пусть он отвечает (в том числе) за режим записи в
разрешенные видеостраницы - просто запись или OR/AND/XOR. Что позволит несколько
ускорить вывод в 8-цветном режиме на уже готовый фон (а в SCF-режиме еще больше
снизит число случаев, когда надо в спековской памяти хранить копию видеостраницы).
А "одноцветные спрайты" (или их "одноцветные куски") можно будет печатать с нормальной
для обычной спековской графики скоростью. Вопрос, насколько это усложнит схему.

Если мелкосхемы видеопамяти размером в 16 кб, то можно иметь два 8-цветных экрана и
переключать их целиком (раз "вентильная" память занята под цвет) при помощи "перепутывания
адресов" (конкретно инверсии 9-го бита адреса при обращении к видеопамяти). Причем
этой возможностью можно будет пользоваться и в SCF-mode, то есть иметь два SCF-экрана,
смешиваемых "вентилем", которые еще можно переключать целиком, отображая один и рисуя
на другом.

А тут еще возникают мысли насчет объединения двух 8-цветных APA-экранов в один 64-цветный...

Lethargeek

22.10.2005, 20:00

ASDT> Проще говоря - гон.

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

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

jtn

22.10.2005, 21:24

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

фантастика, мля... =\

ASDT

22.10.2005, 23:37

"игровой проект и группа людей"
Ну нет таких ...

CHRV

23.10.2005, 00:32

В принципе, если уж есть три экрана, можно и на отдельной SCF-видеокарте 8-цветный APA
режим (битплановый) сделать. (ремарка для CHRV: "разве что этого" и не хватало Касику для
полного счастья).
Личную переписку пожалста не выносите без моего на то разрешения на всеобщее обозрение -буду резать! Пока только предупреждаю.

CHRV

23.10.2005, 00:42

"игровой проект и группа людей"
Ну нет таких ...

А знаете почему нет, потомучто гении которые знают "как делать" почемуто делать ничего не хотят сами, зато пишут и кричат много (сразу вспоминается Нэмо с его знаменитой и точной фразой что в инете прав не тот кто аргументирует, а тот кто громче и больше кричит :) ).
Ну а те кто делает он просто делает и все. Так совершенно неожиданно появился TASiS, появился Virtual TRDOS (которыми пользователи АТМ пользуются уже сейчас). А по поводу новых графических возможностей мне интересней например обсудить с реальшиками: с Быстровым, тем же Касиком, Рониным, некоторыми активистами из Питера что собственно и делается. Потомучто они заинтересованы не в какомто виртуальном обсуждении, а в совершенно реальных вещах. Соственно это одна из основных причин по которым я самоустранился из текущей полемики. Возможно я не прав, но "я так думаю" ( (с) Мимино ).

Ewgeny7

23.10.2005, 16:00

некоторыми активистами из Питера .

Я не некоторый. Я который! "Я так думаю!" (С) :)

ASDT

23.10.2005, 19:55

"кто делает он просто делает и все"
Для этого вопроса - неверно!

Lethargeek

23.10.2005, 20:14

ПРАВДА И МИФЫ ОБ АДАПТАЦИИ ГРАФИКИ К SCF-mode

SMT> переделывать игры без исходников слишком сложно, не из-за вывода, а потому что
' нужно больше данных, меняется раскладка памяти, все привязки к тактам тоже вылетают,
' придётся думать, как в 2 раза ускорять существующий код.

ДА НЕТ ЖЕ!!! :v2_sick:

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

Давай по пунктам:

SMT> переделывать игры без исходников слишком сложно, ...

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

SMT> ... не из-за вывода, ...

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

SMT> ... а потому что нужно больше данных, ...

С чего бы это??? Это при адаптации под видеочипы всякие надо ВСЮ графику переделывать
(не говоря уже о процедурах вывода). В простейшем случае (избавление от "клэшинга") при
адаптации к SCF-mode меняется не ЧТО выводится, а КУДА. Конечно, можно и графику улучшить,
спрайты/фоны раскрасить, если охота. SCF-mode выгодно отличается от всех прочих именно
тем, что ПРИ АДАПТАЦИИ ГОТОВЫХ ИГР ОБЪЕМ ПЕРЕДЕЛОК ЗАВИСИТ ТОЛЬКО ОТ ЖЕЛАНИЯ
И СВОБОДНОГО ВРЕМЕНИ спектрумиста. Это работа, способная стать отдыхом!

SMT> ... меняется раскладка памяти, ...

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

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

SMT> ... все привязки к тактам тоже вылетают, ...

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

SMT> ... придётся думать, как в 2 раза ускорять существующий код.

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

Ну вот и все, что касается адаптации. Не веришь мне - спроси Spectre, он мои
идеи гораздо лучше меня растолкует. :D :D :D

Lethargeek

23.10.2005, 20:20

Насчет остального:

SMT> Остаётся только надежда на поддержку в новых играх, ...

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

SMT> ... а тут гораздо удобнее использовать аппаратный спрайтер, чем мучаться с масками
' и прочим. Софт под старый режим делают лишь из-за массовости железа, ...

Может, и удобнее - в части вывода спрайтов, но вот общий объем работ над игрой будет больше.
А насчет заявлений, что "лишь из-за массовости железа" - так тут надо делать поправку на
время. Сейчас не середина 80-х и даже не середина 90-х. Поздновато делать какие-то резкие
изменения. Уже большую роль играет инерционность мышления, да и просто лень. А работа
с масками давно уже не мучение, а привычка. ;)

На любой платформе при таких резких поворотах часть софтмейкеров неизбежно отсеется.
И хорошо еще, если продолжат писать софт под старое железо, а то ведь вообще забьют.

По этому вопросу до посинения можно спорить, но все аргументы с любой стороны будут
довольно шаткими. Я исхожу из того, что известно о других платформах. Вроде бы нигде
производить такие эксперименты с совершенно новым железом даже не пытались.
А если и было что-то подобное, так ничем хорошим не кончилось (вспомнить историю
Atari-STe с блиттером). И это для "живых" платформ, для которых выходил фирменный софт!
А что было на ПЦ, который у всех перед глазами? - довольно долгое время игры выходили
"с поддержкой" графускорителей (то есть могли работать и на старом железе в software
mode), а не "под ускорители" - это случилось позднее, когда повсюду воцарился вынь
и мощность проца стала достаточной для общения с любым разным железом через кучу
посредников-драйверов (нереальная перспектива для Спека ;) ). Вот для спековской
платы на видеочипе как раз проблема - производство "двойных" версий игр. Не с нашей
ленью, нехваткой времени и многолетними сроками производства софта.

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

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

Ну, крейзи в хорошем смысле слова выберет, пожалуй, обе, а в плохом - хрен его знает,
чего он выберет, он же псих... :D :D Ну да, в начале будет сложно решить, но в конечном
итоге все равно все упирается в "количество умножить на качество" софта и простоту его
разработки. Иначе как объяснить грандиозный успех ужасного уродца под гордым названием
Sinclair ZX Spectrum? ;) И дело ведь было отнюдь не в цене - не такая уж там была разница,
особенно во второй половине 80-х.

SMT> ... вот! а сколько в чипе будет недокументированных возможностей. Да тот же
' стандартный AY раскрывал свой потенциал сколько лет...

Хе-хе. А представь, сколько таких возможностей было в том же Dendy приделанном! Это ж
был не просто видеочип, а целая однокристалка!! Да еще со спековским эраном изображение
можно смешивать - вот где простор для творчества!!! :eek: :eek: :eek: :rolleyes:

Не поздновато ли "раскрывать потенциал" с нуля? От чего отталкиваться? Или это будет
только для избранных, кто имеет опыт программирования на Ямахе? И вообще, готовые чипы
шаблонизируют графику - достаточно взглянуть на игрушки на тех же Atari, C64, MSX, то
есть "спрайтовых" машинах. Абсолютно гибок только APA режим, пусть даже на Спеке он был
монохромный (только цветной ;) ).

Кстати, заметь, есть существенная разница между "недокументированными возможностями",
которые применять просто опасно (черт их знает, какие там внутренние различия от серии
к серии), и неординарным использованием документированных, увидеть которое проще, если
уже программировал нечто подобное. А то из Спека с 90-х годов все пытаются безуспешно
сделать то недо-XT, то недо-Амигу, то недо-MSX. Уж лучше сам Спек до ума довести.
И никто не запрещает потом те же аппаратные ускорители пристраивать. Надо только
обдумать все так, чтобы впоследствии это безболезненно прошло.

А про AY и его "раскрытый" потенциал даже не говори мне... :D

P.S. А чего там насчет "fake low-res" в эмуле? Что думаешь? Скриншоты смотрел?

SMT

24.10.2005, 00:48

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

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

А чего там насчет "fake low-res" в эмуле? Что думаешь? Скриншоты смотрелсории, забыл посмотреть. но сейчас даже быстренько попробовал (оказалось, не так уж быстро :(). смотри в теме "новая версия us"

madcore

24.10.2005, 13:17

Странно, я в ФИДО всех сообщений с форума не вижу, а мои тут видны..

Я уже както писал об этом. Только почему 4 ? Сделать 8 битовых плоскостей и никаких палитр!
Количество плоскостей тут не принципиально, главное что это будет прозрачно для программ. А 4 бита на точку мне показалось оптимальным компрмисом. Если использовать область атрибутов для выбора своей палитры на знакоместо, то сможем иметь на экране одновременно 4096 цветов(правда для хранения палитр понадобится дополнительно 12-16К памяти, мапить её в память спека ИМХО необязательно). И с палитрой много эфекетов можно придумать. Подобие мультиколора, например, даст еще больше цветов.
Например, по умолчанию у нас чтение/запись настроены на одну плоскость, палитра выставлена в соответствии со стандартными спековскими атрибутами - всё выглядит как стандартный экран. Настроив определенным образом палитру, мы можем добиться, чтобы одна плоскость всегда была на переднем плане, а в оставшиеся плоскости можно поместить фононовую картинку на "рабочий стол":) - никакие прграммы этого не заметят. Это будет самый простой способ "разукрасить" старые игры(те же Диззи ) - минимальные измения в коде, просто дял каждого игрового экрана загружаем красивый фон, а осталные объекты рисуются как и раньше на переднем "стандартном" плане. Много еще чего можно придумать. Т.е., от палитры совсем я бы отказываться не стал, можно сделать еще один безпалитровый режим, если в нем есть потребность.
Главное, чтобы скорость копирования графики не зависела от количества плоскостей. Новые игры можно было бы писать сразу под стандартный и цветной экран, они будут отличаться только набором спрайтов и незначительными измениями в коде, связанными с инициализацией видеоадапртера. Векторные игрухи типа Элиты тоже легко можно сделать цветастыми - просто при старте настраиваем нужный режим записи, потом при выводе объектов заносим нужный цвет в регистр цвета - больше никаких изменений не нужно. Правда, не знаю, есть ли какой прок от разноцветных караблей :)

Lethargeek

24.10.2005, 20:01

jtn> 17я страница заканчивается, а толку ни на грамм.

Не все, что происходит, видно глазу...

jtn> предлагаю такой сценарий:

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

CHRV> ...почему-то делать ничего не хотят сами, зато пишут и кричат много (сразу
' вспоминается Нэмо с его знаменитой и точной фразой что в инете прав не тот, кто
' аргументирует, а тот, кто громче и больше кричит. Ну а те кто делает, он просто
' делает и все.

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

Lethargeek

24.10.2005, 20:05

SMT> неплохо, если бы ты довёл этот проект до конкретных спецификаций, то есть до режимов, которые нужно реализовать, раскладки экранов в памяти и адресов портов. тогда можно было прикинуть, во сколько корпусов это выйдет и чем будет полезно для программеров

Погоди немного - пытаюсь с несколькими людьми списаться...
Первые промежуточные спецификации будут, когда получу первые промежуточные ;) ответы от схемотехников.

...там и насчет битпланов планируется, и "ускорение без ускорителей"

Lethargeek

26.10.2005, 20:37

Че-то я не понял, как в личную почту вложения делать, а разбираться некогда... Ладно, смотрите все, кто хочет.

Readme там для SAM style, так что не удивляйтесь ;)

(28-10-2005 удалил - ищите новое)

SMT

26.10.2005, 22:03

SAM style

26.10.2005, 22:42

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

Читкаем мою спецификацию

-------------------------
16 colorz at da pixel
VideoDrive specification
-----------------------------
by SAM style

NOTE: в качестве эксперимента реализовано в unreal032b7, я опробовал, работает. Последний шаг - железо

------------
ПРЕДСМЕРТИЕ: Читал Lethargeek-а, врубился в половину, сломал мозг. Надо чинить...
------------
принцип работы

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

Видеопамять - внешняя, 4 линейки 8К*8.
Линейки отвечают каждая за свой цвет и яркость (B,R,G,I), в каждой в начале - по экрану 256*192 (#1800)
Структура экранов абсолютно такая же как у ZX, поэтому осваивать чего-то очень новое не придется.
------------
отображение

идет тем же путем что и в ZX, но во всех 4 слоях - имеется счетчик, генерирующий те же сигналы,
что и счетчик на ZX (h0-h7, v0-v7, brd, cc, kc), в нужные моменты снимаем с плоскостей 4 байта,
сдвигаем их как в обычном ZX и получаем 4 сигнала R,G,B,I.
------------
общение

управление ведется через один порт, ориентированый на запись.
через него выбирается: активный слой (00-B, 01-R, 10-G, 11-яркость), режим перехвата обращения
к памяти #4000-#57ff (1-вкл, 0-выкл) и режим вывода на экран (1-с видеокарты, 0-с ZX экрана).
бордюр, ясен хрен, выводится обычными сигналами.
------------
чтение-запись

при определенных условиях перехватывается обращение к памяти в области #4000-#57FF и чтение-запись
переводится в выбраный слой видеопамяти
------------
скорость

а мы ничего не потеряли и не приобрели - ZX работает как обычно, только где-то на стороне делается
другое изображение и остается только выбирать, что на экране показывать.
------------
ну че там еще...

А ничего - все просто как два пальца... Моему ежу и то понятно.
------------
ПОСЛЕСМЕРТИЕ:
за 5 минут переделал свой little viewer для просмотра триколоров в новом режиме. АфиГееееЛ как все просто.

ASDT

27.10.2005, 05:42

Почитал ... "все просто как два " :) Ммдя ...
Ещё раз.
Если следовать логике ZX, то можно выводить 2 экрана -
стандартный и ещё 2 байта
Что с ними делать ... вот это и вопрос ...

А разработка внешних видеокарт - это надо другую тему ...

SMT

27.10.2005, 07:39

за 5 минут переделал свой little viewer для просмотра триколоров в новом режиме. АфиГееееЛ как все простобрось сюда картинки с загрузчиком. можно и без загрузчика, если плоскости в отдельных файлах - его легко на васике написать

SAM style

27.10.2005, 08:10

брось сюда картинки с загрузчиком. можно и без загрузчика, если плоскости в отдельных файлах - его легко на васике написать
PLZ... внутри viewer, пара триколоров, *.Y и *.888.

Валера

27.10.2005, 09:54

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

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

Такое нововведение позволило бы решить проблемы с клэшингом атрибутов во многих играх, где требуется плавный попиксельный (2-х, 3-х, 4-х пиксельный) скроллинг фона (к примеру, Ikari warrior, robocop 2, многие космические стрелялки).

madcore

27.10.2005, 10:25

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

А чипам памяти зачем это делать? ЦПУ непосредственно в видеопамять ничего не пишет/читает, его обращение перехватывает видеоадаптер и сам все делает. Т.е., фактически, видеопамять в адресное пространство z80 даже отображать не надо. Кроме приведенных операций не помешает еще сдвиг добавить. Только не циклический, как на ПЦ-шном ЕГА. Осталось обеспечить, чтобы общение с адаптером происходило с такой же скоростью, как и с обычной памятью...

ещё неясно, как суммируются фоновый/спрайтовый/вентильный экраны
А эту идею я вообще не понял...

madcore

27.10.2005, 11:12

принцип работы

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

управление ведется через один порт, ориентированый на запись.
через него выбирается: активный слой (00-B, 01-R, 10-G, 11-яркость), режим перехвата обращения
Уточнение: для записи можно включать сразу несколько слоев. Чтение из выбранного одного, плюс нужен режим, когда адаптер при чтении всегда выдает 0(или 255, щас не сообразить) - поможет для переделки старой векторной графики. Еще нужен режим записи, когда байт проц выступает маской, а цвет берется из соответствующего регисра видеокарты.

к памяти #4000-#57ff (1-вкл, 0-выкл) и режим вывода на экран (1-с видеокарты, 0-с ZX экрана).
Что мешает видеокарте выводить zx-экран? Просто настроить запись/чтение на одну плоскость, астольные либо заполнены 0, либо палитра установлена так что их не видно.
И почему не 5aff? ИМХО, под это дело не грех выделить и 16К - для быстрого копирования спрайтов. Конечно, перекроет систменые переменные и бэйсик, но во время вывода спрайтов оно нам не надо.

а мы ничего не потеряли и не приобрели - ZX работает как обычно, только где-то на стороне делается
другое изображение и остается только выбирать, что на экране показывать.
------------
ну че там еще...
Палитра нужна! Что там гворил Lethargeek про фоновые экраны я толком не понял, но этого можно добиться просто настройкой палитры! Можно сделать количество 1-битных экранов по количеству плоскостей, можно передний план 1-битный, задний - 3-битный и тд любые комбинации. Постораюсь показать на примере 2-х полскостей:
Допустим, 0-я плоскость - передний план, 1я - задний. Настраиваем палитру так, что цвет 01=11 и все! Изображение с 0-й плоскости будет "затирать" 1-ю.

SMT

27.10.2005, 17:49

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

для начала, неплохо бы поинтересоваться, есть ли доступные чипы памяти, с and/or/xor вместо put
А чипам памяти зачем это делать?это уже другой вопрос, и не ко мне. просто, как я понял из описания, Lethargeek хочет такую функцию в видеоплате, ну и интересно, как он видит аппаратную реализацию сей фичи...

не грех выделить и 16К - для быстрого копирования спрайтовуже хочешь аппаратный блиттер видео->видео :)

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

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

SMT

27.10.2005, 18:00

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

SAM style

27.10.2005, 18:19

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

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

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

SMT

27.10.2005, 18:59

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

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

SMT

27.10.2005, 19:05

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

SAM style

27.10.2005, 19:27

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

28.10.2005, 17:20

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

SAM style

28.10.2005, 18:15

ты хочешь карту в слот (или минимум - панелька вместо процессора), или обвешать весь видеоконтроллер соплями к новой карте? стандартный бордюр можно только во втором случае
Планировалось надевание на системный разъем.
Панелькой в процессор не обойдешься - где тогда брать h0..v7? К тому же по идее на карте стоит свой собственный счетчик, а это уже позволяет получать свой brd' прямо на месте, а не брать его с платы.
Меня одно только мучает - перехват чтения-записи в экран. Вот тут точно ни слотом, ни тем более панелькой не обойдешься.

Lethargeek

28.10.2005, 18:39

ASDT> А разработка внешних видеокарт - это надо другую тему...

Ну, начиналось-то не с внешних, к такой постановке вопроса пришли по ходу дискуссии.

Я тоже вот думаю - а не убрать ли в архив все написанное до 19-10-2005 @20:26 (то есть до
моего сообщения с заголовком "Attention!", сразу после которого идет описание последнего
варианта SCF-mode (это надо оставить, чтобы дальнейшее понятно было). И сменить название
у темы на что-нибудь вроде "Планирование спецификаций внешней видеокарты для Спека, их
обоснование и эксперименты с ними" - ну или кто предложит лучший вариант.

Лично я не против, а остальные? И что на это скажут модераторы?

Lethargeek

28.10.2005, 18:41

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:
Распределенные НИОКР, блин.

Lethargeek

28.10.2005, 18:46

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--

Lethargeek

28.10.2005, 18:48

Валера> ... такое нововведение позволило бы решить проблемы с клэшингом атрибутов во
' многих играх, где требуется плавный попиксельный (2-х, 3-х, 4-х пиксельный) скроллинг
' фона (к примеру, Ikari warrior, robocop 2, многие космические стрелялки).

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

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

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

Lethargeek

28.10.2005, 18:49

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, и вообще любой цвет).

Lethargeek

28.10.2005, 18:52

Вот, я перепаковал свое прошлое вложение и добавил туда файл для SMT с инструкциями
по реализации в эмуле своего варианта (в урезанном пока что виде) - "_emul1.txt".
Надеюсь, на той неделе я таки снесу вынь-98 и попробую сконвертить какую-нибудь игруху
под SCF-mode. А SAM style пускай тем временем на 64-цветный режим переучивается! ;)

(Кстати, SMT, а чего мне ставить, win2k хватит, или уже XP необходим?)

(30-10-2005 вложение удалил, последняя версия дальше)

SAM style

28.10.2005, 19:52

А SAM style пускай тем временем на 64-цветный режим переучивается! ;)Я в своей песочнице, ты в своей.
Ittekimasu, чуваки. Как сделаю себе девайс на скорп - вернусь (может быть).

SMT

28.10.2005, 21:48

Ориентируемся на ZX-bus! Не "доделка" же очередная планируется, а нормальная видеокартаа на чём планируешь делать? альтера, микроконтроллер, или рассыпуха? схему SAM style я без труда представляю в железе, а вот твой режим сделаю, не раньше, чем схема будет. по виртуальным (например, 256-цветным) режимам, это Кладов специалист :D

p.s. с вентилем понял. а зачем ему атрибут? чтобы в 8 раз быстрее заполнить переход на один из экранов?

а чего мне ставить, win2k хватит, или уже XP необходимесли хочешь полюбоваться на триколоры SAM style, 2000-й хватит

Vladimir Kladov

28.10.2005, 23:49

по виртуальным (например, 256-цветным) режимам, это Кладов специалист :D

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

Вообще-то если ставить вопрос как тут ставился (где-то в начале обсуждения), то нельзя вообще ничего делать НОВОГО. Надо лишь сделать так, чтобы тот софт, что уже есть, с МИНИМАЛЬНЫМИ изменениями (ИЛИ ВООБЩЕ БЕЗ ИЗМЕНЕНИЙ - этого не было, но об этом все подумали) шел в новом режиме и радовал глаз. Как минимум - отсутствием клэшинга.

SMT

29.10.2005, 01:42

только воплощать в эмуляторе то что будет сотворено, я стану не раньше, чем появится софт, который это железо юзает и сам при том востребован замкнутый круг? а в чём же Lethargeek будет переделывать игрушки под свой режим, как не в твоём эмуляторе? :)

Vladimir Kladov

29.10.2005, 10:40

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

Spectre

29.10.2005, 12:12

Надо лишь сделать так, чтобы тот софт, что уже есть, с МИНИМАЛЬНЫМИ изменениями (ИЛИ ВООБЩЕ БЕЗ ИЗМЕНЕНИЙ - этого не было, но об этом все подумали) шел в новом режиме и радовал глаз. Как минимум - отсутствием клэшинга.

Собственно это и есть основная идея Lethargeek'ого режима. Жаль что не все прониклись ею. Я уже отписал Lethargeek'у в письме что планирую накидать список игр которые я хотел бы видеть в переделке (например, Dizzy, Exolon, Robocop, Laser Squad, то есть классику спектрумских игр), потом изучить их процедуры вывода на экран чтобы представить какие минимально необходимые требования к новому режиму, при этом требующие минимальной переделки игр. То есть главное условие - это компромис. Варианты Sam Style и CHRV в предложенном варианте этому условию не удовлетворяют.

Lethargeek

30.10.2005, 15:41

SAM style> Я в своей песочнице, ты в своей.
' Ittekimasu, чуваки. Как сделаю себе девайс на скорп - вернусь (может быть).

Когда вернешься, жду подробный отчет, как ты на своем девайсе пытался спрайты гонять.
Не представишь - буду песком кидаться! :D

Lethargeek

30.10.2005, 15:43

SMT> а на чём планируешь делать? альтера, микроконтроллер, или рассыпуха? схему SAM style
' я без труда представляю в железе, а вот твой режим сделаю, не раньше, чем схема будет.
' по виртуальным (например, 256-цветным) режимам, это Кладов специалист

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

SMT> p.s. с вентилем понял. а зачем ему атрибут? чтобы в 8 раз быстрее заполнить переход
' на один из экранов?

Ну примерно так. Еще спрайтом мигать можно быстро. Я подумал - все равно контроллер
по два байта читает, не пропадать же второму. ;)

Lethargeek

30.10.2005, 15:46

Vladimir Kladov> Вот это мне и не нравится - опять переделывать. Хочу попробовать другое
' в борьбе с клэшем. Не ИИ, но вроде того. А если удастся это в эмуляторе, то почему бы
' и не воплотить в железо.

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

А вообще хочу сказать большое спасибо за то, что могу в EmuZWin хотя бы оценить, как
будут примерно выглядеть адаптированные игрушки, и графику быстро найти. Кстати, как раз
по поводу Sprite Finder-a у меня есть некоторые рацпредложения:

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

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

И чтобы память в Sprite Finder-е отображалась постранично, а то пока листаешь, страницы
могут переключаться, и видишь глюки.

Lethargeek

30.10.2005, 15:49

Очередной вариант (специально для ewgeny7). Старый убил.
Теперь так и буду вложением кидать - это лучше, чем простыни множить.

В следующий раз, надеюсь, добавлю рисунки.

(убил 1-11-2005)

SMT

30.10.2005, 17:06

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

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

Vladimir Kladov

30.10.2005, 19:18

Vladimir Kladov> Вот это мне и не нравится - опять переделывать. Хочу попробовать другое
' в борьбе с клэшем. Не ИИ, но вроде того. А если удастся это в эмуляторе, то почему бы
' и не воплотить в железо.
тут я сначала ничего не понял, пока не дочитал до конца. Мне кажется вопрос здесь по поводу возможности моего эмулятора - оффтопик, надо было отдельную тему или присоседиться к теме по моему эмулятору.

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

Здесь я опять ничего не понял - это про 256-режим, что ли? Никак почти. Делается каждый уровень отдельно, если спрайтовка разная. Я же не за то, чтобы все на 256 переводить, а то, что переводится, выглядит просто красивее. Я вообще этот режим сделал только потому, что мне понравилось как Knight Lore стал после переделки выглядеть. Правда, потом я его еще улучшил, но даже то, что было, мне нравилось.

А вообще хочу сказать большое спасибо за то, что могу в EmuZWin хотя бы оценить, как
будут примерно выглядеть адаптированные игрушки, и графику быстро найти. Кстати, как раз
по поводу Sprite Finder-a у меня есть некоторые рацпредложения:

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

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

Плюс возможность переворачивать спрайт кверх ногами. А то пока, похоже, только
формат "слева-направо, сверху-вниз" поддерживается.
есть переворот по вертикали. Только надо включить граф редактор, там он и находится. Хотя может и в файндере есть (я не помню, давно не открывал).

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

madcore

31.10.2005, 11:57

Вообще печать спрайта в моем варианте выглядит так: сначала разрешаем для записи все слои и за один проход печатаем маску по AND, затем (допустим, спрайт трехцветный - красного, желтого и зеленого цвета) разрешаем только красный слой экрана, печатаем красный слой спрайта, разрешаем только зеленый слой экрана и печатаем зеленый слой спрайта и... все! Желтый цвет получился слиянием зеленого и красного - преимущество битплановых режимов
(можно раскладывать на спрайт на цветосоставляющие для любого числа слоев).
Возможность копирования точек через регистры-защелки будет? В отличии от ЕГА, хочется, чтобы в этом режиме работали логические операции(включая сдвиг)

Насчет режима записи madcore: "соответствующий регистр" - это просто тот же самый регистр разрешения записи/чтения слоев. Просто в разрешенные слои запись идет по OR, а в запрещенные - по NOT+AND.
Дак заприщенные они для того и запрещенные, чтобы в них ничего не писалось. А надо, чтобы устанавливались все битовые плоскости в соответствии с выбраным цветом.

Для чтения я уже предлагал нечто подобное (перечитай specs!). При записи такой режим даст реальный выигрыш только для одноцветных спрайтов - буквы на фоне рисунка, что ли, печатать собрался?
Еще примитивы - линии, прямоугольники, кружочки:) Т.е., старый код для их рисования менять не нужно будет, только устанавливать регистр цвета перед выводом.

Не лучше ли это сделать по-моему, когда в
APA-mode тоже есть "спрайты". 5 режимов записи (а не 4) - это плохо, бит повиснет ;) Хотя я подумаю, как это сделать, чтобы во всех режимах больше пользы было.
О количестве режимов говорить еще рано. ЕГА, конечно, копировать один-в-один не стОит.

madcore> Что мешает видеокарте выводить zx-экран? Просто настроить запись/чтение на одну
' плоскость, астольные либо заполнены 0, либо палитра установлена так что их не видно.
' И почему не 5aff? ИМХО, под это дело не грех выделить и 16К - для быстрого копирования
' спрайтов. Конечно, перекроет системные переменные и бэйсик, но во время вывода спрайтов
' оно нам не надо.[/I]

Что мешает? Атрибутов нет! Либо все равно удваивать цикл чтения, либо читать их с другого слоя. И писать тогда тоже в два слоя одновременно. То есть опять просто не получится.
Область атрибутов я предлагал использовать для выбора палитры для знакоместа. Стандартный ZX-экран в этом случае просто часть нашего нового режима. Только поддержка мерцания выглядит не очень стройно, но можно продумать. Правда, для 16 цветов хранение 256 различных палитр вполне реально, а вот для 6-ти и 8-ми плоскостей уже уже неоправдано и странно... Тут можно придумать, чтобы атрибуты выступали в качестве модификаторов установленной палитры, или еще чего..

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

SMT

31.10.2005, 12:43

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

Lethargeek

01.11.2005, 20:18

Vladimir Kladov> маркеры продаются в канцтоварах :) Кстати, ручкой удобнее на бумаге
' помечать. Нотепад еще есть, тоже хорошая штука такая...

Ага, в Notepad еще лазить... Кроме шуток, речь же о том, что в Sprite Finder-е не видно
общей картины, приходится все время настройку ширины дергать. А то бы раз нашел спрайт
- и потом его всегда видно.

Vladimir Kladov> В паузе листать надо (однако).

А если надо посмотреть, как программа над своими спрайтами в ОЗУ издевается? Это не
такое уж редкое явление (паузой такие моменты замаешься ловить). Или теневой видеобуфер
можно отслеживать. Вообще неплохо бы Sprite Finder в динамике сделать (если конкретный
пЦ потянет).

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

Lethargeek

01.11.2005, 20:20

madcore> Возможность копирования точек через регистры-защелки будет? В отличии от ЕГА,
' хочется, чтобы в этом режиме работали логические операции (включая сдвиг)

Уже загрузил человека подобным вопросом - чтобы хотя бы ldir-ы всякие внутри видеопамяти
работали параллельно для всех разрешенных плоскостей. А насчет остального - почему
"включая" сдвиг? На z80 вроде как нет команд типа "xor [hl],reg", только одноместные
"rlc/rrc/rl/rr/sla/sra/sli/srl/bit/set/res [hl]" - почти все из которых сдвиги. :)
Для большинства параллельная работа (по крайней мере частично) бессмысленна. Ладно еще
set/res, а вот по команде "rr [hl]" в видеопамять при нескольких разрешенных плоскостях что
должно во флаг переноса попасть? Для подобных команд (а ведь есть еще rrd/rld!) надо изучить
последовательность состояний шины, тогда и станет ясно, что возможно. Хорошо еще, если их
удастся заставить работать при одной выбранной плоскости, а нет - и фиг с ним, это не
фатально (в APA-графике обойдемся, а при адаптации в SCF-mode копия экрана есть в ОЗУ).
Гораздо важнее сделать режим записи байта "со сдвигом" в два "соседних" (на экране) адреса
(причем тоже с учетом OR/AND/XOR), пусть даже с лишним циклом записи (иначе в APA памяти
не напасешься на заранее рассчитанные горизонтальные фазы сдвига многослойных спрайтов).
А остальное тогда пусть глючит, как захочет. ;)

madcore> Дак запрещенные они для того и запрещенные, чтобы в них ничего не писалось.
' А надо, чтобы устанавливались все битовые плоскости в соответствии с выбраным цветом.

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

madcore> О количестве режимов говорить еще рано.
' ЕГА, конечно, копировать один-в-один не стОит.

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

madcore> Область атрибутов я предлагал использовать для выбора палитры для знакоместа...
' ... Цветность мы урезаем только при эмуляции (путем настройки палитры) задних планов.
' Зато этих планов можно иметь, сколько захотим, и любой глубины цвета, лишь бы плоскостей
' хватало. А если нам не нужно, используем все плоскости для одного полноцветного экрана,
' и никакие лишние фоновые экраны не будут висет мертвым грузом. В моем варианте новое
' расширение не является чем-то инородным для спека, цепляемым где-то сбоку. ZX-экран
' является частным случаем нового режима, т.е. никаких отдельных режимов для совместимости
' нет. Возможно, мои объяснения несколько сбивчивы и сумбурны, постараюсь позже оформить
' мою идею более последовательно...

Вот-вот, постарайся, а то впечатление совершенно бредовое. Что значит "планов можно иметь,
сколько захотим, и любой глубины цвета, лишь бы плоскостей хватало"? Глубина цвета - это
количество бит на точку, а вовсе не общий размер палитры! Тут слои как ни распределяй,
все равнов итоге урезание цветности. И что такое "лишние" фоновые экраны? Я, кстати,
подумываю об объединении двух 64-цветных экранов в один 4096-цветный, причем это решение
логически обоснованное и кучи новых железок в моей схеме не потребует. Правда, и годятся
такие "полноцветные экраны без фона" только для просмотра картинок. И ZX-экран, кстати,
является частным случаем SCF-mode, не такой уж он "отдельный".

Ты лучше напиши наподобие того, как я объяснял идею вентильного экрана:
что в каждой плоскости записано, и что мы увидим на экране в результате.

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

Lethargeek

01.11.2005, 20:27

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

Ну смотри. Вот что часто встречается в игрушках для вывода спрайта на заполненный чем
угодно (в том числе другими спрайтами) фон (чтобы пример был менее громоздким, ЦИКЛ
означает "цикл по всему спрайту", с изменением экранного адреса в bc как по горизонтали,
так и по вертикали):

ld bc,^экран
ld hl,^маска
ld de,^спрайт
ЦИКЛ
- ld a,[bc]
- and a,[hl]
- ex de,hl
- or a,[hl]
- ex de,hl
- ld [bc],a
- inc de, hl
- (изменение bc)
ПОВТОРИТЬ

А для SCF-mode будет:

out... ; (вывод по AND в вентильный и спрайтовый экраны)
ld bc,^экран
ld hl,^маска
ЦИКЛ
- ld a,[hl]
- ld [bc],a ; равносильно "and [вентиль],a" + "and [спрайты],a"
- inc hl ; то есть напечатали маску и заодно стерли попавшиеся куски спрайтов
- (изменение bc)
ПОВТОРИТЬ
out... ; (вывод по OR в спрайтовый экран)
ld bc,^экран
ld de,^спрайт
ЦИКЛ
- ld a,[de]
- ld [bc],a ; равносильно "or [спрайты],a"
- inc de
- (изменение bc)
ПОВТОРИТЬ

Для одноцветных спрайтов нужен только первый цикл, так как маска и спрайт совпадают
(только используется цвет PAPER спрайтового экрана, а не INK).

Для двухцветных на первый взгляд SCF-mode несколько медленнее (если в оригинале спрайт
и маска печатались за один проход). НО! Мы забыли одну "мелочь", а именно: запоминание
и восстановление фона. То есть для стандартного экрана нужно сначала стереть старые
спрайты (и не просто "стереть", а забить картинкой), потом запомнить фон в новом месте
и уже после этого вывести туда спрайт. А в SCF спрайты "стираются" элементарно
и фон запоминать не надо. То есть весь "рабочий цикл" в SCF выполняется быстрее.

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

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

(Опять упрощенно):

out... ; (временно отключили автопересчет адреса)
out... ; (вывод по AND в вентильный и спрайтовый экраны)
ld de,^экран
call "пересчет адреса в родной формат" ; быстро, с таблицей
ld bc,de
ld hl,^маска
ЦИКЛ
- ld a,e
- call "цепочка ldi"
- ld e,a
- inc d
ПОВТОРИТЬ
ld de,bc
ld hl,^спрайт
out... ; (вывод по OR в спрайтовый экран)
ЦИКЛ
- ld a,e
- call "цепочка ldi"
- ld e,a
- inc d
ПОВТОРИТЬ
out... ; (включили обратно автопересчет адреса)

Понятно, что могут быть нюансы, и все это можно сделать немного по-другому, но идея ясна?
Цепочки ldi могут быть любого размера вплоть до 256 с ret в конце, и call адресуется в
произвольное место цепочки. Для прямой адресации видеокарты это лучший способ вывода
графики в обоих режимах - и SCF, и APA (просто по вертикали в "среднем" куске экрана
байтов гораздо больше, чем по горизонтали). Это я еще молчу про извращенные варианты
со стеком... ;)

Примечание: не путать ldi из ОЗУ компа в отображаемую видеопамять с ldi исключительно
внутри самой видеопамяти! (Связанные с ним вопросы пока выясняются.)

Lethargeek

01.11.2005, 20:28

Очередной вариант спецификаций.

Добавлена схема автопересчета адреса и сравнительные размеры экранов (файл "_mapadr.xls")

03-11-2005 кое-чего поправлено...

Все, этот вариант похоронен 25-11-2005. :cool:

madcore

02.11.2005, 11:44

Lethargeek>Уже загрузил человека подобным вопросом - чтобы хотя бы ldir-ы всякие внутри видеопамяти работали параллельно для всех разрешенных плоскостей.

А без этого от режима и толку ноль..

Lethargeek>А насчет остального - почему
"включая" сдвиг? На z80 вроде как нет команд типа "xor [hl],reg", только одноместные
"rlc/rrc/rl/rr/sla/sra/sli/srl/bit/set/res [hl]" - почти все из которых сдвиги. :)
Для большинства параллельная работа (по крайней мере частично)

Дык я говорил про сдвиг адаптером, а не цпу :)

Lethargeek>Гораздо важнее сделать режим записи байта "со сдвигом" в два "соседних" (на экране) адреса
(причем тоже с учетом OR/AND/XOR), пусть даже с лишним циклом записи (иначе в APA памяти не напасешься на заранее рассчитанные горизонтальные фазы сдвига многослойных спрайтов).

Так я про то и говорю! Нужен сдвиг как на ЕГА, только _нециклический_, а чтобы байт мог записаться в соседние 2.

madcore> Дак запрещенные они для того и запрещенные, чтобы в них ничего не писалось.
' А надо, чтобы устанавливались все битовые плоскости в соответствии с выбраным цветом.
Lethargeek>Зачем лишний регистр, если битовый список разрешенных и >запрещенных плоскостей фактически и есть цвет.

Нет не фактически, ибо в запрещенных плоскостях может уже быть записан "1", а внашем цвете там "0".

Ладно, об остальном пока не буду, еще подумаю.

Lethargeek>Я, кстати,
подумываю об объединении двух 64-цветных экранов в один 4096-цветный, причем это решение логически обоснованное и кучи новых железок в моей схеме не потребует.

Т.е., фактически у тебя получится экран 12 плоскостей, так? Так вот я это и мею ввиду, что его разделить на 2 можно просто установкой палитры! Ничего специально для этого городить не надо. И распределить количество бит(плоскостей) на точку между планами мы можем как захотим. И вообще, можем сделать хоть 6 планов по 2 бита на точку. И экраны можно сделать полупрозрачные. А рисовать в каждый в отдельности просто запрещая чужие битовые плоскости.
Вот, чтоб была яснее идея, набрасал щас прогу(для ПЦ;(), которая разбивает 256-экран на два 16-цветных. Правда, адресация там не плановая, а линейная, потому условно первая половинка байта - пердний план, вторая - задний. Пикрепил к сообщению.

Lethargeek>Ты лучше напиши наподобие того, как я объяснял идею вентильного экрана:
что в каждой плоскости записано, и что мы увидим на экране в результате.

Постараюсь, просто я сейчас пытаюсь состыковать свою и твою версию.

Lethargeek

03.11.2005, 20:22

madcore> Так я про то и говорю! Нужен сдвиг как на ЕГА, только _нециклический_,
' а чтобы байт мог записаться в соседние 2.

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

Lethargeek> Зачем лишний регистр, если битовый список разрешенных и
' запрещенных плоскостей фактически и есть цвет.

madcore> Нет, не фактически, ибо в запрещенных плоскостях может уже быть
' записан "1", а в нашем цвете там "0".

НЕТ, ФАКТИЧЕСКИ, :) - мало ли что где записано, мы ж говорим про ВЫБРАННЫЙ цвет.

Что касается записи - условно назовем варианты "моим" и "твоим".
Плюс для простоты рассмотрим всего три битовых слоя (красный, синий, зеленый).

ЗАДАЧА ПЕРВАЯ: на произвольном фоне напечатать символ/нарисовать отрезок и т.п.

"твой" вариант - без проблем, выбрали цвет и за один проход отправляем байты во все слои.

"мой" вариант - сначала печатаем "маску" - инвертим байты и отправляем их по AND во все
"нулевые" слои (то есть биты которых - нули в регистре "выбора цвета", он же регистр
разрешения слоев) - а можно вообще во ВСЕ слои, роли не играет. После чего печатаем туда
же исходные неинвертированные байты по OR. То есть два прохода.

ЗАДАЧА ВТОРАЯ: на произвольном фоне напечатать восьмицветный спрайт.

"мой" вариант - сначала печатаем маску спрайта по AND во все слои, как и полагается.
После чего печатаем туда же три цветовых слоя спрайта - R,G,B. Всего четыре прохода.

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

Вопрос на засыпку: какой из двух вариантов следут выбрать? Правильно, ОБА! ;)
Но здесь все опять упрется в сложность схемы. Можно придумать универсальный режим записи,
например, действительно переназвать регистр разрешения слоев в регистр выбора цвета
(или, что точнее, регистр различия слоев), и для обоих "типов" слоев - теперь не
разрешенных и запрещенных, а просто "единичных" и "нулевых", устанавливать свой режим
записи (и чтения), то есть по одному биту на разрешение чтения/записи, по одному биту
на NOT, и по два на OR/AND/XOR (см. поправленные последние спецификации). Такая схема
справится с любыми осмысленными режимами записи и чтения (хочешь - проверь ;) ).
Соблазнительно. Но вот делать это в железе... ладно, об этом ниже. Пока же, если
придется от чего-то отказаться, лучше оставить "мой" вариант, как более универсальный
и ориентированный на спрайты (это важнее векторной графики, которую по-прежнему можно
будет делать в одном цвете с той же скоростью).

madcore> Т.е., фактически у тебя получится экран 12 плоскостей, так? Так вот я это и
' имею ввиду, что его разделить на 2 можно просто установкой палитры! Ничего специально
' для этого городить не надо. И распределить количество бит(плоскостей) на точку между
' планами мы можем как захотим. И вообще, можем сделать хоть 6 планов по 2 бита на точку.
' И экраны можно сделать полупрозрачные. А рисовать в каждый в отдельности, просто
' запрещая чужие битовые плоскости.

Как все просто, оказывается! :D И распределить можем, как захотим, и экраны сделать
"полупрозрачные"... Ты лучше "имей в виду", что разводить все это, паять и отлаживать
не мы с тобой будем (если вообще до этого дойдет), а железячники-добровольцы, которым
уже отдельное спасибо за то, что откликнулись. Или ты крутой схемотехник-электронщик?
Я вот нет... ;) Так что не стоит людей пугать раньше времени, а то они поразбегутся. :(

Пусть сначала хотя бы предварительный (неоптимальный) вариант схемы появится. Пока только
еще отдельные вопросы выясняем. И спецификации, которые я вложением кидаю, тоже не на
пустом месте взялись. Так, идея 4096-цветного экрана основана на том, что в любом режиме
контроллер на каждые восемь пикселов читает из слоя по два байта - в SCF это пикселы и
атрибут, в APA пикселы заднего и переднего планов. И если два плана не нужны, почему бы
не объединить полученные значения пикселов, увеличив разрядность. И "плоскостей" (то есть
физически, как отдельных линеек памяти) у меня 6, а не 12, и писать одновременно даже
в 4096-цветном режиме можно по-прежнему только в 6, то есть вывод в два раза медленнее.
Но просто для картинок пойдет. Причем заметь, что в любом режиме схема чтения контроллером
из видеопамяти практически не меняется. А 6 плоскостей тоже не случайно - это позволит
в крайнем случае обойтись без палитры, а спековские IGRB легко перевести в удобную для
ЦАП форму GRBgrb, аналогично и 64 цвета масштабируются в 4096. А еще это даст возможность
легко менять яркость планов относительно друг друга (обычно лучше, чтобы спрайты были ярче).

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

Не стоит забывать, что видеокарта планируется для СПЕКТРУМА. 16-битной консоли из него
все равно не получится (а если какой-то суперчип прикрутить, еще неизвестно, что к чему
прикручивается, и что получится в результате - навороченный Спек или нерационально
используемый видеочип ;) ). Главная задача - обеспечить неплохие возможности при
сохранении легкости программирования именно для спектрумистов, то есть важен баланс
возможностей/ограничений с одной стороны и сложности реализации с другой. А не просто
"голые" характеристики, как бы завлекательно они ни выглядели.

CHRV

04.11.2005, 00:32

Не стоит забывать, что видеокарта планируется для СПЕКТРУМА. 16-битной консоли из него
все равно не получится (а если какой-то суперчип прикрутить, еще неизвестно, что к чему
прикручивается, и что получится в результате - навороченный Спек или нерационально
используемый видеочип ;) ). Главная задача - обеспечить неплохие возможности при
сохранении легкости программирования именно для спектрумистов, то есть важен баланс
возможностей/ограничений с одной стороны и сложности реализации с другой. А не просто
"голые" характеристики, как бы завлекательно они ни выглядели.
MSX не шестнадцати-битная консоль, а v9990 специально создан для 8битного процессора (я бы даже сказал специально под архитектуру Z80). Если вы этого не знаете, то не надо пудрить другим мозги. Я за трейдом слежу и не желаю чтобы изза своей неосведомленности дизориентировали других. Будьте внимательны!

Lethargeek

05.11.2005, 18:14

CHRV> MSX не шестнадцати-битная консоль, а v9990 специально создан для 8битного процессора (я бы даже сказал специально под архитектуру Z80). Если вы этого не знаете, то не надо пудрить другим мозги. Я за трейдом слежу и не желаю чтобы изза своей неосведомленности дизориентировали других. Будьте внимательны!

Упоминался "какой-то суперчип", а не конкретно v9990. Причем в контексте именно завышенных (на мой взгляд) аппетитов madcore в вопросах разработки оригинального девайса. Чего ему хочется, было скорее для 16-биток, ИМХО.

Lethargeek

05.11.2005, 18:23

Я тут подумал на досуге (пока вы тут все молчите :mad: ) - скорее всего, "внутренний" ldi(r) сделать можно, а если при этом несколько изменить функциональную схему, можно будет его выполнять и с учетом логических операций (и даже возможно сдвига).

А это открывает уже такие возможности... :eek: :eek: :eek:

Короче, грядет очередная ;) перетряска спецификаций. В голове булькает некая смесь из старых моих идей, некоторых предложений madcore и даже Владимира Кладова! Надеюсь, за выходные управлюсь, ждите.

ASDT

05.11.2005, 19:03

Пока "В голове булькает" ...
Напоминаю, тема - "Идея простого расширения ... "

Ewgeny7

05.11.2005, 19:30

Пока "В голове булькает" ...
Напоминаю, тема - "Идея простого расширения ... "
Угу. Пока что никто не предложил схему даже того самого простого расширения.
Зато, глядишь через пару месяцев GeForce будет ничто по сравнению со Спековской карточкой...

SMT

06.11.2005, 02:00

пока самый простой (но глючный)вариант расширения до цвета на точку у AlCo из ZX.SPECTRUM

lvd

06.11.2005, 11:46

пока самый простой (но глючный)вариант расширения до цвета на точку у AlCo из ZX.SPECTRUM

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

Знахарь

07.11.2005, 16:08

Так, народ, я уже одурел :))) А 4x4 attr уже всё ? И CHRV прав насчет v9990. Ну а спрайтов аппартаных не будет ? Как на амиге : задал размер спрайта, куда, откуда - всё. ??? А море цветов, здается мне необязательно. Хватило б и 64. Вполне.

Знахарь

07.11.2005, 16:12

И давайте поддержим 384х304. Хотя бы в текст листалках и т.п. системном софте. Про игры уже молчу :)

Знахарь

07.11.2005, 16:14

LVD, а чего "на скорпе и хз какие будут адреса кусочков" ???

lvd

07.11.2005, 18:21

LVD, а чего "на скорпе и хз какие будут адреса кусочков" ???

А ты почитай про 384х304 в первоисточнике - и поймёшь... =)

Знахарь

08.11.2005, 12:02

Читал... Все ж прошу объяснить. А про режимы может поголосовать ? И потом про режимы аля 1 цвет на 1 точку: не жирно ли ? Зачем ? Это какой размер графики будет ? И где взять граф редактор под такие хитрые режимы ? С режимами типа 4x4 attr и т.п. хоть можно юзать то что есть. Как Вы думаете ?

Lethargeek

08.11.2005, 19:51

Подождите немного, в новом варианте все будет - и атрибуты 4x4, и APA, и стандартный экран, плавно переходящий в APA, и поддержка Hardware Multicolor даже появится. Может, (после)завтра представлю, еще не додумал немного. :sleep:

Навороченность при этом не сильно возрастет, скорее так: произойдет количественное усложнение функциональной схемы при качественном упрощении.

ASDT> Напоминаю, тема - "Идея простого расширения..."

Ну да, начиналось-то с "простого". А я уже предлагал тему переназвать, но реакции нет.

Знахарь> Так, народ, я уже одурел :)) А 4x4 attr уже всё ? И CHRV прав насчет v9990.
' Ну а спрайтов аппаратных не будет? Как на амиге: задал размер спрайта, куда, откуда
' - всё. ??? А море цветов, здается мне необязательно. Хватило б и 64. Вполне.

"Как на амиге" - получится недо-амига. Только дороже. Для полноценных спрайтов надо
полноценный видеопроцессор, взять готовый - прощай совместимость. Пока достаточно
предусмотреть подключение в схему чего-то такого в будущем. Насчет цветов - согласен,
за глаза хватит 64, а 4096 - ну просто само напрашивается приделать, если для этого
почти ничего не надо добавлять - почему бы и нет.

Знахарь> И давайте поддержим 384х304. Хотя бы в текст листалках и т.п. системном софте.
' Про игры уже молчу.

Невыгодно. Для игр - не годится, адресация там ужасная, :v2_scare: ну даже если и для этого сделать
отдельную схему автопересчета адреса (как у меня для совместимости со стандартным экраном)
304 строки - это очень плохо, сильно замедляет обсчет адресов. 256 строк - оптимально,
чем плох режим 384x256? По крайней мере по горизонтали размер тот же. И годится далеко не
только для листалок. ;)

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

Lethargeek

09.11.2005, 18:42

Размышляя на тему реализации "внутренних" ldir-ов, я подумал: что, собственно, происходит
в разных ситуациях при таких пересылках? Например, ldi из ОЗУ в видеопамять - сначала байт
читается из обычной страницы ОЗУ, потом записывается в перехватываемую страницу - и
одновременно в видеопамять через логическую операцию с регистрами-защелками. И наоборот,
для ldi из видеопамяти в ОЗУ сначала в защелки читаются байты, потом они суммируются
какой-то логической операцией и полученный байт через процессор отправляется в ОЗУ.

А при "внутреннем" ldi (то есть когда обращение к обоим адресам источник/приемник
перехватывается видеокартой) что произойдет? То и другое - читаются байты, суммируются,
полученный байт процессором отправляется в ОЗУ - и одновременно обратно в видеопамять.
То есть во все слои попадают одинаковые байты, что очень плохо. Очевидно, что от проца
требуются только адреса приемника и источника, а данные не нужны - и если байт данных при
записи проигнорировать, то в адрес-приемник в видеопамяти попадет содержимое защелок,
полученное перед эти при чтении, то есть произойдет параллельная пересылка, чего мы и
добивались!

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

Понятно, что такой ldi годится только для параллельного копирования данных в видеопамяти,
то есть прежде всего для "побайтных" прокруток изображения. Вот если бы можно было делать
такие пересылки с учетом логических операций! А для этого нужно просто ввести "второй
комплект" регистров-защелок (то есть теперь имеем отдельные для чтения и для записи) и
распараллелить схему выполнения логических операций. А заодно дать возможность отдельно
выбирать базовые 16K страницы видеопамяти для чтения и записи. То есть запись происходит
так: байт, поступивший от проца, распределяется по Ч-защелкам, одновременно заполняются
данными из видеопамяти З-защелки, выполняются логические операции и результат из З-защелок
записывается обратно в видеопамять. А вот при выполнении "внутреннего" ldi прочитанные из
видеопамяти байты сначала попадут в Ч-защелки, суммируются "на выход" (результат отдается
процу) и остаются в Ч-защелках. Теперь, когда придет запрос на запись, Ч-защелки
байтом, поступившим по шине, не заполняются, а сразу производятся логические
операции с заполненными из адреса записи З-защелками и собственно запись в видеопамять.
Добавить к этому возможность записи "со сдвигом" и "зеркальной" записи, как раньше.

Lethargeek

09.11.2005, 18:43

Какой отсюда вывод? А такой, что спрайты можно теперь хранить прямо в видеопамяти,
и выводить на любой фон со скоростью, сопоставимой со скоростью работы обычной спековской
графики - и это все в 64 цветах! Причем маску можно (нужно!) хранить в обычном ОЗУ, что
сэкономит место в видеопамяти под сами спрайты. Даже если в APA-режиме используются все
четыре базовых страницы (два переключаемых задних и два передних плана), все равно в
каждой странице остается 6*4K, что с учетом масок в обычном ОЗУ составит эквивалент 16-32К
обычной спековской графики. Да еще и в неотображаемых (отсекаемых бордюром) областях
можно чего-нибудь хранить. Плюс менее важные спрайты/тайлы можно по-прежнему печатать из
ОЗУ за несколько проходов.

Процедура вывода "спрайта" в APA-режиме будет выглядеть примерно так:

out... ; (установка базовых страниц чтения и записи видеопамяти)
out... ; (вывод по AND во все плоскости)
ld hl,^маска ; в неперехватываемых адресах
ld de,^экран ; в видеопамяти (базовая страница для записи)
push de
ЦИКЛ
- ld a,e
- call "цепочка ldi"
- ld e,a
- inc d
ПОВТОРИТЬ
pop de
ld hl,^спрайт ; в видеопамяти (базовая страница для чтения)
out... ; (вывод по OR во все плоскости)
ЦИКЛ
- ld a,e
- call "цепочка ldi"
- ld e,a
- inc d
ПОВТОРИТЬ
out... ; (восстановили базовые страницы, если нужно)

Можно попытаться еще "упихать" все это в один цикл (с некоторыми аппаратными
доработками), но не уверен, что получим существенное ускорение.

Lethargeek

09.11.2005, 18:44

Следующая мысль: если APA-графика сможет работать с той же скоростью, что и спековская,
нафиг нужен отдельный SCF-режим с собственной логикой на видеокарте - если можно настроить
обычный APA-режим на совместимость со стандартным спековским. Короче, "я тебя породил,
я тебя и убью" - (c) Тарас Бульба. Вместо SCF реализуем "атрибутный" APA.

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

Очевидно, что при движении по строке на каждые восемь 64-цветных пикселов читается сразу
шесть "атрибутов". Эту "избыточность" можно использовать так - каждый "атрибут" будет
состоять из двух байт, причем второй для совместимости используется только при несовпадении
их битов BRIGHT - он определяет дополнительные три бита цветов INK и PAPER, то есть
уже будет тоже по 64 цвета для INK/PAPER. И FLASH-и отдельные можно сделать. И отдельно
включаемый BRIGHT2, и даже, наверно FLASH-color, хотя незачем, по-моему - где они были?
Ну, можно еще гигаскрин аппаратный добавить - просто автоматически переключать базовые
страницы видеопамяти на каждой новой строке.

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

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

В "режиме совместимости" постоянно включены запись "с заменой" во все плоскости, то есть
все абсолютно прозрачно для старого спековского софта. Чтение при этом можно либо вообще
запретить (в ОЗУ есть копия экрана), либо суммировать плоскости по AND (тогда пикселы
остальных цветов получатся нулевыми - PAPER) или по OR (тогда единицами - INK). Плюс
режим "игнорирования данных" надо сделать отключаемым, потому что кроме ldir-ов еще
всякие rr/rl [hl], set/res [hl] и rrd/rld производят и чтение, и запись в память.

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

Lethargeek

09.11.2005, 18:45

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

1. Читаются шесть пар байт из всех плоскостей
2. Определяются INK и PAPER для атрибута
3. Для каждого пиксела (первый байт) определяется его код (цвет)
4. Если это 111111 или 000000, меняем их на INK и PAPER соотв-но
5. Для каждого пиксела (второй байт) определяется его код (цвет)
6. Если он не "прозрачный", заменяем им код пиксела, полученного из первого байта
7. Из формата GRBgrb код преобразуется в формат GRB000grb000 для ЦАП
8. Эти нули заполняются кодом второго байта для получения 4096 цветов

Весь фокус в том, что в "атрибутном APA" на этапе 5 ВК всегда подсовывается "прозрачный"
цвет, а на этапе 8 - нули вместо кода второго байта. В обычном "двухплановом" APA на
этапе 2 INK всегда равен 111111, а PAPER - 000000, на этапе 8 - снова всегда нули. И
наконец, в 4096-цветном режиме те же INK и PAPER подсовываются на 2 этапе, "прозрачный"
цвет на 5 этапе, а на 8 этапе цвет правильно расширяется в формат GRBGRBgrbgrb

Итого субъективно имеем следующие "режимы" (не считая бессмысленных вариантов):

- стандартный режим - частный случай "атрибутного" APA-mode, обрезан бордюром
- полный "атрибутный" APA - 64 цвета, раздельный FLASH, на весь экран (или его часть)
- он же с вертикальными половинками/горизонтальными половинками/четвертушками
- он же с hardware multicolor (второй счетчик бегает по тем же адресам в другой странице)
- этот же multicolor еще и с вертикальными половинками (то есть "атрибут" 1x4)
- "двухслойный" APA-mode - 64 цвета, передний и задний план
- "сдвоенный" APA-mode - 4096 цветов, пикселы разных планов "сцепляются"

Причем все эти "режимы" можно переключать "на лету" на одном экране - вот где просторы для
демомейкерства. Конечно, неплохо бы добавить возможность генерации INT на любой строке, а
обработчик, читая из порта номер последней выведенной строки, сам разберется, кадровое это
прерывание или строчное. Тогда переключение можно использовать в полной мере.

В общем, как я и говорил - количественное усложнение схемы при качественном упрощении.
Основая тяжесть теперь ложится на схему взаимодействия с шиной, а не на видеологику.
То есть на каждую линейку памяти нужно сажать одинаковые схемы для выполнения логических
операций для записи/чтения, сдвига, отражения... но зато - одинаковые. А остальная часть
должна упроститься. И схема Reset-а тоже.