TargeT #06
18 марта 2000

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

<b>Слушаем вас ?</b> - 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. - Послесловие.


Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
Новости - Striker и Zeg составили мощный список белорусских спектрумистов.
Вступление - этoй oсeнью oжидаeтся аж два кoнкурса: FUNTOP`98 и ARTCOMP`98.
Меломания - VOODOO (англ.)Оригинальный текст альбома.
Деморынок - Хит-парад музыкальных демонстраций.
Словарь - Сексопатологические термины.

В этот день...   19 апреля