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

[MVV]

буфер VGA

У меня это 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.
Сейчас подвис с калькулятором, нужно рассчитать все времянки и распределив наложить на видео режим. Интересно то, что у NextZ80@42MHz есть 700000 тактов в прерывании. По сравнению с Z80@3.5MHz, у которого их будет 58333 Если сделать графику 320х240 8bpp, то NextZ80 может строить изображение за одно прерывание...

----------------------------------------------------------------------------------------
VGA
----------------------------------------------------------------------------------------
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

Horizontal timing (line)
Polarity of horizontal sync pulse is negative.

Scanline part	Pixels	Time [us]
---------------------------------
Visible area 	640 	25.422045680238 	25,396825396825396825396825396825 us	25396,8253968254 ns
Front porch 	 16	0.63555114200596 	 0,63492063492063492063492063492063 us	  634,9206349206349 ns
Sync pulse 	 96	3.8133068520357 	 3,8095238095238095238095238095238 us	 3809,52380952381 ns
Back porch 	 48	1.9066534260179 	 1,9047619047619047619047619047619 us	 1904,761904761905 ns
Whole line 	800 	31.777557100298 	31,746031746031746031746031746032 us	31746,03174603175 ns

Vertical timing (frame)
Polarity of vertical sync pulse is negative.

Frame part	Lines	Time [ms]
---------------------------------
Visible area 	480	15.253227408143 	15,238095238095238095238095238095
Front porch 	 10 	0.31777557100298 	0,31746031746031746031746031746032
Sync pulse 	  2 	0.063555114200596 	0,06349206349206349206349206349206
Back porch 	 33 	1.0486593843098 	1,047619047619047619047619047619
Whole frame 	525 	16.683217477656 	16,666666666666666666666666666667	16666666,666666666666666666666667 ns / 23,809523809523809523809523809524 ns = 700000 cycles

----------------------------------------------------------------------------------------
SDRAM 16M16 -75
----------------------------------------------------------------------------------------
CLK	= 126 MHz 	= 7,936507936507937 ns = 1T
WR	= 15T		= 119,047619047619 ns
RD	= 14T		= 111,1111111111111 ns
RFSH	= 9T		= 71,42857142857143 ns

Providing a distributed AUTO REFRESH command every 7.81us	7809,52380952381 ns

[zx-kit]

Интересно то, что у NextZ80@42MHz есть 700000 тактов в прерывании. По сравнению с Z80@3.5MHz, у которого их будет 58333

Ты это... хватит дразнить спектрумистов, у которых нет ReVerSE. Можно и на 3.5 MHz написать хорошую игру. Особенно с новыми видеорежимами. Вернись на землю.

Лучше сделать так, чтобы экран на частоте 3.5 MHz за одно прерывание можно было перерисовать 3 раза. Тогда на 42 MHz сможет 36 раз перерисовать.

[MVV]

дальше можно про ноносекунды забыть

Нужно посчитать, успеет ли прочитаться строка 640 точек 24bpp в буфер для вывода, с учетом обращений хотя-бы проца и регенерации.

---------- Post added at 11:42 ---------- Previous post was at 11:37 ----------

Ты это... хватит дразнить спектрумистов, у которых нет ReVerSE.

Можно и на Speccy2010 попробовать. Всё равно это так, баловство в виде возможности запуска UNIX подобной системы http://sowerbutts.com/socz80/

[zx-kit]

Нужно посчитать, успеет ли прочитаться строка 640 точек 24bpp в буфер для вывода, с учетом обращений хотя-бы проца и регенерации.

Давай прикинем. Чтобы прочитать 16 точек (8 бит на точку) надо 14-15 тактов. Выводим одну точку медленнее - по 5 тактов на точку. Запрос на загрузку новых 16 точек будет формироваться, когда в запасе еще 8 точек. За 8х5=40 тактов точно загрузятся.

Для буфера достаточно 24 регистра по 8 бит.

А зачем ты хранишь точку по 24 бита ? Спрайты тоже будут 24 бита на точку ? Если палитра, то достаточно 8 бит. Копирование блиттером ускорится в 3 раза.

А про UNUX пока забудь - это другой проект.

[zx-kit]

Регенерацию 5 циклов надо попробовать засунуть в строчные синхроимпульсы, чтобы во время отображения строки регенерация не тормозила процессы.

[MVV]

А зачем ты хранишь точку по 24 бита ?

Я представляю это в виде целой строки на 1024 точки R, G, B с возможностью раздельного (R,G,B) доступа к ней блиттера. Как только он начнет работать с множественным доступом к SDRAM, выхватывая нужные данные для послойной сборки изображения, времени станет катастрофически не хватать. Да и удобнее обработка точек. Это пока доводы...

Регенерацию 5 циклов надо попробовать засунуть в строчные синхроимпульсы

Пока оставлю распределенной, через каждые 7809,52380952381 ns по 71,42857142857143 ns. Как-то сейчас проще, отвязывается от видео режима, дальше посмотрим как её и где лучше выставить.

Спрайты тоже будут 24 бита на точку ?

24..1 бит, для этого и прикручиваю конвейер с управляемой загрузкой в FIFO. Он получает пакет, который и распределяет по каналам R, G, B. Т.к. он работает на базовой 126 МГц, то получим рассинхронизацию при обработке пакета с разной bpp с последующей загрузкой FIFO. В общем нужно успевать подкидывать дрова до их вывода на экран.

На данный момент хоть добиться вывода на экран картинки, и доступа процессора к видео буферу, попробовать им что-то нарисовать. А рисовать как оказалось удобнее, закидывая сразу 8bpp или по три байта, где отдельно R, G и B. Это даже упростит конвейер.

[Advertiser]

[zx-kit]

Я представляю это в виде целой строки на 1024 точки R, G, B с возможностью раздельного (R,G,B) доступа к ней блиттера. Как только он начнет работать с множественным доступом к SDRAM, выхватывая нужные данные для послойной сборки изображения, времени станет катастрофически не хватать. Да и удобнее обработка точек. Это пока доводы...

Пока оставлю распределенной, через каждые 7809,52380952381 ns по 71,42857142857143 ns. Как-то сейчас проще, отвязывается от видео режима, дальше посмотрим как её и где лучше выставить.

24..1 бит, для этого и прикручиваю конвейер с управляемой загрузкой в FIFO. Он получает пакет, который и распределяет по каналам R, G, B. Т.к. он работает на базовой 126 МГц, то получим рассинхронизацию при обработке пакета с разной bpp с последующей загрузкой FIFO. В общем нужно успевать подкидывать дрова до их вывода на экран.

На данный момент хоть добиться вывода на экран картинки, и доступа процессора к видео буферу, попробовать им что-то нарисовать. А рисовать как оказалось удобнее, закидывая сразу 8bpp или по три байта, где отдельно R, G и B. Это даже упростит конвейер.

Давай все-таки немного ужмем размеры графики. Для этого используем 1 байт на точку. 256 цветов конечно мало. НО в стандартном режиме их всего 15 ! Не обязательно срузу делать идеальный режим. Можно было бы для начала взять цвета как у ZX-EVO. 6 битов = 64 цвета. Старший бит можно было бы использовать как прозрачный. Даже без палитры 64 цвета - это класно. Ну хотя бы для начала. Опробуем, отладим - потом можно наворачивать биты и палитры.

В Денди в спрайтах вообще вроде 3 цвета на бит + прозрачный. А какие игры. А если ты в самом началае усложнишь - лишняя работа. Кроме этого чем больше битов на точку - тем больше размеры спрайтов, тайлов, больше расход времени на копирование. А если Z80 на 42 MHz, то он не даст работать блиттеру, так как будет без остановки обращаться к памяти и требовать отдать ему КАЖДЫЙ цикл. А ведь нужно еще выводить данные на VGA и САМОЕ ГЛАВНОЕ - он будет тормозить блиттер, который быстрее его.

---------- Post added at 14:44 ---------- Previous post was at 14:40 ----------

Кстати попробуй посчитать размер памяти для тайлов и спрайтов для игры типа WARCRAFT 2 или любой другой. В WC2 немного смухлевали со спрайтами - вместо 8 разных углов поворота нарисовали спрайты только для 5-ти, а остальные 3 угла отображают отзеркаливанием. Из-за этого при повороте персонажей меч может неожиданно из правой руки оказаться в левой. Это не очень хорошо.



Я играл в WC2 на 386-DX40 с 4 мегабайтами памяти. Сколько битов на точку в спрайтах я точно не знаю - наверно 8. Думаю надо планировать, чтобы спрайты, тайлы, 1 Mб память для Z80, буферы экрана и т.п. влезло в 8 Мбайт.

[MVV]

А если Z80 на 42 MHz, то он не даст работать блиттеру, так как будет без остановки обращаться к памяти и требовать отдать ему КАЖДЫЙ цикл. А ведь нужно еще выводить данные на VGA и САМОЕ ГЛАВНОЕ - он будет тормозить блиттер, который быстрее его.

Это если он не будет послан по приоритету арбитром памяти в кэш или wait. Или сам как решит. Если проца два, то переключится на другой, возможно другому данные из SDRAM не нужны будут, аналогично с ихними контекстами.
По поводу bpp, то тут сейчас наглядно просматриваются - 24bpp, 16bpp, 8bpp, 4bpp. Хз как ты будешь их на лету переключать?
В принципе возможно, есть 4 страницы палитры. Поставить её только после конвейера и перед FIFO.

[zx-kit]

Количество битов в VGA DAC разных компьютеров:

8 - ReVerSE-U16, Terasic DE1-SoC
7 - Speccy2010 + второй SD-разъем
6 - ZX-EVO + IDE-DAC, видеокарта TS-Labs
5 - компьютеры с ZX-BUS + видеокарта "Meteor Graphics", Marsohod 2
4 - Terasic DE1 и DE0
3 - ReVerSE-U9
2 - ZX-EVO

Все буферы: тайлов, спайтов, экрана и VGA должны быть в формате 1 байт на точку. После регистра VGA 8 бит номера цвета преобразовываются в 24 бита цвета из палитры. Дальше, в зависимости от железа, цвета отображаются на имеющемся видеоцапе. Это обеспечит совместимость картинок игры на любом компьютере.

[zx-kit]

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

Думаю можно отвечать и в соответствующей теме на этом форуме. Разработчик c того сайта не работает на постояной работе (информация на 8 января 2010), поэтому у него есть время на статьи и форум на своем сайте. Тебе это надо ?

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

Попробуй написать в подписи о помощи. Только много не пей !