nedoPC.org

Я собрался создать технологию будущего, имеющую душу прошлого (Spirit Retro)

Вот примерился прям на девайсике


Алгоритм превращения 720 16-цветных пикселов по горизонтали в 480 256-цветных (пока реализовано софтово) - берём каждые 3 пиксела (P1,P2,P3) и превращаем их в 2 примешивая средний пиксел половинчато:
NEW1 = (P1 + 0.5*P2)/1.5
NEW2 = (0.5*P2 + P3)/1.5
Тут конечно же речь идёт об усреднении каждой цветовой составляющей:
NEWCOLOR1 = (COLOR1 + COLOR1 + COLOR2)/3 (для каждой цветовой составляющей R,G и B)
NEWCOLOR2 = (COLOR2 + COLOR3 + COLOR3)/3 (для каждой цветовой составляющей R,G и B)
И это можно сделать вообще без деления воспользовашись фиксированной точкой (сдвинутой влево на 8 бит):
NEWCOLOR1 = (((COLOR1 + COLOR1 + COLOR2)<<8)*85)>>16
NEWCOLOR2 = (((COLOR2 + COLOR3 + COLOR3)<<8)*85)>>16
Тут 85 это 0.333 в формате фиксированной точки 16.8
Но делать эти расчёты надо не над каждый пикселом, а в самом начале один раз и над палитрой
Берём первоначальную 16-цветную палитру и создаём из неё новую 256-цветную, примешивая цвета по вышестоящей формуле - для каждой пары этих 16 цветов беря первый с весом 2 и второй с весом 1 - далее при выводе изображения в такой палитре с сужением в 1.5 раза надо просто вместо трёх пикселов с номерами цветов C1,C2,C3 из старой 16-цветной палитры нарисовать 2 пиксела их новой большой палитры получив номера таким образом:
NEWCOLOR1 = (C1<<8)|C2
NEWCOLOR2 = (C3<<8)|C2
Вобщем как-то так и оно как видно даже работает

P.S. Вот как это на телеке по HDMI выглядит:



P.P.S. Заодно пофиксил багу в родной прошивке бейджа, из-за которой строчки пикселов из фреймбуфера выводились через DMA не все, а как будто только нечётные и дважды...

Вот бейдж в полный рост

Разбираюсь с верилоговской прошивкой бейджа - как я уже писал ранее там логики 40% свободно и внутренней памяти порядка 40 килобайт ещё есть.

Графика бейджа поделена на 5 слоёв - вот они в порядке вывода на экран (всё смешивается через полноценный альфаканал):

1. Фоновый 24-битный цвет - он просвечивает если поверх него всё прозрачное
2. Фреймбуфер 480x320, который копируется через DMA построчно из внешнего ОЗУ
3. Слой тайлов A (30x20)
4. Слой тайлов B (30x20)
5. Спрайты с масштабированием

Источник: https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/doc/gfx.md

Карты тайлов для слоёв A и B, а также сами тайлы (16-цветные картинки 16x16), которые также используются и как спрайты, хранятся внутри FPGA (максимум может быть 512 разных тайлов и первые 128 повторяют ASCII), а фреймбуфер читается из внешнего ОЗУ, причём pitch (шаг между строчками в памяти) может быть больше длины строки (480), что позволяет делать горизонтальный скролл хоть через всю память! Тайлы всегда 16-цветные, а фреймбуфер может быть как 16-цветным, так и 256-цветным и для него используется отдельная от тайлов палитра (хоть обе они и хранятся в одном массиве цветов длиной 512 ячеек).

Я хочу сделать включаемую отдельно Спринтеровскую нарезку фреймбуфера квадратами 8х8 пикселов - чтобы это получилось, надо оценить скорость перенастройки DMA, которое сейчас делается один раз для каждой строки, а мне надо до 80 раз в пределах одной строки (чтобы поддержать не только линейные графические режимы Спринтера, но и текстовые). В худшем случае мне придётся сделать конвейер, при котором в тени будет готовиться новая строка из кусочков памяти, пока аппаратный рисовальщик будет рисовать текущую строку. Ну и кроме того я хочу прямо в железе сделать сплющивание 720-пиксельных 16-цветных режимов в 480 пикселов по алгоритму, который я описал чуть раньше (и уже реализовал программно). Спринтеровские описатели экранов и палитра (у бейджовского фреймбуфера она одна, но я знаю как поддержать 4 - надо просто сделать массив цветов палитр длиннее) будут находится внутри FPGA (что должно потребовать как раз порядка 40 килобайт).

P.S. Там по ходу для палитры уже используются ДВА 16-килословных блока (причём в слове 18 бит)! Можно загрубить палитру до 18 битов вместо 24 и освободить тем самым 32 килобайта, ну или просто массив палитр увеличить с 512 до 4096 без увеличения расхода памяти, чтобы точно хватило места и для палитры тайлов/спрайтов, и для 8 палитр для фреймбуфера (4 графических и 4 текстовых - как в Спринтере)...

P.P.S. А можно поддержать 64 спринтеровских палитры одновременно (я знаю как добавить 4 скрытых бита выбора палитры в каждый квадратик) - это как раз будут те самые 16 килослов - причём начало памяти палитр оставить под обычные 2 палитры бейджа для тайлов/спрайтов и фреймбуфера (имеющие соответственно фиксированное и программируемое смещение с начала массива цветов), а в парадигме Спринтера можно расположить 24 независимых палитры в области справа от области описателей экрана - их можно пронумеровать номерами от 40 до 63 (60-63 это обычные спринтеровские палитры для текста, а 56-59 это обычные спринтеровские палитры для графики) - более младшие номера палитр будут перекрываться с областью описателей - в будущем их можно разрулить включая-выключая видимость тех или иных областей для процессора, а пока можно воспользоваться 4 дырками в зоне описателей и разместить там ещё 4 палитры с номерами 34,35,36,37

А вот как оно вживую

И на экране большого телека через HDMI (чёрные поля слева и справа отрезал):


(как можно видеть на HDMI слева появилась белая полоса - перенахлёст с правого края?)

P.S. И ещё фотка в полный рост:

Вывод на HDMI ещё занимается апскейлом (увеличением разрешения) и делает он это судя по всему неравномерно, поэтому на экране телевизора некоторые пикселы выглядят "толстыми", по сравнению с остальными - на экранчике девайсика такого эффекта нет - все пикселы одинаково маленькие и квадратненькие

На самом деле в текстовом режиме будет не 80 чтений в пределах одной строки, а 80 чтений по ДВА 32-битных слова (8 байт, чтобы вычитать букву из знакогенератора) в пределах горизонтального ряда квадратиков (8 строк), так что наверное надо будет конвеерно готовить цепочку квадратиков 8x8 разве что под это дело надо будет найти 480x8=3840 байт (причём дважды ибо конвеер). Однако для графических режимов всё-таки придётся вычитывать построчно, причём заранее подсчитав если видеопамять идёт линейно через несколько квадратов, то читать её надо за "один присест" одним DMA запросом. Усложняет задачу ещё и то, что теоретически текстовые и графические режимы могут перемешиваться и нужно уметь правильно настраивать DMA по ходу пьесы.

Другой сложный момент заключается в том, что например расположенная выше картинка (FN с запредельной рамкой-оконтовкой) на реальном Спринтере состоит из квадратиков разной цветности и разрешения - FN имеет высокое разрешение и 16-цветные пиксела, а рамка - низкое разрешение и 256-цветные пикселы (а в примере выше я просто привёл рамку к высокому разрешению и 16-цветам, чтобы не усложнять пример). Так как я предполагаю "сплющивать" высокое разрешение, а низкое оставлять "как есть", мне придётся отслеживать встречались ли в пределах кадра (по видимому прошлого) квадратики высокого разрешения и если был хотя бы один, то надо будет включать "сплюскивание" для квадратиков повышенной чёткости, а квадратики пониженной чёткости придётся "апскейлить", превращая каждые 3 пиксела в 4 (повторяя каждый третий пиксел 2 раза). Если же весь экран состоит из квадратиков пониженной чёткости (и повышенной цветности с 8-битными пикселами), то графика должна выводиться как есть (выдавая в пределе 448 пикселов в ширину - максимум того, что может себе позволить описатель экранов Спринтера, состоящий из 56 квадратиков по горизонтали).

Ещё одна чёрно-белая 16-цветная 736x288 картинка "сплюснутая" в 256-цветные 480x288



P.S. На телеке оно конечно же уже не то...



(возможно надо что-то с гаммой сделать - на телеке более контрастное оно)

Форкнул репу бейджа себе на гитлаб (в моей репе уже есть мой фикс):

https://gitlab.com/shaos/hacking_hadbadge2019_fpgasoc

а также создал проект на Хакадее:

https://hackaday.io/project/193074-spirit-retro-handheld

Shaos, а где такой бадж достать?

Ну это штука редкая - я его пока хочу просто задействовать для обкатки своих верилоговских экспериментов на тему спринтера
А так то это опенсорц сделанный в кикаде - если очень надо, то можно заказать свои платы и собрать
https://github.com/Spritetm/hadbadge2019_pcb

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

Герберов не вижу - надо генерить
А вообще китайцы наверное и кикад возьмут?

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