Новый графический режим для игр

[MVV]

Была прошивка palsw_30, может и новее, где взять ?

У palsw наверно.

Манипуляция с SD FAT16/32 уже не нужна, в новой версии загрузка с ROMS/ZXEVO.ROM на SDHC FAT32. А вот SD разъёмчик нужно будет припаять, или если по профессиональному то написать софт для МК и доработать конфигурацию и загрузчик до версии 0.4.2. Все исходники доступны. Если кого-то просить, то это время, а время...

[Advertiser]

[zx-kit]

У palsw наверно.

Манипуляция с SD FAT16/32 уже не нужна, в новой версии загрузка с ROMS/ZXEVO.ROM на SDHC FAT32. А вот SD разъёмчик нужно будет припаять, или если по профессиональному то написать софт для МК и доработать конфигурацию и загрузчик до версии 0.4.2. Все исходники доступны. Если кого-то просить, то это время, а время...

Пока буду паять разъем и использовать старую прошивку.

Давайте продолжим разработку видеокарты/видеорежима на FPGA и SDRAM. Одной из функций видеокарты является вывод информации о цвете точек на монитор. Благодаря MVV у нас уже настроены частоты и сформированы импульсы VGA развертки - кадровые и строчные синхроимульсы VGA, кадровые и строчные гасящие импульсы. Назовем их кратко KSI, SSI, KGI, SGI.

С частотой кадров 60 Гц нам надо выводить на монитор картинку из буфера экрана. Там она уже готова и имеет такой формат: 320х240 точек по 8 битов на точку. Картинка лежит в SDRAM. Для простоты будем считать, что с адреса 0. Чтобы вывести картинку на монитор надо ее считывать из SDRAM пакетами по 8 слов (16 точек).

Нам нужно подавать на SDRAM адреса точек. Для этого нам нужно два счетчика. Счетчик по-горизонтали будет обнуляться во время SGI=0 и считать когда SGI=1. Этот счетчик будет формировать младшие адреса. Для счета до 319 достаточно 9 битов. Увеличивать счетчик будем каждый 10 такт FPGA (126 MHz).

Счетчик по-вертикали будет обнуляться во время KGI=0 и считать когда KGI=1. Этот счетчик будет формировать старшие адреса. Для счета до 239 достаточно 8 битов. Увеличивать счетчик будем каждую вторую строку VGA.

Теперь нам нужно спроектировать буфер VGA. Для этого создадим в FPGA блок из 16 регистров по 8 бит. В эти регистры будем записывать данные из SDRAM. У нас уже есть счетчик тактов в цикле SDRAM. Используем его для формирования импульсов записи в соответствующие регистры в определенные такты в соответствии с пакетным режимом чтения.

Для записи 8 битов в регистр VGA нам потребуется мультиплексор, который выбирает данные с выходов одого из 16 регистров. Данные с 0 по 7 регистры поступают на входы мультиплексора напрямую, а с 8 по 15 через дополнительные 8 регистров с номерами 16 - 23 по 8 битов. На мультиплексор также подадим 4 младших бита счетчика по-горизонтали. Этот номер точки выбирает, с какого регистра брать данные. Также по фронту старшего из этих четырех битов загружаются данные из регистров 8 - 15 в регистры 16 - 23 и формируется запрос на загрузку следующих данных из SDRAM.

Модель конечно упрощенная. Потом доработаем. А пока будем выводить так. Следующая задача - обеспечить доступ Z80 к SDRAM.

[MVV]

Пока буду паять разъем и использовать старую прошивку.

Припаивай разъем, прошивай, возможно больше ничего и делать не нужно будет, там уже в ts-conf всё необходимое есть.

[zx-kit]

Для чтения данных из SDRAM в Z80 нам потребуются адреса с Z80. Для записи данных из SDRAM достаточно восьмибитного регистра. В соответствующий такт цикла SDRAM данные защелкиваются. Потом данные можно будет подать на Z80 через ZX-BUS или его программную модель в FPGA.

Для записи используем адреса и данные с Z80. В определенный такт цикла записи в SDRAM данные подаются на SDRAM. В другие моменты сигналы выбора старшего и младшего байтов в слове сделать неактивными.

Флаги запроса цикла обмена с SDRAM формировать на основе сигналов адреса, MREQ, RD и WR. Как только доступ осуществлен - флаги сбрасывать, чтобы можно было выполнять циклы доступа буфера VGA.

---------- Post added at 11:20 ---------- Previous post was at 11:16 ----------

Припаивай разъем, прошивай, возможно больше ничего и делать не нужно будет, там уже в ts-conf всё необходимое есть.

Я больше люблю проектировать что-нибудь интересное, чем паять.


---------- Post added at 11:31 ---------- Previous post was at 11:31 ----------

MVV, достаточно описанного для кодирования буфера VGA и диспетчера доступа к SDRAM ?

[Lethargeek]

Mode 0. 256х192 точек, цвет задается атрибутами, сохранены бордюрные эффекты, возможность включения палитры ULA+, fINT=50 Hz. Со скоростью развертки TV цвета точек целого кадра из экранной области ZX Spectrum и бордюра записываются в буфер экрана. При записи используется стандартная палитра или ULA+. Из буфера экрана с частотой кадров 50 или 60 Гц (задается перемычками или прошивкой) цвета точек выводятся на видеоустройство (телевизор, монитор или экран PC в эмуляторе). Стандартный режим ZX SPECTRUM после сброса.
Mode 1. 256х192 точек, цвет задается атрибутами, без бордюрных эффектов, fINT=50 Hz, с дополнительными возможностями для устранения клешинга атрибутов (в стадии проработки). После импульса INT на максимальной скорости цвета точек из экранной области ZX Spectrum без бордюра записываются в буфер экрана. При записи используется стандартная палитра или ULA+. Сверху возможна печать спрайтов. Из буфера экрана с частотой кадров 50 или 60 Гц цвета точек выводятся на видеоустройство (телевизор, монитор или экран PC в эмуляторе).

Жуть какая, зачем карте лазить в память компа и конфликтовать при этом с процессором (и какая к черту совместимость после такого)
Когда карта может просто следить за шиной и записи в экранную область тихо повторять себе в буфер.

Продолжим о замене цветов для отображения разных кланов.
Выше показаны двухголовые великаны из разных кланов. Они отличаются цветом сумок. Допустим, что нам достаточно 8 цветов для различения кланов: черный, красный, синий, зеленый, желтый, фиолетовый, голубой и белый. Каждый цвет может иметь 32 градации от черного до яркого. Выделим для этих 32 цветов старшие номера от 11100000 до 11111111. Нарисуем одного великана, например, с красной сумкой. Как вы знаете, перечисленные выше 8 цветов отличаются тем, в какой комбинации включены лучи RGB монитора. Поэтому для перекрашивания части спрайта в нужный цвет используем маску клана. 111 означает, что все лучи RGB включены и сумка будет в оттенках серого. 100 - красная, 010 - зеленая, 001 - синяя, 110 - желтая и т.д., 000 - черная.

Вот к чему приводит тайловое мышление. При том, что блиттер при любой палитре или без оной позволяет наложить маленький фрагмент другой раскраски поверх большого. Или маленький фрагмент другой формы. Или не поверх. Да пусть хоть причёсками отличаются!

Предложенный мной выше режим со слоями тайлов, спрайтов и селектором подходит для этого ? Может его еще можно улучшить или вернуть старую раскладку битов цвета в байте атрибутов для упрощения переделки игр ?

Cам подход к определению видеорежимов нужен другой. Нужно разделять основу - "общий режим" (максимально близкий к физическому) - и порождаемые в этих рамках частные случаи. Например, PAL имеет 360x288 видимой области (размер точки как у Спектрума если брать) при большой практически доступной глубине цвета (hicolor, допустим). То есть, взяв битмап таких размеров и цветности, можно будет сэмулировать экраны почти всех ретрокомпов домашних или приставок. Нам осталось только решить задачу соответствия пикселей нашего битмапа пикселям экранов этих компов. А для этого понадобятся два блока: (1) транслятор адресов, отображающий адреса любого экрана (например, спектрумовского) в адреса нашего битмапа (при желании со сдвигом окна) и (2) транслятор данных, выполняющий определенные операции с точками битмапа при записи в эмулируемый экран (например, для имитации Спека - групповая запись восьми пикселей соответственно значению атрибута или просто сохранение атрибута). Тут в принципе достаточно только записи, потому что прочитать комп сможет из своей памяти (запись же туда проходит, как и положено). Бордюр можно также имитировать закраской каким-то цветом, при отображении заменяемым. Изменять режим работы этих трансляторов должно быть возможно в любой момент, оставляя старое изображение на экране. То есть, что-нибудь нарисовали в окошке Спектрума, а потом раскладку переключили и рисуем сверху векторную графику с адресами как у Специалиста. Или спрайт можем напечатать уже без клэшинга, по-другому задавая цвета для битов. И конечно, блиттер можно использовать, или даже б-гомерзкие тайлоспрайты (если уж ты кюшать без них не можешь))

[MVV]

Если прикручивать проц к SDRAM, и привязываться к синхронной архитектуре, то все пакеты SDRAM нужно выровнять на 142,8571428571429нс, тогда Z80@3.5MHz max, сейчас пакет 119,047619047619нс. Получается 23,80952380952381нс в пакете тупо простой. Делается окно доступа проц-видео-проц-видео... Когда запроса от проца нет, обрабатывается запрос от видео, если нет от видео то обрабатывается запросы DMA...

Можно сделать асинхронный обмен с SDRAM, с ожиданием данных или выборкой из кэш страницы, при их наличии (попадании).

[zx-kit]

Жуть какая, зачем карте лазить в память компа и конфликтовать при этом с процессором (и какая к черту совместимость после такого)
Когда карта может просто следить за шиной и записи в экранную область тихо повторять себе в буфер.

Все мы знаем, как устроен стандартный режим графики. Видеокарта дожна взять байт пикселов, байт атрибутов и преобразовать в 8 точек определенного цвета. Адреса мы тоже знаем где. Не важно, дублируется ли память в видеокарте или основную память компьютера вообще вытащили. Картинка должна получиться одинаковая. Естественно проще разместить память в видеокарте. И она будет общая для Z80 и FPGA.

Вот к чему приводит тайловое мышление. При том, что блиттер при любой палитре или без оной позволяет наложить маленький фрагмент другой раскраски поверх большого. Или маленький фрагмент другой формы. Или не поверх. Да пусть хоть причёсками отличаются!

Проще нарисовать все спрайты с сумками, сапогами или другими предметами гардероба, а потом перекрашивать одной командой или сменой палитры, а не накладывать сверху спрайт сумки. А у спрайтов, соответственно и у сумок, может быть несколько углов поворота и фаз движения.

Cам подход к определению видеорежимов нужен другой. Нужно разделять основу - "общий режим" (максимально близкий к физическому) - и порождаемые в этих рамках частные случаи. Например, PAL имеет 360x288 видимой области (размер точки как у Спектрума если брать) при большой практически доступной глубине цвета (hicolor, допустим). То есть, взяв битмап таких размеров и цветности, можно будет сэмулировать экраны почти всех ретрокомпов домашних или приставок. Нам осталось только решить задачу соответствия пикселей нашего битмапа пикселям экранов этих компов.

Так я почти тоже самое и предлагаю. У нас например буфер экрана 320х240. Мы туда можем записать стандартную графику 192х256 с бордюрными эффектами, а потом вывести с нужной частотой развертки.

А для этого понадобятся два блока: (1) транслятор адресов, отображающий адреса любого экрана (например, спектрумовского) в адреса нашего битмапа (при желании со сдвигом окна) и (2) транслятор данных, выполняющий определенные операции с точками битмапа при записи в эмулируемый экран (например, для имитации Спека - групповая запись восьми пикселей соответственно значению атрибута или просто сохранение атрибута). Тут в принципе достаточно только записи, потому что прочитать комп сможет из своей памяти (запись же туда проходит, как и положено). Бордюр можно также имитировать закраской каким-то цветом, при отображении заменяемым. Изменять режим работы этих трансляторов должно быть возможно в любой момент, оставляя старое изображение на экране. То есть, что-нибудь нарисовали в окошке Спектрума, а потом раскладку переключили и рисуем сверху векторную графику с адресами как у Специалиста. Или спрайт можем напечатать уже без клэшинга, по-другому задавая цвета для битов. И конечно, блиттер можно использовать, или даже б-гомерзкие тайлоспрайты (если уж ты кюшать без них не можешь))

Вот каждый режим по-своему и заполняет буфер экрана. А из буфера экрана выводим на монитор. Это проще, чем делать все операции на лету, как при аппаратных спрайтах. И стандартный режим графики очень сложен для вывода и занимает много времени. раньше в играх рисовали почти перед лучем телевизора. Поэтому для совместимости нужно весь кадр со скоростью развертки телевизора выводить в буфер экрана. Только после этого останутся бордюрные эффекты после вывода из буфера экрана на монитор с частотой 60 Гц.

---------- Post added at 12:21 ---------- Previous post was at 12:04 ----------

Если прикручивать проц к SDRAM, и привязываться к синхронной архитектуре, то все пакеты SDRAM нужно выровнять на 142,8571428571429нс, тогда Z80@3.5MHz max, сейчас пакет 119,047619047619нс. Получается 23,80952380952381нс в пакете тупо простой. Делается окно доступа проц-видео-проц-видео... Когда запроса от проца нет, обрабатывается запрос от видео, если нет от видео то обрабатывается запросы DMA...

Можно сделать асинхронный обмен с SDRAM, с ожиданием данных или выборкой из кэш страницы, при их наличии (попадании).

Да зачем? Поступил запрос от Z80 - следующий цикл работы с SDRAM его. 3.5 МГц хватит - видео же летать будет ! Процу нечем заниматься будет.

---------- Post added at 12:25 ---------- Previous post was at 12:21 ----------

Когда запроса от проца нет, обрабатывается запрос от видео, если нет от видео то обрабатывается запросы DMA...

С этим согласен. Но каждый цикл SDRAM: чтение, запись, регенерация, простой - сделать своей длины.

[MVV]

Я пока хочу допилить простое - это работа основного режима 640х480@60Hz 24bpp с SDRAM, дальше сделаю производный режим на его базе - 320х240 и заложить возможность работы конвейера с 24..1bpp. У меня сейчас один транслятор адресов - линейный, всё остальное меня пока не интересует.

[zx-kit]

Я пока хочу допилить простое - это работа основного режима 640х480@60Hz 24bpp с SDRAM, дальше сделаю производный режим на его базе - 320х240 и заложить возможность работы конвейера с 24..1bpp. У меня сейчас один транслятор адресов - линейный, всё остальное меня пока не интересует.

Делай сразу вывод из буфера экрана в буфер VGA по предложенному мной алгоритму. Просто точки будут меняться через 5 тактов, а не через 10. Поставь счетчик. До какого числа считать (4 или 9) - брать из мультиплексора для соответствующего режима. Развертка та же, только счетчики точек побольше в два раза (вернее на 1 бит шире). 320х240 и 640х480 имеют общую развертку и очень похожи. Буфер экрана можно общий для обоих режимов взять.

---------- Post added at 12:39 ---------- Previous post was at 12:32 ----------

Палитру 8 бит->9/15/24 бит добавляй после регистра VGA.

---------- Post added at 12:47 ---------- Previous post was at 12:39 ----------

Потом добавим команды для заполнения буфера экрана. Но вывод из буфера экрана на VGA менять уже не надо будет.

---------- Post added at 13:04 ---------- Previous post was at 12:47 ----------

Lethargeek, давай подробнее обсудим идею переделки старых игр для устранения клешинга атрибутов.

Я предлагаю добавить трехслойный режим с линейной адресацией экрана без ускорителя.

Адресация всех экранов с 0 адреса не затрагивает область памяти, где размещена игра. Даже добавляет 8 Кбайт памяти для новых подпрограмм. Этот блок можно будет подгружать дополнительно к игре как патч.

Место в игре, где вычисляюся адреса экрана и подпрограммы печати спрайтов найти можно. Заменить на свои.

Формат битов в байте атрибутов лучше оставить старой чтобы не переделывать графику.

Тайлы выводить в нижний слой.

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

При этом за счет линейной адресации и простого копирования спрайта и маски увеличится скорость вывода графики.
Может появятся и новые игры для этого режима. Графика остается почти такой же, только меняется формат маски для спрайта. Зато более простое вычисление адресов и копирование спрайтов. Даже возможен программный скроллинг двухцветного экрана на 1 линию вверх или вниз командой LDIR/LDDR.

[zx-kit]

У меня это FIFO 1024x24бит, представлен в виде 3-х блоков R, G, B двухпортовой M9K 1024x9бит. Дальше данные R(7..0), G(7..0), B(7..0) поступают на адреса памяти палитры, выполненной в виде 3-х блоков 1024x9бит R, G, B с выходом на VGA RGB 8:8:8.
Сейчас подвис с калькулятором, нужно рассчитать все времянки и распределив наложить на видео режим.
General timing:
Screen refresh rate = 60 Hz 60 Hz 700000 cycles
Vertical refresh = 31.46875 kHz 31.5 kHz
Pixel freq. = 25.175 MHz 25.2 MHz 23,809523809523809523809523809524 ns

Зачем считать? У тебя частота точек 25.2 почти равна с 25.175.
Все параметры указаны в точках и строках. Такие и делать.
Будут стандартные KSI, SSI, KGI, SSI их подавать на VGA. Гасящие импульсы использовать для сброса/счета счетчиков адреса при выводе в буфер VGA. Что-то слишком сложный он у тебя. Упрости.

Когда мы подсчитали длительность различных циклов в тактах - дальше можно про ноносекунды забыть и не забивать себе голову лишними деталями. Все итак складывается удачно, частота 126 МГц идеально подошла. Погрешность минимальна. Для 3.5 MHz Z80 0%