Вид для печати
Вряд ли он Вам будет чем-то полезен. Когда перестаю править, через месяц уже сам забываю, где там что.Цитата:
Сообщение от Vasily_A
Лучше напишите, что конкретно Вас интересует - алгоритм той или иной процедуры, её реализация? С удовольствием расскажу. Можно написать в ЛС, либо на электронку http://ipic.su/img/img7/fs/Email.1569054222.png, или в телеграм
«Композитный» режим CGA
Суть «композитного режима» сводится к следующему.
На видеокартах CGA имеется видеовыход, к которому можно подключить телевизор NTSC. В стандарте NTSC цвет точки зависит от её фазы (положения по горизонтали).
Если разрешение 640х200 (черно-белое) вывести на телевизор NTSC, то цвет каждого четвертого (светящегося) пикселя в строке будет повторяться. И наоборот, каждые идущие подряд четыре пикселя будут иметь разные цвета. При этом каждый светящийся пиксель «окрашивает» не только себя, но и соседние пиксели. Если светятся четыре пикселя подряд, то в сумме они дают белый цвет с «радугой» по краям. Это хорошо иллюстрирует картинка ниже:
https://hsto.org/getpro/habr/post_im...6972c7974e.png
Источник https://habr.com/ru/post/256409/
В разрешениях 320х200 цвет кодируется не четырьмя, а двумя пикселями. Но каждый из них уже может быть окрашен, т.е. иметь какое-то смещение по стандарту NTSC.
В обоих случаях итоговое "эффективное" разрешение составить 160х200.
Более подробно можно почитать например здесь https://en.wikipedia.org/wiki/Color_...mposite_output или здесь https://en.wikipedia.org/wiki/Composite_artifact_colors ,
Первая проблема эмуляции композитного режима заключается в сложности найти готовые таблицы преобразования цветов. С тем же вопросом столкнулся автор mce2vga. Видел его старые сообщения на разных форумах с тщетными попытками найти эту информацию. В итоге он каким-то образом умудрился найти или составить такие таблицы.
Не придумал ничего лучше, чем скопировать у него этот код в свой проект. Предполагаю, что в нём есть ошибки. Уже пришлось делать правки, когда в одной из игр небо оказалось розового цвета: https://www.old-games.ru/forum/threa...mu-cga.105705/
В минимальном варианте нужно шесть таблиц. Две для черно-белого режима 640х200 (в нормальной и высокой яркости), и ещё по две для Pallete 0 и Pallete 1, так же для двух уровней яркости.
Таблица для разрешения 640х200 представляет из себя код из 4-х соседних пикселей и яркости, вида ibbbb, где i – яркость (интенсивность), b – состояние пикселя (1 – светится, 0 – погашен) и соответствующего ему 6-битного кода в палитре EGA. Сейчас он в таком виде:
Для Палитр 0 и 1 таблицы имеют аналогичный вид. Левый столбец вида: "i r1 g1 r2 g2", где i – так же интенсивность, r1 g1 – цвет первого пикселя (без синего), r2 g2 – цвет второго пикселя (так же без синего). Синий зависит от палитры, в Палитре 1 он всегда есть (кроме черного), в Палитре 2 наоборот, его никогда нет.Код://Для ярко белого цвета
5'b10000: Cpst640_decoder = 6'b000000; //black
5'b10001: Cpst640_decoder = 6'b001001; //green
5'b10010: Cpst640_decoder = 6'b010011; //blue
5'b10011: Cpst640_decoder = 6'b001011; //ligth blue
5'b10100: Cpst640_decoder = 6'b100000; //red
5'b10101: Cpst640_decoder = 6'b101010; //gray
5'b10110: Cpst640_decoder = 6'b110011; //dmagn
//5'b10111: Cpst640_decoder = 6'b111011; //pink меняем на
5'b10111: Cpst640_decoder = 6'b101011; //голубой
5'b11000: Cpst640_decoder = 6'b000100; //dark green
5'b11001: Cpst640_decoder = 6'b001100; //light green
5'b11010: Cpst640_decoder = 6'b010101; //dark gray
5'b11011: Cpst640_decoder = 6'b011110; //acqua
5'b11100: Cpst640_decoder = 6'b110100; //orange
5'b11101: Cpst640_decoder = 6'b111100; //light yellow
5'b11110: Cpst640_decoder = 6'b111010; //salmon
5'b11111: Cpst640_decoder = 6'b111111; //white
// ДЛЯ СЕРОГО ЦВЕТА
5'b00000: Cpst640_decoder = 6'b000000;
5'b00001: Cpst640_decoder = 6'b001000;
5'b00010: Cpst640_decoder = 6'b000011; //Проверил
5'b00011: Cpst640_decoder = 6'b001011; //Проверил
5'b00100: Cpst640_decoder = 6'b100000;
5'b00101: Cpst640_decoder = 6'b010101;
5'b00110: Cpst640_decoder = 6'b110011;
5'b00111: Cpst640_decoder = 6'b011011; //Отдает в зелень (циан)
//5'b01000: Cpst640_decoder = 6'b010100; //Буро-зеленый
5'b01000: Cpst640_decoder = 6'b010000; //Меняем на темно-красный (почти темно-коричневый)
5'b01001: Cpst640_decoder = 6'b001100;
5'b01010: Cpst640_decoder = 6'b010001;
5'b01011: Cpst640_decoder = 6'b001110; //Проверил
//5'b01100: Cpst640_decoder = 6'b110100; //Оранжевый
5'b01100: Cpst640_decoder = 6'b110000; //На красный
5'b01101: Cpst640_decoder = 6'b101000;
//5'b01110: Cpst640_decoder = 6'b110011; //Почему-то розовый
5'b01110: Cpst640_decoder = 6'b100011; //Делаем голубой с розовым оттенком
5'b01111: Cpst640_decoder = 6'b111111;
Чтобы сократить код, мне пришлось упростить таблицы из проекта mce2vga. В палитрах 0 и 1 цвет фона всегда принимается черным. По факту видеокарта CGA позволяет задать фон произвольным цветом, например синим. Из-за этого некоторые (редкие) игры могут отображаться неправильно.
Вторая сложность заключается в том, что существовали «старые карты CGA» и «новые карты CGA», которые показывают композитные цвета по-разному. Игры до 1984 года обычно рассчитаны на «старые» цвета композита, а после 1984 – на «новые». Подробнее здесь http://nerdlypleasures.blogspot.com/...-and-just.html
То есть, в идеале, к указанным выше шести таблицам преобразований нужно добавить ещё шесть (что очень ресурсоёмко), либо сделать выборочную корректировку цветов в этих таблицах (уже более достижимо).
Приглашаю к сотрудничеству заинтересованных в доработке алгоритма эмуляции композитных цветов CGA. Как в работе над таблицами преобразований, так и в тестировании в различных играх. От вас будут нужны файлы игры и скриншоты правильного изображения в композитном режиме CGA.
На настоящий момент в конвертере реализован режим «композитный 1» (упомянут выше, включается кнопкой “MODE”) и «композитный 2». Первый – те самые сокращенные таблицы из проекта mce2vga с небольшими доработками. Второй отличается от первого только инвертированием сигнала яркости. Т.е. для яркого изображения используется таблица от нормального, для нормального – таблица от яркого. В некоторых играх это существенно повышает реалистичность картинки.
Как указано выше, в композитном режиме цвет пикселя зависит от его положения в строке. Поэтому после включения эмуляции композита может потребоваться подстройка положения картинки по горизонтали. От этого положения зависят отображаемые цвета.
Положение по горизонтали можно подстроить обладая эталонным скриншотом, или исходя из того, что трава должны быть зеленой, небо голубым, вода синей и т.п.
Такую подстройку для каждой видеокарты нужно сделать один раз, после чего уже во всех играх будут правильные цвета.
Автоматическая подстройка по горизонтали в композитном режиме всегда отключена.
Напоследок пара скриншотов, из игр King's Quest II (https://www.old-games.ru/game/screenshots/759.html) и Frogger II (https://www.old-games.ru/game/screenshots/2216.html)
https://pic.maxiol.com/thumbs2/16768...81410961.1.jpg.... https://pic.maxiol.com/thumbs2/16768...81410961.2.jpg
Сохранение настроек
Часть настроек для каждого входного видеорежима задаётся раздельно, часть общие и не зависят от режима.
Раздельные настройки – это входной пиксельклок, частота кадров выхода VGA и положение изображения по горизонтали. Они сохраняются в оперативной памяти (RAM) микроконтроллера и при возврате в соответствующий режим восстанавливаются, если конвертер оставался включенным.
Аналогичным образом сохраняется цвет монохромного режима, выходное разрешение режима CGA/EGA 640/320Х200 (640х480 или 640х400), состояние “scanlines” в этом же режиме и отдельно положение по горизонтали при эмуляции композитного CGA.
Общие настройки, которые не меняются при изменении входного режима – это фаза и автоматическое выравнивание по горизонтали.
Для фазы обычно доступны одно-два значения, которые выдают качественное изображение во всех режимах конкретной видеокарты. В первую очередь речь о картах EGA. У CGA и Hercules фактически один режим с небольшими модификациями.
Режим автовыравнивания приходится отключать очень редко. Это может быть связано с каким-то не совсем стандартным изображением, которое получается, если софт использует низкоуровневые настройки видеокарты.
Состояние эмуляции композитного режима CGA также не сохраняется, его нужно каждый раз включать вручную.
Помимо этого конвертер сохраняет большинство настроек в энергонезависимой памяти микроконтроллера (EEPROM). Память EEPROM допускает достаточно большое (гарантированно не менее 100 тыс.) но не бесконечное количество циклов записи. Кроме того, чтение/запись в EEPROM у МК Atmega это относительно длительная процедура.
Поэтому запись происходит не сразу, а по истечении примерно 30 секунд после последнего изменения настроек. Т.е. все производимые настройки накапливаются, и записываются в EEPROM сразу «скопом» если в течении 30 секунд не было никаких других изменений. Это подразумевает, что все настройки закончены и полученное изображение Вас полностью устраивает.
Сигнализирует о несохраненных настройках мигающий зеленый светодиод (POWER). Если изменить какую-то настройку, и затем вернуть её в исходное состояние до сохранения в EEPROM, светодиод перестанет мигать – записи не будет. То есть настройки записываются только если они отличаются от хранящихся в EEPROM.
Запись не производится, если до истечения 30 секунд сменился входной видеорежим, или сигнал совсем пропал. Отсчет возобновляется (но начинается с нуля) при возврате в режим с несохраненными настройками.
Можно принудительно сохранить настройки, если нажать и удерживать не менее 2-х секунд кнопку 1 (MODE)
Вышеописанным образом сохраняются следующие настройки:
• Фаза захвата сигнала,
• Входной пиксельклок (для каждого режима),
• Выходная кадровая частота (для каждого режима),
• Цвет для монохромных режимов,
• Формат вывода разрешений 640/320х200 – 640х480 или 640х400,
• Состояние “scanlines”,
• Положение изображения по горизонтали, только при отключенном автоматическом выравнивании, для каждого режима,
• Состояние настройки «автоматическое выравнивание», для каждого режима.
Последняя настройка восстанавливается из EEPROM только для первого видеорежима, после включения конвертера (или после полного отсутствия входного сигнала), и затем уже не меняется.
Фиксированный входной видеорежим сохраняется в EEPROM сразу же после выхода из режима выбора фиксированного режима (нажатия кнопки 1, MODE).
Сброс всех настроек на значения по умолчанию осуществляется по нажатию “ALT+CTRL+DEL”, см. рисунок:
https://pic.maxiol.com/images2/16769...0968.10252.jpg
Причем, по первому нажатию “DEL” происходит сброс настроек только в оперативной памяти. Если выключить-включить конвертер, вернутся старые настройки. И только по второму нажатию “DEL” (“ALT” + “CTRL” нужно продолжать удерживать нажатыми), настройки будут сброшены на значения по умолчанию и в EEPROM.
Может, сделать какую-нибудь утилиту для настройки этого модуля с ПК ? Могу помочь.
Про Open source и документацию к проекту
Практически сразу возникли вопросы о доступности исходных кодов и документации для самостоятельного изготовления, поэтому остановлюсь на этом отдельно.
Как я понимаю Open Source – это когда несколько (иногда десятки) разработчиков по мере сил и возможностей длительно пилят какой-то большой проект. Другой вариант – энтузиаст за несколько (или несколько десятков) вечеров сделал небольшой проект и выложил исходники с комментарием: «Понимаю, что много надо доделывать. Меня устраивает, кому надо доделывайте, вот исходники».
Третий вариант – документацию выкладывают, чтобы энтузиасты могли собрать устройство для себя.
К сожалению реальная ситуация в области новодельных устройств для IBM PC-совместимого железа сейчас совсем другая.
Большинство энтузиастов-разработчиков заняты своими проектами. Шанс, что-то кто-то поучаствует в Вашем, близок к нулю.
Изготавливать для себя одно-два, даже четыре устройства абсолютно не выгодно. В магазинах цены дикие, на али можно заказать детали от 5-10 штук. Печатные платы тоже от 5-ти штук. Купить готовое устройство оказывается выгоднее и дешевле, чем собирать самому.
В итоге, через пару месяцев после появления исходников годного устройства «энтузиасты» начинают продавать наборы для сборки, на авито и ибее появляются готовые изделия, причем по совершенно диким ценам. И их покупают. Потому что продаваны заточены на такие продажи, у них ассортимент, раскрученный аккаунт, много подписчиков, репутация. При том, что в разработку не вложено ни копейки и начисто игнорируется замечание автора разработки, что документация выхожена в общий доступ исключительно для частного, некоммерческого использования.
Если кому-то будет полезен код для своего проекта, с удовольствием поделюсь им и проконсультирую. АБСОЛЮТНО БЕСПЛАТНО.
Если кто-то захочет нажиться на проекте – простите, однозначно нет.
Тут два товарища уже интересовались исходниками и документацией, почему-то после вопроса «зачем?» слились и молчат.
Что касается стоимости готового устройства. Мне бы очень хотелось, чтобы готовый, полный комплект (со шнурком и БП) стоил менее 4500 руб.
Ещё пару месяцев назад это было реально. На днях заглянул на али, и увидел, что цены на комплектующие значительно выросли, доллар уже тоже ~75 руб, внутренний курс али около 80. Поэтому, если курс не вернётся назад, вероятнее всего цена будет выше.
На первую небольшую партию обязательно будет скидка. Детали закупались по старым ценам, плюс небольшая компенсация за возможные баги в софте.
Так же, если будет спрос, возможна продажа неполного комплекта или только основной платы в сборе. В последнем случае останется только собрать "пульт" с кнопками и светодиодами, придумать корпус (или вообще оставить без него, поставив плату на "ножки") и подобрать подходящий БП (5V 0,35А).
Насчет «конструкторов» вопрос пока открыт. Нет статистики работоспособности устройства после сборки. Есть конструкции, которые работают в 99,9% случаев, если нет ошибок сборки. Есть капризные, которые и собрать правильно сложно, и далеко не нулевая вероятность неисправности имеющихся комплектующих.
Если кому-то интересно, принципиальная схема текущей версии: https://disk.yandex.ru/d/rWj_jgUCvFdWew и https://disk.yandex.ru/i/B0W8Q2c4c3cr9g
Напряжение питания конвертера - 5 вольт. Допустимо нестабилизированное напряжение, в пределах 4,5...5,5 вольт. Потребляемый ток: средний - 0,3А, в пике до 0,35А.
Разъём для подключения БП - 5.5х2.5/2.1. Подходят штекеры 5.5х2.5 и 5.5х2.1.
На этом пока всё. Если что-то ещё вспомню, дополню.
Готов выслушать замечания, предложения, пожелания.
я интересовался... наверное в числе одного из двух.
меня общая "архитектура" цплд заинтересовала,
а именно как решена "коммутация" кучи сигналов и генерация разверток на захват и вывод на средней по числу ячеек цплд.
самого интересного все равно нет - я все думал, как на цплд плл для пиксельклока сделать, пусть даже с внешним гун.
смысл - подключение без вывода клока из компа и без ручной подстройки.
виноват, надо было ответить (не вежливо получилось...).
Vasily_A, Вы меня тоже простите за резкость. Признаюсь, намеренно так написал, чтобы спровоцировать ответ.
Да, это было бы оптимальным решением. И даже существовали специализированные чипы, способные генерировать пиксельклок по строчным СИ и количеству пикселей в строке. Но увы, это дефицитные и дорогие чипы, как я понял давно снятые с производства. Сейчас их функционал встроен в один большой чип в мониторе.Цитата:
Сообщение от Vasily_A
Что Вы имеете в виду под "кучей сигналов"? Под каждый конкретный формат видео подстраиваются параметры схемы. На вход и на выход стоят несколько счетчиков, которые считают количество пикселей в строке, паузу после СИ, для выхода - длительность СИ и паузу после него. В зависимости от формата видеосигнала меняются пределы, до которых производится подсчет тактов пиксельклока.Цитата:
Сообщение от Vasily_A
Например, генерация строки вывода изображения производится следующим кодом:
Код:reg [9:0] Pix_Counter; //Счетчик пикселей в строке, до 1024, реально больше 720 не нужно
always @(posedge Clk2) //Счетчик пикселей. Доходит до конца линии и обнуляется
begin
if(H_equal) Pix_Counter <= 10'h1; //Если достигаем предела, начинаем с начала (для строки - с единицы)
else Pix_Counter <= Pix_Counter + 10'h1;
end
reg [1:0] H_phase_counter; //Фаза выходной строчной развертки
// 0 - вывод видимого изо
// 1 - пауза перед СИ
// 2 - СИ
// 3 - пауза после СИ
//Mono выводится в 720 пикселей, всё остальное в 640 пикселей
wire H1_equal; assign H1_equal = (Mono_full?(Pix_Counter == 10'd728):(Pix_Counter == 10'd648)) & H_phase [0]; //Счетчик равен длине видимой строки 640 + запас 8 пикс
wire H2_equal; assign H2_equal = (Pix_Counter == 10'd10) & H_phase [1]; // ..паузе перед СИ
wire H3_equal; assign H3_equal = (Mono_full?(Pix_Counter == 10'd108):(Pix_Counter == 10'd96)) & H_phase [2]; // ..длине СИ
wire H4_equal; assign H4_equal = (Mono_full?{Pix_Counter == 10'd54}:(Pix_Counter == 10'd46)) & H_phase [3]; //Пауза после СИ
wire H_equal; assign H_equal = H1_equal | H2_equal | H3_equal | H4_equal; //Если достигнут предел в любой из фаз
always @(posedge Clk2)
HSo <= ~(H_phase[2] ^ EGA); //EGA HiRes 640х350 ССИ положит, все остальные: 640х480, 720х400, 640x400 - отрицательный
always @(posedge Clk2) //По достижению счетчиком пикселей заданного значения происходит переход в следующую фазу
begin
if(H_equal) H_phase_counter <= H_phase_counter + 2'b1;
end
reg [3:0] H_phase; //Дешифратор фазы
always @(H_phase_counter)
H_phase <= 4'h1 << H_phase_counter;
Роман, такой вопрос: в связи со смертью проекта ZXKit1, который был ориентирован именно на советские ретро-компы, планируешь ли ты в своём прошивки с их поддержкой?
CodeMaster, у ZXKit1 ведь исходные коды открытые? Что мешает разобраться и допилить?
Свой изначально собирался сделать достаточно универсальным, чтобы можно было использовать с разными компьютерами и форматами видео.
Но на текущей элементной базе это вряд ли получится.
Конечно постараюсь выжать максимум, что возможно. Но очень сомневаюсь, что получится добавить существенный функционал.
Тут ещё какой момент возникает.
Если входной сигнал один, формат известен и есть откуда взять видеосигнал RGB-TTL и пиксель-клок - то пожалуй ZXKit оптимальный вариант. Простой и дешевый.
Если мы не хотим влезать в схему, а хотим подключиться к внешнему видео-разъёму компьютера, то там сигнал уже аналоговый и дополнительно нужен ADC для преобразования.
Если же устройство предполагается универсальным, способным работать с разными сигналами, то уже не обойтись без экранного меню с настройками.
Текущее железо конвертера это уже никак не потянет.
Микроконтроллер можно подобрать недорогой. CPLD нужно менять на как минимум EPM570. Это поднимет себестоимость.
С учетом затрат на разработку получится аналог конвертера Raspberry Pi Zero https://github.com/hoglet67/RGBtoHDMI/wiki
И зачем он тогда нужен?
Вообще в нынешних условиях разработка сложных устройств не выгода. Ebay закрыли, а внутренний рынок не позволяет даже покрыть затраты на разработку.
Проще собирать известные Open Source проекты, или делать что-то простое, где достаточно развести плату, а схему взять из даташита или скопировать заводское устройство.