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

[Error404]

По шрифтам - в Орионе они идут 7-битные или полные, 8-битные?
Если 7-битные, то этот "лишний" бит можно использовать как раз вместо сигнала G16.

В Орионе фонты 8-битные (256 символов), к счастью не догадались это как-нибудь аппаратно или "стандартами" урезать до 7 бит как в i8275. В порядке убывания популярности: KOI8-R, CP866, CP1251. Как частный случай (для экономии ОЗУ и совместимости с РК) - 7-битный KOI7-R который по дефолту в Мониторе F800.

По моей реализации с сигналом G16: адрес Y2 пропускаем через AND с G16 - получаем, что он будет активен только при "1" на G16. А для памяти Y2 - через OR. И не будет ни половинок, ни раздвоений. На схеме это не изобразил, потому что рисовал на скорую руку на обеде

Какие-то лишние действия, не? И все равно есть зависимость (или пререквизит) 16pix фонты размещать в ПЗУ сообразно кратности 4кб? Или делить пополам и класть в две страницы? Что-то без схемы не до конца понял твою идею. Все же я бы никак не связывал между собой сканер 8/16 точек и адрес офсета в ПЗУ (который ставил бы напрямую с порта) т.к. не вижу в этом каких-то очевидных минусов, а комбинаторно вариантов получаем больше (кто-нить еще и DEMO слепит из половинок букв ) и схемно проще.

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

По предложению "вместо 2х КП11 иcпользовать только одну W28С512 (где половина её прошита под pass-through кодом с 128-ю повторяющимися блоками перечисления 0..FF)." нет возражений? По-моему достаточно красиво (идея barsik-а, кстати, достаточно очевидное решение для оптимизации).

[andreil]

Какие-то лишние действия, не? И все равно есть зависимость (или пререквизит) 16pix фонты размещать в ПЗУ сообразно кратности 4кб? Или делить пополам и класть в две страницы? Что-то без схемы не до конца понял твою идею. Все же я бы никак не связывал между собой сканер 8/16 точек и адрес офсета в ПЗУ (который ставил бы напрямую с порта) т.к. не вижу в этом каких-то очевидных минусов, а комбинаторно вариантов получаем больше (кто-нить еще и DEMO слепит из половинок букв ) и схемно проще.

Может тогда делать только шрифты 8х8? ИМХО, если использовать как спрайты (например, сделать доступной запись этой МС, использую не-УФ-стираемую, а EEPROM) 256 спрайтов должно "хватить всем".
Если поставить EEPROM, то можно шрифты грузить динамически, сделав парочку из них "пользовательскими", а основные зашить намертво (можно даже сделать защиту от записи на паре логических элементов).

По предложению "вместо 2х КП11 иcпользовать только одну W28С512 (где половина её прошита под pass-through кодом с 128-ю повторяющимися блоками перечисления 0..FF)." нет возражений? По-моему достаточно красиво (идея barsik-а, кстати, достаточно очевидное решение для оптимизации).

Да, тут ничего против не имею.
Итого, для шрифтов 8х8 имеем: 1 ПЗУ, 1 КП11 (для адресов видеопамяти). Ну и ещё небольшая схемка для записи в ПЗЦ "на лету", если будем делать.

[Error404]

Может тогда делать только шрифты 8х8? ИМХО, если использовать как спрайты (например, сделать доступной запись этой МС, использую не-УФ-стираемую, а EEPROM) 256 спрайтов должно "хватить всем".
Если поставить EEPROM, то можно шрифты грузить динамически, сделав парочку из них "пользовательскими", а основные зашить намертво (можно даже сделать защиту от записи на паре логических элементов).

Да, тут ничего против не имею.
Итого, для шрифтов 8х8 имеем: 1 ПЗУ, 1 КП11 (для адресов видеопамяти). Ну и ещё небольшая схемка для записи в ПЗЦ "на лету", если будем делать.

Можно и только 8x8 оставить. Вроде как такой режим реализуем в Орионе128/512 с DRAM. Получится типо для совместимости (ну, и для простоты).
А вот с записью - там наверно тогда проще поставить SRAM-ину на 64к и инициализировать ее при загрузке той ОС, что будет уметь работать с этим алфавитным дисплеем? Или программкой для ОРДОС (если пользоваться этим режимом под Ордос). В любом случае понадобится добавить 3 КП11 (12 адресных, 4 с порта адреса фонта можно не трогать) и один буфер с Z типа АП5 (для записи в то ОЗУ с ШД) плюс какую-то логику выборки этих КП11 и АП5 через какие-то порты. Не сложновато ли?

[andreil]

А вот с записью - там наверно тогда проще поставить SRAM-ину на 64к и инициализировать ее при загрузке той ОС, что будет уметь работать с этим алфавитным дисплеем? Или программкой для ОРДОС (если пользоваться этим режимом под Ордос). В любом случае понадобится добавить 3 КП11 (12 адресных, 4 с порта адреса фонта можно не трогать) и один буфер с Z типа АП5 (для записи в то ОЗУ с ШД) плюс какую-то логику выборки этих КП11 и АП5 через какие-то порты. Не сложновато ли?

Это чисто теоретическое изыскание.
Завтра попробую поколдовать над клавиатурой, может получиться через Linux USB-шную прокинуть на плате - сейчас я ничего не могу сделать, поскольку порт спалил-таки, судя по всему. Как сделаю - буду проверять видеорежимы с ПРОшки, которые будут и в моём варианте схемы.

[andreil]

По реализации псевдографики - набросал в Квартусе:

Куски схемы

[свернуть]

Итого, добавлен мультиплексор на сканирование видеопамяти, и ПЗУ в разрыве vdata.
По поводу смешивания с результатом порта FC - а имеет ли это смысл? Всё равно оттенки меняются сразу на всём экране, а не независимо.

[Error404]

По реализации псевдографики - набросал в Квартусе:
Итого, добавлен мультиплексор на сканирование видеопамяти, и ПЗУ в разрыве vdata.

Я правильно понимаю, что мультиплексор ma_0 и латчи mvdata0+mvdata1 - это корпуса не относящиеся к доработке по АЦД (т.е. просто кусок схемы стандартного Ориона?). Буфера(латчи?) на входе и выходе ПЗУ, стробируемые неким сигналом clk/inst2 - это нечто для внуренней логики квартуса? Мы же ничего такого не планировали.

По поводу смешивания с результатом порта FC - а имеет ли это смысл? Всё равно оттенки меняются сразу на всём экране, а не независимо.

Оттенки (4 градации интенсивности в дополнении к еще одной формируемой по сигналу I) можно будет менять отдельно для каждого из сигналов RGB. Т.е. сейчас у нас в знакоместе есть RGB (8 цветов) куда на диодах замешан четвертый бит I (получаем 16 цветов на точку). Если аналогично (как делается в Орионе-128 для I) туда на диодах же замешать еще по 2 бита отдельно к каждому из R-G-B подав по два бита с порта FC который RGBIRGBI (только с весами мЕньшими чем у I - например 4:2:1, где I=4), то получим 16 цветов на точку (в знакоместе) из палитры 64 цвета (это если оставить I 1-битным). Можно будет например рисовать не вырвиглазными красным и бирюзовым, а их более мягкими оттенками.
Реализуемо такое? А том может это сложнее чем мне кажется, и сделать в RGB добавку многобитных весов не получится как сделано для I на диодах и резисторах?

[andreil]

Я правильно понимаю, что мультиплексор ma_0 и латчи mvdata0+mvdata1 - это корпуса не относящиеся к доработке по АЦД (т.е. просто кусок схемы стандартного Ориона?). Буфера(латчи?) на входе и выходе ПЗУ, стробируемые неким сигналом clk/inst2 - это нечто для внуренней логики квартуса? Мы же ничего такого не планировали.

По АЦД - это только мультиплексор ma_pg и ROM.
В ПЛИС ROM выполнена как On-Chip-Memory, поэтому там требуется тактирование (синхронная память с латчами, все дела).

Оттенки (4 градации интенсивности в дополнении к еще одной формируемой по сигналу I) можно будет менять отдельно для каждого из сигналов RGB. Т.е. сейчас у нас в знакоместе есть RGB (8 цветов) куда на диодах замешан четвертый бит I (получаем 16 цветов на точку). Если аналогично (как делается в Орионе-128 для I) туда на диодах же замешать еще по 2 бита отдельно к каждому из R-G-B подав по два бита с порта FC который RGBIRGBI (только с весами мЕньшими чем у I - например 4:2:1, где I=4), то получим 16 цветов на точку (в знакоместе) из палитры 64 цвета (это если оставить I 1-битным). Можно будет например рисовать не вырвиглазными красным и бирюзовым, а их более мягкими оттенками.
Реализуемо такое? А том может это сложнее чем мне кажется, и сделать в RGB добавку многобитных весов не получится как сделано для I на диодах и резисторах?

Хмм... У меня несколько другое предложение. Выхода мультиплексоров подключаем к АП13 (или ещё чему, главное - развязать сигналы, в оригинале это было на диодах, но для R2R такое решение не подходит), выхода которых выводим на R2R ЦАП:

Формирование RGB-24

[свернуть]

(Сейчас у меня сделано так для выхода на ЦАП, имеющийся на плате)
Сюда же на входа АП-шек можно будет завести выходы порта FC, смешав их с цветом, как и яркость. Для совместимости сигналы от порта надо будет подтянуть к +5, что бы не портило картинку при прочих режимах.

Конечно, можно эту же схему реализовать и на резисторах с диодами, но я тут мало соображаю, к сожалению

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

Между делом добавил в схему формирователь видеосигнала - выше и правее памяти. Осталось определиться с формированием аналогового RGB и дорисовать этот кусочек схемы. Ну и с АЦД решить ещё - пока что не вносил в схему.
Лист А3 забит битком...

[Error404]

Хмм... У меня несколько другое предложение. Выхода мультиплексоров подключаем к АП13 (или ещё чему, главное - развязать сигналы, в оригинале это было на диодах, но для R2R такое решение не подходит), выхода которых выводим на R2R ЦАП:
(Сейчас у меня сделано так для выхода на ЦАП, имеющийся на плате)
Сюда же на входа АП-шек можно будет завести выходы порта FC, смешав их с цветом, как и яркость. Для совместимости сигналы от порта надо будет подтянуть к +5, что бы не портило картинку при прочих режимах.
Конечно, можно эту же схему реализовать и на резисторах с диодами, но я тут мало соображаю, к сожалению

Можно и на АП сделать. Только поставить что-то попроще типа 555АП3 (SN74LS240 - два 4битных инвертирующих шинника в одном корпусе) или 555АП4 (SN74LS241 - два 4битных неинвертирующих) в зависимости от логики что там надо на выходе: инвертировать или нет. Т.е. всего 2 доп. корпуса для RGBI, получив до четырех битов на каждый сигнал.

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

Причем кому это будет не надо (или при поэтапной наладке), вместо этих двух шинников и кучки резисторов достаточно будет 4 перемычки запаять.

[andreil]

Можно и на АП сделать. Только поставить что-то попроще типа 555АП3 (SN74LS240 - два 4битных инвертирующих шинника в одном корпусе) или 555АП4 (SN74LS241 - два 4битных неинвертирующих) в зависимости от логики что там надо на выходе: инвертировать или нет. Т.е. всего 2 доп. корпуса для RGBI, получив до четырех битов на каждый сигнал.

ИМХО, разницы никакой - можно и в нынешней схеме обрезать до 4 бит на канал. Просто мне надо для АЦП 8 бит.

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

Добавил выход на АП13 и R2R АЦП.
Место для АЦД на схеме придётся уже выигрывать перестановками и уплотнениями.

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

Схема почти завершена.
Осталось проверить в её в ПЛИС и исправить ошибки.
Кроме имеющегося будет добавлен только разъём питания. Конденсаторы по питанию - остались за кадром, негде уместить.

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

Кстати, по размеру схемы - распечатал на листе А4, всё отлично видно, масштаб примерно как и в публикациях журнальных. Хотя в KiCAD'е стоит лист А3

[Error404]

А вот интересно: можно ли сделать так, когда в АЦД для хранения кодов символов в ОЗУ используются строки не кратные 8 (0, 8, 16, ...), а (0+1, 8+1, 16+1, ...) или (0+2, 8+2, 16+2, ...) или...
Хотя бы для этого и отображение первой видимой строки пикселей на экране начиналось со сдвигом вниз на 1 или 2 или ... строк пикселей. Т.е. сделать чтобы 7 строк по 64 байта в ОЗУ не пропадали в недоступности закрытые зануляющим мультиплексором, а в них можно было хранить еще несколько текстовых "экранных областей"?