Оптимизировал как мог...
Если у кого-либо имеются идеи по дальнейшей минимизации логики - готов выслушать Своих знаний тут уже явно не хватает...
Теперь думаю о компоновке по корпусам:
1) Как есть, относительно много перемычек-переключателей для задания режимов;
2) Группировка по возможностям, то есть если человеку надо только 4:3, 384 столбца, то он часть деталей не запаивает и ставит мало перемычек;
3) Сделать переключение программным, поставив, например, КП11.
PS: Текущая схема видео-подсистемы занимает 28ALMs.
Последний раз редактировалось andreil; 14.02.2018 в 14:35.
"Байт-48"
По оптимизации не скажу ибо все эти импортные "овалы" мой мозг считывать отказывается, приучен только к ГОСТу.
Имею вопрос по стратегии: этот комп планируется довести до выпуска или он проектируется только в качестве упражнений?
Если к выпуску, то что в итоге с видеовыходом: 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 строк более крупых символов.
Последний раз редактировалось Error404; 14.02.2018 в 16:50.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Там же подписаны функции все - AND2, XOR2, NOR2 и т .п...
Планируется хотя бы для себя. Но плат получится всё равно на 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МГц). Вот фрагмент именно с формированием тактов, выполнено и проверено сегодня.
Последний раз редактировалось andreil; 14.02.2018 в 17:24.
"Байт-48"
Чтобы излишне не усложнять, и раз уж у нас базовые 640 точек в кадре, я бы предложил использовать Орионовский режим 512х256 (широко применявшийся в Орионе-ПРО). На нем прекрасно будет отображаться и 480х256, совпадает по границе 16к (т.е. все совместимо по размещению экранов в ОЗУ), а 64 символа в строке (при символе шириной 8 точек) это все же лучше чем 60.
- - - Добавлено - - -
А почему ты не рад идее АЦД?
Какие я вижу плюсы:
- вывод символа в 8 раз быстрее.
- горизонтальный скроллинг (влево-вправо) в 8 раз быстрее
- оконные функции быстрее в 8 раз и в 8 раз меньше требуется места под буфера окон чем в графике
Что мало меняется: вертикальный скроллинг ускорится примерно на 20%-30% при символах 8х8 и примерно вдвое для символов 8х16. Ну, как говорится - и то хлеб.
Последний раз редактировалось Error404; 14.02.2018 в 18:01.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Я больше волнуюсь о проблемах с разрешением - нужно дополнять формирователи и т.п...
АЦД - не проблема.
"Байт-48"
Но ведь ты уже ввел режим 480 точек. Если вместо него ввести 512 (тоже в-общем вполне Орионовский), то по количеству корпусов останется примерно то же самое? От 640 можно отказаться если оно сильно усложняет.
Те 512 не лезли в телек (и для режима 80 символов в строке при символе шириной 6 точек были избыточны), и раз так, то в 90х делали экран 480 чтобы экономить 1кб в каждой экранной области из четырех. А раз у нас кадр VGA-640 и получаются поля бордюра, то всё в экран влезает с запасом и можно сделать 512.
- - - Добавлено - - -
Еще раз вдумчиво посчитал (первоначально ошибся в оценке сколько tstates уходит на LDIR), при использовании АЦД вертикальный скроллинг получится быстрее в 2-3 раза чем в графическом режиме. Т.е. заметно быстрее, хотя и не в 8 раз.
Последний раз редактировалось Error404; 14.02.2018 в 18:17.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Оно как бы не много, по корпусам если смотреть. Вся сложность именно в перерасчёте тактов и выяснение минимальных функций для всех сигналов по горизонтали Я текущую схему уже дня 4 шлифую почти с утра и до вечера.
"Байт-48"
andreil, тебе уже HardWareMan говорил про синхронность. Все выходные сигналы управления внешними модулями/блоками, включая и сигнала такта проца и nCAS для DRAM, должны быть регистровыми, и должны быть синхронными от одного клока (заведомо большей частоты), и никаких латчей, только флипфлопы! Синхронность - залог устойчивой работы логики на больших частотах. У тебя же все на комбинаторике, это ох!"№;%:?*ые задержки и иголки/глитчи. Даже F[0..3] на 7490 у тебя каскадирован...
Можно сделать как в Векторе-06Ц: поставить отдельный регистр вертикального смещения. Номер текущей/отображаемой строки и содержимое регистра суммируются по модулю 256 и далее результат используется в адресации видеопамяти. В ПЛИСке реализуется элементарно, на рассыпухе, конечно, пожирнее выйдет...
Турбо АГАТ-9/16 (ЦП 65C802, 5 Махов, dual-port SRAM).
Для текстообработки вполне нормально 16 строк, вписанных в растр 512*256, как в КОРВЕТЕ. При 32-х строках символы слишком плющенные, а для нортонов, чтобы влезало больше строк можно использовать графический режим.Сообщение от error404
Я в середине 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 кб, намного быстрее, чем графический. Проблема только в том, что я не уверен, что ОЗУ будет регенерироваться. Кто-нибудь может высказаться на этот счет?
Последний раз редактировалось barsik; 14.02.2018 в 21:07.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)