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

[andreil]

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

Куски схемы

[свернуть]

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

[Advertiser]

[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

[TomaTLAB]

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

При переходах тудым-судым от ПЛИС к "реалу" не забудьте про этот момент.
А то я полчаса втыкал на ересь в первом столбце символов, пока до меня доперла очевидная вещь, что у меня знакогенератор на такт по адресу и на два по данным коматозит относительно счетчиков.

[andreil]

При переходах тудым-судым от ПЛИС к "реалу" не забудьте про этот момент.
А то я полчаса втыкал на ересь в первом столбце символов, пока до меня доперла очевидная вещь, что у меня знакогенератор на такт по адресу и на два по данным коматозит относительно счетчиков.

Это я в курсе. Сегодня как раз получил и запаял платку с реальной памятью и процессором (оный посадил на ZIF-панельку). Так что завтра начну тестировать приближено к реальности.
Ещё бы научиться задавать задержки в логических элементах на схеме для полноценной симуляции...

А так - для подобных рассинхронизация буду добавлять "слепыши" с перемычками на некоторых сигналах - что бы потом туда вставить цепочки из буферов, например, для выравнивания таймингов.

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

А если так: режим "выключения регенерации (из ПРО)" выкидываем, оно и в ПРО то не использовалось, и смысл его не ясен (похожий режим был и на 128 как неслучайный дефект, но он явно был не на бите 6). Вместо этого FA.6 используем для включения АЦД, и тогда F8.5-7 (3 бита) как раз хватает для выбора одной отображаемой из восьми текстовых "экранных областей" внутри куска 16к, базовый адрес которого как и ранее определяется FA.0-1

Не могу представить что бы мне где-то было нужно ПО, которое убивает содержимое всего ОЗУ. Тем более что убить его можно и без выключения регенерации (которая ХЗ как теряет информацию).

В принципе, можно и так. Только бит 5 точно нигде не используется? По спекам с эмулятора - вроде бы нет, но мало ли...
Всё равно софт будет писаться "де-факто", под имеющееся решение, поэтому ещё можно крутить как угодно

[TomaTLAB]

...и процессором (оный посадил на ZIF-панельку)...

Процессор в ZIF-ку ставить практически бессмысленно, под него и обычная пойдет прекрасно. В ZIF-ку лучше сажать ПЗУ-хи (вернее EEPROM, всеми любимую W27, напр.) их горааздо чаще придется между железкой и программатором переставлять.

[andreil]

Процессор в ZIF-ку ставить практически бессмысленно, под него и обычная пойдет прекрасно. В ZIF-ку лучше сажать ПЗУ-хи (вернее EEPROM, всеми любимую W27, напр.) их горааздо чаще придется между железкой и программатором переставлять.

У меня просто идея найти максимальную тактовую в имеющихся процессорах, что бы определиться с потолком турбирования для тестов. Да и потом через эту же панельку буду вешать что-либо ещё, кроме процессора.

[Error404]

В принципе, можно и так. Только бит 5 точно нигде не используется? По спекам с эмулятора - вроде бы нет, но мало ли...
Всё равно софт будет писаться "де-факто", под имеющееся решение, поэтому ещё можно крутить как угодно

Насколько мне известно, бит 5 нигде не используется. Так что предлагаю обойтись портами F8 и FA чтобы не плодить сущности. Итого будет так:

Порт 0F8H:

     D4  D3  D2  D1  D0
     ------------------
     0   x   0   0   0   - монохромный, палитра 1
     0   x   0   0   1   - монохромный, палитра 2
     0   x   0   1   x   - запрет видеосигнала
     0   x   1   0   0   - 2-битный (4-цветный), палитра 1
     0   x   1   0   1   - 2-битный (4-цветный), палитра 2
     0   0   1   1   x   - 16-цветный с групповым кодированием
     0   1   1   1   0   - псевдоцветной (цвет -  в порт 0FCH)
     0   1   1   1   1   - 16-цветный с групповым кодированием (+ палитра порта 0FCH)
     1   0   0   x   x   - 3-битный (8-цветный RGB)
     1   0   1   x   x   - 4-битный (16-цветный RGBI)
     1   1   0   x   x   - 3-битный (8-цветный RGB) +"палитра FC"
     1   1   1   x   x   - 4-битный (16-цветный RGBI) +"палитра FC"

     Код палитры для "псевдоцветного" режима и режима "цвет+палитра FC" доп.цвет записывается в  порт
с адресом 0FCH. Тут обрати внимание на выделенное (минимальные правки - вместо безразличного Х там 
кое-где теперь 0 или 1 чтобы развести все режимы с учетом "палитры") 
Т.е. нужно правильно обработать биты D0 и D3
    Биты D5..D7 - адрес "текстовой плоскости экрана" внутри текущего 16к графического экрана


Порт 0FAH:

     D0 \ номер экрана
     D1 /
     D2..D5 - адрес офсета текстового фонта в ПЗУ текстовых шрифтов
     D6 - включение режима АЦД (текстовый экран)
     D7 - включение широкого экрана