Видеорежимы и работа с ними

[icebear]

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

Я надеюсь что понятно сформулировал вопросы

[Advertiser]

[icebear]

Или не интересно? Или я вопросы поставил непонятно?

[spensor]

ИМХО, не в тот раздел запостил. В программирование нужно было.

[icebear]

ИМХО, не в тот раздел запостил. В программирование нужно было.

Хм, действительно

Господа модераторы, как перенести это в другой раздел? Или заново писать?

[CHRV]

Хм, действительно

Господа модераторы, как перенести это в другой раздел? Или заново писать?

Вышла дока по АТМ , в том числе и по програмированию расширенных видеорежимов. Можно скачать и прочитать.
Смотрите на http://atmturbo.narod.ru

[icebear]

Вышла дока по АТМ , в том числе и по програмированию расширенных видеорежимов. Можно скачать и прочитать.
Смотрите на http://atmturbo.narod.ru

Качал, читал. Собственно вопрос возник именно из-за подобных организаций экранов.

[Максагор]

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

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

512х192 подразумевает деление точек на чётные/нечётные и соотвественно различное местоположение в памяти. Так же это вроде сделано в АТМ.

Да, именно так.

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

И здесь верно.

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

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

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

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

Желательно в таклм случае было бы иметь и видеопроцессор, и прямой доступ одновременно. Хотя если видеопроцессор очень крутой, то, так и быть, согласен обойтись без него!

- если допустить наличие такого спецпроцессора, какие функции он должен выполнять (если можно, то в виде списка)?

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

2) Работа с различными видеорежимами (консоль, ZX-квадратики, аппаратный мультиколор, каждай точка своим цветом, может быть даже TRUE-color)

3) Вывод спрайта (всего или его части) в любую точку экрана.

4) Морфинг спрайтов, их масштабирование.

5) Автоконвертация спрайтов из одного формата в другой (насколько возможно, без потери качества или с минимальной потерей) - к примеру, надо отобразить цветной спрайт, подготовленный на обычном спеке (цвета квадратиками, черезполосица) на линейный TRUE-COLOR (или обратная ситуация, хе-хе...)

6) Рисование и раскраска графических примитивов.

7) Работа с векторной графикой (ломаные линии, дуги, сокрытие теневых контуров, заливка плоскостей цветом и текстурой, работа с освещением (откуда свет, там плоскость светлее и т.д.)).

8) Может еще что забыл...

Я надеюсь что понятно сформулировал вопросы

Вполне.

[icebear]

В первую очередь хочу поблагодарить за ответ. Теперь по пунктам.

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

Другого с 16-ти разрядной шиной не дано. Мог бы спасти eZ80, если бы не его внутренние порты.

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

Понятно. Т.е. работать с кусками видеопамяти через банки труда не составляет. Я почему спросил? Допустим, надо вывести символ или примитив, располагающийся в области экрана, которая приходится на две банки. Это придётся делать bounds check, щёлкать страницами и т.п.

К тому же, если говорить именно про ATM-1/2/2+, то четные и нечетные столбцы изображения (в текстовом и мультиколорном экранах) расположены и в одной и той же странице, только в разных ее половинках. И только атрибуты лежат в другой странице. Сложнее с EGA-дкраном, где атрибутов нет как класса. Там действительно часть столбцов пикселей лежат в разных страницах.

Кстати, из книги я не понял, там (в АТМ) разделение идёт по бит-плейнам (согласно EGA стандарту) или всё-таки постранично (т.е. биты цветов лежат физически в одном куске памяти и располагются в нибле)?

А в случае ATM2/2+ можно вообще запрограммировать диспетчер памяти так, чтобы все необходимые экранные страницы (из всего-то две) одновременно присутствовали в адресном пространстве. Тогда и щелкать портами не надо.

Удобное решение, согласен.

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

Вот здесь я не совсем понял. 32К тяжелы для основного процессора? Или что имеется в виду под тяжестью экрана?

Желательно в таклм случае было бы иметь и видеопроцессор, и прямой доступ одновременно. Хотя если видеопроцессор очень крутой, то, так и быть, согласен обойтись без него!

Зачем необходим прямой доступ к видеопамяти? А как насчёт дать возможность видеопроцессору читать любой участок основной памяти (при условии, что видеопамять как таковая не входит в карту основной памяти)?

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

Опять же, не было бы удобнее это делать не через порты, а через общую память? Например задействовать тотже стандартный экран Спектрума в качестве буфера между основным процессором и видеопроцессором? Порты мне кажется медленно.

2) Работа с различными видеорежимами (консоль, ZX-квадратики, аппаратный мультиколор, каждай точка своим цветом, может быть даже TRUE-color)

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

3) Вывод спрайта (всего или его части) в любую точку экрана.

4) Морфинг спрайтов, их масштабирование.

Ну это само собой, иначе нужен прямой доступ к видеопамяти.

5) Автоконвертация спрайтов из одного формата в другой (насколько возможно, без потери качества или с минимальной потерей) - к примеру, надо отобразить цветной спрайт, подготовленный на обычном спеке (цвета квадратиками, черезполосица) на линейный TRUE-COLOR (или обратная ситуация, хе-хе...)

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

6) Рисование и раскраска графических примитивов.

7) Работа с векторной графикой (ломаные линии, дуги, сокрытие теневых контуров, заливка плоскостей цветом и текстурой, работа с освещением (откуда свет, там плоскость светлее и т.д.)).

8) Может еще что забыл...

Понятно, ещё раз спасибо. Важными пунктами для меня пока остаются глубина цвета (которую я бы посадил жёстко на 8 бит) и единственный видеорежим. Хотелось бы обсудить это.

[Максагор]

Понятно. Т.е. работать с кусками видеопамяти через банки труда не составляет. Я почему спросил? Допустим, надо вывести символ или примитив, располагающийся в области экрана, которая приходится на две банки. Это придётся делать bounds check, щёлкать страницами и т.п.

Естественно, надо заранее продумать архитектуру и расположение экранов и программы. Тогда все будет ОК. А прижелании можно и Пентиум надолго в замешательство ввести.

Кстати, из книги я не понял, там (в АТМ) разделение идёт по бит-плейнам (согласно EGA стандарту) или всё-таки постранично (т.е. биты цветов лежат физически в одном куске памяти и располагются в нибле)?

Нет, разделение не по битпланам.
ZX-экран, текстовая консоль и режим 640х200 имеют, как и в обычном спектруме отдельное поле монохромного изображения и отдельное поле атрибутов. А т.н. EGA-режим 320х200 является EGA-совместимым в том смысле, что повторяет пропорции экрана и количество цветов на экране и в палитре. А все цвета (точнее цветообразующие биты) не разнесены нпо разным битпланам, а расположены в одном байте - по 4 бита на пиксель (RGBY), два пикселя в байте.

Вот здесь я не совсем понял. 32К тяжелы для основного процессора? Или что имеется в виду под тяжестью экрана?

Именно его размеры. 32Кб трудновато процессору ворочать туда-сюда...

Зачем необходим прямой доступ к видеопамяти? А как насчёт дать возможность видеопроцессору читать любой участок основной памяти (при условии, что видеопамять как таковая не входит в карту основной памяти)?

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

Опять же, не было бы удобнее это делать не через порты, а через общую память? Например задействовать тотже стандартный экран Спектрума в качестве буфера между основным процессором и видеопроцессором? Порты мне кажется медленно.

То есть, ты предлагаешь ни много, ни мало, а еще и DMA впридачу?

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

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

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

ТОгда это будет уже не спектрум, а другой комп. Причем без софта!

Понятно, ещё раз спасибо. Важными пунктами для меня пока остаются глубина цвета (которую я бы посадил жёстко на 8 бит) и единственный видеорежим. Хотелось бы обсудить это.

С единственным видеорежимом не согласен (тем более без ZX-экрана). А 8 бит глубины - нехай будут...
Еще бы хотелось подробнее обсудить функции видеопроцессора...

[icebear]

Естественно, надо заранее продумать архитектуру и расположение экранов и программы. Тогда все будет ОК. А прижелании можно и Пентиум надолго в замешательство ввести.

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

Нет, разделение не по битпланам.

Понятно, я так и думал.

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

Опять же, решать столкновения и прочее - это задача видеопроцессора. Цвет пикселя можно прочитать через порт например.

То есть, ты предлагаешь ни много, ни мало, а еще и DMA впридачу?

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

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

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

ТОгда это будет уже не спектрум, а другой комп. Причем без софта!

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

С единственным видеорежимом не согласен (тем более без ZX-экрана). А 8 бит глубины - нехай будут...
Еще бы хотелось подробнее обсудить функции видеопроцессора...

Ну с экраном Спектрума надеюсь разобрались. А вот по поводу функций - список хотелось бы. Только не стоит фантазии давать слишком свободный полёт