nedoPC.org

Ну вот кстати игл многие китайцы берут

P.S. Хм, чото поглядел по китайцам что знаю - действительно только герберы стали брать
А вот американцы до сих пор берут и герберы, и иглы, и кикад:



P.P.S. У меня в дебияне стоит KiCAD 5.0.2 - могу научиться генерить герберы, если надо, но пока не въехал:



P.P.P.S. Вот на JLCPCB есть объяснялка как в пятом кикаде герберы делать: https://jlcpcb.com/help/article/10-How-to-generate-Gerber-and-Drill-files-in-KiCad-5

Кстати у бейджа есть интерфейс "картриджа" - у меня например сзади воткнут картридж-макетка со вторым последовательным EEPROM 16MB, который также как и бортовая EEPROM подключается по USB к компу как флеш-накопитель (я туда свои эльфы на погонять заливаю), а так там ног полно (30 штук) - можно поди и Z80 живой прицепить

Эти 30 сигналов GENIO в текущей версии прошивки программно управляются, но прошивку можно и "подковырять"

Придумал алгоритм, который вот это всё будет учитывать на лету - вобщем у нас будет флаг global_hires, который устанавливается в 1 если в предыдущем кадре был хотя бы один квадратик высокой чёткости (16x8 16-цветных пикселов) - в начале следующего кадра устанавливаются начальные условия в зависимости от состояния этого флага:

Если global_hires=0, то мы имеем зацикленную в кольцо последовательность описателей 112 квадратиков начиная с номера 97, по которой мы будем двигаться с шагом 2 (это позволит иметь по горизонтали максимум 448 256-цветных пикселов - можно это назвать "суперзапредельным" режимом Спринтера, который невозможен на старом Спринтере), причём если по ходу рендеринга попадутся квадратики высокого разрешения, то они будут выведены неправильно в пределах этого кадра, однако после этого флаг global_hires будет установлен в 1, и следующий кадр будет показан правильно (в режиме высокой чёткости и со "сплюснутыми" пикселами).

Если global_hires=1, то мы стартуем с квадратика 107 и идём до квадратика 86 (после номера 111 будет идти номер 0), игнорируя квадратики с номерами от 87 до 106 (они будут за пределами видимого экрана) - в этом режиме надо пропустить первые 3 байта, т.е. из самого левого квадратика будут показаны только 5 256-цветных пикселов либо 10 16-цветных пикселов (в зависимости от битов режима в текущем квадратике и столько же мы потеряем с правого края), либо для простоты можно стартовать с самого левого пиксела, но тогда справа мы потеряем 16 16-цветных пикселов вместо 10 (т.к. при таком подходе можно показать только 720 "сплюснутых" пикселов из 736).

По ходу движения по квадратикам мы будем генерировать четвёрки 256-цветных пикселов (т.е. 1 байт на пиксел), которые можно назвать бинарно 00, 01, 10 и 11:

• Чтобы получить пиксел 00 мы просто копируем текущий пиксел источника как есть (там будет либо 1 полноцветный пиксел либо 2 16-цветных);
  
• Чтобы получить пиксел 01 мы смотрим на состояние флага global_hires и битов режима текущего квадратика:
  
  • если global_hires=0 или текущий квадратик 256-цветный, то копируем текущий пиксел источника как есть (там будет один 256-цветный пиксел);
  • если global_hires=1 и текущий квадратик 16-цветный, то в младший ниббл копируемого байта надо записать младший ниббл из предыдущего байта (тут может произойти путаница палитр, если они были разные у предыдущего и текущего байтов);
• Чтобы получить пиксел 10 мы смотрим на состояние флага global_hires, битов режима текущего квадратика и режим предыдущего пиксела (мы могли попасть на границу квадратиков):
  
  • если global_hires=0 или текущий квадратик 256-цветный:
    
    • если предыдущий пиксел тоже был 256-цветным, то копируем текущий пиксел источника как есть (там будет один 256-цветный пиксел);
    • если предыдущий пиксел был 16-цветным, то копируем байт, составленный из младших нибблов предыдущего байта (с сохранением его палитры);
  • если global_hires=1 и текущий квадратик 16-цветный:
    
    • если предыдущий пиксел тоже был 16-цветным, то копируем байт, составленный из младшего ниббла предыдущего байта и старшего ниббла текущего байта (тут может произойти путаница палитр, если они были разные у предыдущего и текущего байтов);
    • если предыдущий пиксел был 256-цветным, то копируем байт, составленный из старших нибблов текущего байта;
  • если global_hires=1, то инкремент указателя источника в данном такте НЕ ПРОИЗВОДИТСЯ (т.е. мы в глобальном режиме высокой чёткости идём тройками байт источника, а при низкой чёткости - четвёрками)
• Чтобы получить пиксел 11 мы смотрим на состояние флага global_hires и битов режима текущего квадратика:
  
  • если global_hires=0 или текущий квадратик 256-цветный, то копируем байт как есть;
  • если global_hires=1 и текущий квадратик 16-цветный, то в копируемом байте переставляем нибблы местами;

Также при копировании номера палитры (0...63) вместе с байтом графики в режиме global_hires=1 надо будет обнулять старший бит номера палитры если текущий квадратик является 16-цветным (таким образом мы будем превращать 16-цветную палитру в комбинированную 256-цветную, которая будет заполняться программно в палитрах с номерами N-32) либо пока оставить номер палитры нетронутым, но тогда надо быть готовым, что заполнив 16-цветную палитру программно, мы будем читать обратно не те RGB значения, которые были туда записаны.

P.S. Чтобы не было перепутывания палитр на границах "сплюснутых" квадратиков в многопалитровых 16-цветных картинках надо делать смену палитр с шагом 48 16-цветных пикселов, либо делать так, чтобы в пикселах на границах квадратиков использовлись цвета, которые имеют одинаковые RGB значения в разных палитрах, либо чередовать 16-цветные квадратики с 256-цветными - в этом случае границы будут без цветных помех.

Всё что написано выше имеет отношение только к графическим режимам (4 бита на пиксел либо 8 бит на пиксел), а для текстовых режимов (1 бит на пиксел - частным случаем текстового режима является режим ZX-Spectrum) надо делать по другому - там придётся забирать 8 байт знакогенератора нужного символа из внешней памяти и затем переиспользовать эти байты для формирования 8 графических строк в 4 разных палитрах (см. тут) - это относительно несложно для режима низкого разрешения (40 символов в строке), но будет вызывать трудности для режима высокого разрешения, при котором мы миксим соседние пикселы, чтобы влезть в 480 экранных пикселов. Возможно для такой прошивки надо вообще отказаться от подходов к текстовым режимам как в классическом Спринтере и либо остаться в рамках низкого разрешения текста 40x32 (60x36), либо сделать специальный режим высокого разрешения в котором не будет знакомест 8х8 (фактически чтобы попадать в сплюснутые квадратики ширина знакомест должна быть 5.333 пиксела или 3 знакоместа на каждые 16 пикселов).

Ну или самый прямой способ - забыть про 4 палитры по 256-цветов каждая, которые использовались в Спринтере для имитации досовских текстовых атрибутов (FRGBIRGB) и спринтеровских атрибутов (FIBRGBRG) - оба с мерцанием (можно сделать отключаемым) - и просто привести эту задачу к уже решёной - формировать аппаратно картинку байт на пиксел для режима низкого разрешения либо 2 байта на пиксел для режима высокого разрешения и далее работать по алгоритму, описанному выше. Комбинационная схема приводящая текст к нужному графическому виду может принимать на вход 8 битов строки знака, 8 битов атрибутов, 1 бит для индикации досовские это атрибуты или спектрумовские, 1 бит мерцания (можно предусмотреть ещё один бит, отключающий мерцание - в этом случае бит флеша будет задействован как яркость фона) и на выходе будет 8 четвёрок битов, которые будут обозначать 16-цветные пикселы - они годятся как есть для режима высокого разрешения, а для режима низкого разрешения к ним надо добавить по 4 нулевых бита на каждый пиксел. Каждые 4 бита цвета будут выбирать значения RGB из нужной 16-цветной палитры, т.е. палитра будет программно настраиваемая, хоть и одна (хотя можно воспользоваться скрытыми 4 битами на квадратик для выбора другой палитры - в этом случае можно иметь до 16 разных текстовых палитр в пределах экрана).

А вот так текст выглядит на бейдже (с рамкой):


И на телеке по HDMI (upscaled):

Вот как будет выглядеть "запредельноспектрумовский" режим 768x288 (в данном случае откушены средние 720 пикселов, который "сплюснуты" в экранные 480):


И на экране большого телека через HDMI с апскейлом:


P.S. А вообще это моё хитрое "сплюскивание", когда уменьшается количество пикселов по горизонтали, но увеличивается цветность (16 -> 256 цветов), выглядит на маленьком экранчике очень даже неплохо - может быть когда у меня таки дойдут руки до материнской платы Spirit Retro с VGA-выходом, то в первой версии так и сделать - ограничиться полуторным пиксельклоком 26.667 МГц вместо 40.0 и 512 пикселами по горизонтали? Правда настоящий Спринтеровский текстовый режим с 4 палитрами по 256 цветов каждая там также не выйдет - для него надо иметь полноценные 768 полноцветных пикселов по горизонтали без сплющивания...

P.P.S. А если взять пиксельклок 28 МГц, то можно заодно поддержать спец-режимы MiniWhiz и более "родные" частоты для Z80 - 14 МГц, 7 МГц, 3.5 МГц

Для воможности вывода произвольных RGB изображений (например JPG или полноцветные PNG) важно иметь универсальные палитры, способные аппроксимировать цвета без квантования - таких палитр за последние десяток лет я наизобретал 3 штуки:

• EGA2VGA.gpl - палитра в которой замешаны 16 егашных цветов (интерполяция 2 егашных пикселов в одну 256-цветную точку) - в ней лишь порядка 90 уникальных цветов;
• GigasRGBx.gpl - палитра составленная из цветов ZX-гигаскрина с учётом гаммы плюс некоторый набор других промежуточных цветов, чтобы покрыть дырки в цветовом пространстве;
• Uniform676G.gpl - равномерно распределённая палитра, выдуманная мною в мае 2013 года, в которой линейно замешаны 6 градаций красного, 7 градаций зелёного и 6 градаций синего, что даёт 252 цвета, плюс ещё 4 промежуточных градации серого (я их добавил сегодня).

Можно их попробовать на разных примерах без дизеринга (с выбором ближайшего цвета из палитры) и с дизеригом (по Флойду-Стейнбергу).

Вот оригинальная картинка:



Для сравнения берём только егашные 16 цветов:



EGA2VGA:



GigasRGBx:



Uniform676G:

Ещё одна картинка 384x288:



16 цветов EGA:



EGA2VGA:



GigasRGBx:



Uniform676G:

И ещё одна картинка 384x288:



16 цветов EGA:



EGA2VGA:



GigasRGBx:



Uniform676G:



Тут вроде как выходит, что Uniform676G лучше для Флойда-Стейнберга, а GigasRGBx лучше для приближённых цветов?

Кстати быстрый подбор цвета из палитры по входному значению RGB888 можно сделать внутри FPGA

P.S. Хотя например индекс цвета из палитры Uniform676G можно программно получить по простой формуле без поиска: INDEX=INT((R+25.5)/51)+INT((G+21.25)/42.5)*6+INT((B+25.5)/51)*42 (целочисленный вариант формулы см. тут)

P.P.S. И такой быстрый способ выбора цвета из палитры можно задействовать в нашем будущем графическом редакторе nedopixels

P.P.P.S. Палитру обозначенную выше как Uniform676G я выдумал в 2013 году и назвал её тогда "optimal", но сейчас вот думаю, что лучше назвать её словом UNIFORM (типа как равномерное распределение):
https://www.compuphase.com/unifpal.htm
В приведённой заметке подход с равномерным перемешиванием цветов называется "6x6x6 RGB color cube", которым также является так называемая "Web Safe Palette", которая состоит из 216 цветов:
https://www.rapidtables.com/web/color/Web_Safe.html
То что придумал я в 2013 году на самом деле является "6x7x6 RGB color cube" ( даже уже и не cube, а "прямоугольный параллелепипед" ; ) который состоит из 252 цветов, к которым я вчера добавил ещё 4 уровня серого, чтобы получить 6 градаций серого в дополнение к цветовому "кубу" 6x7x6. что даёт полные 256 цветов - сегодня вот решил официально переименовать эту палитру в Uniform676G.gpl (и поменял тексты сообщений выше):