____ / - - ─ ─── ─────────────────────────────────/ / |─── ─── ─ - - Слушаем вас ? / / / 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 привел свою точку зрения. Нельзя несогласится с тем,что спектрумовский экран оставляет желать лучшего. Однако пока никто не решил эту проблему. Почему ? Может быть это не реально ? Может быть нужно наконец признать,что Спектрумэто Спектрум и не пытаться делать из него невесть что ? А может быть все-таки нужно искать ? Ведь кто ищет-тот найдет! Хотелось бы услышать ваше мнение! Пишите нам!