Еще один Орион на ПЛИС

[andreil]

Игреки слиплись. Осторожнее с передвижением блоков.

Да, заметил при сборке
Кактус что-то под конец дня начал жутко педалить, еле растащил нормально всё.
X работает идеально, а вот по Y пока что есть проблемы - буду их устранять после допиливания X'а...

[andreil]

Оптимизировал как мог...
Если у кого-либо имеются идеи по дальнейшей минимизации логики - готов выслушать Своих знаний тут уже явно не хватает...
Теперь думаю о компоновке по корпусам:
1) Как есть, относительно много перемычек-переключателей для задания режимов;
2) Группировка по возможностям, то есть если человеку надо только 4:3, 384 столбца, то он часть деталей не запаивает и ставит мало перемычек;
3) Сделать переключение программным, поставив, например, КП11.

PS: Текущая схема видео-подсистемы занимает 28ALMs.

[Error404]

По оптимизации не скажу ибо все эти импортные "овалы" мой мозг считывать отказывается, приучен только к ГОСТу.
Имею вопрос по стратегии: этот комп планируется довести до выпуска или он проектируется только в качестве упражнений?
Если к выпуску, то что в итоге с видеовыходом: VGA? В каком разрешении?

Если VGA и в приличном разрешении, то я бы предложил ввести режим алфавитно-цифрового дисплея (АЦД). Наиболее просто (цена вопроса 3-4 МСХ логики/регистров и одно ПЗУ с шрифтами) можно было бы реализовать вывод символами 8х8. Логика АЦД такая: при последовательном сканировании в памяти восьми соседних строк, читается из ОЗУ только одна и та же из этих строк (т.е. код символа с отступом по номеру текстового экрана), и вычитанный из ОЗУ байт помещается не в сдвиговый регистр видеовыхода каждый раз напрямую как в графическом режиме, а в регистр-защелку адресных входов A3..A10 ПЗУ шрифтов один раз на все эти восемь строк, а вот выход ПЗУ шрифтов (все 8 строк адресуемого символа выводимые соответственно номеру текущей строки экрана 0..7 т.е. адресные входы A0..A2 ПЗУ шрифтов) уже помещается в сдвиговый регистр видеовыхода. Т.е. укрупненно: "ставим ПЗУ фонта в разрыв между памятью и видеовыходом, и содержимое памяти становится не изображением символа, а его адресом в ПЗУ"

Получим текстовый режим 60х32 символов для разрешения 480х256 (и имеет смысл не теряя совместимость увеличить экран c 15кб до 16кб т.е. до 512х256 получив 64 символа в строке) или 80х32 символов для режима 640х256.
Также очевидно что можно элементарно ввести и матрицу символа 8х16 прямо в этой же схеме как второй режим в дополнение к 8х8, но в этом режиме будет только 16 строк более крупых символов.

[andreil]

По оптимизации не скажу ибо все эти импортные "овалы" мой мозг считывать отказывается, приучен только к ГОСТу.

Там же подписаны функции все - AND2, XOR2, NOR2 и т .п...

Имею вопрос по стратегии: этот комп планируется довести до выпуска или он проектируется только в качестве упражнений?
Если к выпуску, то что в итоге с видеовыходом: VGA? В каком разрешении?

Планируется хотя бы для себя. Но плат получится всё равно на 5-10 штук...
VGA - на два разрешения, 640х480 и 640х350. Для обоих можно выбирать режим отображения - 384х256 или 480х256. Всё это выбирается джамперами - на схеме это "21mux".

Получим текстовый режим 60х32 символов для разрешения 480х256 (и имеет смысл не теряя совместимость увеличить экран c 15кб до 16кб т.е. до 512х256 получив 64 символа в строке) или 80х32 символов для режима 640х256.

Тут проблема будет в перерасчёте таймингов по горизонтали - на схеме там и так логика самая сложная =/ А ввод ещё одного разрешения раздует логику ещё больше - смотри в посте выше схему по ссылке.

Сегодня добиваю видео-часть из "кубиков", буду добиваться корректной работы. Так что может сегодня даже выложу полную схему узла
Ещё и переключение тактовой 2.5/5/10 сделал с возможностью софтварного доступа, если регистр на это дело поставить (0 - 2.5МГц, 1 - 5МГц, 2/3 - 10МГц). Вот фрагмент именно с формированием тактов, выполнено и проверено сегодня.

[Error404]

Там же подписаны функции все - AND2, XOR2, NOR2 и т .п...

Планируется хотя бы для себя. Но плат получится всё равно на 5-10 штук...
VGA - на два разрешения, 640х480 и 640х350. Для обоих можно выбирать режим отображения - 384х256 или 480х256. Всё это выбирается джамперами - на схеме это "21mux".

Тут проблема будет в перерасчёте таймингов по горизонтали - на схеме там и так логика самая сложная =/ А ввод ещё одного разрешения раздует логику ещё больше - смотри в посте выше схему по ссылке.

Чтобы излишне не усложнять, и раз уж у нас базовые 640 точек в кадре, я бы предложил использовать Орионовский режим 512х256 (широко применявшийся в Орионе-ПРО). На нем прекрасно будет отображаться и 480х256, совпадает по границе 16к (т.е. все совместимо по размещению экранов в ОЗУ), а 64 символа в строке (при символе шириной 8 точек) это все же лучше чем 60.

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

А почему ты не рад идее АЦД?
Какие я вижу плюсы:
- вывод символа в 8 раз быстрее.
- горизонтальный скроллинг (влево-вправо) в 8 раз быстрее
- оконные функции быстрее в 8 раз и в 8 раз меньше требуется места под буфера окон чем в графике

Что мало меняется: вертикальный скроллинг ускорится примерно на 20%-30% при символах 8х8 и примерно вдвое для символов 8х16. Ну, как говорится - и то хлеб.

[andreil]

Я больше волнуюсь о проблемах с разрешением - нужно дополнять формирователи и т.п...
АЦД - не проблема.

[Error404]

Я больше волнуюсь о проблемах с разрешением - нужно дополнять формирователи и т.п...
АЦД - не проблема.

Но ведь ты уже ввел режим 480 точек. Если вместо него ввести 512 (тоже в-общем вполне Орионовский), то по количеству корпусов останется примерно то же самое? От 640 можно отказаться если оно сильно усложняет.

Те 512 не лезли в телек (и для режима 80 символов в строке при символе шириной 6 точек были избыточны), и раз так, то в 90х делали экран 480 чтобы экономить 1кб в каждой экранной области из четырех. А раз у нас кадр VGA-640 и получаются поля бордюра, то всё в экран влезает с запасом и можно сделать 512.

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

Еще раз вдумчиво посчитал (первоначально ошибся в оценке сколько tstates уходит на LDIR), при использовании АЦД вертикальный скроллинг получится быстрее в 2-3 раза чем в графическом режиме. Т.е. заметно быстрее, хотя и не в 8 раз.

[andreil]

Но ведь ты уже ввел режим 480 точек. Если вместо него ввести 512 (тоже в-общем вполне Орионовский), то по количеству корпусов останется примерно то же самое? От 640 можно отказаться если оно сильно усложняет.

Оно как бы не много, по корпусам если смотреть. Вся сложность именно в перерасчёте тактов и выяснение минимальных функций для всех сигналов по горизонтали Я текущую схему уже дня 4 шлифую почти с утра и до вечера.

[LeoN65816]

Ещё и переключение тактовой 2.5/5/10 сделал с возможностью софтварного доступа, если регистр на это дело поставить (0 - 2.5МГц, 1 - 5МГц, 2/3 - 10МГц). Вот фрагмент именно с формированием тактов, выполнено и проверено сегодня.

andreil, тебе уже HardWareMan говорил про синхронность. Все выходные сигналы управления внешними модулями/блоками, включая и сигнала такта проца и nCAS для DRAM, должны быть регистровыми, и должны быть синхронными от одного клока (заведомо большей частоты), и никаких латчей, только флипфлопы! Синхронность - залог устойчивой работы логики на больших частотах. У тебя же все на комбинаторике, это ох!"№;%:?*ые задержки и иголки/глитчи. Даже F[0..3] на 7490 у тебя каскадирован...

Что мало меняется: вертикальный скроллинг ускорится примерно на 20%-30% при символах 8х8 и примерно вдвое для символов 8х16. Ну, как говорится - и то хлеб.

Можно сделать как в Векторе-06Ц: поставить отдельный регистр вертикального смещения. Номер текущей/отображаемой строки и содержимое регистра суммируются по модулю 256 и далее результат используется в адресации видеопамяти. В ПЛИСке реализуется элементарно, на рассыпухе, конечно, пожирнее выйдет...

[barsik]

я бы предложил ввести режим алфавитно-цифрового дисплея... вывод символами 8х8 на 32 строки... Можно ввести и матрицу знакоместа 8х16, хотя в этом режиме будет только 16 строк более крупых символов

Для текстообработки вполне нормально 16 строк, вписанных в растр 512*256, как в КОРВЕТЕ. При 32-х строках символы слишком плющенные, а для нортонов, чтобы влезало больше строк можно использовать графический режим.

Я в середине 90-тых собирался сделать лично для себя такой синхронный текстовый режим в ОРИОНЕ. Он прост в реализации. Но увы, руки до этого так и не дошли, потому что я не был уверен, что этот режим не нарушит регенерацию ОЗУ.

Конечно, лучше бы придумать текстовый экран в ОРИОНЕ на таком же синхронном принципе, но так, чтобы под экранное ОЗУ тратилось не 16 кб, а только 1 кб, как в КОРВЕТЕ. Это возможно сделать поставив свой мультиплексор, ОЗУ 1 кб (на 537РУ17) и весь видеовыход с выходным регистром сдвига и ПЗУ с фонтом. Получится почти КОРВЕТ, но деталей в этом варианте намного больше. Тут проблем с регенерацией не возникает.

Зато вариант когда на экран тратятся те же 16 кб, намного проще (отпадают ОЗУ, защёлки и адресные мультиплексоры), хотя нужна коррекция и на основной плате - там надо ставить КП11, которая обнуляет веса V0...V3 идущие от счётчиков на мультиплексор (это чтобы в знакоместе все 16 линий читались из одного адреса ОЗУ). Конструктивно с краю платы ОРИОНА монтируется разъём, куда вставляется крошечная платка текстового видеовыхода. Там ПЗУ 2764 с фонтом (4 кб на один фонт), ИР9 и КП11, которая при включении текстового режима подаёт сигнал с выхода ИР9 на цепь 101 вместо DD51/20. В DD51 ИР13 банки 0 запрещается сдвиг (единица на DD51/1). Через разъём выходы 8 битов из ИР13 DD51 поступают прямо на ПЗУ фонта, куда также поступают веса счётчиков V0...V3 (соответствующие адресам CPU A0...A3).

Как видите деталей совсем немного и смакетировать это можно за пару вечеров. А текстовый режим, даже такой несуразный, что занимает 16 кб, намного быстрее, чем графический. Проблема только в том, что я не уверен, что ОЗУ будет регенерироваться. Кто-нибудь может высказаться на этот счет?