Компьютер "Aleste 520EX"

[Sherlock]

Рекомендую попробовать 60 герц.
Коллега, а какая у вас частота CLK на шине HDMI?

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

В исходном коде частота 27МГц. Но в реальности она точно такая?

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

Изучив бегло ваш код верхнего уровня. У меня возник вопрос к блоку кода always FF который генерирует FF видео reset. Трудно продидактить конечную форму сигнала. Но одно важнейшее условие он должен быть длиной один пиксель клок.
Я думаю что вы долго с этим разбирались тестировали изменяли эта работа сложная. Но тут очень важно каждая длина этого сигнала может поломать работу HDMI модуля.

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

я завел 32кб двупортовой памяти, пишу параллельно в неё и в ОЗУ алесты, затем распаковываю байт видеопамяти в пиксели через палитру и тд.
но и тут есть нюанс. можно быстро подменить С000 ОЗУ через маппер страницу. например с 3 на 7. CRT будет показывать корректно, я - нет.
это мне нужно 128кб чтобы всё параллельно ОЗУ отслеживать.

На мой взгляд лучше этого не делать. Необходимо в памяти держать лишь одну строку. И отображать ее два раза.
Если вы успешно используете асинхронное FIFO то это правильное решение. (если нет то можно два буфера на дну строку. В один кладем из другого читаем)
При это крайне важно чтобы этот промежуточный узел согласования разверток выдавал идеально точно в количестве pixel_clock как одну строку так и весь кадр.

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

P.S. Возможно стоит не использовать HDMI, а вместо этого использовать DVI. Это проще.
Кстати то ядро которое вы используете работает на двух clk. Один clk_pixel_x5, а другой его деление на 5 clk_pixel. Второй не clke так было бы правильно а именно clk.
Работать должно, но на мой взгляд это спорное решение.

[Advertiser]

[AlexBel]

P.S. Возможно стоит не использовать HDMI, а вместо этого использовать DVI. Это проще.

А разве они, кроме звука, чем-то отличаются?

[Sherlock]

А разве они, кроме звука, чем-то отличаются?

Ключевое отличие заключается в сложности реализации. HDMI требует использования готовых сторонних ядер, которые поддерживают множество режимов и функций (аудио, CEC, инфофреймы), но при этом:

* Создают зависимости от чужого кода
* Усложняют отладку из-за своей универсальности
* Вводят избыточность для задач, где нужно только видео

Проблема тактирования в рассмотренном модуле - использование двух раздельных тактовых сигналов (clk_pixel и clk_pixel_x5), когда правильнее было бы использовать:

* Один основной тактовый сигнал (clk_pixel_x5)
* Строб-сигнал разрешения (pixel_enable) для домена с меньшей частотой

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

Создание собственного DVI-модуля позволяет:

* Полный контроль над всей логикой работы
* Упрощенная архитектура без избыточных функций
* Прозрачная отладка - все сигналы понятны и предсказуемы
* Оптимизация под конкретную задачу вывода ретро-видео

[backa]

HDMI требует использования готовых сторонних ядер

можно и без "ядер" обойтись))) вот тут все изящно и красиво и самое главное - портируемо на любой FPGA!!
без привязки к несовместимым библиотечным элементам от производителя кристалла FPGA

[RW9UAO]

звук. хдми делается просто. а вот звук.

[Sherlock]

можно и без "ядер" обойтись))) вот тут все изящно и красиво и самое главное - портируемо на любой FPGA!!
без привязки к несовместимым библиотечным элементам от производителя кристалла FPGA

Все не так просто. Одно дело генерировать видео а другое дело адаптировать существующий видеовыход.

Проблема интеграции контроллера 6845 (Amstrad CPC) с HDMI:

Для стандарта HDMI 720p (PAL) требуется 625 строк. Контроллер 6845 по умолчанию генерирует 312 строк. Даже с учетом теоретической возможности получить 312.5, на практике используется 312.

Это делает метод удвоения строк неприменимым. Наиболее простым и гарантированным решением видится полный захват кадра в буфер.

Рекомендация: Продолжить разработку с использованием полнокадрового буфера.
Моя цель: Параллельно я буду искать решение, позволяющее избежать захвата всего кадра.

[CodeMaster]

Это делает метод удвоения строк неприменимым.

А если все строки удваивать, а первую или последнюю утраивать?

[Sherlock]

А если все строки удваивать, а первую или последнюю утраивать?

Преобразование временных параметров видеопотока

Имеется два видеопотока с разным строчным разложением.

Исходный кадр:

Строки: 1, 2, 3, 4

Время строки: l1

Время кадра: f1 = l1 * 4

Выходной кадр:

Строки: A, B, C, D, E, F, G, H, J

Время строки: l2

Время кадра: f2 = l2 * 9

Алгоритм преобразования строк

Для преобразования 4 строк в 9 используется метод дублирования:

Каждая исходная строка дублируется дважды.

Поскольку 4 * 2 = 8, а требуется 9 строк, последняя (четвертая) строка дублируется трижды.

Результат преобразования:

1, 1, 2, 2, 3, 3, 4, 4, 4

Синхронизация временных параметров

Требуется выполнить два условия синхронизации:

✅ Условие 1: l1 == l2 / 2

Это условие выполняется за счет настройки длительности строки.

Пример: Если l1 = 64 мкс, то l2 = 32 мкс.

❌ Проблема с Условием 2: f1 == f2

При попытке выполнить это условие возникает несоответствие:

f1 = l1 * 4

f2 = l2 * 9

Подставляя условие l2 = l1 / 2, получаем:

f2 = (l1/2) * 9 = l1 * 4.5

Вывод:

f1 = l1 * 4
f2 = l1 * 4.5

Для исходного потока из 4 строк и выходного из 9 строк, где каждая входная строка дублируется, невозможно одновременно соблюсти оба условия:

Время новой строки равно половине времени исходной (l2 = l1 / 2).

Времена кадров обоих потоков равны (f1 = f2).

Это противоречие возникает из-за того, что отношение количества строк (9/4 = 2.25) не равно отношению длительностей строк (2/1 = 2).