Быстрая видеокарта "METEOR-2013"

[Blade]

Основная цель - сделать простое и максимально быстрое построение экрана для игр.

Тогда надо делать тайловый фон со скроллерами, несколько слоев и аппаратные спрайты. Ну и палитра обязательно.

[Advertiser]

[Valen]

Но эта палитра занимает около 256 х 3 байтов и требует 18 бит на формирователь RGB.

Думаю, что палитры в 12 бит (4096 цветов), должно вполне хватить.
(Так сделано в v6z80p, схему видео выхода можно посмотреть)

[Vadim]

Реквестирую, ещё чтобы был на борту пал-кодер, с обычным композитным видео-выходом (тюльпан).
(SCART не у всех то есть.)

На теликах 2012-2013гг уже далеко не везде есть низкочастотный PAL/SECAM-вход. А вот SCART есть у всех. Убрали тюльпан и S-Video((. Я смотрел много моделей телевизоров, редко где остался тюльпан. Сейчас везде стоит композитный вход YPbPr

[zx-kit]

На теликах 2012-2013гг уже далеко не везде есть низкочастотный PAL/SECAM-вход. А вот SCART есть у всех. Убрали тюльпан и S-Video((. Я смотрел много моделей телевизоров, редко где остался тюльпан. Сейчас везде стоит композитный вход YPbPr

Я тоже считаю, что лучше ограничиться выходом SCART, ну может VGA. А YPbPr легко сделать ?

Мне в концепциях предложили увеличить количество слоев экрана и сделать аппаратные спрайты и скроллинг всего экрана.

Это навело меня на более эффективный и удобный способ построения экрана. Можно сделать, наоборот, всего один слой, но два экрана как ZX128. На одном экране будем строить изображение игровой ситуации. А второй экран в это время отображает текущее состояние игры. По прерыванию экраны меняются местами с помощью соответствующей команды.

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

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

Это позволит создавать даже игры типа DOOM2 с объектами на разных планах используя всего один слой и не задумываясь, как нам накладывать загораживающие друг друга объекты.

[Valen]

Но больше 100 МГц память работать не сможет.

56МГц вполне нормальная частота,
100МГц я думаю будет перебор (помехи и т.п.)

[Alex Rider]

От записи в порты лучше воздержаться.

А почему?

И частота с клона должна быть ровно 14 МГц.

То есть, машины с 3,5 Мгц и 7 Мгц идут лесом?

Скорее всего вы пишете 1,2,3 не сразу в первый атрибут, а сначала 1 во второй и т.д. Вы ведь не пишите команды типа:
LD #5800,1
LD #5800,2
LD #5800,3

Так может сделать даже загрузчик с ленты и диска. Например, если активен экран 1 128-х машин, а 5-я страница используется под данные (или переменные программы). Еще так может сделать заглючившая отлаживаемая программа. Или незаглючившая, если я хочу посмотреть счет в некоторых переменных визуально, и не хочу писать вывод цифер. Просто вообще переключение видеорежимов при записи ключа в память (тем более, такого простого) - не айс. Порты надежнее.

Хочется еще уметь делать гарантированный детект девайса и возвращать его в режим 6912. Зачем нужен детект - чтобы писать отциональный софт под него. Зачем нужен возврат в 6912 - чтобы можно было не всю игру переделать под устройство, а оставить, например, классическое 6912-меню или межуровневую заставку.

[zx-kit]

То есть, машины с 3,5 Мгц и 7 Мгц идут лесом?

Имелась ввиду частота кварца в компьютере, которая выводится на шину ZX-BUS для тактирования видеокарты, исправил - частота кварца в клоне должна быть ровно 14 МГц. Нам ведь надо на телевизор сигнал кратно этой частоте формировать. А если будет 16 МГц, как у некоторых клонов, то синхронизации не будет.

Так может сделать даже загрузчик с ленты и диска. Например, если активен экран 1 128-х машин, а 5-я страница используется под данные (или переменные программы). Еще так может сделать заглючившая отлаживаемая программа. Или незаглючившая, если я хочу посмотреть счет в некоторых переменных визуально, и не хочу писать вывод цифер. Просто вообще переключение видеорежимов при записи ключа в память (тем более, такого простого) - не айс. Порты надежнее.

Лучше порты не занимать - их итак свободных не осталось. Почти нет программ, которые запишут подряд в одну ячейку по адресу атрибутов три нужных байта. Это бессмысленно, так как человек не успеет заметить такое быстрое изменение цвета. Да и сканер при выводе на TV сможет прочитать только один из трех в заданный момент.

Хочется еще уметь делать гарантированный детект девайса и возвращать его в режим 6912. Зачем нужен детект - чтобы писать отциональный софт под него. Зачем нужен возврат в 6912 - чтобы можно было не всю игру переделать под устройство, а оставить, например, классическое 6912-меню или межуровневую заставку.

Возврат к стандартному экрану можно сделать при записи другой последовательности байтов в эту же ячейку. Чтение из видеокарты не планировалось, чтобы не конфликтовать с памятью и портами компьютера. В крайнем случае через порт #FF, так как он будет формироваться видеокартой только для стандартного экрана ZX SPECTRUM.

[Alex Rider]

Лучше порты не занимать - их итак свободных не осталось.

Не знаю... Как-то не по уму оно, через память. Спонтанная мысль: может, через последоватетельность хитрых out'ов в #7ffd при включенном экране-1 (+ память)? Если через ZX-BUS можно "заблокировать" блокировку #7ffd, было бы вообше рульно, например, карта переходит в нужный видеорежим если при включенном экране-1 блокируется порт #7ffd.
Кстати, видеокарта должна стать единственным видеовыходом компа же, так? Значит, второй экран 128-го будет тоже на ней?

[Valen]

Чтение из видеокарты не планировалось, чтобы не конфликтовать с памятью и портами компьютера. В крайнем случае через порт #FF, так как он будет формироваться видеокартой только для стандартного экрана ZX SPECTRUM.

В принципе,
можно и обойтись без чтения z80 из ОЗУ видео-карты.
Так что это не смертельно.

Но некие статусные биты, z80 должен уметь читать.
Например,
бит занятости блитера (занят/не занят)
(Т.к. выдавать новую команду блитеру, можно будет только тогда, когда блитер не занят.)

[crazy_bender/ex-PLACEBO]

извините что влез в вашу беседу. но почему бы разработчику не посмотреть то уже было сделано? а именно описание VIC-II на C64? там есть и прерывание по определенной линии растра и 8 аппаратных спрайтов и тд. всегда можно взять готовое и улучшить