|
TargeT
#06
18 марта 2000 |
|
Слушаем вас ? - Valeron рассуждает на тему "чего не хватает спектруму?"

____
/
- - ─ ─── ─────────────────────────────────/ / |─── ─── ─ - -
Слушаем вас ? / / / Valeron
- - ─ ─── ────────────────────────────────────/ /──── ─── ─ - -
/
***
Чего нам давно не хватает.
Hi, people! Опять я отнимаю у вас время своими бреднями. Но
хочется потрепаться, а не с кем.
И причина для трепа есть: видео режим нашего любимца Спека.
На заре рассвета, а кому-то может быть и в самый разгар,
платформы у нас в постсовке любили почесать язык на тему
сколько цветов и сколько точек в строке хотелось бы иметь на
Spectrum. Серьезно так рассуждали со страниц популярных тогда
электронных журналов сколько цветов желательно и таблицы
приводили - сколько памяти это сожрет. Круто выходило, чуть ли
не все 128 килобайт под видео. Я тогда еще совсем зеленым был,
читал разинув рот и восхищался: Во какое будущее ждет!
Однако годы добавили цинизма и скепсиса, понял как трудно
стандартный экран за один инт перебросить, без различных
ухищрений со стекоm не обойтись, да и то не на всех моделях
такой номер проходит, некоторые безбожно тормозят. Конечно
Турбо режим хорош, но и в турбо режиме получить двойное
ускорение работы в ОЗУ практически невозможно (если ошибаюсь -
не бейте!), но суть в другом: сколько же будет строиться такой
экран в памяти? Даже в турбо режиме? Сам собой напрашивается
вывод: экран не должен занимать много памяти, но об этом тоже
конечно можно спорить.Но сколько бы нам не хотелось видеть
цветов на экране, мы должны помнить о производительности
процессора и поэтому видео область не должна быть большой. Если
еще можно мириться с тем что экран перебрасывается за 5-10
интов, то построение такого экрана в памяти будет происходить
безобразно долго. Думаю, не стоит выходить за рамки двойного
размера, так что 6912 + 6912 = 13824. Да, конечно, можно
отвести и целую страницу 16384 байт, но если у вас хватит
терпения дочитать до конца сего опуса, то вы поймете почему
именно 13824.
Сделать расширенный режим цвета будет не легко, но и такая
ситуация как есть тоже не устраивает, один цвет на знакоместо и
один фон сильно усложняют создание цветной графики, особенно не
полноэкранной. Ну как спрайт 2 на 2 знакоместа (что бы
сохранить обзор как можно большего участка карты выбран
наименьший размер спрайта) скролировать попиксельно и сохранить
цвета? Нужен еще хотя бы один битплан. Это и не столь
обременительно для процессора и вполне приемлимо с эстетической
точки зрения: при сохранении системы цвет/знакоместо, что очень
удобно в плане компактности видео области, получается уже 2
цвета и 2 фона. Фон есть фон и его придется делать одинаковым,
а вот цвет - настоящая золотая жила для gfx-мейкера.
Не претендую на оригинальность идеи, ведь вся вселенная
развивается по спирали, и наверняка кому-то приходило в голову
нечто подобное, однако стоит высказать это вслух.
Итак, сама по себе идея сформировалась когда приходилось
любоваться дрожащими заставками, когда каждое прерывание
переключается 5 и 7 страницы памяти в видео области. Дрожание
конечно действует на нервы, но картинки получаются симпатичная.
RAGE такие фокусы часто используют. Если убрать дрожание - вот
вам дополнительный битплан. Что приходит в голову по этому
поводу? Можно сделать как General Sound с отдельным процессором
и своей памятью, но нужно обходиться малой кровью, стоимость
General Sound сыграла, на мой взгляд, роковыю роль в
распростронении этого рульного девайса. Наше устройство должно
быть дешевым, доступным для всех, иначе мало шансов получить
распростронение, и соответственно его не станут поддерживать
програмисты и оно останется никчемным наворотом.
Второй путь - вмешаться в работу видео процессора и
формировать экран с двух страниц. По моему не лучший способ
потому как в разных компах видео процессор реализован по
своему. Но если судить по Балтику, то получается очень
заманчиво попробовать переключать страницу памяти с пятой на
седьмую в тот момент, когда видео процессор выбирает байт
экрана. Тут следует пояснить что я имею в виду. В Балтике
процессор получает команду ожидания по линии WAIT когда к
экранной области обращается видео процессор. На шине памяти
появляется младший байт адреса атрибутов,в следующем такте этот
байт принимается во внутренний регистр регистр РУ'шек и на шину
подается старший байт области атрибутов. В следующем такте этот
байт принимается РУ'шками, а затем в следующем такте из РУ'шек
считывается байт данных в регистр, реализованный на отдельной
микросхеме. Если теперь не дожидаясь прихода следующего
тактового импульса изменить один бит адреса отвечающий за номер
страницы, подать сигнал CAS для записи полученного нового
старшего байта в Ру'шки и тут же считать из РУ'шек байт данных
в еще один регистр, который придется реализовать дополнительно
впаяв еще одну микросхему ИР27, то мы получим два раздельных
байта атрибутов соответствующих одной и той же позиции экрана.
Далее таким же образом поступаем и с байтом данных экрана,
который выбирается в последующих тактах. Итак получим два байта
атрибутов и два байта данных экрана. Теперь нужно только
донести их до выхода видео. Для этого можно просто
продублировать соответствующие микросхемы, в Балтике это КП15 и
две КП12, а в сумме с тремя регистрами ИР27 получается всего
шесть корпусов. Беда в том, что я не уверен что такой подход
сработает, у меня нет описания на работу РУ5 и я не знаю с
какой частотой можно обращаться к ним.
Третий путь - не самый изящный, но, мне кажется, наиболее
приемлимый. Нужно сохранять образ экрана скажем с пятой
страницы и смешивать его с образом из седьмой страницы памяти.
Как это будет выглядеть.
Видео процессор каждую пятидесятую долю секунды приступает к
выборке экрана из видео области. За один раз выбирается один
байт. Этот байт записывается в промежуточный регистр
реализованный на отдельной микрухе. Дальше в разных компах по
разному, в одних вступают в дело мультиплексоры, в других -
сдвиговые регистры, это уже не столь важно - главное что из
этого регистра можно брать этот байт и обрабатывать как
захотим.
Итак, идея в том что бы сохранять этот байт в отдельной
микрухе памяти. Возьмем микруху динамической памяти, например
РУ17 на 8 килобайт. Экран с атрибутами требует 6912 байт, что
вполне поместится в нашей РУшке. Это будет буфер экрана.
Теперь при выборке видео процессором байта экрана из памяти
нужно считать из нашей РУшки байт и сохранить в отдельном
регистре, а на это место в РУшку записать только что изъятый
видео процессором байт. Теперь мы имеем два экранных байта и
можем накладывать биты из обоих друг на друга с
соответствующими цветами inc и paper.
Пока не переключаются страницы 5 и 7 в видео области
компьютера, конечно, байт будет один и тот же, но если же
начать теперь каждый инт переключать экраны с пятого на седьмой
и обратно, то мы можем получить недрожащее (!) изображение.
Ну скажем, в нормальном спектуме экранный байт берется
побитно и с учетом цвета формируется точка экранного
изображения, затем подается на видео выход. Нам теперь нужно
продублировать процесс и паралельно обработать точно таким же
образом второй байт и на этапе формирования точки экранного
изображения смешать биты по логике "ИЛИ". Можно по другому:
формировать точку изображения из первого байта свою, из второго
- свою, а затем, когда уже будет подаваться на видео выход -
смешать сигналы. Поскольку на видео выходе обычно стоят
делители на резисторах, то можно предложить такую схему, когда
меняется коофициент деления и тогда можно получить двойную
яркость для одного цвета или же новые оттенки цветов смешивая
скажем пурпурный цвет с желтым например. Можно даже на
отдельном регистре задавать коофициенты деления на каждый цвет
и тем самым задавать палитру изображения. Можно сделать два
отдельных регистра и задавать палитру для каждого из двух
битпланов. Как вам такое: 16 цветов из палитры 256? А с учетом
полуяркости Bright - вдвое больше.
Теперь о горьком. Такая конструкция не позволяет выводить
анимацию с частотой 50 кадров в секунду, а именно старый спрайт
будет накладываться на новый и на экране будет тянуться хвост
за спрайтом. Хотя можно предложить такой вариант построения
спрайта, когда скажем туловище выводится в пятой странице, а
ноги в седьмой. Тогда меняя поочередно то в пятой то в седьмой
странице участки спрайта можно получить нормальныую анимацию. В
этом отношении этот вариант менее удобен чем второй путь,
который я описывал выше.
Все вышеизложенное является сырой идеей и не подкреплено
никакими экспериментами, никаких попыток реализовать такое на
практике пока не предпринималось к сожалению, все это я пишу
что бы поделиться с заинтересованными людьми своими идеями.
Ну и наконец, кто это может создать в железе. Должен вас
огорчить, но я не смогу. Может когда-нибудь я достигну такого
уровня, но пока мне доводилось препарировать лишь Байты и
Балтики, а карта нужна универсальная, для любого компа. Да и в
одиночку такой девайс разработать самому, согласитесь, трудно.
В любом случае буду рад если кто-то заитересуется этой идеей.
16.09.1999
FOX> Итак,Valeron привел свою точку зрения. Нельзя несогласится
с тем,что спектрумовский экран оставляет желать лучшего. Однако
пока никто не решил эту проблему. Почему ? Может быть это не
реально ? Может быть нужно наконец признать,что Спектрумэто
Спектрум и не пытаться делать из него невесть что ? А может
быть все-таки нужно искать ? Ведь кто ищет-тот найдет! Хотелось
бы услышать ваше мнение! Пишите нам!
Другие статьи номера:
Вступление - Вот так вывалился на белый свет 6-ой номер нашего чтива. |
Вести с полигона - новости из Гродно от Fox, Smont, Black. |
Горизонты - плагин для работы с винчестером на Scorpion 256. |
Слушаем вас ? - Valeron рассуждает на тему "чего не хватает спектруму?" |
Опять промазал :) - За пару дней до аРМИИ... |
P.S. - Послесловие. |
Похожие статьи:
В этот день... 13 ноября