Что максимум можно выжать из КР580ВГ75 Intel 8275? Обсуждение

[freddy]

Спасибо, написали доходчиво. Я когда то имел дело с аркадными автоматами CAPCOM. Может помните систему CPS1 и игры Captain Commando, Street Fighter 2.
Там все упрятано в заказные чипы и выяснить толком ничего нельзя. Из того, что понял, оно имело низкое разрешение, мало одновременных спрайтов на экране, мало спрайтов в линии, но очень много цветов. На вид больше 256. За счет цветов оно выглядело очень сочно и играбельно. Судя по всему было 3 плоскости. 1 для фона, 2 для спрайтов. Фон был статичным, в основном (небо). В одной плоскости спрайтов были фигуры персонажей, в другой подвижный фон (скроллинг), который делался тоже спрайтами. Однако, чтобы это повторить на логике, нужно будет соорудить приличную конструкцию на большой плате, около 100 корпусов. Народной она не станет. Если соорудить более практичную конструкцию на FPGA или STM-32, то тоже никому не нужно будет. К примеру, меня за применение AVR затролили, мол не спортивно, читерство и т.д. Всё думали, что так изящно управлять ВГ75 можно с помощью безмозглого ВТ57. Ах,ах,ах, наивные...
Мне видится более упрощенный процесс формирования кадра. Будет два видеобуфера по 32кб. Из одного будет выводиться картинка, в другом будет рендериться следующий кадр. Буфера будут по очереди перекидываться по кадровому импульсу обратного хода мультиплексорами между рендером и видеогенератором. Видеогенератор тот самый естественно. Рендерер на 2х ВГ75. Одна будет выгребать из памяти спрайтов байты и класть в видеобуфер, вторая будет задавать смещение по X,Y в пределах одного закоместа. Чтобы передвигать на большее значение чем размер знакоместа, достаточно будет в текстовом буфере переписать номер спрайта в другую ячейку и если надо, задать необходимое смещение. Итого получится 80 спрайтов в линии, 4000 спрайтов на экране и возможность пересечения спрайтов в пределах одного знакоместа. По количественному показателю и разрешению экрана, CAPCOMы, NEO-GEO, NES, SNES нервно курят. У нас то технология еще из 70-х )) Размер спрайта 8х16. Сдвигать по X,Y можно одним и тем же сумматором. Он должен прибавлять Y*80+X к адресу записи в видеобуфер. X=(0..7), Y=(0-15). Игровая логика сводится к тому, чтобы перемещать номера спрайтов и их смещение в пределах знакоместа по текстовому буферу. Детектор столкновений при этом проще всего программный. По условию если задано смещение и смещение следующего спрайта в строке меньше смещения предыдущего спрайта, то произошло столкновение.
Бред короче. Это 3 ВГ75 и штук 40 корпусов мелкой логики. Нафиг не нужно.

- - - Добавлено - - -

К стати насчет таймингов всей этой хреновины... Вывод кадра+рендеринг следующего кадра (одновременно). Работа игровой логики асинхронно, разумное время, для получения разумного FPS. По завершению рассчетов игровой логики, по началу VRTC быстрое скармливание текстового буфера рендереру, например с помощью DMA. Рендерер будет работать два прохода. К примеру на первом проходе будет весь кадр заливать фоном, на втором заливать подвижные фигурки. Это нормально, кадровая частота 70Гц, поэтому будет 35 FPS, нормально как бы. Главное чтобы 8080 осилил стлько

- - - Добавлено - - -

В общем без разницы что он будет делать два прохода. Можно ему по номеру прохода подкидывать разную память спрайтов и текстовый буфер, тогда ваще будет круто, много графики. ОЧЕНЬ МНОГО ГРАФИКИ!

[SegaBoy]

Вклинюсь с небольшим оффтопом, но всё же по теме - что максимум можно выжать из ВГ75. Не нашёл на форуме обсуждалось или нет.
Несмотря на то, что внутренние буферы ВГ75 рассчитаны только на 80 символов и в параметре ННННННН не рекомендуется ставить число больше 79 (80 символов в строке) - имеется возможность выставить там любое значение вплоть до 127 (128 символов в строке). Внутренние счётчики ВГ75 честно отрабатывают и выдают сигнал HRTC именно через то количество CCLK (character clock), как будет задано в этом параметре.

[bigral]

... Видеогенератор тот самый естественно. Рендерер на 2х ВГ75. Одна будет выгребать из памяти спрайтов байты и класть в видеобуфер, вторая будет задавать смещение по X,Y в пределах одного закоместа. Чтобы передвигать на большее значение чем размер знакоместа, достаточно будет в текстовом буфере переписать номер спрайта в другую ячейку и если надо, задать необходимое смещение. Итого получится 80 спрайтов в линии, 4000 спрайтов на экране и возможность пересечения спрайтов в пределах одного знакоместа. По количественному показателю и разрешению экрана, CAPCOMы, NEO-GEO, NES, SNES нервно курят. У нас то технология еще из 70-х )) Размер спрайта 8х16. Сдвигать по X,Y можно одним и тем же сумматором. Он должен прибавлять Y*80+X к адресу записи в видеобуфер. X=(0..7), Y=(0-15). Игровая логика сводится к тому, чтобы перемещать номера спрайтов и их смещение в пределах знакоместа по текстовому буферу. Детектор столкновений при этом проще всего программный. По условию если задано смещение и смещение следующего спрайта в строке меньше смещения предыдущего спрайта, то произошло столкновение.
Бред короче. Это 3 ВГ75 и штук 40 корпусов мелкой логики. Нафиг не нужно....

В общем без разницы что он будет делать два прохода. Можно ему по номеру прохода подкидывать разную память спрайтов и текстовый буфер, тогда ваще будет круто, много графики. ОЧЕНЬ МНОГО ГРАФИКИ!

Если честно то я ничего из этого не понял. В моем понимании ВГ75 (как просто обьяснил vinxru) это буфер на 2 строчки по 80 кодов (7bit-ных) + 4bit счетчик строк для тайла. И пока в одну строчку он заливает коды (обычно с использованием внешнего DMA) со второй он может выдавать до 16 раз по очереди от 0 до 79-го коды на выходе (причем 4bit счетчик считающий сколько раз он выдал эту строку тоже выведен наружу и обычно используется как младшая часть адреса в памяти тайлов). Ну и эти коды используют как старшую часть адреса тайлов. И как тогда можно сделать это: "Одна будет выгребать из памяти спрайтов байты и класть в видеобуфер, вторая будет задавать смещение по X,Y в пределах одного закоместа" ?

[Titus]

Внутренние счётчики ВГ75 честно отрабатывают и выдают сигнал HRTC именно через то количество CCLK (character clock), как будет задано в этом параметре.

Куда при этом приходят указатели буферов?

[SegaBoy]

Куда при этом приходят указатели буферов?

Не совсем понял вопрос. Указатели внутренних буферов на 80 символов?
Если строка содержит более 80 символов, то ВГ75 продолжает запрашивать символы у контроллера ПДП. При этом новые символы затирают содержимое буфера с самого начала. Точно такая же ситуация происходит в режиме прозрачных атрибутов, если накидать в строку более 16 атрибутов.

[Titus]

При этом новые символы затирают содержимое буфера с самого начала.

Понятно. Т.е. указатель позиции в буфере закольцовывается переходя на 0-й адрес, а не останавливается или вообще сбивается.

- - - Добавлено - - -

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

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

[Advertiser]

[SegaBoy]

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

Да, но принцип тот же самый.
Например у нас в строке 78 символов и 32 атрибута (вместо 16-ти) в "прозрачном" режиме. Значит ВГ75 настроен на 78 символов в строке, а ПДП на 32 больше. Когда ВГ75 получает атрибут, то помещает его в буфер символов, а следующий за ним символ в буфер фифо (размер которого 16 символов). Получив в дальнейшем 17-й атрибут - так же поместит его в буфер символов, а следующий уже за этим атрибутом символ перезапишет в фифо (или вытолкнет) тот самый первый. В итоге к концу загрузки такой строки у нас будут потеряны 16 символов - потому что размер фифо равен 16.
Аналогичная ситуация с длиной строки в 128 символов. Получив от ПДП 81-й символ, ВГ75 поместит его на место первого и так далее до 128-го. В итоге у нас будут потеряны первые 48 символов (точнее они будут равны последним 48-ми).
Применить на практике это можно, например, так. После HRTC можно "подсунуть" ВГ75 фейковые 48 символов (а само это время использовать на обратный ход и бланкирование). А вот с 49-го по 128-й уже выдать строку нормальных символов из видеопамяти. Не факт что это вообще как-то применимо или кому-то нужно.

Меня лично смущал вопрос - что будет если указать ВГ75 параметр строки больше 80-ти - будет он его игнорировать (считать равным 80, даже если указываешь больше) или будет считаться опять с нуля (например вместо 96 восприниматься как 16). В итоге просто проверил на практике - подключил логический анализатор к Апогею и начал менять параметры ВГ75. В какой-то момент синхронизация сорвалась, но анализатор показал сколько CCLK проходит между HRTC и что при этом выдаётся на CC6..CC0.

[freddy]

И как тогда можно сделать это: "Одна будет выгребать из памяти спрайтов байты и класть в видеобуфер, вторая будет задавать смещение по X,Y в пределах одного закоместа" ?

Также как сделано в видеогенераторе на 2х ВГ75. В текстовом буфере будет 1 байт - номер спрайта, 2 байт - не атрибуты, а смещение по X,Y. Нам как раз 7бит и надо. При этом ноги СС0-СС6 атрибутной ВГ75 будут заведены не на цвета и прочее, а на сумматор, который будет складывать ареса от первой ВГ75 и второй ВГ75 и выставлять на шину адреса видеобуфера кадра. Далее данные из ЗГ, т.е. теперь уже хранилища спрайтов, будут задвигаться не в сдвиговый регистр а записываться в видеобуфер кадра.
Спрайтохранилище вычитываться будет первой ВГ линейно, по классической уже схеме. В видеобуфер кадра будет попадать или линейно без заданных смещений или не линейно, когда смещения заданы.

- - - Добавлено - - -

Применить на практике это можно, например, так. После HRTC можно "подсунуть" ВГ75 фейковые 48 символов (а само это время использовать на обратный ход и бланкирование). А вот с 49-го по 128-й уже выдать строку нормальных символов из видеопамяти. Не факт что это вообще как-то применимо или кому-то нужно.

В свое время я от такого гемороя отказался в пользу пяти корпусов мелкой логики и более простой и скоростной логики работы DMA. Было это давно, еще когда я разрабатывал на одной ВГ75. Мысли точно не помню, но смутил более длинный, в 1,5 раза цикл прокачки экрана. А я гнался за максимальной скоростью. Еще кажись тайминги по VRTC нормально не мог соблюсти. В итоге имеем полностью железный вариант с очень жестким соблюдением промышленного стандарта VGA.

[Titus]

Аналогичная ситуация с длиной строки в 128 символов. Получив от ПДП 81-й символ, ВГ75 поместит его на место первого

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

[freddy]

Если честно то я ничего из этого не понял.

Я попытался изобразить.

Такое может стать народным. Но всеравно конструкция получится для большинства не подъемная. Еще не забываем о логике управления дабл буферингом буферов кадра, логике записи в спрайтовую память, в бывший текстовый буфер, а еще видеогенератор на 3-й ВГ75, который будет выводить отрендереный буфер кадра на экран... как не упрощай, получается сложно.
Вот можете взглянуть на мой блок DMA, не тормозящий процессор. Он выполнен по собственной архитектуре с "изолированной видеошиной"(с) 2017г.
2vg_dma.PDF
Для спрайтового движка как раз то что надо. Пропускная способность в текстовый буфер не менее 1,5Мб/с (375FPS!!! это не менее, возможно и более ), полностью асинхронная, не зависимая работа проца и видеокарты. Но как же сложно и громоздко!
И это только вершина айсберга.

- - - Добавлено - - -

На горизонте виднеется лаптя размером с CAPCOMовский CPS3.

- - - Добавлено - - -

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