Новый графический режим для игр [Архив] - Страница 2 - Speccy

zx-kit

03.07.2015, 06:21

А двигаться он будет попиксельно или кратно 8-ми?

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

А игры будут только "бродилки/леталки", расширятся функционал не будет? Поддержка 3D движков? Или для этого памяти много не потребуется?
Игры будут такие же, какие были на ZX Spectrum, только более быстрые и плавные. 3D пока не планируется.

---------- Post added at 08:21 ---------- Previous post was at 08:11 ----------

Ok, я согласен, что сделать удобно для адаптации всех игр не получится - какие-то придется переписать основательно. Но господа, не забываем одну вещь: сделать новую хорошую игру трудно! Для этого нужны таланты геймдизайнера, художника, музыканта, программиста - сейчас командной работы в этой области почти нет. А вот для переделки игры нужны в основном только программерские способности, ну результат с текущей графикой можно предложить художнику для редизайна. Это сильно проще.

Увы, чего только нет в старых играх для экономии тактов. В том числе, и определение столкновений и даже обработка логики игры во время отрисовки. А про использование экранных атрибутов и графики тайлов в качестве аркадных атрибутов писал даже "Инфорком" в своей серии про графику.
Переделать игру - это будет целое искусство. Но мы можем кое-что предусмотреть. Например, в игре Saboteur можно таблицу тайлов, про которую вы говорили, скопировать каким-нибудь способом в карту тайлов, а видеокарта построит фон в буфере экрана. Сверху добавить спрайты героев и одиночные тайлы.

http://s015.radikal.ru/i333/1507/0b/f9351283bed8t.jpg (http://s015.radikal.ru/i333/1507/0b/f9351283bed8.png) http://s017.radikal.ru/i427/1507/99/82b378d8893ct.jpg (http://s017.radikal.ru/i427/1507/99/82b378d8893c.png) http://s017.radikal.ru/i401/1507/91/325eeb06103ft.jpg (http://s017.radikal.ru/i401/1507/91/325eeb06103f.png) http://s020.radikal.ru/i719/1507/3e/6e6536f5d9act.jpg (http://s020.radikal.ru/i719/1507/3e/6e6536f5d9ac.png) http://s017.radikal.ru/i406/1507/d1/5ee348a9829bt.jpg (http://s017.radikal.ru/i406/1507/d1/5ee348a9829b.jpg)

Давайте посмотрим, что общего на приведенных картинках?
Экран делится на статическую часть и динамическую. Нам надо для построения использовать 2 экрана. Назовем их S_SCREEN1 и D_SCREEN1. При выводе на VGA часть изображения будет браться с S_SCREEN1, а другая с D_SCREEN1. Учитывая то, что на одной паре экранов мы строим изображение, а другая в это время отображается нам надо иметь 4 буфера экрана размером по 512х256 точек (128K x 16) каждый.

CodeMaster

03.07.2015, 07:42

3D пока не планируется.

Может это, вместе с графичискими примитивами, было бы интересно для развития.

Игры будут такие же, какие были на ZX Spectrum, только более быстрые и плавные.

Просто, в таком случае, карта 1024 на 1024 экрана это лишнее, обычно они были вытянутыми. ИМХО 32х1024 или 1024 на 32 будет достаточно. С закольцовкой её можно "растянуть" практически до бесконечности (правда не для линейный карт типа R-Type, если не предусмотреть возможности сдвига одного измерения при переходе границы), а память под будущие апгрейды освободится.

Lethargeek

03.07.2015, 08:23

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

---------- Post added at 08:12 ---------- Previous post was at 08:08 ----------

Учитывая то, что на одной паре экранов мы строим изображение, а другая в это время отображается нам надо иметь 4 буфера экрана размером по 512х256 точек (128K x 16) каждый.
ёлы-палы, скорость блиттера сначала прикинь примерно
а то вдруг он успевает весь экран построить за фрейм с нуля ;)

---------- Post added at 08:23 ---------- Previous post was at 08:12 ----------

Переделать игру - это будет целое искусство.
впечатление, что это главная цель проекта :D

Но мы можем кое-что предусмотреть.
а предусмотреть, чтобы для переделки в принципе НЕ требовался "искусник"?

zx-kit

03.07.2015, 10:52

Может это, вместе с графичискими примитивами, было бы интересно для развития.

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

Просто, в таком случае, карта 1024 на 1024 экрана это лишнее, обычно они были вытянутыми. ИМХО 32х1024 или 1024 на 32 будет достаточно. С закольцовкой её можно "растянуть" практически до бесконечности (правда не для линейный карт типа R-Type, если не предусмотреть возможности сдвига одного измерения при переходе границы), а память под будущие апгрейды освободится.
Надеюсь появятся и новые игры, которым эти возможности могут пригодиться. Например, разделить эту область на две карты тайлов.
http://s018.radikal.ru/i526/1507/98/d100ca4d89cet.jpg (http://radikal.ru/fp/05fa287b545b4f7ebfa34e99fa9e7ef4)
Когда я писал игру FUTURE TANK у меня было две карты: MAP2D и MAP3D. На карту 2D я распаковывал уровень. Там было два вида тайлов - дорога и препятствия. Потом специальная процедура строила программно вокруг дорог стены с помощью разных спрайтов и заполняла карту 3D. По 3D карте заполнялся буфер экрана в игре, а по 2D я определял, куда можно ехать, куда нельзя, где лежат предметы.

---------- Post added at 12:52 ---------- Previous post was at 12:49 ----------

а предусмотреть, чтобы для переделки в принципе НЕ требовался "искусник"?
Хорошо бы остановить игру, добавить несколько POKES и заработало по новому. Пока не знаю, как это сделать...

CodeMaster

03.07.2015, 12:11

и заполняла карту 3D

В смысле изометрию или где там 3D? Под 3D я имел ввиду, что-то типа Wolf 48K (zx-pk.ru/showthread.php?t=19689)

Lethargeek

03.07.2015, 14:02

Хорошо бы остановить игру, добавить несколько POKES и заработало по новому. Пока не знаю, как это сделать...
хорошо бы, только покесов для этого недостаточно
прочитай, что ниже отвечу райдеру

jerri

03.07.2015, 14:16

http://s018.radikal.ru/i526/1507/98/d100ca4d89cet.jpg (http://radikal.ru/fp/05fa287b545b4f7ebfa34e99fa9e7ef4)
Когда я писал игру FUTURE TANK

таки да. а где игра то?

Smalovsky

03.07.2015, 14:16

Не ссорьтесь. gg all.
Может для спекки и нужен гибрид.

Lethargeek

03.07.2015, 14:17

Ok, я согласен, что сделать удобно для адаптации всех игр не получится - какие-то придется переписать основательно. Но господа, не забываем одну вещь: сделать новую хорошую игру трудно! Для этого нужны таланты геймдизайнера, художника, музыканта, программиста - сейчас командной работы в этой области почти нет. А вот для переделки игры нужны в основном только программерские способности, ну результат с текущей графикой можно предложить художнику для редизайна. Это сильно проще.
Видишь ли, "проще", "легче", "сложнее" - понятия субъективные. Что кому-то сделать просто, второй не сможет, третьему же лень возиться или нет времени. Таким образом, сделать переделку простой для всех (или максимально к тому приблизиться) можно лишь одним способом: дать возможность каждому самому определять объём и сложность работ. Чтоб игру можно было переделывать постепенно, независимо корректируя процедурки, переделывая графику по частям. Чтоб результат был рабочим и играбельным на любой стадии, чтобы можно было бросить в любой момент, и все равно выглядел бы лучше оригинала. Сам собой напрашивается вывод, что обеспечить это можно только в том случае, когда старая и новая графика одновременно сосуществуют в одном экране. Что возможно, если старая графика есть одно из состояний новой видеопамяти, а вывод в эту память старыми процедурами перехватывается и обрабатывается девайсом так, чтобы видимых отличий не возникало (если мы, конечно, их не хотим). Ну, как эмулятор спектрума на пц, но с возможностью рисовать без цветовых ограничений на пц-экране из спектрумовской программы, с ускорением (средствами того же эмулятора) или без.

Увы, чего только нет в старых играх для экономии тактов. В том числе, и определение столкновений и даже обработка логики игры во время отрисовки. А про использование экранных атрибутов и графики тайлов в качестве аркадных атрибутов писал даже "Инфорком" в своей серии про графику.
Так то в старых, при нехватке памяти-быстродействия, а зачем в новых видеорежимах этим страдать?

Alex Rider

03.07.2015, 21:25

Таким образом, сделать переделку простой для всех (или максимально к тому приблизиться) можно лишь одним способом: дать возможность каждому самому определять объём и сложность работ. Чтоб игру можно было переделывать постепенно, независимо корректируя процедурки, переделывая графику по частям. Чтоб результат был рабочим и играбельным на любой стадии, чтобы можно было бросить в любой момент, и все равно выглядел бы лучше оригинала.
Да я не против! Мой пост как раз и был к тому, что, если сделать карту только для новых игр, игр с поддержкой этой карты будет чуть меньше, чем одна. Я как раз-таки за то, чтобы карта максиамльно способствовала переделкам, но сокрушаюсь тут, что сделать одинаково удобно для всех игр не получится, игры все равно придется курочить. Но не дай боже, что для того, чтобы при включении карты чтобы хоть что-то похожее на старую игру увидеть, надо сразу же переписать половину игры.

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

zx-kit

04.07.2015, 06:50

Давайте пока отложим способы формирования сцены игры в буфере экрана. Надо время все обдумать. Наверно найдем приемлемый вариант. А пока спроектируем вывод из буфера экрана в регистр RGB. Для начала будем считать, что у нас один буфер экрана с картинкой 320х240 точек по 15 бит на цвет. Потом доработаем для 4х буферов с врезанием экрана с динамической графикой в экран со статической графикой.

Для хранения информации о цвете точек в строке организуем во внутренней памяти FPGA буфер VGA размером 320 ячеек по 15 бит. Из SDRAM будем читать данные пакетами по 8 точек (1 точка за такт) с паузами (по 6 и более тактов) и записывать в буфер VGA. После записи каждой точки в буфер VGA счетчик записи увеличивается на 1. Как только сделано 320 записей - буфер полон. Больше читать из буфера экрана не надо.

Для адресации в буфере VGA во время чтения используем счетчик чтения. Так как читать из буфера VGA можно только тогда, когда он свободен от записи из SDRAM - нужно добавить между буфером VGA и регистром RGB небольшой буфер FIFO. Из регистра RGB будем отправлять данные о цвете точки через HDMI или аналоговые ЦАПы типа R-2R на монитор. Это уже будет зависеть от реализации конкретной видеокарты или девборды. В остальном, кроме типа выхода на монитор, новый видеорежим должен работать одинаково на всех устройствах.

Во время строчного синхроимпульса VGA будем сбрасывать счетчики записи и чтения из буфера VGA, а также проводить регенерацию SDRAM. Достаточно сделать 3 цикла AUTO REFRESH в начале каждой строки VGA. Затем, во время левого бордера в строке начинаем заполнение буфера VGA данными о цвете точек из буфера экрана в SDRAM. К моменту вывода видимой части строки его начало уже будет заполнено.

Так как для экрана 320х240 каждая вторая строка VGA в режиме 640x480@60Hz дублируется, то буфер загружать надо только 1 раз на 2 строки. В начале второй строки нужно сделать только 3 цикла AUTO REFRESH, а остальное время доступ к SDRAM будет в основном у блиттера. Аналогично нужно вывести все 240 строк изображения, сформированного в буфере экрана. Во время бордера в кадре VGA данные из SDRAM читать не надо.

Вот и все. Для простоты частоту точек VGA выбрать 25 MHz, а FGPA и SDRAM 125 MHz.

Alex Rider

04.07.2015, 08:43

А пока спроектируем вывод из буфера экрана в регистр RGB.
Это уже не моя компетенция, но все же: оно будет нормально, без искажений показывать обычный спектрумовский 6912, если карту не активировать после сброса/включения питания, а VGA-монитор подключить только к карте? Какие частоты развертки будут поддерживаться?

Во время бордера в кадре VGA данные из SDRAM читать не надо.
15с-BORDER по #fe сделать получится?

zx-kit

04.07.2015, 08:56

Это уже не моя компетенция, но все же: оно будет нормально, без искажений показывать обычный спектрумовский 6912, если карту не активировать после сброса/включения питания, а VGA-монитор подключить только к карте? Какие частоты развертки будут поддерживаться?

15с-BORDER по #fe сделать получится?

Мы пришли к выводу, что после сброса работает стандартный режим 256х192 15 цветов с бордером. Вывод на SCART 50 Гц или на монитор VGA 640х480@60Hz без геометрических искажений. INT стандартный 50 Гц. Возможно получится и 50 Гц VGA.

После включения нового режима 320х240 32K бордера уже нет так как экран занимает всю видимую часть на мониторе VGA 640х480@60Hz. INT новый 60 Гц для уменьшения мерцаний и совпадения с частотой развертки VGA.

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

Полностью совместить 50 и 60 Гц не получается, приходится выбирать приемлемый и достаточно хороший вариант вывода.

shurik-ua

04.07.2015, 10:27

Возможно получится и 50 Гц VGA.
а почему не получится ? - сделать то его не сложно просто не все мониторы поддерживают 50 Гц - мой Асус 22'' например минимум 56 Гц поддерживает, я даже спецом для спековских дел купил CRT 17'' )

Eagle

04.07.2015, 11:01

Полностью совместить 50 и 60 Гц не получается, приходится выбирать приемлемый и достаточно хороший вариант вывода.
А конвертировать на лету, как в китайских конвертерах SCART to HDMI — не судьба?

zx-kit

04.07.2015, 11:18

Мы уже обсуждали кадровые частоты ранее. Для старого режима 50 Гц или 60 Гц, для нового 640х480@60Hz.
Эмулятор UNREAL выводит картинку в режиме 640х480@60Hz, любой монитор и телевизор с VGA входом также поддерживает этот режим. Это стандарт. Поэтому новый режим будет одинаково отображаться на любом экране. Разве что у широкоформатных по бокам будет лишнее затемнено.

Надо блиттер делать. А сначала вывести состояние SDRAM на экран, потом добавить рисование точками. Работы много. а мы опять спорим про частоты.

zx-kit

04.07.2015, 11:27

Я сейчас занимаюсь разработкой основного режима 640х480@60Hz 24bpp, на его базе: 640x480@60Hz 24bpp/15bpp/8bpp, 320x240@60Hz 24bpp/15bpp/8bpp.
На данный момент работает базовый режим 640х480@60Hz 24bpp и ZX-Spectrum screen x2 = H:32+256+32; V=24+192+24 с возможностью наложения.
ОК. На какой частоте работает SDRAM и FPGA? Можешь сделать так, чтобы моя тестовая программа рисовала цветные полоски? Для этого надо реализовать команду рисования по точкам. А до этого пакетный режим SDRAM по 8 точек на частоте 125 MHz (для упрощения вывода на VGA)

Valen

04.07.2015, 13:53

Потом доработаем для 4х буферов с врезанием экрана с динамической графикой в экран со статической графикой.

Это аппрататное врезание статического и динамического экрана ?
Думаю что не нужно, трата логики.
Блиттер успеет.

zx-kit

04.07.2015, 15:44

Это аппрататное врезание статического и динамического экрана ?
Думаю что не нужно, трата логики.
Блиттер успеет.
Не все можно сделать с помощью денди-скроллов. Надо и неподвижную информацию выводить.

zx-kit

04.07.2015, 18:49

Добавил палитру, получается 4-ре страницы. Как лучше сделать обращение к палитре со стороны ЦП и переключение страниц, через порта? Тогда нужно 3-ри развёрнутых порта типа 0xnnD0, 0xnnD1, 0xnnD2, где nn=0-255. Или отображать палитру на память, это 3К (4-ре страницы). Формат записи тогда какой, страница палитры 0: +0 R, +1 G, +2 B ... +253 R, +254 G, +255 B, страница палитры 1: +256 R, +257 G, +258 B ... +509 R, +510 G, +511 B ... ?
В блоке адресов регистров выдели два регистра. 1 регистр - установка номера цвета/начальный адрес для загрузки данных. 2 регистр - данные. Записывать в регистр данных последовательно R0,G0,B0, R1,G1,B1. Видеокарта сама увеличивает адреса, начиная с загруженного в регистр 1.

00 MODE - режим графики: 1 = 256х192 32K, 2 = 320х240 32K, 0 - стандартный 256х192 с атрибутами
01 ADDR_SCR1 - адрес экрана 1
02 ADDR_SCR2 - адрес экрана 2
03 CLEAR - закрасить экран цветом COLOUR
04 PLOT - нарисовать точку цветом COLOUR по координатам Y, X с предварительным смещением в качестве параметра: 0 = без смещения
05 PL1_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
06 PL1_DATA - последовательные данные цветов RGB в палитре
07 PL2_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
08 PL2_DATA - последовательные данные цветов RGB в палитре
09 PL3_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
0A PL3_DATA - последовательные данные цветов RGB в палитре
0B PL4_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
0C PL4_DATA - последовательные данные цветов RGB в палитре
0D PL_SELECT - выбор палитры 1-4

Alex Rider

05.07.2015, 02:14

Возможно сделаем, как вы просили, возможность включения вывода стандартного режима по-новому в центре экрана для упрощения постепенного перекрашивания игр. При этом бордер будет как раньше или как статическая часть экрана 320х240.
Да, это обязательно надо. Мало того, большинство игр не получится переделать под другое разрешение экрана (без переписывания игры заново). Надо сделать режим 256x192 с новыми фишками - палитрами, прозрачностью и прочими запланированными плюшками.

---------- Post added at 02:14 ---------- Previous post was at 02:12 ----------

0D PL_SELECT - выбор палитры 1-4
На всякий, если не сложно - а можно сделать каждому слою (и "прсевдслою", на который выводится векторная графика) свою палитру?

zx-kit

06.07.2015, 05:55

Я так понял, MVV решил добавить новые режимы 8 битов на точку с палитрой. Палитра будет загружаться при смене уровня или когда надо задать эффект плавного затемнения. MVV, как планируешь использовать палитру и где ее указывать ?

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

Векторную графику в режимах 320х240 и 256х192 применять затруднительно - точки слишком крупные. Если только в режиме 640х480.

MVV

06.07.2015, 12:53

как планируешь использовать палитру и где ее указывать ?
Сейчас доступно 4-ре палитры. Размер одной страницы палитры 768 байт. Доступ к палитре IN/OUT через три порта: #iiBF (Red), #iiBE (Green), #iiBD (Blue), где ii=индекс интенсивности цвета в одной из 4-х страниц палитры от 0 по 255. Порт выбора страницы палитры #01BC, биты 1..0=00-страница 0, 01-страница 1...
Как-то-так, адреса портов вымышленные, использую исключительно для отладки в конфигурации DE1-SoC:ZX128K.
Пример:

; Инициализация палитры 24bpp
LD BC,#00BD ; Palette=Blue, Address=0
L1 OUT (C),B
DJNZ L1
INC C
L2 OUT (C),B
DJNZ L2
INC C
L3 OUT (C),B
DJNZ L3
RET

; Чтение палитры 24bpp
LD HL,addr
LD BC,#00BD ; Palette=Blue, Address=0
INIR
INC C
INIR
INC C
INIR
RET

; Запись палитры 24bpp
LD HL,addr
LD BC,#00BD ; Palette=Blue, Address=0
OTIR
INC C
OTIR
INC C
OTIR
RET

MVV

06.07.2015, 14:54

Параллельно с графической картой ещё делаю конфигурацию для DE1-SoC и ReVerSE-U16, планируется переход на NextZ80. Конфигурация получит два процессора с максимальной частотой 42МГц c 16К+16K L1 и 1К L2 кэшем. Быстродействия и объёма памяти вполне должно хватить для нового видео режима 640x480@60Hz 8bpp/15bpp/24bpp. Было-бы правильнее сделать совместимость графической системы с zx-evo, но есть проблема, команда ts-labs неохотно идет на встречу, оно и понятно, zx-evo себя полностью исчерпал в аппаратном плане, а вести работу над конфигурацией на других платах никто из них не будет. Да нас рать, есть возможность и желание сделать лучше, то почему-бы и не сделать.

s_kosorev

06.07.2015, 16:30

Параллельно с графической картой ещё делаю конфигурацию для DE1-SoC и ReVerSE-U16, планируется переход на NextZ80
А исходный код доступен? Хотелось бы на своей плате запустить

MVV

06.07.2015, 16:48

А исходный код доступен? Хотелось бы на своей плате запустить
У меня сейчас наброски для DE1-SoC, просто удобней вести разработку. Попробуй запустить ZX128K (https://github.com/mvvproject/DE1-SoC-Board/tree/master/de1soc_zx128k), на его базе и делаю. Если успею, вечером попробую собрать новые рабочие модули и выложить.

zx-kit

10.07.2015, 06:21

Так как мы напридумывали уже больше одного дополнительного режима надо кратко описать каждый. Я начну, а вы добавляйте :

Mode 0. Стандартный режим ZX SPECTRUM после сброса. 256х192 точек. Точка может быть двух цветов из 15, заданных с помощью атрибута. fINT=50 Hz. Предположильный способ формирования изображения - каждые 20 mS данные из экранной области ZX Spectrum и состояние BORDER построчно записываются (включая цвет BORDER-a) в буфер экрана. Из буфера экрана с частотой 50 или 60 Гц цвета выводятся на видеоустройство (телевизор, монитор или экран PC в эмуляторе).

Mode 1. Аналог режима 0 с дополнительными возможностями для устранения клешинга атрибутов 256х192 точек + доп возможности. Точка может быть двух цветов из 15, заданных с помощью атрибута. fINT=50 Hz. Предположильный способ формирования изображения - каждые 20 mS данные из экранной области ZX Spectrum и состояние BORDER построчно записываются (включая цвет BORDER-a) в буфер экрана. Из буфера экрана с частотой 50 или 60 Гц цвета выводятся на видеоустройстов (телевизор, монитор или экран PC в эмуляторе).

Mode 2. 320х240 точек. Точка может быть любым из 32768 цветов или прозрачной. fINT=60 Hz. Экран может состоять из статической и динамической частей. В динамической части возможен аппаратный скроллинг экрана и вывод изображения из карты тайлов 1024х1024 тайла размером по 8х8 точек. Предположильный способ формирования изображения. Фон строится из карты тайлов. Программист указывает координаты в карте тайлов для копирования в буфер экрана. Если в тайле фона точка прозрачного цвета - то будет изображен цвет фона (нижнего плана). Далее выполняются командные буферы, куда Z80 записал номера и координаты спрайтов для вывода поверх фона в буфер экрана. Сверху возможно рисование линий аппаратными точками заданным цветом. Из буфера экрана с частотой 60 Гц цвета выводятся на видеоустройство (телевизор, монитор или экран PC в эмуляторе).Два буфера экрана - на одном строим изображение, со второго изображение в этот момент выводится на видеоустройство.

Mode 3. 640х480 точек. Похож на режим 2, только точек в два раза больше по-вертикали и по-горизонтали.

MVV, какие режимы ты предлагаешь добавить ?

bigral

10.07.2015, 16:20

какие режимы ты предлагаешь добавить ?

Мне вот интересно, можно ли добавить эмуляцию доп. граф. режимов от АТМ и ПРОФИ? Понятно что оно будет "инородным телом" в новой разработке, но чисто для привлечения внимания к разработке вполне логичный ход.

Alex Rider

10.07.2015, 23:26

А получится ли малой кровью в Mode1 добавить поддержку ULA+ так, чтобы не переделывать игры?

zx-kit

11.07.2015, 01:21

Мне вот интересно, можно ли добавить эмуляцию доп. граф. режимов от АТМ и ПРОФИ? Понятно что оно будет "инородным телом" в новой разработке, но чисто для привлечения внимания к разработке вполне логичный ход.
Наверно можно. Но стоит ли ? Просто разместить в основной памяти компьютера дополнительные графические области - это пол дела. Нужно, чтобы все работало просто и быстро. Чтобы дать Спектруму второе дыхание надо сделать так, чтобы в новых режимах мог разобраться обычный программист, который захочет написать игру. На основе опыта, какие операции в играх занимают максимальное время, нужно пытаться оптимизировать это с помощью новых видеорежимов/видеокарты.

Очень много для этого сделано в TSconf. В TSconf есть тайлы 8х8 как в Денди, отображение тайлов из карты и аппаратный скроллинг. Плюс там увеличено количество возможных тайлов по сравнению с 256 у Денди. Также в TSconf, по сравнению с Денди увеличено количество и размер спрайтов. У Денди 64 спрайта размером 8х8, в TSconf 85 размером до 64х64.

Но в TSconf есть и некоторые недостатки. Изображение строится на лету при выводе на монитор. Спрайты аппаратные. Это приводит к некоторым ограничениям и сложным преобразованиям. У Денди при выводе больше 8 спрайтов в строке остальные начинают мерцать или пропадают. Не будет ли такого же тут ? Карта тайлов есть, но как в Денди размером 64х64. Желательно увеличить до 1024х1024, чтобы программисту не надо было заниматься лишней работой при скроллинге экрана. Наличие палитры ограничивает количество возможных цветов. Такая ситуация может возникнуть, если надо добавить картинку с другой палитрой.

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

Нужно в новом режиме графики разделять экран на статическую область и динамическую, как это делается в большинстве игр. Статическую область можно заполнить один раз, а потом только обновлять некоторые области, например. Индикатор заряда энергии, счет, изображение поднятого предмета.

---------- Post added at 03:21 ---------- Previous post was at 03:13 ----------

А получится ли малой кровью в Mode1 добавить поддержку ULA+ так, чтобы не переделывать игры?
Если для формирования изображения мы читаем данные из стандартного экрана и попиксельно записываем изображение в буфер экрана, то при этом стандартные 15 цветов преобразовываются в соответствующие цвета 32К. При этом можно подменить стандартную палитру на ULA+. Немного сложнее, но думаю возможно. Но это ближе к режиму 0.

В режиме 1 надо будет сделать возможность устранить клешинг. Он будет выглядеть также как 0, но формироваться по-другому. Надо еще продумать. Пока мне видится это так:

Цвет каждой клетки размером 8х8 точек определяется двумя атрибутами. При записи в черно-белую область экрана или область атрибутов включается стандартный цвет из первого атрибута. При записи в определенные регистры видеокарты можно включить второй атрибут. Точки могут быть трех цветов: PAPER2, INK2 или прозрачными. Если прозрачные, то сквозь них видны точки 1 атрибута. Так можно нарисовать Диззи на переднем плане. Как только будет запись в черно-белую область экрана или область атрибутов включается стандартный цвет из первого атрибута.

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

zx-kit

12.07.2015, 00:34

http://s013.radikal.ru/i323/1506/80/8c52ddf17628t.jpg (http://s013.radikal.ru/i323/1506/80/8c52ddf17628.jpg) http://s61.radikal.ru/i174/1507/ff/d4ca9518ad98t.jpg (http://s61.radikal.ru/i174/1507/ff/d4ca9518ad98.jpg)
Уточнено описание режимов графики:

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 в эмуляторе).

Mode 2. 320х240 точек. 15 бит на цвет точки (любой из 32768 или прозрачный), fINT=60 Hz. Картинка в игре делится на статическую и динамическую области. В статической области изображается вспомогательная, медленно меняющаяся информация в игре, например, выбранное оружие, количество снарядов и набранных очков. В динамической области возможен аппаратный скроллинг экрана. Фон строится из карты тайлов.

Программист указывает координаты и размер динамической области на экране и координаты в карте тайлов. После INT по карте тайлов и координатам в ней строится формируется изображение фона игры путем копирования изображений тайлов из буфера тайлов в буфер экрана. Номера тайлов могут быть от 0 до 4095. Размер тайлов по 8х8 точек. Две карты тайлов размером по 256х512 клеток. В первой карте - номера тайлов для изображения фона. Вторая карта предназначена для аркадных атрибутов. По ним определяется, что находится в данном месте - препятствие, проходимое место, опора, предмет, который можно подобрать, другой герой и т.д.

Далее выполняются командные буферы, куда Z80 записал номера и координаты спрайтов и тайлов для печати поверх фона в буфер экрана. Сверху возможно рисование линий аппаратными точками заданным цветом. Из буфера экрана с частотой кадров 60 Гц цвета точек выводятся на видеоустройство (телевизор, монитор или экран PC в эмуляторе). Если в буфере экрана точка прозрачного цвета - то при выводе он будет заменен на BACK_COLOUR. Используется два буфера экрана - на одном строим изображение, со второго изображение в этот момент выводится на видеоустройство.

Mode 3. 640х480 точек. 15 бит на цвет точки (любой из 32768 или прозрачный), fINT=60 Hz. Похож на режим 2, только точек в два раза больше по-вертикали и по-горизонтали.

Mode 4. 320х240 точек. У тайлов и спрайтов по 4 бит на цвет точки с возможностью выбора своей палитры (из 32768 или прозрачный), fINT=60 Hz. При печати тайла или спрайта в буфер экрана формируются цвета по 15 бит на точку, В остальном похож на режим 2.

Mode 5. 640х480 точек. У тайлов и спрайтов по 4 бит на цвет точки с возможностью выбора своей палитры (из 32768 или прозрачный), fINT=60 Hz. При печати тайла или спрайта в буфер экрана формируются цвета по 15 бит на точку, В остальном похож на режим 3.

Eagle

12.07.2015, 12:44

А наложение двух спектрумовских экранов для исключения мерцания в мультиколорных демках не будет?

zx-kit

13.07.2015, 05:46

А наложение двух спектрумовских экранов для исключения мерцания в мультиколорных демках не будет?
Как писал alone (http://zx-pk.ru/showpost.php?p=611638&postcount=116), мультиколор было сложно использовать. Как и графику ATM. Для ULA+ возможно будут перекрашенные игры от наших иностранных коллег. Для сложных и медленных режимов мог написать игру только один программист. Лучше смотреть в будущее. Надо сделать так, чтобы игры было писать легко. А у нас еще даже аппаратная точка не работает. А это резко ускорило бы векторную графику типа ELITE.

Давайте лучше обсудим, какой должна быть видеокарта для моей любимой игры WARCRAFT 2. Пока мы заложили возможности для разработки денди-игр - аппаратный вывод тайлов размером 8х8 из карты тайлов, апппаратный скроллинг в окне, наложение спрайтов сверху.

http://s015.radikal.ru/i333/1507/75/7b205df85f12t.jpg (http://s015.radikal.ru/i333/1507/75/7b205df85f12.png) http://s017.radikal.ru/i400/1507/c3/da08bd4ba627t.jpg (http://s017.radikal.ru/i400/1507/c3/da08bd4ba627.png) http://s017.radikal.ru/i435/1507/8b/ab11e4494dfdt.jpg (http://s017.radikal.ru/i435/1507/8b/ab11e4494dfd.png) http://s017.radikal.ru/i441/1507/03/50dc65e5832dt.jpg (http://s017.radikal.ru/i441/1507/03/50dc65e5832d.png)

Допустим Вячеслав Медноногов Часть 1 (http://pmg.org.ru/gamedev/epic1.htm), Часть 2 (http://pmg.org.ru/gamedev/epic2.htm), или обычный программист решил написать для нового режима Спектрума игру типа Черный Ворон. Посмотрев тайлы и спрайты в WARCRAFT 2, (http://www.spriters-resource.com/pc_computer/warcraft2/) узнаем, что тайлы имеют размер 32х32, размер спрайта лучника и троля с топором 72х72. Спрайты у героев могут быть разного размера, количество фаз тоже разное, около 12-14 на каждое направление, некоторые направления зеркалятся. По данным Вячеслава Медноногова размер карты в игре 128х128 клеток. Скорости Z80 хватит, если мы ему поможем ускорить вывод на экран.

Приходим к выводу, что для аппаратного изображения фона нужно, чтобы в карте тайлов можно было разместить тайлы 32х32. Глядя на спрайты можно сделать вывод, что для спрайтов хорошего качества 16 цветов на спрайт маловато. То есть надо 256 (8 битов) с палитрой или HI-COLOR (15 битов). Также надо решить. как удобнее рисовать спрайты и в каком формате их хранить в памяти видеокарты - целой картинкой на каждого героя игры или нарезав на отдельные куски. Также надо придумать команды, для простого указания на спрайт, используя имя героя, направление движения, номер фазы. Желательно. чтобы видеокарта получала адрес начала спрайта. то есть надо где-то хранить информацию по спрайтам. Это важный вопрос для упрощения программирования и для ускорения вывода на экран.

http://s020.radikal.ru/i701/1507/68/da07b3d3e010t.jpg (http://s020.radikal.ru/i701/1507/68/da07b3d3e010.png)
Еще надо придумать как, имея один спрайт, перекрашивать его в разные цвета кланов.

MVV

13.07.2015, 09:15

zst, кто сейчас участвует в разработке, статус, схема, рабочее железо, прототип?

Valen

13.07.2015, 14:21

Еще надо придумать как, имея один спрайт, перекрашивать его в разные цвета кланов.

При печати спрайта, можно подсовывать таблицу, какие цвета, на какие поменять при печати.

zx-kit

13.07.2015, 17:51

zst, кто сейчас участвует в разработке, статус, схема, рабочее железо, прототип?
Участвуют: я, надеюсь ты и другие читатели этой темы. Давайте разрабатывать открыто, on-line. Вместе у нас больше шансов разработать что-то стоящее. Железо пока не нужно. Сначала опробуем на ReVeRse и Speccy2010 - ведь у некоторых программистов они есть. Может попробуют в работе, подскажут. что не так - мы исправим. Да, ZX_Fanat внес материальный вклад на мой счет для покупки комплектующих для разработки видеокарты.

---------- Post added at 19:01 ---------- Previous post was at 18:52 ----------

При печати спрайта, можно подсовывать таблицу, какие цвета, на какие поменять при печати.

Я вот что предлагаю. Допустим, для уменьшения занимаемой памяти и увеличения скорости копирования спрайтов мы выбрали режим 8 бит на точку в тайлах и спрайтах с возможностью выбора из 4х палитр. Одну палитру закрепим за спрайтами, а три - на тайлы для разной местности. Например, пустыня, снег и лед и лес. При чтении номера цвета точки из буфера спрайтов берем по номеру цвет из палитры и записываем в буфер экрана 15 бит цвета + старший бит как признак прозрачности.
http://s010.radikal.ru/i313/1507/43/76d69224b931t.jpg (http://s010.radikal.ru/i313/1507/43/76d69224b931.png)

MVV, просвети, можно читать-писать в память палитры и двухпортовой памяти для буфера VGA на тактовой частоте FGPA, или она работает медленнее ?

Продолжим о замене цветов для отображения разных кланов.
http://s018.radikal.ru/i527/1507/42/960ae62b9192t.jpg (http://s018.radikal.ru/i527/1507/42/960ae62b9192.jpg) http://s020.radikal.ru/i719/1507/f8/70f2a2419677t.jpg (http://s020.radikal.ru/i719/1507/f8/70f2a2419677.jpg) http://s018.radikal.ru/i527/1507/37/a3641509cbcct.jpg (http://s018.radikal.ru/i527/1507/37/a3641509cbcc.gif) http://s018.radikal.ru/i524/1507/5d/281c31ae4521t.jpg (http://s018.radikal.ru/i524/1507/5d/281c31ae4521.jpg) http://i056.radikal.ru/1507/54/f0323067f2e6t.jpg (http://i056.radikal.ru/1507/54/f0323067f2e6.png)

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

---------- Post added at 19:51 ---------- Previous post was at 19:01 ----------

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

MVV

13.07.2015, 19:04

zx-kit

13.07.2015, 20:05

zst, может тогда уже лучше ts-conf установить, доработать видео часть на зависть zx-evo? Они то в опе сейчас сидят тихо, сотрудничать не хотят, гордые. Новое железо есть, Speccy2010 и ReVerSE-U16, на U16 ещё можно и сеть поднять, железо отлажено, архитектура позволяет сделать всё о чем тут понаписали, разрабатывать велосипед уже не нужно, а это время-деньги, не факт что разработка платы это сейчас актуальная и разумная идея. Новые платы реверса Rev.C через 2-3 недели появятся в продаже, к этому моменту возможно тестовую конфигурацию успею дописать, потихоньку сам ведь делаю. Еще неделя и будет uBus2ZXBus переходник, а это все платы для спектрума подключить можно будет, хоть звуковую "ZXM-MoonSound", хоть контроллер дисковода, винта...
Видеорежим надо в FPGA делать так, чтобы работал на любом циклоне с SDRAM. Настроить частоту PLL, добавить модуль вывода (HDMI в ReVerSE или аналоговый VGA в Speccy2010). А остальное должно быть общее.

Я и планировал только видеочасть делать. Все остальное обычно в компьютере уже есть или можно поставить. Видеокарта - это часть модульного компьютера. Может сделаю когда-нибудь. Это ReVerSE никак не должно мешать. Наоборот, это будет хорошо, если у людей будет выбор.

Если дорабатывть ts-conf, то видеочасть надо свою всю, модуль SDRAM свой. Может порт управления этот же взять ? Я кроме видеочасти там ничего не изучал.

NedoPC и TS-Labs любят разрабатывать тихо, без лишнего шума, а потом выдать готовый продукт. Мне больше нравится, как разрабатывает Mick. Видно процесс разработки, обсуждение.

---------- Post added at 22:00 ---------- Previous post was at 21:52 ----------

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

Кстати когда делали WARCRAFT - сначала использовали спрайты из DUNE 2 (http://geektimes.ru/post/149298/). Когда разрабатывали КАЗАКИ - сначала двигали спрайты из WARCRAFT 2 (http://www.youtube.com/watch?v=9rV7sljLRvk&t=5m10s).

---------- Post added at 22:05 ---------- Previous post was at 22:00 ----------

Но им было труднее - им приходилось работать в рамках возможностей железа под DOS и WINDOWS. У нас же нет этих ограничений. Мы сделаем видеорежимы под себя. Давай продолжим разработку. Я пока не могу в полном объеме делать на FPGA. Покажи, что уже готово для новых режимов. Может что подскажу. Только пожалуйста не пытайся сделать все режимы по максимуму. Надо начать с простого. Надо организовать SDRAM в пакетный режим, настроить частоту на 125 МГц, двухпортовое ОЗУ для буфера VGA. Я уже писал об этом.

Sergey

13.07.2015, 20:37

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

Eagle

14.07.2015, 01:11

Как писал alone, мультиколор было сложно использовать.
То есть реализовать некий noflic в подобие фильтру в эмуляторе unreal сложнее, чем прикрутить сотни команд для чудных блиттеров?

zx-kit

14.07.2015, 05:30

То есть реализовать некий noflic в подобие фильтру в эмуляторе unreal сложнее, чем прикрутить сотни команд для чудных блиттеров?
Я не изучал старые медленные режимы графики за период между оригинальными компьютерами 48К и 128К и сегодняшним днем. Наверно некоторые люди тоже никогда не видели АТМ, гигаскрин, мультиколор, а знают только Ленинград 1. Если вы напишите, как его включить и выключить и реализовать, может быть он будет добавлен. Но пока не сдаланы новые режимы вероятность того, что будет новая видеокарта мала. Вы меня извините, но то что не интересно - делать трудно.

Для меня интересно сделать новые быстрые режимы. Я пытался писать игру "FUTURE TANK". Понял как неудобно и медленно выводить графику на стандартный экран. Большую часть времени оптимизировал по скорости процедуры вывода на экран. Добился определенных успехов. В итоге к конкурсу не успел сделать и интерес пропал. Зачем программе тратить время на изображение графики ?

Знаю, что ZX Spectrum проектировался как компьютер для образования, сделан для вывода текста. Удивительно, что потом для него написали столько хороших игр. Но для графики было бы правильнее сделать адресацию экрана как в компьютере "Специалист". В нем для перехода к байту справа надо увеличить старший байт адреса. Для перехода к байту ниже надо увеличить младший байт адреса. Может нам сначала такой режим сделать? Это позволило бы немного увеличить скорость старых игр после переделки под новую адресацию экрана. А разработка новых игр упростилась бы. Представьте, что не надо контролировать переход в другой сектор экрана - все байты идут непрерывно. И можно было бы копировать не по 8 байтов, а по 16 или 24, хоть весь столбик. Экран можно было бы увеличить до 256х256 точек.

Вместо битов FLASH и BRIGHT можно было бы сделать BRIGHT_INK и BRIGHT_PAPER. Раньше, наверно многие об этом мечтали. Разработчики ZX Spectrum не могли это сделать раньше. А сейчас, с появлением FPGA в новых компьютерах, это можно сделать.

s_kosorev

14.07.2015, 09:34

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

---------- Post added at 09:34 ---------- Previous post was at 09:32 ----------

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

zx-kit

15.07.2015, 06:09

MVV, постепенно уточняется алгоритм работы некоторых блоков видеокарты.

В качестве тактовой частоты FPGA и SDRAM формируем с помощью PLL частоту 126 MHz. Из нее получаем остальные частоты:

126:36=3,5 MHz (частота Z80)
126:18=7 MHz (частота точек SCART )
126:9=14 MHz (частота точек для нестандартного режима VGA 50 Hz)
126:10=12,6 MHz (частота точек для режима 320x240 VGA 640x480@60Hz)
126:5=25,2 MHz (частота точек для режима 640x480 VGA 640x480@60Hz)

Буфер VGA можно сделать из двух блоков регистров по 8 точек в каждом:

В начале строки VGA делаем 3 цикла регенерации SDRAM, затем заполняем оба блока регистров данными первых 16 точек в строке. Данные читаются из буфера экрана и записываются в регистры буфера VGA пакетами по 8 точек с частотой 126 MHz. В регистр цвета читаем данные из буфера VGA с частотой, которая соответствует режиму графики, т.е. каждый пятый, девятый, десятый или восемнадцатый такт частоты FPGA. Как только прочитали все 8 точек из одного блока регистров - формируется запрос для загрузки следующих 8 точек из буфера экрана. И так поочередно заполняются оба блока регистров.

batr

15.07.2015, 20:05

да не надо там никаких буферов отдельных от основной памяти видеокарты, и вообще -
это всё самый примитивный блиттер (http://zx-pk.ru/showpost.php?p=812185&postcount=61) лишь с одной командой переброски строк с разрывом и так умеет
но увы, автору просто нравится бессмысленно и беспощадно городить сложные решения частных случаев

Глас вопиющего в пустыне!

AndyD

16.07.2015, 23:44

Я считаю чтобы был успех у видяхи,вам надо скооперироваться с Миком,у него вроде как стандартный экран реализован,взять за основу,но на жирной альтере,пообщяться с ТСлаб,Если к альтерке прикрутить порт ХДД(например СМУК)Зависит от прошивки альтеры,например возможно было-бы на ТС использовать с ДМА режимами,на первое время как видеоцап(портировать прошивку),а на обычном спектруме хоть 48м использовать ХДД как внешнюю память с ДМА,спек получит 2а устройства сразу,тоесть Выпустить не готовую видео карту ,а Дев Борду с базовым спековским экраном и портами ХДД,такие вещи как потоковое видео в расширеные режимы,подгрузка палитр,спрайтов без медленной шины спека,нет ограничений на объем видео данных.
Если надо грузим в видео память с хдд или спектрума.Прошивку загружать со спеки,проект сделать открытым.
Вот как-то так.[COLOR="Silver"]

MVV

17.07.2015, 11:33

AndyD, да всё намного проще, проблема сейчас у тех, у кого железо утратило способность к развитию, а что-то новое всегда интересно и лучше, вот и лепят к нему разных монстров как ты описал. Как хобби и для обучения, это ещё понять можно. Но, без командного движка, увы, это так и останется в виде хорошей идеи.
К примеру, тут в основном у народа в подписи - ZX-Evolution rev.С разработка 2011 года. Стоимость на сегодня составляет 6500 руб (около $110). Кто готов выложить ещё примерно столько-же, написать конфигурацию и софт, чтобы у него была его новая видео карта, с возможностью работать так-же, как и железо к которому подключена? :)
Со своей стороны, мне нет смысла браться за разработку платы этой видео карты, т.к. занимаюсь U16, для которой портировал ts-conf. Мне остается только разработать и добавить эти новые видео-режимы в ts-conf без дополнительных затрат на видео карту. А вот обладателям ZX-Evolution останется продавать IDE Video-DAC и покупать ещё одну игрушку для своей ёлки ZXBus :) К стати, и U16 получит расширитель uBus-ZXBus чтобы нарядится к Новому году :v2_dizzy_christmas: можно даже ради прикола подключить Evo через IDE-uBus и побыть U16 в роли новой видео карты HDMI + USB Host + Ethernet + SD :)

MVV

17.07.2015, 13:15

Стоимость U16 вроде сейчас даже больше Эво - 120 USD
Забыли ещё к Эво прибавить стоимость корпуса, компьютерного блока питания, видео карты, Ethernet контроллера и USB Host и нескольких конфигураций - Zet, MSX2, Atari, NES... :)

AndyD

17.07.2015, 13:46

у народа в подписи - ZX-Evolution rev.С разработка 2011 года.
Я не имел в виду только Эво,такая видиМо карта могла-бы работать на любом спексовместимом пк с ZX-BUS,только я выдвинул идею использовать винт с дма подключенный прямо к видео,чтоб не грузить z80 на загрузки пересылки всякие,ведь самое ресурсоОтжирающее с новыми граф режимами будет видео,почему бы не грузить прямо в видео память ,которую можно разделить ,на именно память и буфер,буфер будет к примеру как дополнительные страницы спектрума.

Со своей стороны, мне нет смысла браться за разработку платы этой видео карты
Так она может быть виртуальной(программной) в U16,главное определиться с режимами и портами.
А вот обладателям ZX-Evolution останется продавать IDE Video-DAC и покупать ещё одну игрушку для своей ёлки ZXBus
например этот видео цап можно как выход видео использовать,то-есть не распаивать его на основной плате а развести контактную площядку под разьем ,нет цапа распаиваем на плате.Ведь видео карте все равно нужен цап,этот чем плох?

про U16 знаю что можно ,речь про весь парк спектрумов.

HDMI + USB Host + Ethernet + SD это все бонусы,они не обязательны,то-есть кому будут нужны купят U16.

MVV

17.07.2015, 15:19

такая видиМо карта могла-бы работать на любом спексовместимом пк с ZX-BUS
Идея хорошая, но не вяжущаяся с мыслью, что карта может работать даже не вставленной в слот совместимого, без напряга просто эмулируя его. Да и стоимость, заставляет задуматься о необходимости приобрести её. Поэтому здесь и было предложено сначала разработать и отладить новые режимы совместно с разработчиками железа и софта на уже действующем железе, без дополнительных затрат на разработку новой платы. Я даже привёл обзор уже разработанных видео карт под ZX-BUS:
http://zx-pk.ru/showpost.php?p=813379&postcount=147
http://micklab.narod.ru/ZXMVideoCard.htm
И даже универсальную плату ordroid-w, доработав которую можно использовать ещё и как достаточно простой и современный ускоритель 3D.

Также мной было предложено разработать ускоритель на базе графического контроллера EVE, что намного лучше выше предложенного, из-за простоты подключения (SPI/I2C) к ZX_Evolution, ReVerSE-U16, Speccy2010, ZX-Spectrum... с достаточно мощной функциональностью из коробки:
http://zx-pk.ru/showpost.php?p=737954&postcount=321

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

zx-kit

21.07.2015, 06:17

Для совместимости с играми для ATM в режиме 320х200 16с надо для переключения использовать порты графики ZX-EVO (http://nedopc.com/zxevo/rom/zxevo_base_configuration.pdf) EFF7, XX77 и возможно за ними понянутся еще некоторые порты управления памятью и палитрой.:
http://i024.radikal.ru/1507/0d/ecc32321267et.jpg (http://i024.radikal.ru/1507/0d/ecc32321267e.png)

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

zx-kit

23.07.2015, 06:05

Изучив режимы ZX-EVO, можно сделать такие выводы:

Они используют страницы ОЗУ, которые используются в модели 128K - это плохо.
Они могут включать страницы графики в любое окно по 16К - это хорошо.
Последовательность байтов и битов сложная - это плохо.
Экраны или их части располагаются с адреса, отличного от 0 - это плохо.
Возможна палитра 16->64 цвета - это хорошо.

Что можно улучшить - упростить и ускорить ?:

Графику расположить с 0 адреса - это упростит и ускорит определения адреса в ОЗУ экрана.
Использовать другие страницы свыше 8 страниц режима 128K. Это позволит дорабатывать старые игры.
Адресацию сделать непрерываной. Это упростит копирование спрайтов.
Биты атрибутов сгруппировать по 4.
Дополнительные экраны тоже размещать с адреса 0.
Фон рисовать в нижнем слое, а спрайты в верхнем. Это устранит клешинг атрибутов.

Давайте сделаем новый режим 256x192 NEWATTR CONTINUOUS 2 LAYERS+SELECTOR:

Для работы с графикой в новых режимах будем временно отключать ПЗУ компьютера. Для этого в шине ZX-BUS есть специальный сигнал.
Будет два основных слоя - нижний и верхний, а также вспомогательный слой-селектор. Основные слои похожи на обычные экраны ZX Spectrum, но с оптимизированной адресацией. Слой селектор показывает, из какого слоя отображать точку на экране TV/VGA. 0 - из нижнего, 1 - из верхнего.
Адресация байтов у всех слоев одинаковая. Экран можно представить состоящим из 32х24 клеток размером 8х8 пикселов. У каждой клетки цвет задается байтом NEWATTR. Биты D7-D4 задают цвет единичного пиксела COLOR1, а биты D3-D0 задают цвет нулевого пиксела COLOR0.

Адрес HL в области пикселов по координатам X,Y клетки можно определить так: H=X, L=Y*8 (сдвиг влево три раза).
Адрес HL в области атрибутов по координатам X,Y клетки можно определить так: H=X, L=Y+192 (OR $00C0).
Нужный экран временно подставляется в окно с 0 адреса. Для этого в специальный порт записывается номер страницы.

Чем новый режим лучше стандартного:

Линейная адресация с 0 адреса упрощает и ускоряет вычисление адреса в области пикселов и атрибутов.
При копировании блока размером более 8 байтов по-вертикали нет необходимости контролировать переход в другой сектор (треть) экрана, что делалось для старого экрана.
Возможность ускорения копирования спрайтов с помощью новых комбинаций команд Z80 (змейкой и т.п.).
Атрибуты задают независимую яркость цветов для 0 и 1 пикселов.
Нет клешинга атрибутов при движении спрайтов, так как их можно отображать в верхнем слое.
Не надо сохранять и восстанавливать фон при движении спрайта.
Использвание дополнительных страниц вне основного ОЗУ позволяет дорабатывать старые игры, использующие все 8 страниц 128 К.

zx-kit

24.07.2015, 05:30

Мы когда-то обсуждали узким коллективом очень давно, на какую внешнюю видеокарту было бы проще переделывать старые игрушки. Схема приблизительно такова - перехват на шине записи в экранную область Спека и соотв-но запись в память видеокарты до восьми пикселей (многобитных, но для совместимости на два цвета атрибуты будут влиять; после резета эти два и привязаны к 0 и 1 спектрумовской записи в растр). Далее, вывод спрайта в большинстве игрушек такой примерно: чтение (побайтно) с экрана, чтение маски, чтение спрайта, AND с маской, OR со спрайтом, запись в экран. Это всё достаточно заменить на: чтение маски, запись маски, чтение спрайта, запись спрайта. И при входе в процедуру включить режим, при котором при каждой чётной записи в экран единицы - прозрачный цвет, а нули - цвет маски (допустим, чёрный); а для каждой нечётной записи нули - прозрачный цвет, единицы - цвет спрайта. Потом выключить (для оставленных без изменений процедур печати фона, текста, стирания). Это если минимально хотим вмешаться, только чтобы клэшинг убрать. Правда, на старом спековском экране спрайты будут затирать фон (что неважно, если вывод только через новую видеокарту предполагается, а можно сделать, чтоб игра и на обычном Спеке шла без отличий, а через видеокарту - уже без клэшинга, лишь слегка замедлится процедура из-за лишней записи фона с маской).
Предложенный мной выше режим со слоями тайлов, спрайтов и селектором подходит для этого ? Может его еще можно улучшить или вернуть старую раскладку битов цвета в байте атрибутов для упрощения переделки игр ?

---------- Post added at 07:30 ---------- Previous post was at 07:12 ----------

Alex Rider, можно ли под предложенный выше режим переделать игру типа Saboteur 2 ? Стоит ли менять раскладку битов атрибута или лучше оставить страой ? Оставить 256х192, так как старые игры в этом разрешении или немного увеличить количество точек ?
---------------------------------------

Наверно стоит начать с простого и основного, а потом переходить к более сложному:

разработать стандартный режим 50 Гц SCART
VGA60 для стандартного режима
палитру ULA+
изготовить опытный образец видеокарты
описанный выше режим с линейной адресацией с одним слоем с адреса 0000.
добавить второй слой с адреса 0000 и слой селектор тоже с адреса 0000
объявить конкурс игр для режима с линейной адресацией.
, , .
А уже потом добавлять другие возможные расширения:
режим ATM 320x200 16c
режим 320х240 с аппаратной точкой 32K цветов.
добавить блиттер для спрайтов с 256 цветов на точку без палитры
добавить палитру 256->32К цветов
добавить автоматическое построение фона из карты тайлов
добавить статическую и динамическую области для экрана
режим 640х480.

Возможно не все режимы получатся. Начнем с простых, а потом постепенно, совместными усилиями энтузиастов будем добавлять новые режимы.

AndyD

24.07.2015, 11:12

Наверно стоит начать с простого и основного, а потом переходить к более сложному:
Да,надо сделать для начала стандартный спековский экран ,
изготовить опытный образец видеокарты
за основу можно взять разработки IanPo.
По памяти, в идеале ,что бы можно было проецировать любую область памяти в видео память,чтоб не пересылать данные в 0й адрес ,а потом отправлять в видео.Чтение из видео в любую область памяти.

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

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

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

MVV

25.07.2015, 10:49

AndyD

25.07.2015, 11:28

SDHC 32GB не подойдет?
Если на ReVerSE-U16,ЕvO то да ,а если на видео еще одна флешка будет,то как к ней будет обращатся спек? если конечно собираетесь делать видео карту.

zx-kit

25.07.2015, 11:35

Отладил работу контроллера SDRAM в пакетном режиме на плате ReVerSE-U16 (EP4CE22E22C7; MT48KC16M16A2-75) в тестовой конфигурации, теперь есть привязка ко времянкам:

SDRAM:
Base Clock = 126MHz, 1T = 7,936507936507937ns
SDRAM Clock = 126MHz (<=133MHz, CL=3)
CL = 3
Burst = 8 (Auto Precharge)
WR = 15T = 119,047619047619ns
RD = 14T = 111,1111111111111ns

Отлично - то что надо ! Где можно посмотреть ? Может будешь выкладывать здесь ?

REFRESH = 9T = 71,42857142857143ns (>=66ns) Auto Refresh каждые 7.81us

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

HDMI:
Serializer Clock = Base Clock = 126MHz
Pixel Clock = 25.2MHz (126/5)

Это тоже отлично. Сделай, пожалуйста, для Speccy2010 такую же модель, только выход на аналоговый VGA. На биты D7, D1, D0 каждого цапа R-2R надо подать 0. На остальные 5 - цвета 32К.

Palette 24bpp:
Red = 1KB (<=4 страницы)
Green = 1KB (<=4 страницы)
Blue = 1KB (<=4 страницы)
Mode (на данный момент реализованы):
1) VGA 640x480@60Hz 24bpp/15bpp/8bpp, INT = 60Hz. Базовое разрешение.
2) VGA 320x240@60Hz 24bpp/15bpp/8bpp, INT = 60Hz.
3) Text VGA 640x480@60Hz 3bpp, где аппаратно 80х30 символов 8x16, знакогенератор 4KB
4) ZX-Spectrum VGA 640x480@60Hz 2bpp, где (border left 32+screen 256+border right 32; border top 24+screen 192+border bot 24), INT = 60Hz.

Не надо гнаться за 24 битами - это замедлит работу карты и усложнит прошивку. Давай для начала сделаем без палитры 1 байт на точку. 16 стандартных цветов. Когда все заработает - добавим палитру 256-32K.
Все режимы, для начала стандартный, выводить сначала в буфер экрана, а потом с нужной частотой выводить на VGA.

CPU:
1) NextZ80@42MHz..2MHz (126/x, где x=3..63)
2) NextZ80@42MHz..2MHz (126/x, где x=3..63)
3) T80@126MHz..2MHz (126/x, где x=1..63)

В разработке:
DMA
Арбитр памяти SDRAM-Cache-CPU1/CPU2/CPU3/DMA/VGA
Cache для CPU

Предлагаю для начала не усложнять, упростить по максимуму, частоту Z80 сделать 3.5 MHz. Режим предполагается для большинства компьютеров. Тем более на больших частотах доступ к SDRAM может быть усложнен. Пока без ДМА.

Сейчас тестовая программа крутится во внутренней памяти FPGA (проверка SDRAM) на NextZ80@42MHz, отладочная информация выводится в текстовом режиме.
Важно сделать арбитр памяти и кэш, чтобы запустить графический режим для отладки. Кто возьмется?

Запись/чтение Z80<->SDRAM ? Давай сначала сделаем стандартный режим ZX Spectrum c выводом через буфер экрана и регенерацию. Записывать в буфер экрана надо с частотой развертки TV 50 Hz, чтобы изображение было аналогично тому, что выводится на телевизор.

Наверно, самый компактный по размерам спрайтов и тайлов и быстрый режим, когда в буферах спрайтов, тайлов и экрана на каждую точку приходится 8 бит. То есть за один пакет будет читаться-писать по 16 точек. Надо создать 32 регистра по 8 бит. За один пакет из SDRAM будем заполнять 16 регистров. Читать из регистров с частотой точек для данного режима. Для начала 12.6 MHz. То есть, каждый десятый такт 126 MHz. Для других режимов эти числа потом можно будет брать из мультиплексора.

Палитру можно будет потом добавить после буфера VGA. Сначала без палитры. Про буфер VGA я писал выше, только там было для режима 16 бит на точку, а нам надо 8 бит на точку. Затем добавим доступ Z80.

SDHC 32GB не подойдет?
Какие сейчас системы загрузки есть и их особенности ? Какая лучшая ?

MVV

25.07.2015, 12:24

Сделай, пожалуйста, для Speccy2010 такую же модель
Сейчас минимум. Первая проблема - у меня нет Speccy2010, вторая - придется каждый раз переносить конфигурацию с U16 с учетом особенностей архитектуры, FPGA и сделанных правок, а это дополнительная работа и время.
На Speccy2010 затруднен прямой доступ к SD, нужно пилить МК или паять второй разъем SD, также подгонять кэш под M4K.
Кто ещё будет заниматься проектом на Speccy2010, на U16...? Также нужен программист, нужно будет написать хоть драйвера под железо и демо примеры. Возможно кто-то согласится помочь за вознаграждение.

zx-kit

25.07.2015, 13:09

Сейчас минимум. Первая проблема - у меня нет Speccy2010, вторая - придется каждый раз переносить конфигурацию с U16 с учетом особенностей архитектуры, FPGA и сделанных правок, а это дополнительная работа и время.
На Speccy2010 затруднен прямой доступ к SD, нужно пилить МК или паять второй разъем SD, также подгонять кэш под M4K.
Кто ещё будет заниматься проектом на Speccy2010, на U16...? Также нужен программист, нужно будет написать хоть драйвера под железо и демо примеры. Возможно кто-то согласится помочь за вознаграждение.
Надо сделать так, чтобы большинство модулей, связанных с новыми видеорежимами было одинаковыми. Их и будем менять. А частоту тактовых, распределение выводов FPGA, VGA- выход почти меняться не будут.

Зато я и другие, у кого есть Speccy2010 смогут присоединиться к разработке и тестированию. Пока модули можно выкладывать здесь. Потом, когда устареют сотрешь. Так все желающие смогут скачать одним файлом, посмотреть, запустить. Пока на Speccy2010 придется паять второй SD-разъем. Только нужно написать как и как прошивать. Потом может syd или другой специалист доработает.

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

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

Давай пока обойдемся без палитр и кэша. Как все заработает, тогда будем думать и добавлять.

---------- Post added at 15:09 ---------- Previous post was at 14:54 ----------

Также нужен программист, нужно будет написать хоть драйвера под железо и демо примеры. Возможно кто-то согласится помочь за вознаграждение.
Драйвера не нужны - мы же не WINDOWS пишем. Когда отладим режимы, можно будет устроить конкурс игр с призами.

MVV

25.07.2015, 13:29

Давай пока обойдемся без палитр и кэша. Как все заработает, тогда будем думать и добавлять.
Палитру я уже сделал, остается самое основное - арбитр памяти. Нужно связать CPU, VGA с SDRAM.
Проект создам у себя на github.

zx-kit

25.07.2015, 13:56

Палитру я уже сделал, остается самое основное - арбитр памяти. Нужно связать CPU, VGA с SDRAM.
Проект создам у себя на github, так намного удобнее будет нескольким разработчикам работать над проектом в ветках, вести историю исправлений и вносить исправления, комментировать.
Сначала сделать чтение из буфера экрана размером 320х240 точек в буфер VGA. Потом запись стандартной графики в буфер экрана. Каждую точку экрана спектрума, включая бордер представить в виде одного байта и записать в буфер экрана.

Как только FPGA определит, что команда чтения или записи Z80 в/из ОЗУ должен подаваться запрос на доступ к ОЗУ - устанавливаться флаг или бит. Это значит, что как только будет закончен текущий пакет обращения к SDRAM со стороны блиттера или буфера VGA - следующий пакет будет отдан Z80. Так как пакеты по 8 слов можно выбрать один байт в первом слове. Остальные байты игнорировать соответствующими управляющими сигналами на SDRAM.

Как только произведен обмен Z80-SDRAM сбрасывать флаг доступа Z80 и следующий пакет могут использовать AUTO REFRESH, буфер VGA или блиттер. Пока блиттера нет. А AUTO REFRESH будем делать 5 циклов в начале строки. После этого загружаем 16 слов в буфер VGA. Как только начнется активная часть строки - начинаем брать по 1 байту из буфера VGA и выводить в ЦАП/HDMI. Во время кадрового бордера читать в буфер VGA не надо.

---------- Post added at 15:41 ---------- Previous post was at 15:31 ----------

Так как экран спектрума у тебя уже показывает - пока можно добавить запись этих точек в буфер экрана. Наверно в качестве ОЗУ у тебя кэш. Потом эти же данные будем брать из SDRAM.

Самый высоких приоритет при доступе к SDRAM будет у Z80. Затем AUTO REFRESH. Затем чтение из буфера экрана в буфер VGA. Затем чтение из экранной области стандартного ZX Spectrum-a и запись точек в буфер экрана. Самый низкий приоритет будет у блиттера.

В новых режимах чтение из экранной области стандартного ZX Spectrum-a и запись точек в буфер экрана не требуется. А в старых режимах не будет блиттера.

---------- Post added at 15:56 ---------- Previous post was at 15:41 ----------

Допустим, флаги имеют имена F1...F5 соответственно. 1- когда установлен. Чтобы определить, какой будет следующий пакет SDRAM анализируем флаги:
F1=1 - значит Z80.
F1=0, F2=1 - значит AUTO REFRESH.
F1=0, F2=0, F3=1 - значит буфер VGA и т.д.

Соответственно на SDRAM с помощью мультиплексора подаем адреса с Z80 или соответствующих счетчиков.
Флаг F2 устанавливать в начале каждой строки VGA и сбрасывать после выполнения 5 циклов регенерации. Флаг F3 устанавливаем как только прочитали и выдали на VGA 16 точек. Сбрасывать - когда загрузили из буфера экрана в буфер VGA (32 регистра по 8 бит) следующие 16 точек.

denpopov

25.07.2015, 14:00

Сначала сделать чтение из буфера экрана размером 320х240 точек в буфер VGA
а зачем?

Потом запись стандартной графики в буфер экрана
а как? дма в руки.

zx-kit

25.07.2015, 14:08

а зачем?

а как? дма в руки.

Стандартную графику нельзя скопировать с помощью DMA. Надо прочитать байт пикселов, байт атрибутов, преобразовать цвета 8 точек в формат: 1 байт на точку. Возможно потребуется преобразование с помощью палитры ULA+. Потом готовые 8 точек записать в буфер экрана.

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

Буфер VGA представляет из себя 32 регистра по 8 битов. Предназначен для согласования процессов чтения из буфера экрана по 16 точек и вывод в ЦАП VGA с другой частотой по одной точке.

denpopov

25.07.2015, 14:25

Стандартную графику нельзя скопировать с помощью DMA
Бугага, читаем дальше:

Надо прочитать байт пикселов, байт атрибутов, преобразовать цвета 8 точек в формат: 1 байт на точку

выходит, это простое побайтное мышление?

Возможно потребуется преобразование с помощью палитры ULA+. Потом готовые 8 точек записать в буфер экрана

мне больше нечего сказать концептологу.. Фантазируй ищо!

zx-kit

25.07.2015, 14:29

Бугага, читаем дальше:

выходит, это простое побайтное мышление?

мне больше нечего сказать концептологу.. Фантазируй ищо!

Что опять не так ? Где я ошибся ? Даже если ошибся - поправь.
В моей видеокарте все режимы графики формируют результирующую картинку в буфере экрана. Потом с требуемой частотой кадров и точек картинка выводится на TV или VGA. Вроде все просто. Если не понятно - спрашивайте.

denpopov

25.07.2015, 14:54

Что опять не так ? Где я ошибся ? Даже если ошибся - поправ

Стандартную графику нельзя скопировать с помощью DMA

Тгода вопрос - зачем дма?

zx-kit

25.07.2015, 15:01

Тгода вопрос - зачем дма?
Дма пока и не планировалось использовать. У Z80 и видеокарты общая память. Оба имеют к ней доступ. Может потом потребуется для копирования картинки после загрузки в другую область памяти. А так планировался блиттер для копирования спрайтов в область экрана.

Если будет возможность - лучше сразу грузить в нужную страницу ОЗУ, подключив ее в нужное окно 16К, как в ATM/ZX-EVO.

denpopov

25.07.2015, 15:07

Дма пока и не планировалось использовать
тогда сразу в топку затеи

У Z80 и видеокарты общая память
Интересно, у TS-Conf общая память не особо и мешает.

А так планировался блиттер для копирования спрайтов в область экран

И как блиттер будет планироваться? копирование побайтно или попиксельно? Или, может, с четными адресами?

Если будет возможность - лучше сразу грузить в нужную страницу ОЗУ, подключив ее в нужное окно 16К, как в ATM/ZX-EVO

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

zx-kit

25.07.2015, 15:21

Хотя возможно ДМА или блиттер без учета прозрачного цвета может понадобиться при загрузке спрайтов с носителя. Спрайты обычно рисуют в одной картинке. Тип так:

http://s019.radikal.ru/i635/1507/be/9ad1c95ac8adt.jpg (http://s019.radikal.ru/i635/1507/be/9ad1c95ac8ad.png) http://s010.radikal.ru/i312/1507/fa/c468dcff4cfat.jpg (http://s010.radikal.ru/i312/1507/fa/c468dcff4cfa.png) http://s019.radikal.ru/i611/1507/61/599705767285t.jpg (http://s019.radikal.ru/i611/1507/61/599705767285.png)

Чтобы обеспечить доступ к каждому спрайту при загрузке картинку нужно будет скопировать в определенное место SDRAM емкостью 8 мегабайт. После загрузки и копирования Z80 должен будет вычислить адрес каждого спрайта для последующего быстрого поиска. При загрузке нужно будет создать специальную таблицу с параметрами спрайтов. В ней каждый спрайт имеет номер, адрес начала в SDRAM, ширину, высоту, возможно дополнительные параметры. Возможно потребуется большой файл со спрайтами разделить на отдельные спрайты и скопировать в нужное место SDRAM. В результате будет таблица, по которой легко можно будет найти по номеру адрес спрайта и его размеры. После этого программа сможет работать со спрайтами на более высоком уровне без указания адреса и размеров.

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

---------- Post added at 17:21 ---------- Previous post was at 17:14 ----------

тогда сразу в топку затеи
Интересно, у TS-Conf общая память не особо и мешает.

И как блиттер будет планироваться? копирование побайтно или попиксельно? Или, может, с четными адресами?

отм пусть сразу идет лесом. Лучше бы адрес конкретной видеостраницы работал, а не по страницам.
Копирование спрайтов аналогично TSconf, но не в реальном режиме времени (так как это сложно) и не ограничено количеством 85 и размерами 64х64. Насколько хватит времени и объема памяти - выбирает программист. Копирование таких же как в TSconf спрайтов происходит в буфер экрана поверх тайлов и других спрайтов.

В TSconf наверно тоже можно включать в любое окно любую страницу SDRAM. Какие видеостраницы ? Все адресное пространство Z80 64К и SDRAM 8М разделено на окна и страницы соответственно размером по 16 К. Ко всем имеют доступ Z80 и видеокарта. Есть буфер спрайтов, тайлов, экрана. Буферов экрана может быть несколько. Буферы размером больше 64 К. К ним обычно доступ не нужен. Только при загрузке тайлов и спрайтов с носителя. Там придется через окна 16 К. Хотя..

denpopov

25.07.2015, 16:00

Ну, в топку ваши проекты. Много умных слов и ничего на деле.

MVV

25.07.2015, 16:28

zx-kit

25.07.2015, 17:49

zst, собрал для Speccy2010 (EP2C8Q208C8) и ReVerSE-U16 (EP4CE22E22C7). Для Speccy2010 PLL не генерит 126МГц, пришлось выставить 125.0МГц, VGA 25.0МГц.
Попробуй, должно вывести на экран палитру 24bpp 16Мцветов с наложенным текстовым слоем 80x30, режим 640х480@60Hz 24bpp как на фото:

Спасибо. Что-то не могу конкретной информации про подключение второй SD карты найти. Надо перечитать всю тему. Дайте ссылку с пошаговой процедурой подключения TSconf. Достаточно просто припаять 4 проводка и резистора к переходнику SD-микро SD ? Без м/с часов и прочее.

Я так понял, что заняли R-2R AUDIO. Может какие другие выводы FPGA можно задействовать. Дело в том, что я давно TDA1543 не паяю, а паяю R-2R. Был у меня где-то один б/у Speccy2010 на зеленой плате c TDA1543. Но хотелось бы сделать универсальное подключение.

denpopov

25.07.2015, 18:07

Дайте ссылку с пошаговой процедурой подключения TSconf

tslabs.info все твоё:)

MVV

25.07.2015, 18:14

Дайте ссылку с пошаговой процедурой подключения TSconf.
http://forum.tslabs.info/viewtopic.php?f=31&t=483

zx-kit

25.07.2015, 18:15

Например, непонятно зачем сигналы JOY0_SELECT, JOY1_SELECT, VGA_SDAT, VGA_SCLK. Можно было бы их отрезать и использовать для SD-CARD2. Наверно, если поискать, можно еще найти несколько лишних сигналов. Возможно, биты 7,1,0 в R-2R цветов. Но нужно точно знать, используются ли они в стандартной прошивке.

MVV

25.07.2015, 18:18

Возможно, биты 7,1,0 в R-2R цветов. Но нужно точно знать, используются ли они в стандартной прошивке.
В этом (http://zx-pk.ru/showpost.php?p=819178&postcount=333) тесте используются.

zx-kit

25.07.2015, 18:24

В этом (http://zx-pk.ru/showpost.php?p=819178&postcount=333) тесте используются.
Это понятно, а в старых прошивках они нужны? У стандартного режима, который был в Speccy2010 достаточно было бы двух битов на цвет, как в VGA&PAL. Но у сида наверно они используются для формирования PAL сигналов. Если подавать 1 на старшие биты R-2R цветов сигналы на VGA могут быть больше 0.7 V, что нем не надо. А младшие 1 и 0 особо и не заметно будет в играх.
Можно было бы отпаять резисторы, через которые идут сигналы старших битов и припаять SD-карту. Надеюсь нам часы не нужны ?
Основная карта у нас как отформатирована, какие файлы кидать для TS-conf и нового режима ?
Дополнительная карта у нас как отформатирована, какие файлы кидать для TS-conf и нового режима ?

MVV

25.07.2015, 18:57

zx-kit

25.07.2015, 19:06

Пересобрал для ReVerSE-U9. Тут цветов поменьше будет - 9bpp, SDRAM тоже запустилась в burst 8 на 126МГц. Читает правда 8 байт, это можно поправить - заменой burst на full page и прерывать после чтения 16-го байта.
В общем работает, и выглядит всё намного лучше чем на фото:

Собираю для U8, после небольшого причёсывания обновлю на git.
Молодец. Давай запустим на максимальном количестве комьпьютеров. 3 бита на канал цвета для начала тоже хорошо. Пока отладим без палитры. Если будут игры на высокой скорости с небольшим количеством цветов - это уже большой прогресс. Даже для начала хватит и стандартных цветов ZX Spectruma. Может так и сделаем ? 15 цветов + прозрачный.

MVV

25.07.2015, 19:16

Основная карта у нас как отформатирована, какие файлы кидать для TS-conf и нового режима ?
Дополнительная карта у нас как отформатирована, какие файлы кидать для TS-conf и нового режима ?
http://forum.tslabs.info/viewtopic.php?f=31&t=483
http://zx-pk.ru/showthread.php?t=12425
https://github.com/andykarpov/tsconf-wxeda

Давай запустим на максимальном количестве компьютеров.
На U8/U9/DE1-SoC можно будет стартовать из 128К Спектрума, т.к. имеется дополнительная память. На U16 и Speccy2010 придется допиливать арбитр памяти, т.к. здесь всё весит на SDRAM.

zx-kit

25.07.2015, 20:23

http://forum.tslabs.info/viewtopic.php?f=31&t=483
http://zx-pk.ru/showthread.php?t=12425
https://github.com/andykarpov/tsconf-wxeda

На U8/U9/DE1-SoC можно будет стартовать из 128К Спектрума, т.к. имеется дополнительная память. На U16 и Speccy2010 придется допиливать арбитр памяти, т.к. здесь всё весит на SDRAM.
Вот что я понял про установку TSconf на Speccy2010. Если не так - поправьте:
Скачать и распаковать архивы с текущей прошивкой speccy2010_tsconf_v029(20141026).7z оттуда (http://forum.tslabs.info/viewtopic.php?f=31&t=483&start=25), Wild Commander оттуда (http://zx-pk.ru/Wild Commander).
Подготовить три SD карты:
1. FAT16 или FAT32. Файлы: стандартная флешка с файлами прошивки SPECCY2010, но файл SYN/tsconf.rbf переименовываем в speccy2010.rbf и закидываем на флешку. Установить до включения в разъем SD на плате Specy2010. C нее загружается прошивка в FPGA.
2. FAT16. Файлы: zxevo.rom Установить до включения в дополнительный разъем SD. С нее грузится система. После загрузки в дополнительный разъем вставить третью карту и нажать ENTER.
3. FAT32.

Записать в корень файл softwares/boot.$C
Скачать дистрибутив Wild Commander http://zx-evo-fpga.googlecode.com/hg/pentevo/soft/WC/wc.rar, распаковать и переписать на SD-карту директорию WC
Записать необходимое количество Ваших образов TRD, SCL, TAP, музыки в формате PT3, и чего угодно, что поддерживает WC, можно распихивать их по вложенным директориям.
Подробнее о WC: http://tslabs.info/forum/viewtopic.php?f=26&t=143

---------- Post added at 22:23 ---------- Previous post was at 22:01 ----------

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

MVV

25.07.2015, 22:55

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

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

zx-kit

26.07.2015, 08:32

У 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

26.07.2015, 09:14

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

zx-kit

26.07.2015, 09:31

Для чтения данных из 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

26.07.2015, 09:43

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 - черная.
Вот к чему приводит тайловое мышление. :v2_dizzy_facepalm: При том, что блиттер при любой палитре или без оной позволяет наложить маленький фрагмент другой раскраски поверх большого. Или маленький фрагмент другой формы. Или не поверх. Да пусть хоть причёсками отличаются!

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

MVV

26.07.2015, 09:53

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

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

zx-kit

26.07.2015, 10:25

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

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

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

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

26.07.2015, 10:28

zx-kit

26.07.2015, 11:04

Я пока хочу допилить простое - это работа основного режима 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

26.07.2015, 11:23

У меня это 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%

MVV

26.07.2015, 11:32

буфер 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

26.07.2015, 11:32

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

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

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

MVV

26.07.2015, 11:42

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

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

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

zx-kit

26.07.2015, 11:43

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

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

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

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

zx-kit

26.07.2015, 11:51

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

MVV

26.07.2015, 12:32

А зачем ты хранишь точку по 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. Это даже упростит конвейер.

zx-kit

26.07.2015, 12:44

Я представляю это в виде целой строки на 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 (http://www.spriters-resource.com/pc_computer/warcraft2/) или любой другой. В WC2 немного смухлевали со спрайтами - вместо 8 разных углов поворота нарисовали спрайты только для 5-ти, а остальные 3 угла отображают отзеркаливанием. Из-за этого при повороте персонажей меч может неожиданно из правой руки оказаться в левой. Это не очень хорошо.

http://s019.radikal.ru/i640/1507/cf/ba6a209a6e20t.jpg (http://s019.radikal.ru/i640/1507/cf/ba6a209a6e20.png) http://s018.radikal.ru/i503/1507/4d/05ffdc18dbbbt.jpg (http://s018.radikal.ru/i503/1507/4d/05ffdc18dbbb.jpg)

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

MVV

26.07.2015, 13:30

А если Z80 на 42 MHz, то он не даст работать блиттеру, так как будет без остановки обращаться к памяти и требовать отдать ему КАЖДЫЙ цикл. А ведь нужно еще выводить данные на VGA и САМОЕ ГЛАВНОЕ - он будет тормозить блиттер, который быстрее его.
Это если он не будет послан по приоритету арбитром памяти в кэш или wait. Или сам как решит. Если проца два, то переключится на другой, возможно другому данные из SDRAM не нужны будут, аналогично с ихними контекстами.
По поводу bpp, то тут сейчас наглядно просматриваются - 24bpp, 16bpp, 8bpp, 4bpp. Хз как ты будешь их на лету переключать?
В принципе возможно, есть 4 страницы палитры. Поставить её только после конвейера и перед FIFO.

zx-kit

28.07.2015, 16:55

Количество битов в 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

29.07.2015, 16:26

zst, в общем устал уже всем отвечать с разъяснениями и примерами, желающего народу столько, что нужно делать новый сайт, как например тут (http://shop.easyelectronics.ru/index.php?categoryID=102).

Думаю можно отвечать и в соответствующей теме на этом форуме. Разработчик c того сайта не работает на постояной работе (информация на 8 января 2010) (http://easyelectronics.ru/otladochnaya-plata-pinboard-v11.html#comment-15730), поэтому у него есть время на статьи и форум на своем сайте. Тебе это надо ?

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

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

zx-kit

07.08.2015, 21:09

Написал на Verilog и протестировал в Icarus-Verilog (спасибо авторам сайта Marsohod (http://marsohod.org/index.php/11-blog/113-icarus)) модуль развертки VGA.

http://s018.radikal.ru/i524/1508/17/363645a4a842t.jpg (http://s018.radikal.ru/i524/1508/17/363645a4a842.png)

http://s019.radikal.ru/i641/1508/4d/43d732026fc1t.jpg (http://s019.radikal.ru/i641/1508/4d/43d732026fc1.png)

http://s017.radikal.ru/i440/1508/6c/5e91c36382det.jpg (http://s017.radikal.ru/i440/1508/6c/5e91c36382de.png)

http://s57.radikal.ru/i156/1508/eb/e5e8aed6ba92t.jpg (http://s57.radikal.ru/i156/1508/eb/e5e8aed6ba92.png)

http://s019.radikal.ru/i630/1508/2b/7c4d17dec249t.jpg (http://s019.radikal.ru/i630/1508/2b/7c4d17dec249.png)

http://i056.radikal.ru/1508/2a/9d0e658ed3e6t.jpg (http://i056.radikal.ru/1508/2a/9d0e658ed3e6.png)

http://s020.radikal.ru/i718/1508/58/f69a9abc399at.jpg (http://s020.radikal.ru/i718/1508/58/f69a9abc399a.png)

http://s017.radikal.ru/i400/1508/73/15fabb6dc136t.jpg (http://s017.radikal.ru/i400/1508/73/15fabb6dc136.png)

http://s010.radikal.ru/i313/1508/88/9d9c5dd0000at.jpg (http://s010.radikal.ru/i313/1508/88/9d9c5dd0000a.png)

Из картинок можно убедиться, что:

1. Счетчик pixel clock считает от 0 до 4, т.е. делит на 5, а 126 / 5 = 25.2 MHz.
2. Гашение до строчного синхроимпульса (Front porch) от 784 до 799, т.е. 16 пикселов.
3. Строчный синхроимпульс (Sync pulse) от 0 до 95, т.е. 96 пикселов.
4. Гашение после строчного синхроимпульса (Back porch) от 96 до 143, т.е. 48 пикселов.
5. Счетчик пикселов в строке считает от 0 до 799, т.е. в строке (Whole line) 800 пикселов.
6. Гашение до кадрового синхроимпульса (Front porch) от 515 до 524, т.е. 10 строк.
7. Кадровый синхроимпульс (Sync pulse) от 0 до 1, т.е. 2 строки.
8. Гашение после кадрового синхроимпульса (Back porch) от 2 до 34, т.е. 33 строки.
9. Счетчик строк в кадре считает от 0 до 524, т.е. в кадре (Whole frame) 525 строк.
10. Начало кадрового синхроимпульса (спад от 1 до 0) совпадает с началом строчного синхроимпульса.

http://s017.radikal.ru/i402/1508/19/c56dc1aa793et.jpg (http://s017.radikal.ru/i402/1508/19/c56dc1aa793e.png)

zx-kit

08.08.2015, 10:26

Режим графики NO CLASH (без блиттера).

Новый режим должен обеспечивать новые возможности с минимальными доработками в играх. Для этого нужно обеспечить выбор параметров:

1. Атрибуты - стандартные / новые (отдельная яркость INK и PAPER)
2. Начало экрана - стандартное (4000) / новое (0000)
3. Адресация экрана - стандартная / новая (линейная)

Для введения режима графики NO_CLASH в игры можно использовать стандартные параметры. Подпрограмму печати тайлов фона оставляем без изменений. Подпрограмму печати движущихся объектов модернизируем:

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

Для вывода спрайта с маской в режиме NO_CLASH надо загрузить в аккумулятор байт маски и записать в адрес пикселов. Затем загрузить байт спрайта и записать по этому же адресу в адрес пикселов. И так далее - байт маски, байт спайта. Потом на каждые 8 байтов спрайта записать один байт атрибутов. В итоге спрайты будут двигаться поверх фона без клешинга. И это без особых переделок графики и программ.

Для новых игры можно установить новые параметры режима. Это упростит и ускорит вывод на экран.

Режим NO_CLASH можно реализовать в большинстве клонов на FPGA, включая Speccy2010, ReVerSE, ZX-Evo.
Надо выбрать адреса портов и значения чисел для управления новым режимом.

denpopov

08.08.2015, 11:41

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

zx-kit

08.08.2015, 11:48

интересно - как?
забить лукапы с адресами?
Если экран начинается с $0000 - экономим на прибавлении адреса $4000 при вычислении адреса байта пикселов и атрибутов.

Если адресация линейная - нет деления на секторы - экономим время при вычислении адреса по координатам.

Адрес HL в области пикселов по координатам X,Y клетки можно определить так: H=X, L=Y*8 (сдвиг влево три раза).
Адрес HL в области атрибутов по координатам X,Y клетки можно определить так: H=X, L=Y+192 (OR $00C0).

Подробнее описано тут (http://zx-pk.ru/showpost.php?p=818806&postcount=314).

denpopov

08.08.2015, 12:03

Адрес HL в области пикселов по координатам X,Y клетки можно определить так: H=X, L=Y*8 (сдвиг влево три раза)

у кого плохо с устным счетом и сколько байт отводится на линию? 8?

zx-kit

08.08.2015, 12:08

у кого плохо с устным счетом и сколько байт отводится на линию? 8?
Если координаты заданы в клетках или знакоместах (8 * 8 точек), то L = Y * 8. Если координаты заданы в точках, то L = Y.

В горизонтальной линии также 32 байта. У них одинаковый L (младший байт адреса).

denpopov

08.08.2015, 12:49

так сколько видеопамять места займет?

Reobne

08.08.2015, 16:56

zst,
3. Адресация экрана - стандартная / новая (линейная)
Тут я вижу 2 варианта, что случится при переключении линейности:
1. Картинка на экране "замиксуется"
2. Процессор будет адресовать видеопамять по другому, а картинка сохранится.

Второй вариант, кажется, лучше. Он позволит проще ускорять программы, переделывая только значимые для оптимизации процедуры рисования, а мелочёвку оставлять как есть.

zx-kit

08.08.2015, 17:49

так сколько видеопамять места займет?
При линейной адресации вместе с атрибутами 8 килобайт из стандартной памяти, это если с адреса 4000. Если с адреса 0, то используется дополнительная память видеокарты сверх стандартных 48 или 128 К. Для режима NO_CLASH верхний слой тоже в дополнительной сверх памяти.

denpopov

08.08.2015, 18:12

При линейной адресации вместе с атрибутами 8 килобайт из стандартной памяти, это если с адреса 4000. Если с адреса 0, то используется дополнительная память видеокарты сверх стандартных 48 или 128 К. Для режима NO_CLASH верхний слой тоже в дополнительной сверх памяти.

Как у амстрада.

zx-kit

08.08.2015, 18:56

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

Режим NO_CLASH все-таки близок к стандартному. Не надо переучиваться - используется имеющийся опыт. Подходит для улучшения некоторых игр. Позволит устранить клешинг для простых игр типа ходилок. Ускорение для такого режима незначительное, не более 1.5 раза, зато не надо переделывать графику, а только заменить небольшую подпрограмму с помощью патча.

Блиттер подразумевает серьезные изменения в спрайтах. И его труднее сделать. А тут процессор все делает сам.

При линейной адресации экрана с адреса 0000:
Первый столбик байтов имеет адреса 0000, 0001, ... 00BF.
Второй столбик - 0100, 0101, ... 01BF.
Последний столбик - 1F00, 1F01, ... 1FBF.

При линейной адресации экрана с адреса 4000:
Первый столбик байтов имеет адреса 4000, 4001, ... 40BF.
Второй столбик - 4100, 4101, ... 41BF.
Последний столбик - 5F00, 5F01, ... 5FBF.

---------- Post added at 20:17 ---------- Previous post was at 20:14 ----------

zst,
Тут я вижу 2 варианта, что случится при переключении линейности:
1. Картинка на экране "замиксуется"
2. Процессор будет адресовать видеопамять по другому, а картинка сохранится.

Второй вариант, кажется, лучше. Он позволит проще ускорять программы, переделывая только значимые для оптимизации процедуры рисования, а мелочёвку оставлять как есть.

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

---------- Post added at 20:17 ---------- Previous post was at 20:17 ----------

Как у амстрада.
Не знал.

---------- Post added at 20:56 ---------- Previous post was at 20:17 ----------

По поводу новой адресации я тоже ничего не понял напишите маску расчета как для стандартного: bit (7-x2x1x0) addr 010y7 y6y2y1y0 : y5y4y3x7 x6x5x4x3
Для экрана с адреса 0000: bit (7-x2x1x0) addr 000x7x6x5x4x3 : y7y6y5y4y3y2y1y0
Для экрана с адреса 4000: bit (7-x2x1x0) addr 010x7x6x5x4x3 : y7y6y5y4y3y2y1y0

zx-kit

08.08.2015, 19:39

zst, собрал на U16 твой синхронизатор http://zx-pk.ru/showpost.php?p=821946&postcount=364, ну что сказать, круто! Считать-считает, только ничего на экране нет :(
Там же только синхроимпульсы. Они идут на монитор ? KGI и SGI надо использовать для обнуления и счета адресов точек. Для начала можно из этих адресов сформировать цветные полосы.

always @(posedge clk)
begin
if (sgi) // во время видимой части строки считают счетчики
begin
if (pix_cnt == 9) // если max для частоты точек 12.6 МHz
begin
pix_cnt <= 0;
addr_lo <= addr_lo + 1'b1;
end
else
pix_cnt <= pix_cnt + 1'b1;
end
else // во время строчного гасящего импулься счетчики обнуляются
begin
pix_cnt <= 0;
addr_lo <= 0;
end
end

Частота пикселов для режима 320х240 и 256х192

shurik-ua

08.08.2015, 20:07

ну что сказать, мегакруто!
а в чём разница между этим - http://zx-pk.ru/showpost.php?p=812088&postcount=41
и тем что zst написал )

shurik-ua

09.08.2015, 00:11

Если по теме то как-то развитие темы забуксовало - как-то всё не очень понятно что автор задумал - какие-то тайлы вперемешку с блиттером, процессор там что-то двигает в байте прежде чем отправлять в аксель - имхо это не правильно.
Насчёт того как правильно у меня такие соображения:
как тут уже неоднократно проскакивала мысль что нагородить можно кучу любых режимов, но скорее всего они не будут поддержаны - поэтому нужен максимально совместимый режим со стандартным спековским экраном, и вот как это примерно должно быть
1. у акселя своя память и он слушает шину - никаких ДМА и прочей ереси;
2. каждый экран я бы сделал для начала байт на точку с палитрой - итого 49152 байт на экран, самих экранов от 2 до 4;
3. например при записи байта по адресу между 0х4000 .. 0х57FF аксель должен успеть записать в свою видеопамять 8 байт а при записи по адреcам из области атрибутов успеть записать уже 64 байта - также нужно после ресета первые 16 цветов палитры сделать как стандартные цвета спека - это всё для что касается режима совместимости;
4. теперь что касается самих наворотов - проц должен общаться с акселем более высокоуровнево, вот например список основных команд:
0х01 - послать в память акселя спрайт номер такой-то с размером таким то - примерно как в GS - аксель уже сам сообразит где у себя в памяти его разместить
0х02 - отобразить спрайт номер тако-то по координатам таким-то.
0хFF - типо инит - очистить внутреннюю память спрайтов или чтото ещё )
остальные команды добавлять - там точку, линию или print_char аппаратный.

в общем как-то так - игры адаптировать под такое элементарно, или даже на бейсике писать новые )

а то что-то грустно совсем следить за этой темкой ))

zx-kit

09.08.2015, 08:07

Да, zst, а в чём разница?Разница в подходах, предпочтениях, характеристиках видеорежимов.

ЦЕЛИ РАЗРАБОТКИ НОВЫХ ВИДЕОРЕЖИМОВ

ZST Упростить и ускорить вывод 2D графики для улучшения старых игр и для увеличения количества и качества новых игр.
MVV: Наверно сделать более крутым ReVerSE для запуска UNIX.

ПРЕДПОЧТИТЕЛЬНЫЙ КОНСТРУКТИВ КОМПЬЮТЕРА НА БАЗЕ ZX SPECTRUM:

ZST Многоплатный конструктив, модульная конструкция с шиной ZX-BUS или ZST-BUS. Возможность реализации новых видеорежимов на большинстве компьютеров на базе FPGA и SDRAM, а также в виде видеокарты на отдельной плате.
MVV Миниатюрный компьютер типа ReVerSE с мощной FPGA, большой SDRAM, микросхемами часов, USB и сетевой карты.

ПРЕДСТАВЛЕНИЕ О ВИДЕОРЕЖИМАХ:

ZST Нужно разработать такую систему команд, чтобы передавать как можно меньше параметров. Работать на ассемблере, но на более высоком уровне. Например, чтобы напечатать спрайт, видеокарта должна получить номер спрайта и координаты для копирования, а адрес и размеры видеокарта должна взять сама из таблицы.
MVV ?.

ЧАСТОТА Z80:

ZST Для режимов с блиттером достаточно стандартной частоты 3.5 MHz. При этом процессор не будет часто требовать доступ к ОЗУ, что позволит предоставить больше квантов времени для работы сканера и блиттера.
MVV 42 MHz.

РАЗРАБОТКА ВИДЕОРЕЖИМА:

ZST Прорабатывает характеристи и команды новых видеорежимов.
MVV Более склонен к технической реализации, отлаживает режимы на FPGA.

НАЗВАНИЕ ВИДЕОРЕЖИМА / ВИДЕОКАРТЫ:

ZST Не любит сокращения. Назвал видеокарту "Meteor Graphics".
MVV Не нравится название "Meteor". Любит сокращения типа "GPU".

ВИДЕОЦАП VGA:

ZST Считает достаточным и технически реализуемым 5-битный ЦАП R-2R на каждый канал, что позволит изображать досточно качественно цвета на многих компьютерах на базе FPGA.
MVV Считает, что ЦАП должен быть 8-битным.

ВЫХОД VGA:

ZST Стандартный аналоговый VGA.
MVV Цифровой HDMI.

КОЛИЧЕСТВО БАЙТОВ НА ТОЧКУ:

ZST Для большинства режимов достаточно 1 байта на точку. Для некоторых 2 (в одно слово SDRAM уместится 3 * 5 = 15 битов цвета, что ускорит копирование).
MVV Считает, что желательно 3 байта на точку. В каждом байте по 8 бит цвета, всего 24 бита.

ПАЛИТРА:

ZST Предлагает для начала реализовать режимы без палитры, ограничившись количеством цветов 15, как в стандартных режимах ZX-Spectrum, или 64, как на плате ZX-Evo.
MVV Предлагает сразу начать с четырех палитр по 24 бита.

СПОСОБ ВЫВОДА НА ЭКРАН:

ZST Считает, что все режимы, новые и старые, должны готовить изображение в буфере экрана. Откуда потом просто выводить на VGA через буфер VGA на основе 24 восьмибитных регистров.
MVV Вывод через двухпортовую память и буфер FIFO.

РЕГЕНЕРАЦИЯ SDRAM:

ZST Достаточно 5 циклов регенерации во время строчного синхроимпульса VGA, что упростит реализацию доступа к буферу экрана при выводе на VGA.
MVV Считает, что циклы регенерации лучше проводить через равные промежутки времени.

СПОСОБЫ ПРОЕКТИРОВАНИЯ:

ZST Предпочитает начинать с простого, постепенно добавляя новые функции. Часто не отвечает на письма и любит делать перерывы в работе на обдумывание и отдых. Любит придумывать новые режимы, часто потом их модернизирует, что затрудняет следить за текущим состоянием разработки.
MVV Сначала составить спецификацию, план работ и т.п. Должна быть команда специалистов по железу и софту. Работает быстро, сделал уже много, любит отвечать на письма в реальном режиме, считает, что после обсуждения сообщения лучше удалить, что несколько затрудняет следить за нитью обсуждения в теме через некоторое время.

У них много разногласий, свои предпочтения, но их объединяет стремление что-то сделать для ZX Spectrum. В некоторых технических вопросах достигнуто соглашение:

Основная развертка экрана 640х480@60Hz с проектированием на нее остальных разрешений.
Частота FPGA и SDRAM 126 MHz
Пакетный режим работы SDRAM с длиной пакета 8.
Чтобы не изобретать велосипед можно добавлять новые режимы в TS-conf для ReVerSE и Speccy2010.

zx-kit

09.08.2015, 11:01

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

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

третье - никто так и не удосужился заглянуть на git и попробовать запустить то что уже было написано, zst принялся писать то, что уже отлажено и разрабатывалось не один месяц, а это всё время... Не ну, я не исключаю того, что у него возможно получится лучше с нуля, но у нас ведь не конкурс, а "вроде как" командная работа над одним проектом? Раз такая пьянка, то было-бы лучше распределить работу среди тех, у кого есть желание принять участие в проекте.

По текущей ссылке в твоей подписи трудно найти. Там даты старые. Если он там есть - я не нашел, если в другом месте - приведи прямую ссылку в подписи, чтобы каждый мог сразу туда попасть. Наверно лучше назвать типа новый видеорежим Meteor или GPU и две папки для ReVerSE и Speccy2010.

четвертое - на данный момент уже работает, отлажено и выложено на git:
1) контроллер SDRAM, работа в Burst 8 на частоте 126 МГц, wr=15 тактов (119,047619047619ns), rd=14 тактов (111,1111111111111ns), rfsh=9 тактов (71,42857142857143ns);
2) синхронизатор VGA
3) текстовый режим 80х30 (знакоместо 8х16), 16-цветов, аппаратный курсор.
4) zx-screen режим, INT=60Гц, на базе режима 640х480@60Hz
5) graphics режим 640х480@60Hz 24bpp, INT=60Гц
6) HDMI serializer (U16)
7) палитра
8) NextZ80@42MHz

Надо постепенно находить общий язык. Почему бы не сделать для нового режима стандартную частоту 3.5 MHz, убрать палитру и текстовый режим? Ты предпочитаешь для вывода на VGA двухпортовое ОЗУ вместо обычных регистров, отказался регенерацию сделать, как я предложил. Используешь ли ты буфер экрана как я предложил - я даже не знаю ? Вот и делаем каждый, как считает правильным. Тянем в разные стороны, как в басне "Лебедь, щука и рак". А воз и ныне там.

zx-kit

09.08.2015, 15:27

Лебедь, Щука и Рак

Когда в товарищах согласья нет,
На лад их дело не пойдёт,
И выйдет из него не дело, только мука.
Однажды Лебедь, Рак да Щука
Везти с поклажей воз взялись
И вместе трое все в него впряглись;
Из кожи лезут вон, а возу всё нет ходу!
Поклажа бы для них казалась и легка:
Да Лебедь рвётся в облака,
Рак пятится назад, а Щука тянет в воду.
Кто виноват из них, кто прав — судить не нам;
Да только воз и ныне там.

denpopov

09.08.2015, 15:29

Да только воз и ныне там
Золотые слова. Лучше спроектировать задуманное, чем доказывать, что ты не верблюд.

AndyD

10.08.2015, 00:01

учится вам и учится , глянь на сумму сборов
Не в обиду,человек не за баксы думает,за идею болеет,ну может компенсацию расходов на разработку.
А вы похоже зарабатывать не там решили,спектрум и его разновидности давно не коммерческий проект,вы талантливый,умный человек и найдете применение своим знаниям.Вы хотите zst завербовать чтоб панели делать на пару?
Для чего вы про солнечные панели ,видео поклали сюда,оно к видеорежимам не применить.

---------- Post added at 00:01 ---------- Previous post was at 00:01 ----------

учится вам и учится , глянь на сумму сборов
Не в обиду,человек не за баксы думает,за идею болеет,ну может компенсацию расходов на разработку.
А вы похоже зарабатывать не там решили,спектрум и его разновидности давно не коммерческий проект,вы талантливый,умный человек и найдете применение своим знаниям.Вы хотите zst завербовать чтоб панели делать на пару?
Для чего вы про солнечные панели ,видео поклали сюда,оно к видеорежимам не применить.

zx-kit

16.08.2015, 09:25

Новые режимы

Z80 только записывает данные в экранную область, остальные преобразования битов и закрашивание слоев выполняет видеокарта !

Режимы цвета без палитры:

1 бит на цвет точки:

ZX - 2 цвета на 64 точки (знакоместо размером 8х8 точек)
Это стандартный режим Спектрума. Работает в слое 0. Цвета точек зависят от атрибута, общего для 8 байтов пикселей. Бит FLASH в байте атрибута работает как аппаратное инвертирование цветов в знакоместе.

COLOR1C - 1 цвет на 8 точек + прозрачный
По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту: 0 - прозрачный, 1 - цветной. Номер цвета предварительно записывается в переменную color. 0 - прозрачный, 1-255 выбранный цвет. Данный режим предназначен для наложения одноцветного изображения поверх существующего. Например, для вывода текста, рисования линии по точкам, а также для стирания тайла/спрайта с текущего слоя, если color = 0.

COLOR2 - 2 цвета на 8 точек
По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту. Цвета задаются стандартным байтом атрибута, который записывается в переменную attr перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. Если установлен бит FLASH - цвета записываются с инверсией, но без аппаратного мигания.

COLOR2M - 2 цвета на 8 точек + маска
По соответствующему адресу в области пикселей нужно записать подряд 2 байта. Отличается от режима COLOR2 тем, что перед байтом данных записывается байт маски. Биты маски указывают - прозрачные точки или цветные. Цвета задаются стандартным байтом атрибута, который записывается в переменную attr перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. Если установлен бит FLASH - цвета записываются с инверсией, но без аппаратного мигания.

Режимы цвета с палитрой для рисования:

COLOR2P - 2 цвета на 8 точек
По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту. Цвета задаются палитрой, номер которой записывается в переменную pl2 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 2 цвета от 1 до 255 и прозрачный 0.

COLOR2MP - 2 цвета на 8 точек + маска
По соответствующему адресу в области пикселей нужно записать подряд 2 байта. Отличается от режима COLOR2P тем, что перед байтом данных записывается байт маски. Биты маски указывают - прозрачные точки или цветные. Цвета задаются палитрой, номер которой записывается в переменную pl2 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 2 цвета от 1 до 255 и прозрачный 0.

2 бита на цвет точки:

COLOR4P - 4 цвета на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 2 байта данных. На каждую из восьми точек приходится по 2 бита из разных байтов.
Цвета задаются палитрой, номер которой записывается в переменную pl4 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 4 цвета от 1 до 255 и прозрачный 0.

3 бита на цвет точки:

COLOR8P - 8 цветов на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 3 байта данных. На каждую из восьми точек приходится по 3 бита из разных байтов.
Цвета задаются палитрой, номер которой записывается в переменную pl8 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 8 цветов от 1 до 255 и прозрачный 0.

4 бита на цвет точки:

COLOR16P - 16 цветов на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 4 байта данных. На каждую из восьми точек приходится по 4 бита из разных байтов.
Цвета задаются палитрой, номер которой записывается в переменную pl16 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 16 цветов от 1 до 255 и прозрачный 0.

Предварительно палитры заполняются необходимыми цветами. Номер палитры выбирается перед рисованием очередных 8 точек, знакоместа, тайла/спрайта или по мере необходимости.

Alex Rider

18.08.2015, 01:29

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

торой слой и режимы с прозрачным цветом позволят рисовать спрайты без клешинга и затирания фона.
как карта понимает в какой слой производится рисование? Битик в порту? Получится ли за один проход по экрану рисовать в оба слоя сразу?
В первом слое тоже можно применить прозрачный цвет. Это позволит сделать фон любого цвета, а поверх нарисовать тайлы с произвольными контурами.
Опять же вопросы: для фона можно будет использовать палитру? Если да, то с какой глубиной цвета? Если да, то будет ли палитровый BORDER? Если да, то как все это будет управляться?

zx-kit

18.08.2015, 05:10

Мне лично эта идея по нраву. Только что вот вопросики есть:

как карта понимает в какой слой производится рисование? Битик в порту?
Нужно записать число 0 или 1 в параметр layer. Область параметров видеокарты будет располагаться в конце адресов ПЗУ. Это упростит настройку параметров. Можно использовать команды прямой адресации. Это быстрее, чем запись в порт и не требуется регистр BC для адресации порта.

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

Опять же вопросы: для фона можно будет использовать палитру? Если да, то с какой глубиной цвета?
Я предполагаю, что лучше дать возможность программисту для каждого слоя и фона использовать свои палитры VGA. А так как для фона палитра состоит из одного цвета, то может лучше сразу указать три байта в параметрах back_color_r, back_color_g, back_color_b. А VGA DAC изобразит на экране столько битов на цвет, сколько сможет.

Если да, то будет ли палитровый BORDER? Если да, то как все это будет управляться?
Указать три байта в параметрах border_color_r, border_color_g, border_color_b.

О модернизации игр.

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

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

Для начала тайлы можно печатать без изменений. Только перед печатью тайлов выбираем слой 0, записав 0 в параметр layer в области параметров видеокарты. Режим цвета выбираем стандартный, записав число COLOR2X64 в параметр color_mode. Далее, как обычно заполняем экран тайлами фона.

Перед печатью спрайтов выбираем слой 1, записав 1 в параметр layer. Режим цвета выбираем 2 цвета на 8 точек + маска, записав число COLOR2X8M в параметр color_mode.

Подпрограмму печати спрайта модернизируем. Выбираем цвет спрайта, записав соответствующее число в параметр palette_2c. Вычисляем адрес в области пикселов. Записываем по два байта по одному адресу: маску и пикселы. И так для всех 8 линий части спрайта размером 8х8 точек. Для следущих частей спрайта цвет уже выбирать не надо - только маски и пикселы для каждых 8 точек.

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

Для перехода из режима 2 цвета на 64 точки к режиму 2 цвета на 8 точек надо сделать так:
Допустим было так. В памяти тайлы фона хранятся в таком виде - 8 байтов пикселов + 1 байт атрибутов на клетку 8х8 точек. Подпрограмма печати тайла вычисляет адрес в области пикселов, копирует туда 8 байтов пикселов из области тайлов. Затем вычисляет адрес в области атрибутов и копирует туда атрибут тайла.

Надо немного переделать порядок операций при вывода тайлов. Перед печатью тайлов фона выбираем слой, в который будем печатать тайл - 0. Выбираем режим цвета - 2 цвета на 8 точек. Это указываем в блоке параметров видеокарты.

Адрес в области атрибутов теперь не требуется. Подпрограмма печати тайла копирует атрибут тайла в параметр palette_2c. Затем вычисляет адрес в области пикселов, копирует туда 8 байтов пикселов из области тайлов.

Немного подробнее про палитры:
Палитры первого уровня типа palette_2c преобразовывают 1-4 бита на точку в 8 битов. Это аппаратное представление номера цвета в буфере экрана. При выводе на монитор 8 битов можно будет преобразовать с помощью палитры VGA в 32K цветов или другое разрешение в зависимости от видеоцапа в конкретном компьютере. То есть в 0 и 1 слое могут быть любые 255 цветов из палитры 32К + прозрачный. Для начала палитры можно настроить так, чтобы они соответствовали стандартным цветам. Это упростит модернизацию старых игр. Числа, записываемые в palette_2c будут соответствуют атрибутам стандартного режима.

Для совместимости палитры первого уровня должны иметь номера 1-15 для стандартных 15 цветов + прозрачный с номером 0.

zx-kit

18.08.2015, 17:26

Можно уменьшить количество параметров:

layer - номер слоя, 0 - обычно для тайлов, 1 - обычно для спрайтов, возможно в будущем получится добавить 2 и 3.
color_mode - режим цвета, описывет количество цветов на тайл или спрайт (2, 3, 4, 7, 8, 15 или 16), наличие прозрачного и т.п.
attribute - цветовой атрибут, описывает соответствие для преобразовывания 1-4 бита на точку в 8 битов номера цвета, для режимов с 2 цветами аналогичен стандартному атрибуту.
back_color_r, back_color_g, back_color_b - составляющие RGB цвета заднего фона, его будет видно, если во всех слоях эта точка прозрачная.
border_color_r, border_color_g, border_color_b - составляющие RGB цвета бордера.

Включение блока параметров в область ПЗУ: двойной записью числа 1 в ячейку 3FFF.
Выключение блока параметров из области ПЗУ: одинарной записью числа 0 в ячейку 3FFF.

Для справки: у Денди тайлы обычно объединяются в блоки размером 16х16 точек, 3 цвета на блок + прозрачный, одна из 4-х палитр на блок.

Alex Rider

18.08.2015, 19:56

Включение блока параметров в область ПЗУ: двойной записью числа 1 в ячейку 3FFF.
Может все же хотя бы для включения/выключения задействуем один битик в каком-нибудь порту? Олсл остался открытым вопрос о детекте карты.

zx-kit

19.08.2015, 04:08

Может все же хотя бы для включения/выключения задействуем один битик в каком-нибудь порту? Олсл остался открытым вопрос о детекте карты.
Пока карта получается без чтения и портов, может порты ZX-EVO ? Можно будет вернуться к этому вопросу, когда все остальное разработаем и если карта будет изготовлена или добавлена поддержка в эмуляторе. Пока остается в игре в разделе настроек вручную выбирать режим графики: Стандартный или "Meteor Graphics Mode1".

Все остальное нормально ? Давайте вместе подумаем, какими командами включать этот и будущий режимы, чтобы оставалась совместимость. Как потом добавлять скроллинг, карту тайлов, блиттер, точки и линии, менять размер экрана. Отладить все мысленно. Потом подумать, как добавлять постепенно новые возможности в эмулятор. Кто это может сделать и какое описание для этого нужно ? Для начала режимы с 2,3,4 цветами на тайл/спрайт и стирание 8 точек.

Для загрузки первичных палитр в SDRAM будет окно в области ПЗУ размером 768 байт. Выбираем режим цвета, потом загружаем данные в соответствующую этому режиму палитру. Для режимов 15 и 16 цветов в каждой строке палитры по 16 цветов. Если строк 256 *16=4KB ! Надо еще подумать, как лучше сделать и сколько строк в каждой палитре достаточно для режимов 2, 4, 8, 16 цветов на спрайт...

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

Sayman

19.08.2015, 06:40

да сделайте уже нормальное 3д. чё вы к этим тайлам привязались???

zx-kit

20.08.2015, 04:54

да сделайте уже нормальное 3д. чё вы к этим тайлам привязались???
3D - это конечно интересно, но кто будет это все писать ? А предлагаемые мной режимы легко реализовать на FPGA. Никакой математики и глобальной переделки игр. Представьте, за много лет для Спектрума написали 1000 игр разного уровня цветности, скорости. Игрокам понравились из 1000 только 10. Они предпочтут перекрасить 10 популярных игр, у которых уже хорошая графика или сюжет. А 1001 игра, хоть и 3D может и не понравится. Поэтому для Спектрума нужен режим графики для плавного улучшения стандартных режимов и написания игр с похожей, но улучшенной графикой, но не 3D. А 3D игр итак полно. Вот ELITE недавно сделали в 3D ...

А тайлы - это основа большинства игр для Спектрума и Денди. Большие экраны и игровые пространства строятся из маленьких повторяющихся тайлов. Только у Спектрума - 2 цвета на тайл, а у Денди - 3 + прозрачный. Разница не очень большая, но какой эффект ! Так давайте лучше немного проапгрейдим компьютер 1982 года до количества цветов игровой приставки 1983 года.

Надо начать с простого. Лучше сразу в эмуляторе, чтобы все смогли попробовать. Есть у нас такие специалисты ? Даже просто второй слой и режим 2 цвета + маска позволят устранить клешинг атрибутов. А если реализовать 3 цвета + прозрачный и 4 цвета на тайл/спрайт, то этого будет достаточно для резкого повышения качества графики в играх. Дальнейшее увеличение количества цветов до 8 и 16 на тайл/спрайт может и не потребуется.

---------- Post added at 06:54 ---------- Previous post was at 06:46 ----------

Alex Rider, у тебя какие компьютеры ?

Sayman

20.08.2015, 06:49

3D - это конечно интересно, но кто будет это все писать ? А предлагаемые мной режимы легко реализовать на FPGA. Никакой математики и глобальной переделки игр. Представьте, за много лет для Спектрума написали 1000 игр разного уровня цветности, скорости. Игрокам понравились из 1000 только 10. Они предпочтут перекрасить 10 популярных игр, у которых уже хорошая графика или сюжет. А 1001 игра, хоть и 3D может и не понравится. Поэтому для Спектрума нужен режим графики для плавного улучшения стандартных режимов и написания игр с похожей, но улучшенной графикой, но не 3D. А 3D игр итак полно. Вот ELITE недавно сделали в 3D ...
и где на спектруме Элиту в 3Д выпустили? хотя СТОП - на спектруме она и так была в 3Д, только "проволочном" и жутко тормозном. А теперь представь эту элиту на спектруме в нормальном, текстурированном 3Д. Лично мне это уже интересно. В элиту не играл как раз из-за убогости графики и тормознутости, ну пожалуй, кривое управление. Есть ещё куча идей и проектов для реализации в 3д. Может оно и сложно реализовать в железе, но результат зато только положительный. Такую карту я был бы готов купить и за 3т.р. и за 5т.р., особенно если была бы возможность прикрутить к спринтеру.

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

Alex Rider

20.08.2015, 16:44

Alex Rider, у тебя какие компьютеры ?
Только PC. Реала нет.
нужно начать с того, что для переделки, скажем, того же зинапс, её нужно переломать. залезать в код и менять все процедуры вывода спрайтов.
Обсуждалось тут уже. Это проще, чем сделать новую игру. Потому что для этого нежен только кодер с прямыми руками, а для игры - куча других персонажей, которых мало кто совмещает в одном лице. Мало того, если уж разбирать игру, ее можно переделать сразу и под "Метеор", и под TSConf, и под экран Profi, и, боже упаси, под АТМ.

zx-kit

20.08.2015, 17:05

Графические переменные и их адреса:

3FFF enable_graphic_variables - включение блока графических переменных в область ПЗУ двойной записью числа 1, выключение записью числа 0.

Остальные переменные расположены в области ПЗУ по адресам 3F00 - 3FFE. Размер переменной 1 байт. Адрес уточняется при реализации.

color_mode - текущий режим цвета, определяет количество битов на точку, наличие байта маски и палитры
color - номер цвета для режима "1 цвет на байт"
attr - цветовой атрибут для режима "2 цвета на байт"
pl2 - номер палитры для рисования для режима "2 цвета на байт"
pl4 - номер палитры для рисования для режима "4 цвета на байт"
pl8 - номер палитры для рисования для режима "8 цветов на байт"
pl16 - номер палитры для рисования для режима "16 цветов на байт"

current_layer - номер слоя, на котором рисуем
layers - байт включенности слоев 0-7 (0 = off, 1 = on),
где слой 0 - стандартная графика ZX Spectrum-a, 1-7 - слои с расширенной графикой

layer0_pl - номер палитры отображения для слоя 0
layer1_pl - номер палитры отображения для слоя 1
layer2_pl - номер палитры отображения для слоя 2
layer3_pl - номер палитры отображения для слоя 3
layer4_pl - номер палитры отображения для слоя 4
layer5_pl - номер палитры отображения для слоя 5
layer6_pl - номер палитры отображения для слоя 6
layer7_pl - номер палитры отображения для слоя 7

Координаты спрайта

В некоторых старых играх спрайты выводятся не вертикальными столбиками из байтов, а горизонтальными линиями из байтов. При этом, для экономии места, спрайты иногда перед выводом сдвигают программно на нужное количество битов. Чтобы облегчить доработку таких игр добавляются следующие переменные, где 0-7 = номер байта в линии спрайта, A-D (или E-H) = байты 1-4 для соответствующего режима цвета:

A0, A1, A2, A3, A4, A5, A6, A7,
B0, B1, B2, B3, B4, B5, B6, B7,
C0, C1, C2, C3, C4, C5, C6, C7,
D0, D1, D2, D3, D4, D5, D6, D7,

или

E0, F0, G0, H0,
E1, F1, G1, H1,
E2, F2, G2, H2,
E3, F3, G3, H3,
E4, F4, G4, H4,
E5, F5, G5, H5,
E6, F6, G6, H6,
E7, F7, G7, H7,

Например, для вывода с маской в байты A0-A7 (или E0-E7) записываются 1-8 байтов маски, а в байты B0-B7 (или F0-F7)— соответствующее количество байтов спрайта.

Координаты на экране левого байта линии спрайта предварительно задаются следующими переменными:

x — мл. байт координаты X в пикселах
xh — cт. байт координаты X в пикселах
или
xc — координата X в знакоместах
xs — смещение по-горизонтали в знакоместе

y — мл. байт координаты Y в пикселах
yh — cт. байт координаты Y в пикселах
или
yc — координата Y в знакоместах
ys — смещение по-вертикали в знакоместе

Это позволяет рисовать спрайты на экране с расположением с точностью до пиксела.

back_color_r - составляющие RGB цвета заднего фона, его будет видно, если во всех слоях эта точка прозрачная.
back_color_g
back_color_b

border_color_r - составляющие RGB цвета бордера
border_color_g
border_color_b

mask_level - какие биты в маске означают прозрачность точки: 0 = нули, 1 = единицы
scr_addr - адресация расширенных экранов: 0 = стандартная с адреса 4000, 1 = линейная с адреса 0000

graphics_mode - режим графики, 0 = стандартный, 1 = Meteor Graphics Mode 1.

ZXMAK

20.08.2015, 17:45

zx-kit

20.08.2015, 17:49

идея простого расшмрения графики звучит неплохо, но расширение разрядности цвета несколькими записями по одному адресу будет проблемным - сложно определить что в данный момент времени нужно писать в ячейку - старший или младший байт.
Количество цветов можно увеличить за счет бита flash, он почти нигде не используется.
Не так уж и сложно. Допустим режим 3 цвета + прозрачный. Надо записывать по 2 байта. Запись первого байта в область пикселов - байт с 0 битами, запись следующего - байт с 1 битами номера цвета и т.д.

Для режима 2 цвета + маска. Надо записывать по 2 байта. Запись первого байта в область пикселов - маска, запись следующего - байт пикселов и т.д.

В чем сложность ?

После записи двух байтов в область пикселов получаем 8 точек с номерами цветов с помощью атрибута, записываем полученные 8 байтов в слой 1 (те точки, которые не прозрачные). При отображении нескольких слоев анализируем прозрачность точек.

ZXMAK

20.08.2015, 18:12

Не так уж и сложно. Допустим режим 3 цвета + прозрачный. Надо записывать по 2 байта. Запись первого байта в область пикселов - байт с 0 битами, запись следующего - байт с 1 битами номера цвета и т.д.

Для режима 2 цвета + маска. Надо записывать по 2 байта. Запись первого байта в область пикселов - маска, запись следующего - стандартный атрибут и т.д.

В чем сложность ?

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

Суть в чем - можно сделать виртуальный видеорежим, в котором видеопамяти как таковой не будет. Будут только команды акселератору. По аналогии с Open GL и Direct3D. Т.е. Z80 при инициализации загружает в видеопамять текстуры. А потом просто выдает набор команд с координатами спрайта и идентификатором текстуры. Таким образом мы получаем спрайты любого разрешения с любой битностью цвета, затрачивая на каждый всего десяток инструкций Z80.

Для векторной графики можно добавить команды отрисовки линий и треугольников. Одна команда будет рисовать wireframe, другая заливать фигуру нужным цветом, третья заливать текстурой с указанным id.

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

Это действительно для спектрума будет прорывом в графике. :cool_std:

Видеопамяти думаю 128 мегабайт вполне хватит для навороченых текстур. Десяток команд акселератора и Z80 может забыть про графику, независимо от разрядности цвета, разрешения и т.п. Т.е. у Z80 все освободившееся от рисования графики время остается на логику игры :smile:

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

zx-kit

20.08.2015, 18:17

Я тоже сначала так думал, но надо начать с простого. Сделать в эмуляторе режим 2 цвета + маска, переделать пару игр и посмотреть разницу. Alex_Rider модернизирует Saboteur2. Думаю ему несложно будет добавить этот режим в игру на экране настроек. Игра без клешинга должна выглядеть намного лучше.

ZXMAK

20.08.2015, 18:28

zx-kit

20.08.2015, 19:06

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

Примеры рисования 8 точек в различных режимах

Перед рисованием очередного тайла/спрайта нужно выбрать текущие цвета точек с помощью переменной attr. В режимах "2 цвета" и "2 цвета + маска" он точно такой же, как и атрибут в стандартной графике ZX Spectrum-а.

Пример рисования 8 точек тайла/спрайта с клешингом атрибутов (в стандартном режиме):
Прочитать байт с экрана
Прочитать байт маски тайла/спрайта
Сложить по определенному закону (AND)
Прочитать байт пикселов тайла/спрайта
Сложить по определенному закону (OR)
Записать в область пикселов экрана

Пример рисования 8 точек тайла/спрайта в режиме 2 цвета:
Прочитать байт пикселов тайла/спрайта
Записать в область пикселов экрана

Пример рисования 8 точек тайла/спрайта в режиме 2 цвета + маска:
Прочитать байт маски тайла/спрайта
Записать в область пикселов экрана
Прочитать байт пикселов тайла/спрайта
Записать в область пикселов экрана

Пример рисования 8 точек тайла/спрайта в режиме 3 цвета + прозрачный:
Прочитать первый байт тайла/спрайта
Записать в область пикселов экрана
Прочитать второй байт тайла/спрайта
Записать в область пикселов экрана

Пример рисования 8 точек тайла/спрайта в режиме 4 цвета:
Прочитать первый байт тайла/спрайта
Записать в область пикселов экрана
Прочитать второй байт тайла/спрайта
Записать в область пикселов экрана

Sayman

20.08.2015, 19:39

Z80 на режимы без клешинга будет тратить меньше времени, чем на режимы с клешингом.
так, минуточку. т.е. рисовать будет всё таки проц? а нафига тогда картока? вот на спринтере, я задал размер линии (максимум 256 байт), дал команду - рисовать. всё. я на экране получаю либо n байт горизонтально либо вертикально. я процом там ничего не рисую вообще. смысл иметь карточку которая сама ничего делать не умеет?
и что значит переделать проще, чем написать с нуля? когда я пишу, я знаю свою логику и логику будущей программы. когда я смотрю на дизасм чужой программы - а фиг его знает что тут автор хотел сказать. это гемор переделывать игру не имея исходников, а только дизасм. данные от кода нужно ещё отделять и т.д. гемора хватает. проще переписать или вообще с нуля сделать. если говорим про 3д, то даже проще, чем кажется.

Alex Rider

20.08.2015, 21:30

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

Raydac

20.08.2015, 23:04

Интересно, а кто напишет графический интерфейс пользователя (GUI) - систему средств для взаимодействия пользователя с устройством предоставляющую этому пользователю все системные объекты и функции в виде графических компонентов к примеру?
вариант "никто" устроит?

Alex Rider

20.08.2015, 23:41

ZXMAK

21.08.2015, 03:40

Режимы спроектированы так, что Z80 на режимы без клешинга будет тратить меньше времени

Я вот о чем говорю:

Пример рисования спрайта 256x256 с 32 битным цветом (260 КБ):

LD HL,0 ; координаты спрайта
LD DE,0 ; идентификатор спрайта
LD B,0 ; режим рисования ( например с учетом прозрачности)
LD B,B ; команда акселератору на отрисовку
; тут спрайт уже нарисован

zx-kit

21.08.2015, 04:51

Я вот о чем говорю:

Пример рисования спрайта 256x256 с 32 битным цветом (260 КБ):

LD HL,0 ; координаты спрайта
LD DE,0 ; идентификатор спрайта
LD B,0 ; режим рисования ( например с учетом прозрачности)
LD B,B ; команда акселератору на отрисовку
; тут спрайт уже нарисован

Да, это мы сделаем потом, так как это сделать труднее. Тут надо проработать систему подачи команд, чтобы Z80 не ждал. Короче - работы много. И в игре надо переделать спрайты.

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

Переделать всю игру и спрайты ведь труднее, чем процедуры вывода на экран.

Следующим шагом можно добавить в эмулятор линейную адресацию экрана - это немного упростит и ускорит расчет адресов на экране.

Помогите отладить эти режимы, если можете. Если мы это сделаем, то облегчим программистам модернизацию старых и написание новых игр. Да, это не 3D, но это будут игры в стиле Спектрума с улучшенной графикой.

ZXMAK

21.08.2015, 05:49

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

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

Reobne

21.08.2015, 07:37

процессор вообще не должен заниматься рисованием
Так уж исторически случилось, что в спектруме процессор занимается рисованием.
При улучшении старых программ, хочется получить хороший результат при минимуме усилий.
Писатели новых игр тоже не должны быть против. ИМХО, что если ты пишешь для спектрума, то должна быть версия, которая пойдёт на 48К либо на 128К. Иначе не канонично. Вот и получается, что есть версия под 128К и под "Метеор", и хочется, чтобы они были схожи и функционально и в коде и в ресурсах.

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

AndyD

21.08.2015, 11:38

процессор вообще не должен заниматься рисованием
Да ,только так,должен быть аксель в котором 3 устройства:
1 видео (...какой нибудь проц прицепленный к альтере чтоб считал всякие 3Д векторную графику)
2 аудио(GS программно совместимая)
3 внешний накопитель(HDD,SD,все стандарты уже есть)
общяя память и окно общего доступа к этой памяти для спека например 128кб.
На базе этой карты можно переделывать старые игры и делать новые,вообще не паханное поле получиться,при поддержке эмулятора так вообще можно отработать все без железа.

Alex Rider

21.08.2015, 12:40

я не об этом, а о том, что процессор вообще не должен заниматься рисованием
Опять же, это подходит в основном для новых игр. Во многих играх для ускорения отрисовка и логика перемешаны, и отломить отрисовку просто так не получится. А вот переделать отрисовку похожим способом вполне реально.

Думаю, надо выбрать игру-жертву эксперементов
Могу пошарить откомментированные исходники оригинального Саботера. Переделка под "Метеор" у меня пока не запланирована, есть много других задач. Но, в принципе, при поддержке в эмуляторе с нормальным отладчиком можно проверить, что переделка игры под "Метеор" - задача простая :)

AndyD

21.08.2015, 13:07

это уже всё есть, по крайней мере у меня на U16.
проблема в том,что,это не видео карта и не акселератор к спектруму,а другой ПК.
Если я правильно понял,нужно сделать девайс для любого спека с улучшенной графикой максимально совместимой с родной для доработки имеющихся игр,а новые режимы это дополнительные режимы - на любителя сделать что то новое,что в принципе и сделал ТСлаб для пентевы.

Valen

21.08.2015, 13:32

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

И я о том же, с этого и начинали.
А потом автор сполз на клэшинг.

Как по мне если и возится с клэшингом, то уже после работающего блиттера.
С блиттером можно уже карту производить и продавать, паралельно копаясь с тем же клешингом.

Djoni

21.08.2015, 14:45

Может было бы логично оснастить видеокарту своим процессором Z84C0020FEC 20MHz или T80 (софтядро Z80) чрез на бортный контроллер SD Card
по команде основного процессора видеокарта будет подгружать видео данные разгружая основной процессор, ну и православный режим для Z80
4 окна проецирования памяти включая пзу.

Djoni

21.08.2015, 15:25

Уже оснащено, двумя софт-ядрами NextZ80@42МГц. Тут советовали MIPS, можно и MIPS, или OpenRISC 1200 (https://en.wikipedia.org/wiki/OpenRISC_1200). Если потянете :)
Или вот ссылка (http://www.nallatech.com/solutions/fpga-accelerated-computing/opencl-fpga-cards/).

Хорошо, а возможен захват шины основного Z80 по сигналу BUSRQ
с видеокарты работающей на софт-ядре для получения доступа к периферии компьютера ?

Djoni

21.08.2015, 15:56

Да возможно.

Или вот ссылка (http://www.nallatech.com/solutions/fpga-accelerated-computing/opencl-fpga-cards/).
Вот на выбор, что можно попробовать:
Real Time Dynamic 3D Graphics Processor (http://www.academia.edu/4405487/A_Real_Time_Dynamic_3D_Graphics_Processor_Using_FP GA)
Sprite graphics accelerator (http://andybrown.me.uk/2014/06/01/ase/)
Open-Source GPU (http://www.phoronix.com/scan.php?page=news_item&px=MTExMzE)
ORSoC Graphics Accelerator (http://opencores.org/project,orsoc_graphics_accelerator)

Это уж чересчур круто :)

Меня бы для начала устроила поддержка видео режимов которые получили распространения на спектрум совместимых компьютерах.

16col (http://speccy.info/16col) Pentagon 1024SL 2.x (http://speccy.info/Pentagon-1024SL), PentEvo,
512x192 Байт-01 (http://zxbyte.ru/?id=36),Timex_Computer_2048 (http://speccy.info/Timex_Computer_2048),Pentagon 1024SL 2.x
512x240 Profi (http://zxpress.ru/article.php?id=1931)
320x200, 16 цветов на точку ATM ,Pentagon 1024SL 2.x, PentEvo.
640x200 hardware multicolor ATM
Текстовый режим 80x25 по стандарту ATM.

С правильным диспетчером памяти да процессором NextZ80@42МГц :v2_dizzy_roll:

Reobne

21.08.2015, 16:17

Могу пошарить откомментированные исходники оригинального Саботера
Это как-то не совсем спортивно, уже все исходники...
Да и игра не типичная.
Зинапс \ Р-тайп \ ексолон ... - и так уже сильно красочные игры.
Джо Бладе \ Рик Дангероус \ Свитч Бладе \ Штормлорд ... - клоны на других платформах.

Может кто-то имеет любимую игру, которую он хотел-бы видеть обновлённой.

А может что-то из чуреровских взять, или Дизи какую-нибудь?

AndyD

21.08.2015, 16:28

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

Может кто-то имеет любимую игру, которую он хотел-бы видеть обновлённой.Черный Ворон в цвете просто супер.

solegstar

21.08.2015, 17:28

Черный Ворон в цвете просто супер.
warcraft что-ли? :)

AndyD

21.08.2015, 18:18

warcraft что-ли?
Нет,Черный ворон от Медноногова.Я в варкрафт не играл.

zx-kit

23.08.2015, 14:04

Вот как можно было бы перекрасить ходилки. На каждой картинке слева - оригинальные цвета спрайта, справа - вариант раскраски для нового режима.

http://s009.radikal.ru/i309/1508/a4/369684e333a0t.jpg (http://s009.radikal.ru/i309/1508/a4/369684e333a0.png) http://s001.radikal.ru/i195/1508/f7/7163ef858f4ct.jpg (http://s001.radikal.ru/i195/1508/f7/7163ef858f4c.png)

http://s018.radikal.ru/i516/1508/29/96dd26ec4a76t.jpg (http://s018.radikal.ru/i516/1508/29/96dd26ec4a76.png) http://s017.radikal.ru/i403/1508/8c/470ba5e65df8t.jpg (http://s017.radikal.ru/i403/1508/8c/470ba5e65df8.png)

http://s013.radikal.ru/i322/1508/e3/81231f94b718t.jpg (http://s013.radikal.ru/i322/1508/e3/81231f94b718.png) http://s019.radikal.ru/i617/1508/88/9fc508da9078t.jpg (http://s019.radikal.ru/i617/1508/88/9fc508da9078.png)

В таких играх у спрайтов есть маска. Спрайты остаются те же. Для каждого байта спрайта надо выводить маску, затем спрайт по одному и тому же адресу. Это проще, чем переделывать всю игру. Конечно отладку лучше вести на игре, для которой ясно, где что надо поменять. Лучше на современной игре, для которой можно выпустить обновленную версию.

Reobne

23.08.2015, 14:56

zx-kit

23.08.2015, 17:33

Чёрный ворон. Тяжела игра, на 2 дисках.Нашёл, что есть авторские исходники.
Если только в самом окне геймплея людей сделать одним цветом, кунгов другим - как задача минимум.
Уже даже все здания раскрасить - замучится, не говоря про заставки и анимацию...

Да, черно-белую игру трудно перекрасить.

Три недели в раю. Есть версия на CPC. (картинка справа)
Клешинга нет, но разрешения поменьше. Есть смысл делать под "метеор" ?
Опять-же просто сделать, чтобы Глав.Герой ходил и не клешинговал - это одно, а всю графику переделать - это не для одного человека работёнка.

Для Спектрума игра красивее. Да, для начала достаточно ГГ рисовать без клешинга.

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

Надо начать с простого. Описание режима, адреса переменных есть. Нужна поддержка в эмуляторе. Тогда желающие смогли бы начать эксперименты.

Саботёр. ИМХО хорош как есть. Оригинальный основной чёрный цвет само по себе решение вопроса клешинга. А что контура разноцветные, так и снукеристы когда над столом наклоняются у них лица зеленеют, но никто-же не замечает. :)
Да, тут клешинг почти не виден. Зато это свежая доработка, можно не ней провести эксперимент. Если будет поддержка в эмуляторе, наверно, Alex_Rider мог бы проверить работоспособность на каком-нибудь экране. Это проще, чем дизассемблировать заново.

Потом, когда работоспособность будет проверена, может напишут новую игру под "Meteor Graphics".

---------- Post added at 19:33 ---------- Previous post was at 18:45 ----------

На приведенных выше картинках показан эффект применения режима 2 цвета на спрайт + маска. При этом спрайты остаются такими же. В новых играх можно применить режим 3 цвета на спрайт + прозрачный. Спрайты, конечно, уже будут новыми. Зато 3 цвета позволят изобразить деталь одежды или лицо другим цветом. Ну и можно будет накладывать несколько спрайтов при движении. При трех цветах спрайты будут выглядеть более объемными, чем при двух. Кстати, в каждом байте спрайта могут быть разные три цвета, если при печати спрайта менять и байт атрибута. Например, для головы одни 3 цвета, для туловища - другие, для ног - другие.

Reobne

23.08.2015, 18:19

Three Weeks In Paradise remake (http://zx-pk.ru/showthread.php?t=11473) ещё есть.
http://www.latinfo.lv/img/games/pc/3weeks2/3.png
Что на порядок обесценивает полную переработку графики под "метеор". :(
Но просто убрать клешинг ГГ вроде смысл есть. Пусть не для того чтобы осчастливить кого-то, а просто для отработки технологии.

ZXMAK

23.08.2015, 20:19

Reobne

24.08.2015, 03:38

ZXMAK,
Такого уровня графика вполне по зубам спектруму, если спрайтовый акселератор добавить
Спрайтовый акселератор.
А ещё нужен большой носитель данных. SD карта или CD-диск.
Потом нужно будет перелопатить игру, чтобы использовала акселератор.
Графику переконвертить с PC ремейка.
И в результате всех усилий мы получим то... , что уже давно было доступно на PC.

zx-kit

24.08.2015, 05:38

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

Перечитал вот это предложение. Теперь я понял, как надо делать. Надо обеспечить программисту выбор:

использовать только стандартную графику
дополнительно к стандартной графике изображать ГГ без клешинга, используя дополнительный слой и режим 2 цвета + маска
переделать спрайты для 3 цветов + прозрачный
дополнительно к стандартной графике изображать ГГ с помощью блиттера и спрайтов 8 бит на точку
все изображать с помощью блиттера и спрайтов 8 бит на точку.

Эмулятор или FPGA с частотой развертки TV читает из слоя номер 0 стандартные пикселы и атрибуты и вычисляет номера цветов 8 точек. Если режим новый, то читает ГОТОВЫЕ 8 точек из слоя 0. Затем читает ГОТОВЫЕ цвета 8 точек из слоя 1. Складывает их с учетом прозрачного цвета и записывет 8 номеров цвета в буфер экрана. Когда надо вывести на экран изображение эмулятор или FPGA читает ГОТОВУЮ картинку из буфера экрана и выводит на монитор с частотой 60 Гц.

Слой 0 можно выбрать со стандартной графикой или другой, подходящий для конкретной задачи режим графики. Имея слой 1 мы сможем продолжить работу над блиттером, который ускорит копирование спрайтов в эту же область 256х192 по 1 байту на точку. Так мы постепенно сможем добавлять новые возможности.

Дополнительный слой номер 1 для режимов 2-4 цвета на спрайт - это область памяти размером 256х192 точек. Цвет каждой точки определяется одним байтом. Поэтому мы можем накладывать сверху спрайты программным способом, используя прозрачный цвет. Видеокарта уже начинает выполнять часть работы за Z80. По двум байтам данных и атрибуту вычисляет цвета восьми точек. Далее, если точка не прозрачная, номер цвета записывается в слой номер 1.

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

Lethargeek

24.08.2015, 08:18

Все мы знаем, как устроен стандартный режим графики. Видеокарта дожна взять байт пикселов, байт атрибутов и преобразовать в 8 точек определенного цвета. Адреса мы тоже знаем где. Не важно, дублируется ли память в видеокарте или основную память компьютера вообще вытащили. Картинка должна получиться одинаковая.
Да с чего же она это вот прям ДОЛЖНА? Не ЮЛА, небось. Пусть как хочет, так и делает одинаковую.

Естественно проще разместить память в видеокарте. И она будет общая для Z80 и FPGA.
Это как - и код оттуда же выполнять?? :v2_conf2:

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

Так я почти тоже самое и предлагаю. У нас например буфер экрана 320х240. Мы туда можем записать стандартную графику 192х256 с бордюрными эффектами, а потом вывести с нужной частотой развертки.
И при чём тут видеорежимы и совместимость?! "вывести с нужной частотой развертки" - это дело кадрового конвертера, какой может быть вообще отдельным девайсом и никак не управляться видеокартой, а работать тупо по сигналу видеовыхода. Хотя может быть и отдельным блоком видеокарты - не суть важно, для софта не должно быть разницы никакой. И не путай разные буфера (для конвертера, кстати, нужно целых ТРИ своих отдельных буфера, вроде как)

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

---------- Post added at 08:14 ---------- Previous post was at 08:08 ----------

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

---------- Post added at 08:18 ---------- Previous post was at 08:14 ----------

Перечитал вот это предложение. Теперь я понял, как надо делать. Надо обеспечить программисту выбор:
использовать только стандартную графику
дополнительно к стандартной графике изображать ГГ без клешинга, используя дополнительный слой и режим 2 цвета + маска
переделать спрайты для 3 цветов + прозрачный
дополнительно к стандартной графике изображать ГГ с помощью блиттера и спрайтов 8 бит на точку
все изображать с помощью блиттера и спрайтов 8 бит на точку.
Нет, не так - даже это слишком жёсткие варианты. И конечно же, не надо разных слоёв, это нерациональный расход памяти и пропускной способности шины карты. Лучше - однослойный тупой битмап, но с хитрым и ускоренным доступом. Эх, нету времени сейчас подробно расписывать, и не знаю, когда снова буду на форуме :(

zx-kit

25.08.2015, 05:04

Слои графики в видеокарте "Meteor Graphics"

Во многих играх есть неподвижный или медленно меняющийся фон и несколько движущихся объектов. Разделение графики в видеокарте "Meteor Graphics" на слои упрощает и ускоряет построение изображений в играх.

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

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

При выводе на телевизор/монитор несколько слоев складываются с учетом прозрачного цвета. Если в слое с большим номером точка прозрачная, то сквозь нее будет видна точка со слоя с меньшим номером. Если во всех слоях точки прозрачные, то сквозь них виден цвет back_color.

Преобразование данных в номера 8 точек для различных режимов (эту работу выполняет видеокарта)

В стандартном режиме цвета ZX SPECTRUMа цвета 8 точек, видимых на экране, зависят от байта пикселов, байта атрибутов и сигнала FLASH, который предназначен для мигания курсора. При изменении любого из трех могут измениться цвета 8 точек. Поэтому стандартный режим нельзя сразу преобразовать в 8 номеров цветов. Преобразование происходит синхронно с частотой кадров телевизора, равной 50 Гц. При этом полученные 8 номеров цветов используются вместо цветов из слоя 0.

В дополнительный режимах цвета данные о номерах цветов 8 точек вычисляются сразу после записи одного или нескольких байтов в область пикселов экрана. Для вычисления используется параметр attribute. Полученные 8 байтов записываются в соответствующий слой.

Alex Rider

25.08.2015, 22:43

zx-kit

26.08.2015, 05:14

Что-то подумал я про переделку Саботера 2 под Метеор, и грустно мне стало... Лучшее, что я смогу там сделать - это "неСпектрумовское" синее небо в слое фона и перекрашенные тайлы переднего фона. А почему? А потому что в Саботере 5 слоев графики, из них 4 с маской. Вот так вот :(
Для начала не обязательно менять цвета - можно сначала устранить клешинг с одновременным ускорением вывода спрайтов. А как, в двух словах, эти 5 слоев графики выводятся на экран в игре?

Для их вывода подходит новый режим цвета: 2 цвета + маска. Этот режим позволит просто накидать 4-5 слоев графики в слой 1 видеокарты. Маска задает контуры/форму спрайта. Если точка вне контура, то считается прозрачной. Прозрачные точки не записываются в область графики 1 слоя. Остается тот цвет точки, который был записан до этого. В результате получим наложение нескольких слоев без клешинга. А в слое 0 можно расположить тайлы фона, которые рисуются в стандартном режиме цвета.

Alex Rider

26.08.2015, 22:09

А как, в двух словах, эти 5 слоев графики выводятся на экран в игре?
В буфер знакоместа копируется тайл фона с атрибутом. На него накладываются по маске по очереди тайлы ГГ, Охранника-1, Охранника-2, переднего плана. INK и PAPER знакоместа определяются хитрой логикой (каждый слой начиная с ГГ и заканчивая передним планом могут поменять атрибут в буфере). Потом буфер знакоместа копируется в экранную область.
А с Метеором мне непонятно как в один слой его спрайтов вывести 4 слоя (ГГ, охранники, передний фон), да еще и с маской.

Valen

26.08.2015, 22:32

с Метеором мне непонятно как в один слой его спрайтов вывести 4 слоя (ГГ, охранники, передний фон), да еще и с маской

А вот если бы менять игру, под аппаратные спрайты, было бы проще?

Alex Rider

26.08.2015, 22:55

А вот если бы менять игру, под аппаратные спрайты, было бы проще?
Для начала это хотя бы видится реальным. У меня в планах есть переделка игры под TS-Conf, я немного думал на эту тему. Там тоже гемора будет прилично, но в целом это сделать можно.
Для Саботера идеально было бы простое наличие 5 тайловых слоев - тогда переделки минимум. Но Саботер - не единственный тип игр с точки зрения графического движка.

zx-kit

27.08.2015, 05:58

В буфер знакоместа копируется тайл фона с атрибутом. На него накладываются по маске по очереди тайлы ГГ, Охранника-1, Охранника-2, переднего плана. INK и PAPER знакоместа определяются хитрой логикой (каждый слой начиная с ГГ и заканчивая передним планом могут поменять атрибут в буфере). Потом буфер знакоместа копируется в экранную область.
А с Метеором мне непонятно как в один слой его спрайтов вывести 4 слоя (ГГ, охранники, передний фон), да еще и с маской.
С Метеором все намного проще. Тайлы фона, ГГ, Охранника-1, Охранника-2 и переднего плана можно записывать сразу в слой 0 или 1.

Для каждого объекта:

1. Записать цвета INK и PAPER объекта в переменную attrubute.
2. В HL записать адрес верхнего байта в знакоместе в экранной области.
3. Выполнить восемь циклов:

загрузить в A байт пикселов
записать A по адресу в HL
загрузить в A байт маски
записать A по адресу в HL
вычислить следующие адреса пикселов и маски в области тайлов
перейти к следующему адресу пикселов на экране (INC H).

И все. Видеокарта сама наложит по маске 5 слоев графики Saboteur2 Meteor version ! :v2_dizzy_roll:

---------- Post added at 07:58 ---------- Previous post was at 06:45 ----------

Можно подумать и об увеличении слоев. Слой 0 для стандартной графики и слои 1-5 для дополнительной.
3F00 layer0 - режим слоя 0: 0 = off, 1 = on (стандартный режим ZX Spectrum-a)
3F01 layer1 - режим слоя 1: 0 = off, 1 = on
3F02 layer2 - режим слоя 2: 0 = off, 1 = on
3F03 layer3 - режим слоя 3: 0 = off, 1 = on
3F04 layer4 - режим слоя 4: 0 = off, 1 = on
3F05 layer5 - режим слоя 5: 0 = off, 1 = on

zx-kit

28.08.2015, 05:47

Наличие нескольких слоев, которые можно включать/выключать, облегчит написание новых игр. Допустим, в слое 1 и 4 у нас два слоя фона. Оба включены, поэтому видны. А слои 2 и 3 можно использовать для спрайтов. При этом один из них включен (отображается на экране). А другой - выключен (невидимый), на нем можно рисовать спрайты для следующего кадра игры. По сигналу INT можно поменять состояние включения этих двух слоев на противоположное. При этом к тем же слоям фона подключится слой спрайтов с новым изображением. А на другом слое старые спрайты стираем и неспешно, в течение целого кадра рисуем новые.

Alex Rider

28.08.2015, 14:13

zx-kit

28.08.2015, 15:16

А, если еще и слоев сделать сколько хочешь, было бы здорово. Тогда бы получился Саботер без сечения лучом. Для этого надо 8 слоев: фон, передний план (статичные) и по три слоя на ГГ и охранников: отображаемые и отрисовываемые.
По отдельному слою на каждый объект это неоправданно сложно. А вдруг напишут Саботер 3, где будет 3 охранника. Можно ведь все движущиеся объекты нарисовать последовательно на одном слое. Маска нам поможет.

Alex Rider

28.08.2015, 16:22

Можно ведь все движущиеся объекты нарисовать последовательно на одном слое.
А как это выглядит технически? Вот я вывел фон на слой 0, включил слой 1, и пишу в него пары "маска-изображение" для ГГ и обоих охранников, а карта сама раберется как их на слое смешать чтобы каша не получилась?

zx-kit

28.08.2015, 16:39

А как это выглядит технически? Вот я вывел фон на слой 0, включил слой 1, и пишу в него пары "маска-изображение" для ГГ и обоих охранников, а карта сама раберется как их на слое смешать чтобы каша не получилась?
Представьте, что все объекты вырезаны из тонкой цветной бумаги и вы их по-очереди накладываете на прозрачную пленку. Будет виден тот объект, который положен последним. А у ранних - только части, которые не загорожены последними. Также и в видеокарте надо рисовать объекты по-очереди. Сначала дальние, затем ближние. Можно рисовать сразу объект целиком или по знакоместу от каждого объекта. Главное соблюдать порядок закраски. А видеокарта по маске перекрашивает точки слоя цветами очередного объекта. Маска автоматически определяет, закрашивать точку в слое или нет.

Eagle

28.08.2015, 18:15

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

zx-kit

28.08.2015, 19:48

zst, для чего такие извраты с последовательным наложением? Не судьба организовать аппаратные слои которые уже будут иметь свой приоритет перекрывания?
Решили сделать пять аппаратных слоев графики. В каждом слое объекты также смогут накладываться. Дальше на усмотрение программиста, как лучше использовать эти возможности. Потом в этих же слоях попробуем добавить и блиттер.

zx-kit

29.08.2015, 04:24

А, если еще и слоев сделать сколько хочешь, было бы здорово. Тогда бы получился Саботер без сечения лучом. Для этого надо 8 слоев: фон, передний план (статичные) и по три слоя на ГГ и охранников: отображаемые и отрисовываемые.
Можно и 8 слоев, если не все сразу будут включены.

Теперь надо посчитать объем памяти на 8 слоев. Если каждый слой будет размером максимум 320х240 точек и по одному байту на точку, один слой займет 512 х 256 = 131072 байта = 128 KB. На 8 слоев надо 8 * 128 KB = 1024 KB = 1 MB. Хорошо. У нас базовый размер SDRAM 8 MB.

shurik-ua

29.08.2015, 05:22

1 MB. Хорошо. У нас базовый размер SDRAM 8 MB.
тут скорее ограничение на кол-во слоёв не объём а пропускная способность памяти.

zx-kit

29.08.2015, 06:22

Слои

Разделение графики в видеокарте "Meteor Graphics" на слои позволит упростить и ускорить построение изображений в новых играх, а также устранить клешинг атрибутов. Также слои облегчат модернизацию своих старых игр путем постепенного перехода от стандартной графики ZX Spectrum-а к новым возможностям расширенной графики.

Основной слой 0 предназначен для стандартного экрана ZX Spectrum-а, дополнительные слои 1-7 - для расширенной графики. Каждый слой может быть включен или выключен для отображения на экране. Выключенные слои можно использовать для построения изображений для следующего кадра игры. А по прерыванию программы от сигнала INT можно включать и выключать соответствующие слои.

При выводе на телевизор/монитор включенные слои накладываются с учетом прозрачного цвета. Если в слое с большим номером точка прозрачная, то сквозь нее будет видна точка со слоя с меньшим номером. Если во всех слоях точки прозрачные, то сквозь них будет виден цвет back_color.

Наложение объектов в дополнительных слоях

Графические объекты могут накладываться на текущий слой с учетом прозрачного цвета.

Представьте, что все объекты вырезаны из тонкой цветной бумаги и их по-очереди накладывают на прозрачную пленку. Будет виден тот объект, который наложен последним. А у первых будут видны только части, которые не загорожены последними объектами.

Также и в видеокарте надо рисовать объекты в текущем слое по-очереди. Сначала дальние, затем ближние. Можно рисовать сразу объект целиком или по знакоместу от каждого объекта. Главное соблюдать порядок закраски. А видеокарта перекрашивает точки текущего слоя цветами очередного объекта. Маска или прозрачный цвет в спрайтах показывает, закрашивать точку в слое или нет.

Alex Rider

29.08.2015, 17:13

shurik-ua

29.08.2015, 19:45

вот интересный проект - очень похоже на то что пытается сделать автор

http://board.kolibrios.org/viewtopic.php?f=41&t=2868
http://habrahabr.ru/post/179839/

zx-kit

30.08.2015, 05:21

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

Статические слои можно нарисовать однократно, а потом не трогать. Если для движущихся объектов используются два слоя по-очереди, то надо с помощью переменной current_layer выбирать слой, в котором рисовать. Обычно это делают по сигналу INT. Сначала распределить слои и подобрать удобные режимы цвета для каждого слоя. Допустим для спрайтов выбраны два слоя 2 и 3. Один из них включаем, другой выключаем.

layer0 = 1 ; задний фон (стены) включен, режим "стандартной графики ZX Spectrum-a"
layer8 = 1 ; передний фон (ящики) включен, режим "2 цвета на тайл/спрайт + маска"

layer2 = 1 ; слой спрайтов включен (отображается текущий кадр), режим "2 цвета на тайл/спрайт + маска"
layer3 = 0 ; слой спрайтов выключен (на нем рисуется очередной кадр), режим "2 цвета на тайл/спрайт + маска"
current_layer = 3

Каждый кадр после INT меняем состояние включения 2 и 3 слоев и рисуем следующий кадр на том слое, который выключим:

layer2 = 0 ; слой спрайтов выключен (на нем рисуется очередной кадр)
layer3 = 1 ; слой спрайтов включен (отображается текущий кадр)
current_layer = 2

Перед рисование новых спрайтов стереть старые в режиме цвета color_mode = COLOR1C, attribute = 0.

А еще все же интересно как надо будет переделывать графику. Я опять на примере Саботера (потому что других игр пока не знаю).
В Саботере фактически 4 способа хранения графики:
1. Задний фон - тайлы со стандартными атрибутами (9 байт) - выводятся "как есть", но их атрибуты могут быть запросто изменены (комната бессмертия - стены и вещество в ящике, искры на ограде). В почти таком же формате хранятся изображения предметов в ящиках и в руках ГГ.

1 вариант. Используем слой 0 и рисуем в стандартном режиме ZX Spectrum-a:
current_layer = 0. Дальше записываем атрибут в область атрибутов экрана и 8 байтов пикселов в область пикселов экрана.

2 вариант. Используем слой 1 и рисуем в режиме графики "2 цвета на тайл/спрайт":
current_layer = 1, color_mode = COLOR2. Дальше записываем атрибут в переменную attribute и 8 байтов пикселов в область пикселов экрана.

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

Используем слой 2 или 3 и рисуем в режиме графики "2 цвета на тайл/спрайт + маска":
current_layer = 2 или 3, color_mode = COLOR2M. Раз цвета могут меняться, записываем этот цвет в переменную attribute и 16 байтов пикселов в область пикселов экрана, парами байт пикселов, байт маски.

3. Спрайты переднего фона - имеют растр, маску и атрибуты (17 байт), тоже могут быть перекрашены (консоль, например, когда на ее ГГ попадает).

Используем слой 8 и рисуем в режиме графики "2 цвета на тайл/спрайт + маска":
current_layer = 8, color_mode = COLOR2M. Раз цвета могут меняться, записываем этот цвет в переменную attribute и 16 байтов пикселов в область пикселов экрана, парами байт пикселов, байт маски.

4. Фонт - стандартный формат по 8 байт на символ без атрибутов, раскрашивается при выводе (может быть отрисован как тайлы переднего слоя).

Используем слой 8 и рисуем в режиме графики "2 цвета на тайл/спрайт":
current_layer = 8, color_mode = COLOR2. Раз цвета могут меняться, записываем этот цвет в переменную attribute и 8 байтов пикселов в область пикселов экрана.

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

Вроде расписал. Перед рисованием очередного тайла/спрайта нужно выбрать текущие цвета точек с помощью переменной attribute. В режимах "2 цвета" и "2 цвета + маска" он точно такой же, как и атрибут в стандартной графике ZX Spectrum-а. Цвет можно менять перед рисованием каждого знакоместа или только тогда, когда надо поменять цвет. То есть при отображении объектов одного цвета, например, всех ящиков или текста можно один раз выбрать цвет, а затем рисовать только пикселы ящиков или текста.

Если требуются еще объяснения для полной ясности деталей новых видеорежимов - спрашивай.

В первый пост добавил ссылки на текущее описание параметров видеокарты "Meteor Graphics".

zx-kit

30.08.2015, 09:08

COLOR1C - 1 цвет на 8 точек + прозрачный
Данный режим может использоваться для наложения одноцветного изображения поверх существующего. Например, для вывода текста, стирания тайла/спрайта, рисования линий по точкам. По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту: 0 - прозрачный, 1 - цветной. Номер цвета задается переменной attribute. 0 - прозрачный, 1-255 выбранный цвет.

Alex Rider

31.08.2015, 16:12

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

Перед рисование новых спрайтов стереть старые в режиме цвета color_mode = COLOR1C, attribute = 0.
То есть, получается, что карточка всегда рисует то, что в данный момент записано в слой, а, чтобы начать рисовать заново, надо стереть то, что там уже нарисовано? Мне кажется, не самое удачное решение... Получается, что мы экономим такты только на вывод маски, зато тратим их на стирание - это плохо. А нельзя сделать команду "стереть весь слой"?

zx-kit

31.08.2015, 19:01

То есть, получается, что карточка всегда рисует то, что в данный момент записано в слой, а, чтобы начать рисовать заново, надо стереть то, что там уже нарисовано? Мне кажется, не самое удачное решение... Получается, что мы экономим такты только на вывод маски, зато тратим их на стирание - это плохо. А нельзя сделать команду "стереть весь слой"?
Команду "стереть весь слой" можно сделать, но это уже следующий уровень автоматизации. Надо попробовать сначала программное стирание. Времени должно хватить, ведь мы его много сэкономили при рисовании спрайтов. А стирание спрайта быстрее раза в 4, чем его рисование. Надо заполнить прямоугольник по габаритам спрайта байтом FF. А как стираются спрайты сейчас ?
Все относительно. Надо сравнить время стирание+рисование для старого и нового метода. Если получается быстрее - результат хороший. Не обязательно гнаться за максимальной скоростью.

Alex Rider

01.09.2015, 00:03

А как стираются спрайты сейчас ?
А никак не стираются. Ну, вернее, если логика пометила знакоместо как измененное, то оно полностью перерисовывается от заднего фона к переднему. Преимущество в том, что это делается в линейном буфере с фиксированным адресом. А тут придется по знакоместу в дисплее туда-сюда елозить. Хотя, это не должно быть проблемой. Кроме того, 2 из 5 слоев вообще отрисовывать не надо - отрисовать их сразу при перехода в другую комнату, и менять, если что, изменяемую графику только.

zx-kit

01.09.2015, 04:14

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

Преимущество в том, что это делается в линейном буфере с фиксированным адресом. А тут придется по знакоместу в дисплее туда-сюда елозить. Хотя, это не должно быть проблемой. Кроме того, 2 из 5 слоев вообще отрисовывать не надо - отрисовать их сразу при перехода в другую комнату, и менять, если что, изменяемую графику только.

Для новых режимов можно включить линейную адресацию экрана с адреса 0000: переход к байту справа командой inc h, переход к байту снизу командой inc l.

goodboy

01.09.2015, 10:36

Для новых режимов можно включить линейную адресацию экрана с адреса 0000: переход к байту справа командой inc h, переход к байту снизу командой inc l.
а не наоборот ? ( inc l / inc h )

Reobne

01.09.2015, 10:39

только наверно inc l / inc h
Справа-то только на 32. Поэтому INC H. А то сильно много будет. :)

ZXMAK

02.09.2015, 03:09

zx-kit

02.09.2015, 05:27

а не проще было бы поставить отдельный видеопроцессор со своей видеопамятью, он сам графикой бы и занимался, а спектрум клавиатуру бы обрабатывал... :)
Сразу решается проблема с недостаточностью адресного пространства - в качестве видеопроцессора можно сразу 32-разрядный процессор использовать...
Я предлагал в качестве видеопроцессора - эмулятор на PC. А новые режимы - нужны для постепенного перехода от стандартной графики к улучшенной. Z80 тоже кое что может рисовать. Тому подтверждение огромное количество игр. Мне интереснее переделать старую игру или делать новую для компьютера типа ZX Spectrum, чем для PC или другого компьютера. Иначе я сидел бы на другом форуме.

Чтобы сделать линейную адресацию не нужен отдельный процессор. Достаточно переставить биты адреса в видеокарте при выводе на экран телевизора/монитора. То есть для этого достаточно мультиплексора: стандартная/линейная адресация экрана.

То, что Синклер сделал кривую адресацию - ему было виднее, возможно хотел сэкономить 1 килобайт ОЗУ или хотел, чтобы заставки к игре загружались красиво. Интересно было бы узнать, почему адресация именно такая? И зачем в каждом байте атрибутов вместо отдельной яркости на PAPER и INK добавили бит FLASH? Курсор не обязательно было делать аппаратно мигающим знакоместом. Это можно было бы сделать и программно. А вот в играх курсор особо и не нужен, а отдельная яркость пригодилась бы.

Линейная адресация с адреса 0000 упростила и ускорила бы вывод графики. Так давайте исправим эту ошибку хотя бы сейчас, пока еще кто-то помнит про ZX Spectrum. И будем писать игры для него, а не для других компьютеров. Да это и интереснее. Тут все просто и понятно, нет операционной системы, драйверов и т.п. усложнений.

Destr

02.09.2015, 06:50

Линейная адресация с адреса 0000 упростила и ускорила бы вывод графики.
Это как? Сейчас буковку выводим например так:
; HL=адрес на экране, DE=адрес буквы
LD B,8 ; высота
LD A,(HL)
LD (DE),A
INC DE
INC H ; след. линия
DJNZ
...

А по-твоему будет как?

; HL=адрес на экране, DE=адрес буквы
LD B,8 ; высота
LD A,(HL)
LD (DE),A
INC DE

; след. линия
PUSH BC
LD BC,32
ADD HL,BC
POP BC
DJNZ
...

Так что-ли?

Интересно было бы узнать, почему адресация именно такая? И зачем в каждом байте атрибутов вместо отдельной яркости на PAPER и INK добавили бит FLASH? Курсор не обязательно было делать аппаратно мигающим знакоместом. Это можно было бы сделать и программно. А вот в играх курсор особо и не нужен, а отдельная яркость пригодилась бы.
А вот это правильно...

---------- Post added at 07:50 ---------- Previous post was at 07:49 ----------

Линейная адресация будет хороша если байты будут не горизонтально а вертикально (столбиком) выводится.
Тогда INC L - это на пиксель влево, INC H - на строку вниз.

Reobne

02.09.2015, 06:58

переход к байту справа командой inc h, переход к байту снизу командой inc l.
столбики привычные и горизонтальные.

Тогда INC L - это на пиксель влево, INC H - на строку вниз
столбики непривычные вертикальные.

; след. линия
PUSH BC
LD BC,32
ADD HL,BC
POP BC
DJNZ

Так что-ли?
...
Нет, просто INC L и всё.
То есть INC H заменяем на INC L.
И если в старом экране надо было вписаться в знакоместо, то теперь можно легко попиксельно двигать текст вверх вниз.
А речь вообщето даже не про вывод текста, а про вывод графики.

Destr

02.09.2015, 07:49

А речь вообщето даже не про вывод текста, а про вывод графики.
Да какая разница что выводить, на спеке текст=графике (текстового экрана нет, буквы - суть те-же спрайты 8х8).

столбики непривычные вертикальные.
Привыкнуть можно.
Зато очень хорошо для игр по типу Wolf (рэйкастинг).
Их было-бы сейчас столько-же, сколько всяких JET SET WILLY (ибо нынешняя архитектура экрана хорошо подходит для блочной графики, а вертикальные байты - для растра и вектора)

Sayman

02.09.2015, 08:01

было бы удобнее вот так примерно:

port_y equ 0x89

;в DE адрес = координата по X
;в HL адрес данных
ld b,8
in a,(port_y)
loop: ld a,(hl)
ld (de),a
inc hl
inc a
out (port_y),a
djnz loop

тут координатой Y управляем через порт. данные соответственно для стандартного экрана( пикселя, 1 бит на точку). тогда и думать не нужно о расчётах следующей строки. просто указали нужную строку в порт и кидаем данные от 0 до сколько-там максимум по X. если прикрутить сюда линейный акселератор, то ещё и скорости добавится.

port_y equ 0x89

;в DE адрес = координата по X
;в HL адрес данных
;данные расположены не "горизонтально", а "вертикально" (спрайт заранее развёрнут на 90гр).
ld d,d ; включить Аксель
ld a,8 ; задали размер данных (8 байт, т.е. строк)
ld b,b
ld a,a ;вертикальный перенос
ld a,(hl)
ld (de),a
ld b,b
inc hl
inc de

если ничего не напутал, тогда данные будут забивать 8 строк по 1 байту, при условии, что графика аля спектрум. при цветном выводе (цвет на точку) нужно добавить цикл. акселератор забивает видеопамять в разы быстрее проца. координатой Y рулить не требуется. после отработки акселя значение координаты Y будет увеличено на размер прокинутых данных акселем.

Reobne

02.09.2015, 08:26

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

---------- Post added at 12:26 ---------- Previous post was at 12:19 ----------

zst,

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

Sayman

02.09.2015, 10:01

Мало того что не удобно но и медленно и не работает к тому же.
это где медленно и не удобно? т.е. удобнее и быстрее на каждую треть экрана или каждые 8 строк делать пересчёты или тратить память под таблицу адресов? я вас умоляю, прочитал порт и получил текущую строку, кинул в порт и задал нужную строку. никаких расчётов и таблиц. экономия по памяти и по тактам. И как я написал - линейный акселератор ускорит процесс вывода (вброс байтов в экранную область/видеопамять). На Спринтере это прекрасно работает и быстрее, чем на любом 128м, профике или эве (может быть только конфа ТС будет равна или чуть быстрее местами).

Пути 3 - спрайты, блиттер или что то типо шейдеров.
про шейдеры я предлагал. опять таки - блиттер+шейдеры будут интереснее, чем тайлодвиг предлагаемый ТС.

Sayman

02.09.2015, 11:10

становятся номером строки
потому, что спрайт повёрнут под вертикальный вывод. и вариант с табличками и третями экрана годен только для стокового 128го режима. тут же в этой теме речь идёт не про стоковый режим. если иметь цвет на точку (4бита или там 8 бит, не суть важно), то стоковыми методами ничего кроме тормоза не получишь. можно посмотреть на работу АТМ или профика с их режимами и как там всё "быстро" работает. т.е.е сли говорить не о 128м экране, а про что-то более новое и быстрое, то старые методы забудь. к примеру, спринтёр за фрейм кидает весь экран (а это, на минуточку, 82кб).

Sayman

02.09.2015, 11:51

ты ничего не понял)))
в примере я привёл вариант вертикального вывода. спрайт заранее развёрнут. инкремент адреса данных приводит к инкременту на следующий столбец, на первый байт этого столбца. да. там немного не точно, тем не менее - я беру первый байт столбца и акселем кинул в экран. делать +1 к координате Y не требуется, т.к. аксель это делает сам в этом режиме. кинули столбец, сделали адресу данных +1,сделали координате X +1, кинули второй столбец и т.д.
zst хочет сделать карту, которая с минимальными трудозатратами по разработке железа и переделке игр приведёт к обесклешиванию старых игр + новые режимы. я же говорю о том. что на обесклешивание нужно положить один большой инструмент и просто сделать нормальную карту, подключаемую к любому 128/атм/профи и спокойно ворочать там цветными спрайтами. и как вариант я предлагал или просто блиттер (а не тупой тайлодвиг) или шейдеры или аналог уже давно проверенной и работающей карточки аля спринтер. потому вот так и связаны такие темы как спринтер кидает пиксели и адреса данных и что ты там ещё не смог понять...

---------- Post added at 14:51 ---------- Previous post was at 14:45 ----------

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

Reobne

02.09.2015, 12:01

zst, Память, говоришь, ориентируешься на 4Мх16Бит? Это на одной микросхеме, или на нескольких(для одновременного доступа по произвольным адресам) и сколько обращений на 1 пиксель? Примерно.

s_kosorev

02.09.2015, 12:23

Раньше то как было? Ползёт лучик электронный по строчке экрана телевизора, схема видеовывода считала из памяти 2 байта (растр и атрибуты) и целых 8 пикселей обеспечены. А если пытаться вертикальный байтик отобразить, то пришлось-бы промежуточный буфер делать, на 512 байт, либо с хитрым доступом, либо с ещё одним промежуточным буфером на 8 байт с хитрым доступом. Либо частоту повышать.
Да тоже самое, в Специалист, Орион байтики вертикальные, и там процессор 2-2.5 8080 вполне даже крутит 12кб экран
Какие буферы 512к непонятно (собранные на дискретной логике как бы)

Sayman

02.09.2015, 12:26

Почему то никто не переделывает ay плееры под TSFM или General Sound, а просто прикрепляют новый с новыми мелодиями и эффектами, тут абсолютно тоже самое.
вот вот и я о том же.

зачем тогда кидать данные в (de) и их же +1 в порт #89 ?
там два примера было.в первом типа если бы Акселя не было, тогда координату Y ручками +1 и кидаем в порт. во втором примере там вертикальная операция акселя по примеру спринтера. при этом ld a,(hl) ld (de),a делать нужно именно на спринтере, т.к. Альтера там перехватывает опкоды проца. Альтера видит, что было вкелючения Акселя (ld d,d), кинули размер данных, включили режим вертикального переброса и дали каману выполнить. команда выполнить. источник данных это через перехват каманды ld a,(hl) или ей подобной, а адрес куда кидать через перехват ld (de),a или аналогичную каманду. когда аксель увидел все каманды, он их начинает выполнять. в результате за одну каманду мы можем кинуть не 1 байт, а сразу 256 байт. и в отличии от ТС тут нет привязок к чётности.

Reobne

02.09.2015, 12:34

Какие буферы 512к непонятно
Я имел ввиду 2 буфера по 256 байт ( а не к) для двух восьмипиксельных строк, один буфер пишем, другой выводим.
Сколько мегагерц процессора, это другой вопрос. А сколько мегагерц обращения к памяти, и блокируется-ли процессор, при обращении к памяти, системы видеовывода, это первый вопрос.

s_kosorev

02.09.2015, 12:57

Я о том что экран столбиком и "железячникам" и программистам знаком, а в том что в 2раза более слабый процессор рисует на в 2 раза более емком экране, уже о многом говорит

Valen

02.09.2015, 14:27

Жаль что zst свалился в не особо нужный (или точно уж второстепенный) клэшинг.
И отшел от простого и привычного блиттера.
Но видимо чел занимается тем что интересно.

Спрайты/шейдеры автор не потянет, он изначально говорил.

Alex Rider

02.09.2015, 23:32

То, что Синклер сделал кривую адресацию - ему было виднее, возможно хотел сэкономить 1 килобайт ОЗУ или хотел, чтобы заставки к игре загружались красиво. Интересно было бы узнать, почему адресация именно такая?
Недавно где-то пролетала ссылка на статью lvd по этому поводу. Опять дело было в экономии - Синклер пытался выжать максимальную скорость из медленной и дешевой памяти, которая не позволяла с нужной скоростью читать при линейной адресации, но позволяла при такой вот. Там, вроде, при чтении байта растра и байта атрибута не меняется кто-то из RAS или CAS, не помню тонкостей.
И зачем в каждом байте атрибутов вместо отдельной яркости на PAPER и INK добавили бит FLASH?
Вот это большой вопрос, ибо сделать раздельный BRIGHT для INK и PAPER было бы не сложнее аппаратно, а курсором можно было бы поморгать и в ISR.
столбики непривычные вертикальные.

Зато очень хорошо для игр по типу Wolf (рэйкастинг).
С этого момента дружно забываем домыслы про вертикально ориентированные биты в байте и понимаем такую вещь: адрес вывода обычного горизонтального байта на экран равен x * 32 + y (x в знакоместах, y в пикселах). Все. Если в hl адрес байта, то переход к той же линии в соседнем знакоместе - inc h, переход к следующей линии в том же (или следующем снизу) знакоместе - inc l.

Мало того что не удобно но и медленно и не работает к тому же.
47 страниц, а понимания что адресацией и извратами производительность не прибавить не понятно.
Тред читать надо. Вывод символа на слой фона с координатами (X, Y):

; hl - адрес символа
ld de, x * 256 + y * 8
dup 8
ldi
edup

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

; hl - адрес символа
ld de, x * 256 + y * 8
dup 8
ldi
dec e
ldi
edup

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

Пути 3 - спрайты, блиттер или что то типо шейдеров.
Это все уже сделал TSL. Нужна еще одна реинкарнация? Вот, кстати, для этого случая переделка игры скорее всего потребует полного проворота через мясорубку обратно, ибо спрайтовая графика будет толще (не влезет в тот объем памяти, под который заточена игра), а вывод на экран надо будет перепахать от слова "совсем". А с Метеором же можно, кстати, переделывать игру можно в 2 этапа: сначала разогнать и обесклешить, не переделывая графику совсем (!), потом уже перекрасить под большее количество цветов (а rgb-палитра позволит перекрасить игру способом наподобие ULA+) даже без изменения чего-то в ней.

Жаль что zst свалился в не особо нужный (или точно уж второстепенный) клэшинг.
Победа клештнга - одна из приятных фич.

И отшел от простого и привычного блиттера.
А кому он прост и привычен? Много у тебя игр получится переделать с пол-пинка под обычный блиттер без извратов?

s_kosorev

02.09.2015, 23:57

Открою секрет, каждый аппаратный спрайт это отдельные слой
Можно сгруппировать как 2 слоя, а можно как 10, зависит от того сколько спрайтов одновременно может вывести движок

Alex Rider

03.09.2015, 00:09

Открою секрет, каждый аппаратный спрайт это отдельные слой
[TSL] с тобой бы чуть поспорил. Ибо слой - это не только графическое изображение, но и привязанная палитра/набор палитр. Если говорить только о взаимодействии с остальным изображением, то да, как бы отдельный слой.

s_kosorev

03.09.2015, 00:10

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

Alex Rider

03.09.2015, 00:11

Кстати, аппаратные спрайты (как и всякие остальные блиттеры/шейдеры) проблемы переделки игр, имхо, не решают.

---------- Post added at 00:11 ---------- Previous post was at 00:10 ----------

Кто запрещает спрайтам привязывать палитру?
Да, чот я погорячился. Никто не запрещает. Зависит от реализации. Загнался реализацией в TS-Conf.

s_kosorev

03.09.2015, 00:22

Пока я вижу неимоверными усилиями попытку реализовать спрайтовый движок какими то странными командами

Еще раз напомню мысль, как можно ускорить кардинально графику

Берем ядро AVR на opencores, привязываем к примеру регистры ядра к блокам DMA, MMU и получаем шейдерный процессор, добавляем блоков для формирования изображения, перехватов данных процессора о которых тут много речи и получаем движок, который сможет все вышеописанное реализовать, но не какими то странными а достаточно простым способом, залили прошивку, получили спрайтовый движок, залилили другую, получили карту которая умеет примитивы рисовать, третья прошивка к примеру может уметь текстурированые треугольники выводить, можно спец прошивки для игр, которые будут к примеру по известным адресам и игрушке брать координаты спрайтов и сама выводить их на экран, т.е. можно вообще без переделывания игры качественно изменить графику.

Alex Rider

03.09.2015, 00:42

но не какими то странными а достаточно простым способом, залили прошивку, получили спрайтовый движок, залилили другую, получили карту которая умеет примитивы рисовать, третья прошивка к примеру может уметь текстурированые треугольники выводить, можно спец прошивки для игр, которые будут к примеру по известным адресам и игрушке брать координаты спрайтов и сама выводить их на экран, т.е. можно вообще без переделывания игры качественно изменить графику.
Это уже изобрели. U16 называется. Берешь и делаешь для нее прошивку, которую тебе любую ZX-игру в PC-аналог неотличимый превращает. Пользователь должен вставить карту в Пентагон, скачать игру, ее поддерживающую, и играться. Перешивать карту он не должен, если не фанатеет этим, конечно.
Программист, пишущий игру, должен взять спецификацию карты и написать игру по ней. Не думая о том, что он пишет игру под прошивку во спрайтами, а у пользователя - с треугольниками. А еще ZX-программист не должен писать прошивку к своей игре для карты :) И уж тем более переделка старых игр путем подмены прошивки видеокарты выглядит как-то гм...

---------- Post added at 00:42 ---------- Previous post was at 00:39 ----------

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

Еще раз напомню мысль, как можно ускорить кардинально графику
И, кстати, задачи ускорять графику кардинально тоже не стоит, как я понял. Чуть ускорить - да. Главное при этом - сделать так, чтобы адаптация игры не требовала полного реверс-инженеринга.

s_kosorev

03.09.2015, 00:45

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

Но это для спец прошивок, по сбросу может загружаться какая то типовая и посредством команд, переключаться на другие типовые (спрайтовый движок/блиттер/3д/векторный итд)

---------- Post added at 00:43 ---------- Previous post was at 00:42 ----------

И, кстати, задачи ускорять графику кардинально тоже не стоит, как я понял. Чуть ускорить - да.
Ну когда есть возможность кардинально ускорить, это полностью покрывает требования "чуть ускорить"

---------- Post added at 00:44 ---------- Previous post was at 00:43 ----------

Предлагают увеличить глубину цвета и сделать несколько независимых слоев по мотивам экрана Спектрума.
И дальше что? Увеличили грубину цвета в 2 раза + пару слоев, процессор в итоге это все будет отрисовывать в 4 раза медленней, зачем оно надо?

---------- Post added at 00:45 ---------- Previous post was at 00:44 ----------

А еще ZX-программист не должен писать прошивку к своей игре для карты
ПЦ программисты и программисты мобилок, шейдеры пишут нараз, чем ZX-программисты хуже? Если это в итоге проще к тому же

Alex Rider

03.09.2015, 02:47

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

И дальше что? Увеличили грубину цвета в 2 раза + пару слоев, процессор в итоге это все будет отрисовывать в 4 раза медленней, зачем оно надо?
Читаем тред внимательно - без переделки графики скорость вывода растет довольно значительно и исчезает клешинг (переделывается и ускоряется только рендер спрайтов). С переделкой графики можем иметь до 4 бит на точку из палитры для 8-ми точек байта. Про скорость вывода этого пока ничего сказать не могу, но навскидку большого замедления я не вижу.

ПЦ программисты и программисты мобилок, шейдеры пишут нараз, чем ZX-программисты хуже?
Тем, что разработка/переделка игр в качестве хобби будет длиться годами.

Прошивка карты одна, заливаются прошивки во внутренние рамблоки для AVR (читай, загружают шейдеры), реализуется это загрузчиком для игры, который сначала грузит "спец прошивку" потом передает управление загрузчику игры"
Но это для спец прошивок, по сбросу может загружаться какая то типовая и посредством команд, переключаться на другие типовые (спрайтовый движок/блиттер/3д/векторный итд)
Повторюсь, это все уже реализовано в серии Reverse, можно сделать и на ZX Evolution. MVV, ЕМНИП, делает сейчас для U16 мост для ZX-Bus, можно будет воткнуть ее как карточку в тот же Пентагон и использовать со всеми шейдерами и блиттерами - пиши, не хочу. Еще раз повторюсь, переделка игр под спрайтовые движки и другие подобные фичи - задача весьма нетривиальная.

Олсо zst не собирается забивать все ресурсы карты текущей реализацией. Сделает такую, рабочую версию, сможет при желании заняться и автоматизацией векторной графики, и аппаратными спрайтами, и загрузкой кастомных рендереров с ZX. А вот выяснить сейчас, что предложенная идея - ***** и надо сразу делать мегамонстра из серии GeForce - это потенциально похоронить разработку или оставить вообще все на личное усмотрение автора, что часто одно и то же.

zx-kit

03.09.2015, 06:10

Для чего предназначены новые режимы графики:

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

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

Поэтому нужно обратить внимание на улучшение графики существующих игр. Некоторые из них вышли недавно и для них есть исходные тексты. Это упростит модернизацию. Но перейти от программного рисования спрайтов к аппаратным спрайтам не так-то просто. Для режимов графики, спроектированных до видеокарты "Meteor Graphics", надо было переделывать не только процедуры вывода на экран, но и сами спрайты. Это дополнительная работа и не всем это понравится.

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

После долгих обсуждений в этой теме из большого количества предложений, я выбрал, на мой взляд, наиболее простые в реализации и эффективные режимы. От многого на 1 этапе расширения графики пока пришлось отказаться, например, от палитры, аппаратного скроллинга, автоматической карты тайлов, аппаратного рисования спрайтов (блиттера), аппаратного рисования линий, 3D и т.д.

Новые режимы предназначены, в первую очередь, для устранения клешинга без изменения спрайтов. Но спроектированы они так, что производительность компьютера при их использовании не падает, а наоборот, возрастает ! Это продемонстрировал на примерах кода (http://zx-pk.ru/showpost.php?p=825797&postcount=480) Alex_Rider.

Sayman

03.09.2015, 08:12

Порты для Y резко проигрывают на старте
Если у тебя по координатам X, Y всего по 8 бит, то это бесспорно. если хоть одна координата, например X, больше (320 точек, к примеру), тогда порт для Y сильно уходит вперёд. Но при этом ты упускаешь одну важную деталь - регистр ты можешь затереть и текущую координату тоже. нужно постоянно её хранить в переменных. А порт это порт - его прочитал, что нужно сделал и забил про регистр и переменную. Порт всегда выдаст тебе актуальную инфу по координате.
И ты не понимаешь самого главного - большинство спрайтов в играх для Спектрума - ЧБ. хоть 100 слоёв дай, чб будет чб. т.е. спрайты нужно уже перекрашивать. я тебя уверяю, можно с таким же успехом взять. распотрошить любую игру и переделать вывод со спектрумовского экрана на любой другой, например, АТМ или тот же спринтер. И всЁ, и никакого клэшинга, и при этом все родные цвета будут и конечно же ЧБ спрайты ГГ, противников и т.д. Нет принципиально разницы под что ты будешь переделывать - под Метеор или не Метеор - тебе всё ровно залезать в кишки движка игры, всё ровно переписывать вывод. А если ещё и палитры хочешь и цветов побольше, то ещё и спрайты перерисовывать. так объясни, в чём преимущество Метеора перед тем же Спринтером? Никакой Метеор никогда не сделает без переделки игры антиклэшинг.

Поэтому нужно обратить внимание на улучшение графики существующих игр. Некоторые из них вышли недавно и для них есть исходные тексты.
Игры вышедшие недавно и имеющие исходники легко переделываются под любой клон, под любую карточку или режим. Игры для которых нет исходников, вот это реальный гемор. И снова вспоминаем - Zynaps, R-Type, ещё море таких интересных игр. Но в таких случая действительно - проще написать с нуля, чем шариться по дизамсу и вникать в чужой код.

s_kosorev

03.09.2015, 12:59

Читаем тред внимательно - без переделки графики скорость вывода растет довольно значительно и исчезает клешинг (переделывается и ускоряется только рендер спрайтов). С переделкой графики можем иметь до 4 бит на точку из палитры для 8-ми точек байта. Про скорость вывода этого пока ничего сказать не могу, но навскидку большого замедления я не вижу.
Не вижу препятствий что бы такой режим реализовывала одна из прошивок AVR

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

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

---------- Post added at 12:59 ---------- Previous post was at 12:58 ----------

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

s_kosorev

03.09.2015, 13:20

zst, как успехи? Работает хоть что-то уже? )))
отчего же, смотрел исходники, там видережим реализован на базе FSM, т.е. реализация при небольшой аппаратной поддержке, вполне возможна

Alex Rider

03.09.2015, 17:39

распотрошить любую игру и переделать вывод со спектрумовского экрана на любой другой, например, АТМ или тот же спринтер. И всЁ, и никакого клэшинга, и при этом все родные цвета будут и конечно же ЧБ спрайты ГГ, противников и т.д. Нет принципиально разницы под что ты будешь переделывать - под Метеор или не Метеор - тебе всё ровно залезать в кишки движка игры, всё ровно переписывать вывод.
Вопрос в объеме переделок. Ликвидация клешинга под "Метеор" не требует обязательной переделки спрайтов и ускоряет вывод. Мало того, под Метеор можно переделать только часть спрайтов, например, фон оставить оригинальным. Переделка под "цвет-на-точку" требует обязательной перерисовки всех спрайтов (с увеличением размера занимаемой памяти и, для старых игр, с вполне ожидаемым выходом за 48К). В общем, без полного дизасма будет адъ. Переделка процедуры отрисовки под "антиклешинг" выглядит более простой и не требующей дизасма.
А если ещё и палитры хочешь и цветов побольше, то ещё и спрайты перерисовывать.
Блин, вот ULA+ вообще не требует залезать в код игры, только сменить палитру в загрузчике. Достаточно применить отдельные палитры для слоев, и получишь уже перекрашенную игру (да, с монохромными спрайтами, если они были таковыми), но не в 15 цветах же уже.

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

Не вижу препятствий что бы такой режим реализовывала одна из прошивок AVR
Или одна из прошивок для текущей архитектуры. Не важно. Про аппаратную реализацию я не шибко могу дискутировать, не специалист. Но уж, если делать новую видеокарту хоть на Core i7 + GeForce 960, режим, подобный предложенному zst сейчас там очень даже должен быть.

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

s_kosorev

03.09.2015, 18:09

Или одна из прошивок для текущей архитектуры. Не важно.
От блин тугой же, 3 раз говорю, не меняется прошивка карты, запиши где нить в блокнотике, что бы следующий раз не возращаться к этому вопросу, в карте внутри процессор (шейдер) AVR например, вот ему и заливаются прошивки

Как может выглядеть к примеру переделка игры с клешенгом
на Ц пишем для avr к примеру такой код
Который будет каждый кадр, читать из памяти спектрума координаты ГГ и выводить их, если новый спрайт попиксельно перекрывает старый, то можно ничего не делать, если не перекрывает, то в игрушке в процедуре рисования спрайта ГГ сразу ставим выход, что бы не рисовал

// инициализация
uint16_t human_posx = 0xc000; // адрес в памяти хоста, где хранится координат X ГГ
uint16_t human_posy = 0xc001; // тоже для Y
uint16_t human_fase = 0xc002; // адрес фазы анимации в хосте
uint32_t sprites_base = 0x10000; // базовый адрес в памяти карты, где храняться спрайты

rect src = { strip = 1024, h=8, w=8}; //настраиваем источник, спрайты 8х8 truecolor, 256 бай, храняться в текстуре 1024байта шириной

// в обработчике int
uint8_t fase_val = RdSpecMem(human_fase); // получаем фазу анимации
point dst = {x=RdSpecMem(human_posx), y =RdSpecMem(human_posy)}; // настраиваем куда выводить спрайт
src.addr = sprites_base * fase_val *256;
BitBlt(src, dst); // вывод

15 минут кодить, больше головняков будет найти адреса которые слушать и нарисовать новый спрайт

Sayman

03.09.2015, 18:38

Вопрос в объеме переделок.

Переделка под "цвет-на-точку" требует обязательной перерисовки всех спрайтов
под экран с цветом на точку я просто возьму оригинальные спрайты из игры, чб, не чб и просто засуну их их в "цветной" экран. да, чб спрайты будут чб, цветной фон будет цветной. вот и нет клэшинга. И для метеора придётся делать всё тоже самое - разгребать код в дизасме, шарить где там в дампах спрайты и всё по списку. разницы нет никакой вообще.
И то мы ещё не берём в расчёт игры, которые были написаны на си и при этом нет исходников. там ещё хуже сидеть и разбирать весь этот код.
Ещё раз - код менять хоть под Метеор хоть под что угодно придётся 146%.

и я пока реально не могу понять, что за экран такой должен быть у Метеора для избавления от клэшинга. самый простой режим, я понял - подобие экрана Спектрума, только с двумя планами так? т.е., ипа в одном экране должно быть два спектрумовых плана. вывод на план_0 фона, вывод на план_1 ГГ и монстры так? ну т.е. два экрана в сумме по 6кб так?

Ликвидация клешинга под "Метеор" не требует обязательной переделки спрайтов и ускоряет вывод.
под любой экран, хоть для ПЦ, оставляем оригинальную графику, нам нужно только клэшинг убрать. А потому я не вижу пока каких-то преимуществ Метеора.

Я не очень хорошо знаю Спринтер, но, во-первых, это - отдельный комп, а не графическая карта,
Исходники Спринтера открыты. Бери - не хочу. Всё давно отработано, проверено, всё работает. Логика известна. Велосипед давно изобретён, всё украдено до вас.

Блин, вот ULA+ вообще не требует залезать в код игры
да да, ровно как и от клэшинга не спасает. не интересная штука.

Alex Rider

03.09.2015, 22:00

Ещё раз - код менять хоть под Метеор хоть под что угодно придётся 146%.
Код менять придется, согласен. Вопрос в масштабах. Получится для Спринтера наложить спрайты ГГ в его разрешении на 6912, оставив без изменений кода вывода заднего фона? Тут еще вот в чем дело. Как только начинается переделка игры и включается новый видеорежим, мы на экране не видим уже ничего. То есть, не получится, к примеру, сначала перекрасить статические рамки, потом передний фон, потом персонажей, потом задний фон... Придется делать макетный проект, отлаживать на нем процедуры, подменять готовые и искать в игре где что не срослось. С Метеором же графику можно менять последовательно, поскольку она лежит над стандартным экраном, и непеределанный код работает по-старому, игра остается функциональной.

ну т.е. два экрана в сумме по 6кб так?
Ну да, типа того. Клешинг убирается за счет того, что смешиваются они в карте, которая умеет и маску верхих слоев тоже тоже понимать.
От блин тугой же, 3 раз говорю, не меняется прошивка карты, запиши где нить в блокнотике, что бы следующий раз не возращаться к этому вопросу, в карте внутри процессор (шейдер) AVR например, вот ему и заливаются прошивки
Ну для меня не принципиально что там меняется - конфиг ПЛИС или код для карточного процессора. Факт, что это - другие, непонятные мне байты, ничего общего с ZX-программированием не имеющего, непонятные в отладке (асинхронной, к тому же). То, что при этом при переделке можно не менять код игры (но раскопать его надо будет очень основательно, до каждой переменной и флажка, относящихся к выводу на экран) и накодить аналогичный отрисовщик в карте, для меня не плюс, а минус.
В целом доказывать мне преимущества разных архитектур, наверное, не стоит - с точки зрения программирования на ZX важен интерфейс и особенности, а не начинка. Заложить в карту изначально побольше возможностей - не грех, только вот тот режим, который мы обсуждаем с zst тут, надо сделать искаропки и без лишних телодвижений от программиста - включили режим, и он есть всегда, без заливки какого-то дампа внутрь карточки.

s_kosorev

03.09.2015, 22:26

ничего общего с ZX-программированием не имеющего, непонятные в отладке (асинхронной, к тому же).
1. Где там асинхронность, явно же указал что по int срабатывает отрисовка
2. Для AVR средств отладки много, при желании можно даже JTAG AVR реализовать и с AVR Studio отлаживать, для спектрума отладчиков чуть больше чем 0
3. Найти адреса и разобраться в флагах по затратам ровно столько же сколько при патче самого кода, только вот патчить не надо и сложность соответсвенно меньше
4. Это один из вариантов, возможны варианты к примеру, когда AVR слушает запись в какой то порт, интерпретирует команды как тут выше насочиняли
5. Прошивку AVR опять же писал, можно штатную держать в карте, но есть возможность на свои менять (по сбросу возвращается заводская), для тех кого не устраивает штатная, либо он хочет на карту возложить сложную отрисовку, которую спектрум даже примерно не потянул бы. Для спектрума есть звуковая карта General Sound, у неё есть прошивка по сбросу и тем не менее можно загружать свой код, тут тоже самое

AndyD

03.09.2015, 22:27

Ещё раз - код менять хоть под Метеор хоть под что угодно придётся 146%.
Правильно,придется и что-то не переделывают.
Есть много графических спек разновидностей и что-то под них не особо кто то переделывает легендарные спековские игры,а почему?Архитектура компа то та-же,проц,память,все есть,дык проблема то не в железе,а в том что спековские игры переделывать очень проблемно,они сильно связаны программно с железом и простая перерисовка графики не поможет,нужно менять всю структуру игры от вывода на экран до логики построения картинки.
Слишком много трудо-затрат на не существенное изменение красочности игры.
Спеку нужен реально мощный акселератор графики,на котором возможен запуск старых игр и существенная их доработка,не просто убрать клешинг,а потенциал развития не нагружающий центральный проц,как тут уже говорили новыми прошивками например,но упор надо делать на возможность подключить аксель к большенству спектрумов и тогда будет больше желающих переделать свою любимую игру,вложив много труда на переделку игры человек будет знать ,что она будет работать на скорпионе и пентагоне с акселем Надо объединить всех в универсальном решении,думаю это нужно и интересно спетрум-сообществу.

Alex Rider

04.09.2015, 00:12

1. Где там асинхронность, явно же указал что по int срабатывает отрисовка
И работает дальше асинхронно. Либо должна уметь не только читать память спека, но и иметь прерывания на ее изменение. Ибо Спек в игре может менять переменные когда ему вздумается и как ему вздумается и отрисовывать графику в видеопамять потом когда сочтет нужным. Рендерер должен быть к этому готов. Ну или Спек дает команду карте и ждет пока она отрисует очередной фрагемнт. Предложенный zst вариант предполагает как раз подмену в игре логики вывода картинки в видеопамять именно в тот момент, когда данные отрисовки в памяти находятся в нужном состоянии.

2. Для AVR средств отладки много, при желании можно даже JTAG AVR реализовать и с AVR Studio отлаживать, для спектрума отладчиков чуть больше чем 0

А как отлаживаться в игре "на живую" параллельно с исполнением кода Спеком?

3. Найти адреса и разобраться в флагах по затратам ровно столько же сколько при патче самого кода, только вот патчить не надо и сложность соответсвенно меньше
Вот неправда твоя ни разу. Когда я патчу вывод в экранную область, мне достаточно знать, что, если на этот момент (addr1) = 0, то рисовать черным, иначе - красным. И пофиг мне на остальной смысл (addr1) в этой игре. Карта же не знает когда Спек начнет отрисовку именно в этом месте и может считать (addr1) в произвольное время в произвольном состоянии. Пример из забитого в этой теме Саботера (там вообще int не используется и к нему ничего не привязано): логика кидает в тайлмап выстрел из огнемета для каждлго кадра заново в цикле, пока луч не упрется в ГГ, препятствие или край экрана. Если карта будет рисовать сцену по тайлмапу независимо от логики и будет отрисовывать луч в момент формирования или стирания от предыдущего фрейма, выстрел будет в каждом кадре разной длины. Как это победить без переделки игры? Рендереры для видеокарт же на PC и других платформах пишутся вместе с кодом игр, и код специально заточен под наличие рендереров.

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

Я вот лично сам знать не знаю AVR, C знаю с трудом и был бы рад, если бы на карте стоял Z80, i8051 или интерпретатор C#. То есть, AVR меня, как потенциального передельщика игр, на подвиги не возбудит, ибо незнакомо, проще кодом на Спеке сделать или не сделать совсем. Кстати, вспоминаются тут статьи покойного Веремеенко по скрещиванию Спека с Денди, он там предлагал варианты использования, но симбиоза у него так и не получилось: либо Денди отрисовывает только BORDER, либо Спек используется только как загрузчик игр.

Спеку нужен реально мощный акселератор графики

потенциал развития не нагружающий центральный проц

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

s_kosorev

04.09.2015, 00:35

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

---------- Post added at 00:28 ---------- Previous post was at 00:28 ----------

А как отлаживаться в игре "на живую" параллельно с исполнением кода Спеком?
У процессора есть сигнал останова

---------- Post added at 00:29 ---------- Previous post was at 00:28 ----------

Вот неправда твоя ни разу. Когда я патчу вывод в экранную область, мне достаточно знать, что, если на этот момент (addr1) = 0, то рисовать черным, иначе - красным. И пофиг мне на остальной смысл (addr1) в этой игре. Карта же не знает когда Спек начнет отрисовку именно в этом месте и может считать (addr1) в произвольное время в произвольном состоянии.
Ну карта не только для саботера, правда же? Тем более если опишеш проблему, возможно опишу решение в рамках предлагаемого движка

---------- Post added at 00:31 ---------- Previous post was at 00:29 ----------

Я вот лично сам знать не знаю AVR, C знаю с трудом и был бы рад, если бы на карте стоял Z80, i8051 или интерпретатор C#.
Вот как, zst не понимает еще не понимает что такое акселератор, ты не знаешь С, все должны подстраиваться под вас?

Вся соль в том что движок на проце может реализовать режимы zst, обратное утверждение не верно

---------- Post added at 00:32 ---------- Previous post was at 00:31 ----------

AVR меня, как потенциального передельщика игр, на подвиги не возбудит, ибо незнакомо, проще кодом на Спеке сделать или не сделать совсем.
то что делает zst адекватного программиста тоже не должно возбуждать

---------- Post added at 00:33 ---------- Previous post was at 00:32 ----------

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

---------- Post added at 00:35 ---------- Previous post was at 00:33 ----------

Ладно, я понимаю что навязать что zst не выйдет, opensource он такой, каждый лепит что ему интересно

Пасую, я просто хотел показать что есть решения слегка под другим углом

Alex Rider

04.09.2015, 04:12

У процессора есть сигнал останова
Ну вот и будет либо дудочка, либо кувшинчик: либо отлаживаем код игры на живом спеке, либо отлаживаем код акселя в AVR. А, самое главное, наживую уже мало кто пишет и отлаживает, а прилепить к спековскому эмулю еще и эмуль АВРа... Тут что-то не видать желающих даже такую карту поэмулировать.
Тем более если опишеш проблему
Проблема в том, что аксель знает где в игре хранятся данные для отрисовки, но не знает когда они актуальны. Об этом знает только игра. Да, и отрисовок в главном цикле может быть много.

все должны подстраиваться под вас?
Не, все должны подстраиваться под zst, ибо он автор. А он должен слушать мнения людей и решать, что он будет делать, а что - нет.

то что делает zst адекватного программиста тоже не должно возбуждать
Ну вот я - явный пример того, что может же возбуждать :) Потому что мне приятнее копаться в коде Z80 и адаптировать его под другую железку, особенно с учетом понятной мне модели программирования.

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

Пасую, я просто хотел показать что есть решения слегка под другим углом
Не обижайся, мы тебя услышали. Просто как бы... Ну атмосфера тут такая... Мало кому хочется реализовывать незапланированные фишки для абстрактных "всех", которые как будто бы тут же ринуться их использовать. Я показываю zst что можно сделать с Саботером (ну да, потому что я знаю только его изнутри), он к части идей прислушивается. Покажи, что ты с акселем переделаешь Elite и уже знаешь примерно как и чего тебе не хватает, разработчик к тебе прислушается.

Sayman

04.09.2015, 07:44

С Метеором же графику можно менять последовательно, поскольку она лежит над стандартным экраном, и непеределанный код работает по-старому, игра остается функциональной.
так, погодь. вот я воткнул в свой пень Метеора. Запускаю Zynaps, ииии....ничего. игра остаётся самой собой. Запускаю эту же игру на Спринтере, ииии...тоже самое, стандартная 128я графика. Потому мне не понятно, что значит менять последовательно. Т.е. я беру, делаю дизасм игры. Нахожу код по выводу графики. Дальше что? включаю порты Метеора, собираю игру, запускаю и получаю в лучшем случае чёрный экран, в худшем - мусор на экране. Чтобы на экране Метеора появилась графика нужно вносить в код изменения - включить режим, кинуть спрайты в карточку, кинуть палитру, указать номера слоёв. Всё так, ничего не упускаю? собираю и вот тогда уже на экране будет что-то, возможно без клэшинга. При этом нужно понимать, что у Метеора уже своя видео память. А значить делать вывод старыми методами уже нельзя. Точно так же, беру и нахожу весь код по выводу, включаю спринтеровый режим, вместо вывода стандартного фона (процедуры) подставляю процедуру вывода фона на экран спринтера, потом персонажи и прочее. Т.е. Различие только в том, что в Метеоре нужно кидать последовательно всё на разные планы, а на Спринтере нет такого понятия как план. Хотя конечно, придётся сделать одну вещ - спрайты из 1бит на пиксель придётся переделать на 8бит на пиксель. Без добавления цветов или подобного. Т.е. все спрайты сохранять свои цвета и места где цвета применяются, только спрайты будут немного в другом формате и всё. Это тут будет единственное различие.
В общем и целом. всё как-то сильно заморочено и не очень так интересно. Когда будет блиттер и нормальный алгоритм вывода, без извратов, позовите...

specorg

04.09.2015, 10:19

Hi All!

Читаю вашу ветку, наткнулся и инете на это:

Inferno #10, 30 апреля 2007, Железо
Будущее Спектрума - Видеоконтроллеры V9990. Расширение графических возможностей ZX Spectrum.
http://www.zxpress.ru/article.php?id=8681

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

AVR, ARM, CPLD и VGA… 1760 часов чистого времени
http://www.polesite.ru/?p=2553

VGA видеоадаптер [Незавершенный эксперимент]
http://www.polesite.ru/?p=4354

Тайловая графическая система /0x01
http://www.polesite.ru/?p=2424

Тайловая графическая система /0x02
http://www.polesite.ru/?p=2475

Тайловая графическая система /0x03
http://www.polesite.ru/?p=2450

Тайловая графическая система /0x04
http://www.polesite.ru/?p=2514

Динамическая система освещения двумерной графики
http://www.polesite.ru/?p=5338

8-бит Графическая библиотека (C++)
http://www.polesite.ru/?p=2676

Эксперименты с Due — VGA вывод
http://www.polesite.ru/?p=2207

Так же есть канал на ютубе http://www.youtube.com/user/krikusZ80

Вот в частности демонстрация GPU:

Homebrew GPU Test#1 http://www.youtube.com/watch?v=behbBRC4SKc

http://www.youtube.com

Homebrew GPU Test#2 http://www.youtube.com/watch?v=LxGfVtqwm2Q

http://www.youtube.com

Homebrew FPGA GPU Project - Dual Screen R-Type http://www.youtube.com/watch?v=ffkc-ic16Zo

http://www.youtube.com

shurik-ua

04.09.2015, 11:04

Сразу видно - полёт фантазии не ограничен ни временем ни фин. возможностями )

- R-Type Dual Screen Test - [Jan 2014]

- 2 x 80 Mhz 32 Bit MIPS CPU's
- 2 x Spartan 6 FPGA based GPU's
- 2 x 1 Meg by 16 Bit 100 Mhz SRAM Video Memories
- 1 x Cyclone II FPGA Video Mixer & Effects Unit
- 1 x 1 Meg by 8 Bit 100 Mhz SRAM
- 1 x 16 Meg by 8 Bit 133 Mhz SDRAM
- Twin VGA Outputs - 12 Bit & 30 Bit per pixel

Alex Rider

04.09.2015, 13:03

Будущее Спектрума - Видеоконтроллеры V9990. Расширение графических возможностей ZX Spectrum.
Да, помнится такая статья. Несколько лет назад Alone активно продвигал идею построения карточки на v9990, а, когда TSL опередил NedoPC в этом вопросе и сделал куда лучше, Alone стал называть это "неспектрумом", "дендиконфой" и гнобить TS-Conf на каждом углу.

Потому мне не понятно, что значит менять последовательно. Т.е. я беру, делаю дизасм игры. Нахожу код по выводу графики. Дальше что? включаю порты Метеора, собираю игру, запускаю и получаю в лучшем случае чёрный экран, в худшем - мусор на экране.
Нет :) Ты получаешь ту же игру (насколько я понял из спецификаций zst). Специально сделано так, что, если ты включаешь видеорежим карты, но не меняешь ничего больше, то графика остается стандартной.

Чтобы на экране Метеора появилась графика нужно вносить в код изменения - включить режим, кинуть спрайты в карточку, кинуть палитру, указать номера слоёв.
Ну можно, например, включить отображение 1-го слоя, найти код вывода ГГ, поменять его на вывод по канонам Метеора и спокойно отладить на фоне остальной стандартной графики игры. При этом, если у ГГ есть маска, тут же получим антиклешинг для него (а, если маски нет, дорисовываем ее для кадой фазы спрайта и наблюдаем результат). Захотели перекрасить статическую рамку в большее количество цветов - взяли графику рамки, переделали, нашли код вывода рамки, переделали, получили великолепие цвета при все еще работающем по-старому фоне и спрайтах врагов. Делаем последовательно, наблюдаем результат сразу.

Когда будет блиттер и нормальный алгоритм вывода, без извратов, позовите...
Блиттер не позволяет легко переделывать игры на Спектруме. Писать новые - да, наверно. В любом случае, для TS-Conf это уже сделано вместе с нормальными аррапатными спрайтами, зовем.

Valen

04.09.2015, 14:34

Блиттер не позволяет легко переделывать игры на Спектруме.

Что с блиттером переделывать - копаетесь в игре.
Что с клэшингом - тоже копаетесь.

AndyD

04.09.2015, 15:11

У меня вот вопрос - как быть тысячам пользователей Spectrum Vega games console без Метеора? )))
Раз они ее купили,то им нужен был чисто спек без наворотов.
Ответ: пыриться в старые игры.

zx-kit

05.09.2015, 08:32

Подведу итоги, что запланировано для 1 этапа расширения графики на эмуляторе и в видеокарте "Meteor Graphics":

Режимы:
Разрешение экрана 256х192 точек.
7 слоев для расширенной графики + 0 слой для стандартной. Каждый слой можно включить или выключить для отображения на экране. На выключенных слоях можно подготавливать изображение для следующего кадра игры, а затем включить.
С точки зрения программиста на экране рисуется сразу по 8 точек. Адреса байтов стандартного экрана Спектрума. Текущий слой для рисования указывается в переменной current_layer.
Для устранения клешинга атрибутов тайлы рисуют в слое с меньшим номером, а спрайты с большим и используют режим "2 цвета + маска". Для изображения спрайтов по новым координатам сначала программно стирают спрайт по старым координатам - восстанавливают прозрачность слоя.
Текущий режим цвета в переменной color_mode.
Режимы цвета для 1 ступени 1 бит на цвет точки: "1 цвет + прозрачный", "2 цвета" и "2 цвета + маска".
В расширенной графике только один байт атрибутов, а не 768. Записывается в переменную attribute - он задает цвета рисуемых далее точек.
Для режимов "2 цвета" и "2 цвета + маска" атрибут соответствует стандартным цветам.
Для режима "1 цвет + прозрачный" атрибут задает цвет закраски 1-15 + 0 как прозрачный.
Графические переменные для управления расширенной графикой расположены в области ПЗУ.
Стандартная графика: с адреса 4000, тип адресации - стандартный, байт атрибута - стандартный.
Расширенная графика: с адреса 4000, тип адресации - стандартный или с адреса 0000 с линейной адресацией, байт атрибута для режимов с 2 цветами на байт - стандартный.
Линейный режим упрощает и ускоряет вывод тайлов и спрайтов.

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

---------- Post added at 10:32 ---------- Previous post was at 09:42 ----------

У меня вот вопрос - как быть тысячам пользователей Spectrum Vega games console без Метеора? )))
Также как и без ReVerSE !
Ты когда угомонишься ? Не помогаешь - так хоть не мешай !

Alex Rider

06.09.2015, 00:34

Для режимов "2 цвета" и "2 цвета + маска" атрибут соответствует стандартным цветам.
zst, а можно все-таки сразу сделать палитры для слоев? Типа, атрибуты в слое задают не стандартные цвета Спектрума, а индексируют rgb-цвета из одной из 16 палитр, индекс которой задается для каждого слоя в переменных. Чтобы потом не переперепеределывать игры. И, вроде, хотели еще сделать "слой -1" с rgb-цветом (подложка).

zx-kit

06.09.2015, 06:46

zst, а можно все-таки сразу сделать палитры для слоев? Типа, атрибуты в слое задают не стандартные цвета Спектрума, а индексируют rgb-цвета из одной из 16 палитр, индекс которой задается для каждого слоя в переменных. Чтобы потом не переперепеределывать игры. И, вроде, хотели еще сделать "слой -1" с rgb-цветом (подложка).
ОК. Надо подумать. Вопрос не простой. Надо разработать команды загрузки палитр. Какие цвета и палитры будут после RESETа. Возможно лучше это оставить на 2 ступень расширения графики.

Добавил переменные для выбора номера палитры в каждом слое:

3F10 layer0_pl - номер палитры для слоя 0
3F11 layer1_pl - номер палитры для слоя 1
3F12 layer2_pl - номер палитры для слоя 2
3F13 layer3_pl - номер палитры для слоя 3
3F14 layer4_pl - номер палитры для слоя 4
3F15 layer5_pl - номер палитры для слоя 5
3F16 layer6_pl - номер палитры для слоя 6
3F17 layer7_pl - номер палитры для слоя 7
3F18 layer8_pl - номер палитры для слоя 8

Reobne

06.09.2015, 12:27

Reobne

06.09.2015, 15:38

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

zx-kit

06.09.2015, 17:50

zst, Что такое первичная палитра, что такое строка первичной палитры, которая выбирается переменной [3FF5 attribute - цветовой атрибут]? Прошу прощения, если эта информация уже была.

Вопрос с палитрами еще не до конца проработан. Переменная attribute определяет, какими цветами будут рисоваться точки. Но в разных режимах цвета по-разному:
1 цвет - номер цвета 0-15
2 цвета - стандартный атрибут
3-4 цвета - тут уже в одном байте не опишешь. Это уже маленькая палитра из четырех байтов или строка в первичной палитре.
7-8 цветов - в палитре 8 байтов
15-16 цветов - в палитре 16 байтов

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

Во всех слоях точки описаны 8 битами, то есть может быть 255 цветов. А ВидеоЦАП у нас будет 15-ти битный. То есть тут тоже можно добавить палитру. Пока она называетс палитра VGA.

Кроме этого Alex_Rider предложил на каждый слой свою палитру для двухцветных режимов. Давайте подумаем, как лучше все спроектировать.

Тема уже большая, глаза разбегаются. Как-то бы собрать всё в один документ. И добавить-бы макетов общих функциональных схем...
В первом посте я собираю ссылки на важные страницы темы с текущим описанием новых режимов. Это все в процессе корректировки и уточнения. Потом можно будет собрать это все в файл LibreOffice Writer или OpenOffice Writer c содержанием и ссылками по документу и преобразовать в PDF. Там выглядит лучше, чем в таблице. Схем наверно не будет. Это трудно описать схемой. Вместо схем описание словами.

Nesser

06.09.2015, 18:03

zx-kit

06.09.2015, 18:10

Ну как там? :)

Что бы переделывать старые игры достаточно 256x192x1 байт на цвет -49 152 байт
При чём скорость заполнения должна быть не менее 49152*50*5=~12 мбайт/сек, если принять спрайт размером 8x8 пикс заполняемый аппаратно при помощи спец DMA переносящий спрайты, то проц при 3,5 мГц успеет высчитать от силы 400-500 спрайтов в кадр, то есть по факту даже не успеет заполнить экран, он даже задний фон не успеет дорисовать.
Значит для этого нужен сторонний проц который подготавливает координаты для проца который их выводит? а что тогда должен делать Z80 ? :)
Играть музыку на бипере? :D
Пока давайте не будем гнаться за Денди. Z80 прекрасно справляется с работой по рисованию тайлов и спрайтов. Ведь так ? Игры вроде работают ? В чем проблема - ведь Z80 успевает ? Спрайты также рисуются с масками.

В новых режимах он также и будет успевать. Плюс мы ему сделали такие режимы, в которых он может экономить время на некоторых операциях. И Z80 пишет байтами на 8 точек, а не на одну ! Это внутри видеокарты каждая точка представлена байтом, а для Z80 одним или 2-4 битами.

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

Eagle

06.09.2015, 18:11

а что тогда должен делать Z80 ?
Рулить внешними устройствами: опрашивать клавиатуру, пулять данные в AY, в видеокарту, пулять биты в бипер. Очевидно же. :)

zx-kit

06.09.2015, 18:32

При трех цветах на спрайт + прозрачный скорость рисования будет достаточно высокая и качество достаточно хорошее. Всего 2 бита на цвет точки.
А сейчас в играх всего два цвета на спрайт + клешинг. И тоже 2 бита на цвет точки.

Nesser

06.09.2015, 19:29

В том то и прикол что он НЕ УСПЕВАЕТ рисовать :)
Спрайты запихиваются в лучшем случае при помощи стека, в худшем при помощи LDI.
Но даже в идеальном случае не получается заполнить весь игровой экран за 1 кадр, приходится уменьшать кол-во спрайтовой инфы на экране.
А в случае с 8 битной точкой объём увеличивается в 8 раз, поэтому вариант только спрайтовая система, то есть аппаратный драйвер перекидки спрайтов из одной линейной области памяти в область отображения по координатам, мало того треба ещё и второй экран, иначе некрасяво смотреть как это все перекидывается :) А тут встаёт проблема предварительной очистки неактивной области перед заполнением спрайтами.

---------- Post added at 19:58 ---------- Previous post was at 19:58 ----------

А 2 бита на цвет точки какой смысл? 4 цвета на точку? ляпота :)

---------- Post added at 20:06 ---------- Previous post was at 19:58 ----------

Эээмм всё ещё хуже?
0 - Чёрный
1 - Серый
2 - Белый
3 - Прозрачный

Так что ли?

---------- Post added at 20:13 ---------- Previous post was at 20:06 ----------

И как понять аппаратный скроллинг фона? То есть я должен подготовить в памяти картинку 4096x192 а некое устройство будет его кидать на экран, а потом сверху кидать спрайты? И как эта штука будет перекидывать если к примеру у меня начало спрайта попадает не на 0 бит а к примеру на 6 бит?

---------- Post added at 20:14 ---------- Previous post was at 20:13 ----------

У денди кстати не плавный скроллинг, у него есть байт смещения вывода, 8 раз смещаешь а потом докидываешь новый спрайт, где же он плавный :)

---------- Post added at 20:29 ---------- Previous post was at 20:14 ----------

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