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

Вид для печати

20.07.2005, 12:23
icebear

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

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

Я надеюсь что понятно сформулировал вопросы :)
21.07.2005, 11:19
icebear

Я так понял, это никому не надо?

Или не интересно? Или я вопросы поставил непонятно?
21.07.2005, 11:37
spensor

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

Цитата:

Сообщение от spensor

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

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

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

Цитата:

Сообщение от icebear

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

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

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

Цитата:

Сообщение от CHRV

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

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

Цитата:

Сообщение от icebear

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

Линейная, но зато нет одновременного доступа сразу ко всему экрану, а только к одной текущей строчке (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) Может еще что забыл...

Цитата:

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

Вполне. :cool:
22.07.2005, 12:28
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 бит) и единственный видеорежим. Хотелось бы обсудить это.
22.07.2005, 13:08
Robus

Цитата:

Сообщение от icebear

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

Новые видеорежимы как правило не прижываются на Speccy, все привыкают к стандарту. Нужно сделать их легко-доступными, тогда будет смысл их создавать!

Цитата:

Сообщение от icebear

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

Смотря как сделать выбираемые участки. Например Atari, там сделанно просто велеколепно, для каждой вертикальной линии можно задать собственный режим, то-ли цветной текст, то-ли графика в любых вариациях. Да ещё и можно указать любую точку памяти от куда брать данные. А на Atari-ST, вообще можно скорость горизонтальной развёртки давать для каждой линии разную !!!
Думаю, что для Speccy идеально будет сделать что-то подобное, что я и делал в Wild Speccy ! Там можно всего-то в каждой линии задать свой адрес памяти для графики и для паперов, плюс цвет палитры для пикселов и не пикселов.

Цитата:

Сообщение от icebear

- скорость вывода графики приемлема при работе с участками экрана через банки?

Приемлема, но если есть проблема с одновременным доступом к памяти процессора и видяхи, то можно сделать какой-нибудь битик в порте который выбиралбы ЧИП для записи в видео буфер. То есть пока ты пишешь что-нибудь в ПАМЯТЬ-1 вторая высвечивается на моник, после OUT'а меняются местами. И тормозов не будет, и всякие корявые программеры, любящие не задумываться о дискреции анимации, будут вынуждены по-умнеть !!!

Цитата:

Сообщение от icebear

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

Конечно стоит сделать процессор, мало того, если сделаете возможность отправить ему собственную прогу и сполнить, то это будет максимально идеально. Так у меня в Wild'е.

Цитата:

Сообщение от icebear

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

Для каждой задачи по разному. А какой проц ? Если у него мощная математика, то грех не сделать 3Д. А список может быть ООООООООчень длинный. Например:

-Возможнть аппаратного мультиколора.
-Что-нибудь со спрайтами.
-Изменение частоты кадров.
-Было бы прикольно вставить рисовалку линий, можно на аппаратном уровне сделать ELIT'у да ещё и ONE-FRAME.
-Неплохо вставить какой-нибудь декомпрессор, я имею в виду для распаковки графики в реальном времени, например: спрайтов. Я когда-то такое делал на Speccy в своей игре Mortal Kombat, она валяется где-то разобранная, но за-то на весь экран, и спрайты на 2/3!

Многое можно придумать ... Но лучше всего самому в процессор отправлять программу. НО НЕ ИМЕТЬ ДОСТУП К ПАМЯТИ - ПЛОХО, пусть с торможениями, но лучше вдвоём, чем кто-то там в "тёмной коробочке" !!!
22.07.2005, 13:36
icebear

Цитата:

Сообщение от Robus

Новые видеорежимы как правило не прижываются на Speccy, все привыкают к стандарту. Нужно сделать их легко-доступными, тогда будет смысл их создавать!

Тоже интересная мысль.

Цитата:

Сообщение от Robus

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

Что понимается здесь под "линией"? Линия знакомест или линия пикселей?

Цитата:

Сообщение от Robus

Да ещё и можно указать любую точку памяти от куда брать данные.

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

Цитата:

Сообщение от Robus

А на Atari-ST, вообще можно скорость горизонтальной развёртки давать для каждой линии разную !!!

А зачем это? И не похоже ли это на возможности Спринтера иметь "окна" на экране в раличных разрешениях?

Цитата:

Сообщение от Robus

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

Какое практическое применение есть этой сегментации видеопамяти? Wild Speccy - это клон?

Цитата:

Сообщение от Robus

Приемлема, но если есть проблема с одновременным доступом к памяти процессора и видяхи, то можно сделать какой-нибудь битик в порте который выбиралбы ЧИП для записи в видео буфер. То есть пока ты пишешь что-нибудь в ПАМЯТЬ-1 вторая высвечивается на моник, после OUT'а меняются местами. И тормозов не будет, и всякие корявые программеры, любящие не задумываться о дискреции анимации, будут вынуждены по-умнеть !!!

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

Цитата:

Сообщение от Robus

Конечно стоит сделать процессор, мало того, если сделаете возможность отправить ему собственную прогу и сполнить, то это будет максимально идеально. Так у меня в Wild'е.

Похожая идея есть (или даже такая же): иметь стандартный софт для видеопроцессора но с возможностью менять его на custom.

Цитата:

Сообщение от Robus

Для каждой задачи по разному. А какой проц ? Если у него мощная математика, то грех не сделать 3Д. А список может быть ООООООООчень длинный. Например:

-Возможнть аппаратного мультиколора.
-Что-нибудь со спрайтами.
-Изменение частоты кадров.
-Было бы прикольно вставить рисовалку линий, можно на аппаратном уровне сделать ELIT'у да ещё и ONE-FRAME.
-Неплохо вставить какой-нибудь декомпрессор, я имею в виду для распаковки графики в реальном времени, например: спрайтов. Я когда-то такое делал на Speccy в своей игре Mortal Kombat, она валяется где-то разобранная, но за-то на весь экран, и спрайты на 2/3!

Насчёт процессора не знаю, пока я просто собираю информацию и мнения по работе с графикой на Спектруме. Что из этого выйдет - неизвестно, но GF или Radeon не выйдут точно :)
Аппаратный мультиколор мне кажется абсолютно ненужным, ибо мультиколор как таковой родился из-за убогих граф. возможностей (как структура экрана, которая должен признать сделана очень умно для своего времени/целей/возможностей, так и глубина цвета).
Изменение частоты кадров - это зачем?
Рисовалки линий и т.п. - для реализации на аппартном уровне я глуп, программно могу, но т.к. я не пуп Земли, любой другой сможет использовать собственную реализацию.
По поводу декомпрессора: упирается в реализацию спрайтов и их формата, пока ещё совсем рано об этом говорить.

Цитата:

Сообщение от Robus

Многое можно придумать ... Но лучше всего самому в процессор отправлять программу. НО НЕ ИМЕТЬ ДОСТУП К ПАМЯТИ - ПЛОХО, пусть с торможениями, но лучше вдвоём, чем кто-то там в "тёмной коробочке" !!!

Да, я вижу аппетит вполне здоровый :) Прелесть "чёрной коробчки" в предсказуемости её поведения и стабильность. А так же некая базовая абстракция.

Спасибо за ответ.
25.07.2005, 08:28
Максагор

Цитата:

Сообщение от icebear

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

Сообщение от icebear

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

1) читай доку по спец процам амиги. там все функции для работы с 2д. Блиттер амижный умеет даже линии рисовать (не как спринтер прямые, но любые диагональные/прямые...)
25.07.2005, 10:40
Shiru

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

Для 3d-игр такая организация неудобна, конечно, зато для 2d даёт очень высокую скорость работы.
25.07.2005, 12:57
icebear

Цитата:

Сообщение от Shiru

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

Вот это мне кажется более разумное построение.
25.07.2005, 13:24
icebear

Цитата:

Сообщение от Максагор

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

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

Цитата:

Сообщение от Максагор

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

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

Цитата:

Сообщение от Максагор

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

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

Цитата:

Сообщение от Максагор

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

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

Цитата:

Сообщение от Максагор

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

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

Цитата:

Сообщение от Максагор

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

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

Цитата:

Сообщение от Максагор

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

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

Цитата:

Сообщение от Robus

А на Atari-ST, вообще можно скорость горизонтальной развёртки давать для каждой линии разную !!!

Это, скорее всего на машинах (Атари-СТ), на которых стоял AGA. Т.е. амижные спец.процы.
26.07.2005, 01:21
acidrain

Цитата:

Сообщение от icebear

А зачем это? И не похоже ли это на возможности Спринтера иметь "окна" на экране в раличных разрешениях?

Да, еще раз повторюсь - это пошло с Амиги, где можно выводить два или более экранов с разным разрешением у каждого. Там вообще хорошие спец.процы. Дело в том, что не стоит изобретать велосипед, сначала изучите опыт уже существующих наработок (пусть то будет игровая консоль или амига), а потом надо делать ;)
Да и существуют же чипы с 2д ускорителями, например вроде texas instruments делает такое чудо =)
А скажите, зачем вообще нужно что-либо читать из портов видео процессора?
26.07.2005, 01:32
acidrain

Цитата:

Сообщение от icebear

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

Ну, мой список вы уже видели =) Если надо более конкретно, то могу по пунктикам разложить =)

* A custom graphics coprocessor, called the Copper, that allows changes
to most of the special purpose registers in synchronization with the
position of the video beam. This allows such special effects as
mid-screen changes to the color palette, splitting the screen into
multiple horizontal slices each having different video resolutions and
color depths, beam-synchronized interrupt generation for the 680x0, and
more. The coprocessor can trigger many times per screen, in the middle
of lines, and at the beginning or during the blanking interval. The
coprocessor itself can directly affect most of the registers in the
other custom chips, freeing the 680x0 for general computing tasks.

* 32 system color registers, each of which contains a 12-bit number as
four bits of red, four bits of green, and four bits of blue intensity
information. This allows a system color palette of 4,096 different
choices of color for each register.

* Eight reusable 16-bit wide sprites with up to 15 color choices per
sprite pixel (when sprites are paired). A sprite is an easily movable
graphics object whose display is entirely independent of the background
(called a playfield); sprites can be displayed over or under this
background. A sprite is 16 low resolution pixels wide and an arbitrary
number of lines tall. After producing the last line of a sprite on the
screen, a sprite DMA channel may be used to produce yet another sprite
image elsewhere on screen (with at least one horizontal line between
each reuse of a sprite processor). Thus, many small sprites can be
produced by simply reusing the sprite processors appropriately.

* Custom bit blitter used for high speed data movement, adaptable to
bitplane animation. The blitter has been designed to efficiently
retrieve data from up to three sources, combine the data in one of 256
different possible ways, and optionally store the combined data in a
destination area. The bit blitter, in a special mode, draws patterned
lines into rectangularly organized memory regions at a speed of about 1
million dots per second; and it can efficiently handle area fill.

* Dynamically controllable inter-object priority, with collision
detection. This means that the system can dynamically control the video
priority between the sprite objects and the bitplane backgrounds
(playfields). You can control which object or objects appear over or
under the background at any time. Additionally, you can use system
hardware to detect collisions between objects and have your program
react to such collisions.

Это описание из старой доброй книги Amiga® Hardware Reference Manual. В ней описан ECS, предшественник AGA. Но и этой инфы вполне достаточно, чтоб представить о чем идет речь. Если интересно - могу выложить в сети часть книги и программу для винды для просмотра amigaguide.
26.07.2005, 01:49
Shiru

Цитата:

Сообщение от acidrain

А скажите, зачем вообще нужно что-либо читать из портов видео процессора?

Во-первых, чтобы ловить обратный ход луча (на некоторых системах нет прерывания по этому событию). Во-вторых - детект столкновений. С прерываниями, конечно, удобнее...
26.07.2005, 09:35
megabyte

Цитата:

Сообщение от acidrain

Это, скорее всего на машинах (Атари-СТ), на которых стоял AGA. Т.е. амижные спец.процы.

Гм. Начнем с того, что в амиге спецпроцессор называется "блиттер", а не "близзард", как ты указал выше.
И в Атари никогда не ставились амижные сопроцессоры. Это из области научной фантастики.
26.07.2005, 11:27
acidrain

Цитата:

Сообщение от megabyte

И в Атари никогда не ставились амижные сопроцессоры. Это из области научной фантастики.

Согласен, ошибся в попыхах написал не то. А вот историю атари предлагаю почитать.
Вот цитата:
Кроме того на Atari ST и Atari STFM можно было установить дополнительно амиговский спецпроцессор “блиттер” - он очень быстро рисовал точки и прямоугольники. На Atari Ste блиттер стоял изначально, но игр поддерживающих его было до обидного мало. Атариевские программисты предпочитали вешать всю графику на центральный процессор Motorolla 68000 8 Mh ( на AMIGA 68000 7 Mh). На STE можно было устанавливать 30-пиновую память SIMM доведя стандартый 1 Mb до 4.
26.07.2005, 12:02
icebear

Цитата:

Сообщение от acidrain

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

По поводу изобретать велосипед: никто ничего не изобретает. Я пока собираю информацию, как хотелось бы работать с новым видеорежимом, если такой появится. Во вторых, про Амигу я знаю и про её возможности тоже. Но вот делать недоАмигу из Спектрума не стоит. Никто не будет разрабатывать спец. чипы, ибо это стоит знаний (это меня касается), времени, денег и ОГРОМНОГО желания. Начинать нужно с малого.

Цитата:

Сообщение от acidrain

Да и существуют же чипы с 2д ускорителями, например вроде texas instruments делает такое чудо =)

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

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

Цитата:

Сообщение от acidrain

А скажите, зачем вообще нужно что-либо читать из портов видео процессора?

А как хост-системе обращаться с видеопроцессором? Как пример, дать видеопроцессору команду и прочитать из порта результат. Это легче и быстрее, чем организовывать прозрачный доступ обоих узлов к общей памяти. Я могу конечно и ошибаться.
26.07.2005, 12:40
acidrain

@icebear:

Понимаю, я ведь начинающий схемотехник, посему о некоторых тонкостях могу лишь догадываться. Считал, что 2д ускоритель от какого нибудь карманника будет выходом из положения. Но видимо ошибся.
Спасибо за наиболее полный ответ. =)
26.07.2005, 12:55
icebear

Цитата:

Сообщение от acidrain

@icebear:
Понимаю, я ведь начинающий схемотехник, посему о некоторых тонкостях могу лишь догадываться. Считал, что 2д ускоритель от какого нибудь карманника будет выходом из положения. Но видимо ошибся.
Спасибо за наиболее полный ответ. =)

Начнём с того, что я тоже не гуру, более того, профессионально схемотехникой не занимаюсь. 2Д ускоритель был бы выходом из положения, если бы его можно было легко и непринуждённо интегрировать в имеющуюся систему (именно интегрировать, а не подключить). Посему надо смотреть на более handy решения и потом уже развивать их. Я уверен, ни GS ни DMA USC не появились сразу во всем известном виде.

А вобще хочу всех поблагодарить за участие и за идеи.