Moderator: Shaos
Я собрался создать технологию будущего, имеющую душу прошлого (Spirit Retro)TolikTrek wrote:Серьёзно? То есть ты создашь технологию 2023 года?)))Shaos wrote:Повторение старого спринтера "as is" считаю тупиковой идеей - на носу уже вторая четверть XXI века, а вы там всё с технологиями 90х носитесь...
Или технологию 91-ых в 2023? Хм... странно... мы возимся с ретро компом потому что ностальгия и прикольно. Почему ты решил создать что-то типа древнее, чего в древности не существовало?
Вот примерился прям на девайсикеShaos wrote: Или линейно усредняя по RGB составляющим:
Что выглядит терпимее:
Однако 736 пикселов в ширину при таком подходе не влезает (что есть максимум в моих "запредельных" режимах) - только 720 (усреднённые в 480 экранных пикселов), что наверное не так уж и страшно...
Разбираюсь с верилоговской прошивкой бейджа - как я уже писал ранее там логики 40% свободно и внутренней памяти порядка 40 килобайт ещё есть.Shaos wrote:Заодно пофиксил багу в родной прошивке бейджа, из-за которой строчки пикселов из фреймбуфера выводились через DMA не все, а как будто только нечётные и дважды...
А вот как оно вживуюShaos wrote:Однако 736 пикселов в ширину при таком подходе не влезает (что есть максимум в моих "запредельных" режимах) - только 720 (усреднённые в 480 экранных пикселов), что наверное не так уж и страшно:
И на экране большого телека через HDMI (чёрные поля слева и справа отрезал):Shaos wrote:А вот как оно вживуюShaos wrote:Однако 736 пикселов в ширину при таком подходе не влезает (что есть максимум в моих "запредельных" режимах) - только 720 (усреднённые в 480 экранных пикселов), что наверное не так уж и страшно:
Вывод на HDMI ещё занимается апскейлом (увеличением разрешения) и делает он это судя по всему неравномерно, поэтому на экране телевизора некоторые пикселы выглядят "толстыми", по сравнению с остальными - на экранчике девайсика такого эффекта нет - все пикселы одинаково маленькие и квадратненькиеShaos wrote: Вот примерился прям на девайсике
Алгоритм превращения 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 не все, а как будто только нечётные и дважды...
На самом деле в текстовом режиме будет не 80 чтений в пределах одной строки, а 80 чтений по ДВА 32-битных слова (8 байт, чтобы вычитать букву из знакогенератора) в пределах горизонтального ряда квадратиков (8 строк), так что наверное надо будет конвеерно готовить цепочку квадратиков 8x8 разве что под это дело надо будет найти 480x8=3840 байт (причём дважды ибо конвеер). Однако для графических режимов всё-таки придётся вычитывать построчно, причём заранее подсчитав если видеопамять идёт линейно через несколько квадратов, то читать её надо за "один присест" одним DMA запросом. Усложняет задачу ещё и то, что теоретически текстовые и графические режимы могут перемешиваться и нужно уметь правильно настраивать DMA по ходу пьесы.Shaos wrote: Я хочу сделать включаемую отдельно Спринтеровскую нарезку фреймбуфера квадратами 8х8 пикселов - чтобы это получилось, надо оценить скорость перенастройки DMA, которое сейчас делается один раз для каждой строки, а мне надо до 80 раз в пределах одной строки (чтобы поддержать не только линейные графические режимы Спринтера, но и текстовые). В худшем случае мне придётся сделать конвейер, при котором в тени будет готовиться новая строка из кусочков памяти, пока аппаратный рисовальщик будет рисовать текущую строку. Ну и кроме того я хочу прямо в железе сделать сплющивание 720-пиксельных 16-цветных режимов в 480 пикселов по алгоритму, который я описал чуть раньше (и уже реализовал программно). Спринтеровские описатели экранов и палитра (у бейджовского фреймбуфера она одна, но я знаю как поддержать 4 - надо просто сделать массив цветов палитр длиннее) будут находится внутри FPGA (что должно потребовать как раз порядка 40 килобайт).
Ну это штука редкая - я его пока хочу просто задействовать для обкатки своих верилоговских экспериментов на тему спринтераfifan wrote:Shaos, а где такой бадж достать?
