Что максимум можно выжать из КР580ВГ75 Intel 8275? Обсуждение

[freddy]

Вложение 57170
В архиве схема, печатная плата, прошивка контроллера и ЗГ. Для себя уяснил, что это не окончательный вариант. Буду переделывать, но не сильно
Что может текущая версия:
-прикидывается (вполне успешно) терминалом DEC VT52, не поддерживается альтернативная раскладка цифровой клавиатуры;
-работает пока только на 9600bps 8N1, в дуплексном режиме без управления потоком;
-атрибуты ВГ75 не задействованы никак, нет их у VT52;
-формат экрана 80х25 (640х400), шрифт очень крупный 8х16, выдран из редактора "Слово и дело";

Что хочу доделать:
-по эмуляции терминала доделать поддержку ANSI кодов управления атрибутами поля + некоторые команды DEC Private (VT100);
-переключить клавиатуру на второй COM порт;
-добавить поддержку инверсии и 8-ми цветов, задействовав(RVV, HGLT, GP0, GP1);
-сделать 4 знакогенератора, переключение через LA0, LA1 (на счет этого пока не уверен).

Пока что наступил на грабли. ВГ75 формирует опережающие сигналы на выводах атрибутов. Их перед использованием, надо защелкнуть в регистр, тем же импульсом, которым записывается код символа в сдвиговый регистр. Завтра допаяю. А пока курсор в виде инверсного видеоблока формируется немного не там При том что курсор в виде подчеркивания там

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

Для желающих повторить:
-Обратите особое внимание на U1, U5, U2. Нужны быстродействующие серии F, AC, ACT. У меня стоят U1-КР531ЛН1, U5-ОКР1533ИР10, U2-КР1533ИЕ5.
-Все остальные микросхемы могут быть серий К155, К555 без разницы.
-Все диоды любые импульсные кремниевые
-Все подтягивающие резисторы 2-10к всеравно какие.
-Mega128 с фьюзами на запуск от внешнего скоростного кварца

[Advertiser]

[Shaman]

Скан описания микросхемы КР580ВГ75 из справочника "Интегральные микросхемы".
Может кому, пригодится

[freddy]

Привет! Сделал поддержку команд терминала VT100. Теперь терминал подходит почти ко всему (DEC PDP, CP/M, Unix...) Немного переработал схему. Текущий вариант такой: Вложение 57271 На К555ТМ9 и КР531ЛП5 собрана защелка атрибутов и их распределение по каналам цветности.Теперь схема может 8 цветов и инверсию знакоместа. Курсор в виде подчеркивания убран из схемы совсем (это триггер U6 на старой схеме). Сигнал LTEN я попробую использовать в качестве дополнительного адреса для знакогенератора. С количеством ЗГ тоже определился, будет один со стандартной раскладкой ASCII, русифицированный. Курсор теперь только в виде мигающего инверсного блока, так смотрится красивее, в духе конца 70-х
Итак, по железу осталась переброска клавиатуры на UART1, ну и драйвер переписать.
По софту беда. Сейчас у меня не хватает ОЗУ микроконтроллера под видеобуфер из-за применения атрибутов. Но я что-нибудь придумаю, пока юзайте старую прошивку она на этой схеме работает.
Пишите сюда свои соображения, что еще можно добавить/убрать. Пока что то делать нет возможности, переезжаю на ПМЖ.

[b2m]

Сигнал LTEN я попробую использовать в качестве дополнительного адреса для знакогенератора.

Интересная идея. До сих пор вроде никто такого не делал.

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

По-моему, линия подчёркивания активна только на одной линии знакоместа. Или нет?

[freddy]

Да, только на одной линии. Это не удобно, нужно этот сигнал защелкивать, чтобы он действовал на всех 16 линиях знакоместа. Поэтому подчеркивание должно быть установлено в 0-й линии строки, за время 0-й линии произойдет запись LTEN в необходимые знакоместа. Запись по условию CCLK&(~LC0)&(~LC1)&(~LC2)&(~LC3). Для этого понадобится 80бит регистровой памяти, чтоб запомнить всю строку. Далее остальные 15 линий регистровая память будет гонять эти 80 бит по кругу Сбрасываться память будет сигналом HRTC&LC0&LC1&LC2&LC3, т.е. после последнего знакоместа 16-й линии символа. Собственно на чем сделать эту память я пока не думал. Идеально для этого подходят сдвиговые регистры. Взять 10 8ми битных Как ни крути, получается грамостко, и сейчас же " непризнанные гении" забросают гнилыми помидорами. Хотя реализовать можно. Можно счетчик адресов и какое-нибудь однобитное ОЗУ. Так получится около 3-х корпусов. Однако... нужен ли этот LTEN? Проще забить, например, на инверсию и использовать RVV в качестве старшего бита адреса знакогенератора.

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

Вот так я хотел использовать LTEN:
Вложение 57288
К555ИЕ5 и КР565РУ5 взяты для примера, потому что у меня их много. А так вобще можно уложиться и в 2 корпуса.
LTEN в данном примере работает как старший адрес знакогенератора. Все оказалось проще, чем я думал. Однако до сих пор сомневаюсь в правильности такой идеи. Может ну его... лучше пусть подчеркивает потихоньку?

[Error404]

Тут многие мануалы не читают, в основном копируя всякие бытовые компы 80-х 90х на современный манер. Однако Вы всеже посмотрите на нее даташит. Одноудовольствие как Intel сжато и понятно все излагает. В ВГ75 буфер не 64 символа и он там не один. И да! На самом деле выводит 80х25 символы 8х16, при этом видеорежим видимый 640х400@70Гц, физический 800х448.


Да, вы точно сказали. Никаких гоблинов и принцев. Только текст ее удел. Если на нее навесить графику, то простой схема уже не будет. Я очень люблю CP/M. И там ВГ75 как раз то что нужно. Ей можно доделать шину S100 или ISA8. Или как я на фото выкладывал вариант несколькими постами выше. Это законченный видеотерминал с поддержкой ESC-последовательностей ANSI/VT-52. Все что нужно - это сделать простенькую одноплатную машину с CP/M на z80 с COM-портом, подсоединить туда этот терминал и только в путь!

Мануалов не читаю, но очень хочу текстовую видеокарту 80х25 символы 8х16, при этом видеорежим видимый 640х400@70Гц для моего Ориона на шину а-ля ISA8 (она почти орионовская). Видится как плата расширения с одельным набортным буфером видео-ОЗУ и знакогенератором в набортном же ОЗУ, оба массива доступные для ПК на запись/чтение через порты в некотором диапазоне (условно, регистр адреса видеоОЗУ{запись} и регистр данных {запись/чтение}). Примерно то же, что и в приведенном выше проекте с контроллером на Меге, но без контроллера.

[freddy]

Да, да. Я как раз думал о варианте чисто видеокарты на ВГ75. Из схемы можно выбросить UART и клавиатуру. Из прошивки выбросить терминал, оставить только сам движок, который выгребает видеобуфер. На шину вывести 12бит адреса для адресации внутреннего буфера и 8бит данных. RD и WR завести на прерывания меги, CS формировать аппаратно, например на 155ЛА2 и 155ЛН1 либо взять чтото по современнее, типа 74НС688. Но от микроконтроллера отказываться не стоит. Просто я придумал уже логику работы видеобуфера, особенно с атрибутами поля. Логика довольно сложна. Но... видеобуфер всегда остается линейным, сколько бы атрибутов в нем не вставляли. Т.е. сохраняется закрепление знакомест за физическими адресами, а не как у всяких РК-клонов. Если убрать мегу и делать арбитр шин на логике, то это увеличит еще количество корпусов примерно на 10-15. Это возможно, но... сейчас опять полетят гнилые помидоры Если же мегу всетаки оставить, то это позволит цеплятся вообще за любую шину, ISA, S100, пофиг. Ног у меги много, хватит чтобы работать с набором управляющих сигналов любой древней шины.

[Error404]

С одной стороны, алгоритмы можно попробовать реализовать не в видеокарте, а в драйвере компьютера, к которому подключена видеокарта - лишь бы интерфейс с картой был быстрый (сократив модуль RS-232). Другое дело если Мега позволяет радикально сократить количество корпусов, то тогда можно (и даже нужно) оставить ее. Единственно, есть ли возможности заюзать какой-нибудь контроллер, для которого существует корпус в ДИПе? Например, AtMega32? Памяти встроеннной в ней, конечно, меньше, но возможно стоит смотреть в сторону использования внешней SRAM (какой-нибудь типа 32Кх8 или 64Кх8)? Чтобы и в цветах/атрибутах знакоместа себя не ограничивать, и знакогенератор сделать загружаемым в это ОЗУ, и несколько переключаемых "экранных плоскостей" (т.е. выбирать адрес откуда в ОЗУ лежит начало экрана). И как-то более "лампово" получится, и сподручно для пайки людям с руками заточенными только под ДИП. Будет 2 сороконогих БИС на карте.

[freddy]

Хватит и ATMega16, нужна будет внешняя память 8кб это еще +1 корпус. Получится 2 экрана. Знакогенератор программно не доступен, но есть несколько обходных путей. Это еще +2 корпуса.

[Error404]

Хватит и ATMega16, нужна будет внешняя память 8кб это еще +1 корпус. Получится 2 экрана. Знакогенератор программно не доступен, но есть несколько обходных путей. Это еще +2 корпуса.

Пару корпусов за загружаемые знакогенераторы - это вполне разумная плата. Зато какое дополнительное преимущество: от собственно загрузки шрифтов на вкус любого пользователя, до чанковой графики (если вместо 128 - надеюсь получится и 256 - символов загрузить требуемое количество знакомест с разной степенью и разной конфигурации заполненности их точками).

Что до экранов (экранных плоскостей), то можно Мегу и ВГ75 даже не ставить в известность о их существовании, потратив их ножки вместо старших адресов ОЗУ (адреса экрана) на еще какой-нить полезный расширенный функционал, а старшие адреса ОЗУ выбирать просто аппаратным портом (одним из - в диапазоне портов видяхи), установив на плате всего-то еще один регистр типа ТМ9/ИР23 (или подобных). При этом решение получится прозрачным и на той же самой прошивке способным работать с любым ОЗУ >= 4к, количество экранов ограничивается только имеющимся в наличии у пользователя ОЗУ. Поставил 8к - у тебя 2 экрана, поставил 64к - у тебя их уже 16.

Хотя... Очень полезный режим когда один экран видимый (тот, который сканируется и выводится ВГ75 на монитор), а другие - действительные (временно не видимые, но куда Мега выводит символы в данный момент - в какой буфер кладет). А это как я понимаю, должно быть под управлением Меги (и соответственно ее адресных ножек к ОЗУ). Т.е. активный и видимый экраны могут в какой-то момент быть одним и тем же экраном, а в какой-то (управляемо ESC-кодом), выбирать активный экран не совпадающий с видимым. Это было бы архиполезно для UZIX, порт которого уже есть, и где такую видяху можно было бы поддержать (когда многозадачные приложения выводят каждый в свой экран, при этом один из экранов активный - видимый и имеющий фокус ввода, а в остальные пишем в фоне).

Еще у меня есть вопрос и "I have a dream".
Вопрос: реализуем ли (или м.б. уже есть?) "аппаратный" скроллинг действительного экрана? Например, средствами Меги - "задать окно X*Y, в окне текст на N строк вверх/вниз, на N столбцов влево/вправо"? Эта операция достаточно много тактов съедает у CPU хоста (небыстрого старичка), и раз уж у нас на видяхе есть проц, то почему бы не распараллеливать подобные нагрузки? Чтобы понимать что Мега в процессе скроллинга байтов видеоОЗУ, да и вообще какой-то из длительных операций {если они есть} можно для CPU=драйвераОС вывести ножку "МегаЗанята")

И "a dream". Некий режим, когда можно просмотреть "уехавшее скроллингом за экран" (например, когда компилятор вывалил ошибки на экран, их было много, и они "уехали" из-за скроллинга). Типа как буфер в современных програмных терминалах типа Putty,Hyperterm и подобных, который можно "прокрутить вверх". Конечно, можно извратиться и такой "уезжающий" вывод команд перенаправить средствами ОС в файл, но не все ОС так умеют (например, CP/M 2.2 нативно не умеет). В реализации это получится резервирование под экранный буфер, скажем, вдвое большего места в ОЗУ (уж ОЗУ то найдем, 32к-64к вполне распространены), и таки та самая нами ранее съэкономленная внешним регистром ножка. При этом если окно действия скроллинга/очистки/покраски (то самое X*Y) стоит на весь экран, то по условию скроллинга на строку вверх не пересылать массив на 80 символов вверх, а увеличивать на 80 адрес начала сканирования, пока "окно 80*25" не опустится на дно буфера (MAX_адрес - 2000). А вот когда окно уже "лежит на дне буфера", то таки при очередном переводе строки придется делать пересылку содержимого буфера, причем уже вдвое большего. Стоит ли так заморочиться, или нунафиг, переложить на ОС?

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

Вот для пояснения темы с окнами (ограниченными экранными областями X*Y) и экранами 80*25 видимыми/активными во вложении описание экранного драйвера от Ориона-128.