FPGA-реплика ЭВМ ДВК-3 и платы МС1201

[hobot]

На самом деле, квадратных (5:4) мониторов уже лет 10 как не делают

но это не значит, что их нет, под ретро проект можно и достать ЭЛТ любой диагонали, было бы хотение! ;-)

или как на чертеже от @Manwe сразу нужного размера матрицу лепить к проекту - вот это вообще "под ключ" )

[Vslav]

На большинстве плат VGA DAC сделан тупо на резисторах и никто сигнал I2C обратно в FPGA не заводит.
С HDMI чуть лучше в этом плане: стоит отдельная IC

Ну вот так всегда - придет поручик и опошлит все мероприятие
Да, на VGA почти нигде не заведено I2C на FPGA, там же согласователь уровней надо ставить для гарантии.
На HDMI повеселее, на Reverse-U16 вроде бы I2C заведено.

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

Да не, EDID - это уже фантастика.

Да, это уже следующий уровень. Ессно, никто не критикует и не настаивает, просто для понимания как оно в норме должно бы быть.

На самом деле, квадратных (5:4) мониторов уже лет 10 как не делают.

Зашел на hotline - все еще есть в продаже новые 1280х1024, и даже модели 2019 года. Но согласен, не мейнстрим давно уже.

if ((col < 11'd141 && mode == 2'b0) |
    (col < 11'd190 && mode == 2'b1) |
    (col < 11'd230 && mode == 2'b2) |
...
) begin

Вот эти все константы 11'dxxxx - надо записать в регистры, и сравнивать не с константой, а с регистром, и все будет ОК.
Но, в идеале, надо осваивать перепрограммирование PLL и делать отдельный клоковый домен для VGA, тогда любой видеорежим можно поддержать. Ну... непрост... но в идеале....

[Hunta]

Ну, 1600х1200, это, конечно, не 5:4, а 4:3, но и не 16:9

[andreil]

Да не, EDID - это уже фантастика.
На самом деле, квадратных (5:4) мониторов уже лет 10 как не делают. Для современных мониторов стандарт - 1920*1080. А совсем скоро стандартом станет 3840*2160 Наши простенькие FPGA и близко не подойдут к поддержке таких разрешений.
Все квадратные разрешения эти мониторы делают интерполяцией видеосигнала, с соответствующей корявой картинкой, и придется с этим смирится. Впрочем, мой текстовый экран 640*480 смотрится не так уж и плохо, если кто запустит проект - сам убедится. Думаю, что и графика 400*286 будет смотреться не хуже, слишком уж она грубая. Посмотрим...

Что касается поддержки смены разрешения, то даже не знаю, как такое возможно. Там же все тайминги разные, а вешать селекторы в виде кучи вложенных сцепленных if в цикле попиксельной обработки - это будет выглядеть примерно так:

if ((col < 11'd141 && mode == 2'b0) |
    (col < 11'd190 && mode == 2'b1) |
    (col < 11'd230 && mode == 2'b2) |
...
) begin

И так по всему циклу. Синтезатор там такого насинтезирует, что ни в какие временные рамки не влезет. И это еще только развертка, а там ведь и адресация видеобуфера съедет, и соответствие шрифта и знакоместа для текстовых экранов... Ну, настоящие специалисты, наверное, знают, как решить эту проблему просто и изящно, но мне ничего простого в голову не приходит.
Ладно, надо будет попробовать хоть как-то сделать, а там видно будет. Для начала придется текстовый видеоконтроллер переделать на 800*600. Это не так-то просто, он ведь сложнее чисто графического, поскольку должен не просто отображать пиксели из видеобуфера, а выдавать изображение символов на основе шрифтов. На УКНЦ, например, из-за этого вообще отказались от текстовых режимов и текст графикой рисуют.

1) Я в своём хобби-проекте как раз делаю видеовыход с поддержкой EDID - VGA/HDMI/DVI. Всё режается установкой одного мелкого STM32F103.
2) Куча разрешений легко укладываются, если картинку "вписывать" удвоением/утроением/etc пикселей. Просто для адресации видео-ОЗУ клок для счётчиков делим, как надо. Минусы - дублирующая логика. Если брать только с удвоением или без - просто мультиплексированием битов счётчика.
У меня STM'ка читает EDID с VGA, а вот с DVI/HDMI общается свой чип - с него инфа забирается так же в STM'ку. Оттуда по SPI вся инфа о таймингах и параметры PLL пишутся в FPGA - там сделал регистры для управления видео и PLL, всё вполне работает в железе. Сейчас жду печатки, что бы проверить чип для HDMI и избавиться от макеток с кучей проводков.
А если FPGA жирная, то у меня есть готовое решение без внешней STM'ки - с софт-ядром Cortex-M0, функционал тот же, только регистры висят сразу на шине AHB.

[andreil]

Вот вполне рабочий код, если кому надо: https://pastebin.com/dejJnD4e
Тут вся работа с EDID имеется - чтение, парсинг. Печатает Modeline в *NIX-like стиле, только частота в килогерцахи в HEX:

[ZPilot]

Получается полтора пикселя на бит видеопамяти или 3 пикселя на 2 бита. Как такое выводить-то?

Да 3 пикселя на 2 бита, левый и правый "оригинальные", средний =(Лп+Пп)/2, только не забыть, что для каждой составляющей цвета отдельно.
Вернее тут биты должны стать байтами..

[Advertiser]

[forth32]

Очередной этап развития проекта завершен. Я сделал наконец обещанный контроллер MY.
Это, пожалуй, самый сложный и интеллектуальный контроллер дисковода из всех использовавшихся с ДВК. Он использует DMA и имеет производительность не хуже RK11 - команда COP/DEV MY0: MY1: отрабатывается меньше чем за 5 секунд. Что странно, для загрузки параметров команды в этом контроллере используется не набор регистров (цидиндра, сектора, счетчика итд), как в стандартном дековском оборудовании, а блок данных в памяти, также передаваемый через DMA. Возможно, таким образом упростили схемотехнику контроллера или упростили жизнь программистам - такой метод проще и быстрее, чем последовательная загрузка через один регистр в RX01.
Оригинальный контроллер был построен как микропроцессорная система на 1801ВМ1. Мой FPGA-вариант обошелся набором машин состояний, дабы не загромождать и без того ограниченный бюджет FPGA огромным процессорным ядром и не убивать производительность программной реализацией DMA-обмена.
Имеются следующие отличия от оригинального контроллера:

• Оригинальный контроллер мог работать с 40- и 80-дорожечными дисководами - это задавалось перемычками на плате. Мой вариант эмулирует только 80-дорожечный дисковод. Образы, снятые с 40-дорожечного дисковода и записанные на SD-карту контроллер будет корректно читать и записывать, но проинициализировать 40-дорожечную файловую систему невозможно. Да и не надо.
• Команды "форматирование" и "чтение заголовков" не поддерживаются. Реализация этих команд не имеет никакого смысла, поскольку мы работает с поблочными DSK-контейнерами на SD-карте, где никаких служебных областей и близко нет.
• Команды "чтение с меткой" и "запись с меткой" работают как обычные команды чтения-записи. Служебной области у нас нет, метку хранить негде. Я сомневаюсь, что эту возможность вообще хоть кто-то использовал на практике.
• Оригинальный контроллер мог работать с секторами размером 256, 512 и 1024 байта. Формат сектора хранился в его заголовке. Здесь поддерживаются только 512-байтные сектора, что более чем достаточно для работы с образами, созданными на ДВК.
• Контроллер в DMA-режиме ограничен 16-битным адресным пространством. Оригинальный контроллер имел возможность расширения адреса до 22 бит, но в данном случае реализация этой возможности не имеет никакого смысла - у нас 16-битная шина адреса. Но доработать контроллер до полной 22-битной шины адреса можно за полчаса. Будем надеяться, что когда-нибудь появится смысл в такой доработке.

В остальном контроллер функционально повторяет оригинал. Загрузка системы работает. В стартовый образ initdisk.img я добавил образ диска MY0 с системой ФОДОС-ТМОС. Теперь можно напрямую использовать огромные залежи MY-дискет, лежащих в разных архивах в сети.

Также прилично доработана документация. Описано распределение памяти на SD-карте, более детально описана работа дисковой подсистемы, добавлена полезная информация для портирующих проект на другие типы FPGA.

По сути, все массово применявшиеся в ДВК дисковые контроллеры теперь реализованы. Был еще MX, но делать эмуляцию этого убожества на SD-карте нет никакого смысла.
Теперь, конечно, было бы неплохо реализовать ленточный контроллер MT с магнитофоном CM-5300. Но у ленты, в отличие от диска, переменный размер блока и последовательный доступ в оба направления. Боюсь, что тут машинами состояний не обойтись, придется процессорное ядро подключать. Или ну ее нафиг эту ленту, все равно на ДВК ей мало кто пользовался...-

[Hunta]

как в стандартном дековском оборудовании

Насколько я себе представляю, DU/MU и всякие XU/XL/XQ работают так же. Но особо в драйверах не копался, так что наверняка не скажу. Вот плотней займусь XU - тогда смогу сказать точнее

[Alex_K]

Оригинальный контроллер мог работать с 40- и 80-дорожечными дисководами - это задавалось перемычками на плате. Мой вариант эмулирует только 80-дорожечный дисковод. Образы, снятые с 40-дорожечного дисковода и записанные на SD-карту контроллер будет корректно читать и записывать, но проинициализировать 40-дорожечную файловую систему невозможно. Да и не надо.

Перемычками на контроллере задавались временные параметры дисковода - время разгона мотора, время перехода между дорожками, время загрузки головки. Естественно для эмулятора на SD эти параметры и не нужны. А объём дискеты задавался в драйвере MY.SYS, что-то типа того SET MY NTRK=40. Так что при необходимости можно проинициализировать и 40-дорожечную файловую систему, главное найти нужный драйвер.

[forth32]

Перемычками на контроллере задавались временные параметры дисковода

Там всего-то 2 перемычки, уходящие в стартовый регистр процессора. Они и задавали тип дисковода 6022 или 6121, а отличаются эти дисководы как раз числом дорожек.
А параметр NTRK, насколько я помню, использовался для чтения 40-дорожечных дискет на 80-дорожечном дисководе. Хотя я могу и ошибаться - в исходники драйвера я не влезал, а реально пользовался всем этим четверть века назад.

Насколько я себе представляю, DU/MU и всякие XU/XL/XQ работают так же.

Насчет сетевых интерфейсов не знаю, ни разу не сталкивался в реальной жизни. А MSCP-контроллеры, да, конечно, использовали похожий метод, но не совсем - там контроллеру отправлялся командный пакет вместе с кодом команды и всеми парамтерами. Пакет ставился в очередь, и можно было отправлять следующий пакет. В MSCP это логично и оправданно. А вот так, чтобы задавать код команды через регистр, а параметры пакетом - такого мне больше нигде не встречалось. Хотя есть еще DY, с ним я не встречался никогда, может быть там тоже так же сделано...