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

[barsik]

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

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

Ожидал также, что введение быстрого текстового режима небольшим по объёму труда способом заинтересует любителей ОРИОНА и СПЕЦИАЛИСТА. И, т.к сам я плохо дружу с паяльником и МГТФ-ом, надеялся, что кто-то захочет отмакетировать это в железе, а затем организует производство плат простой текстовой приставки к ОРИОНУ и СПЕЦИАЛИСТУ. Это вполне реально и несложно, а ниже я покажу как решить проблему регенерации ОЗУ.

Текстовый адаптер в ОРИОНЕ простым способом

Итак, почему ОЗУ не будет регенерироваться и как эту проблему решить?

В ОРИОНЕ и СПЕЦИАЛИСТЕ регенерация динамического ОЗУ происходит за счёт работы видеогенератора. С этой целью все самые высокочастотные сигналы (веса) с выходов счётчиков сгруппированы в мультиплексоре так, что выдаются на РУ5-тые по /RAS (т.к именно по /RAS в РУ5-тых происходит регенерация).

При этом, т.к в РУ5-тых, как и в РУ3-тьих вектор регенерации не 8-ми битовый, а семибитовый, достаточно, чтобы за интервал в 2000 МКСЕК на 7-ми входах из 8-ми пробегали все 128 адресов. При этом сигнал на 8-мом мультиплексируемом входе A7 (9 нога) не участвует в регенерации.

В ОРИОНЕ веса счётчиков (и соответствующие им адреса CPU) подаются на мультиплексор совершенно логично. Вот какие сигналы мультиплексируются на выходы КП12-ых при /RAS=1 и защелкиваются в ОЗУ по заднему фронту /RAS.

H0 (A8) -- DD23 --> на A0 РУ5-тых
H1 (A9) -- DD23 --> на A1 РУ5-тых
H2 (A10) - DD24 --> на A2 РУ5-тых
H3 (A11) - DD24 --> на A3 РУ5-тых
H4 (A12) - DD25 --> на A4 РУ5-тых
H5 (A13) - DD25 --> на A5 РУ5-тых
V0 (A0) -- DD26 --> на A6 РУ5-тых
V1 (A1) -- DD26 --> на A7 РУ5-тых

В скобках указаны адреса CPU соответствующие весам счётчиков. Видим, что веса расположены в порядке возрастания частот и вполне логично. Как отмечено выше, для регенерации то, что подаётся на A7 не важно. В текстовом режиме с 16-ю строками веса V0...V3 обнуляются, что приводит к тому, что сигнал на адресе A6 ОЗУ при /RAS не меняется (т.к V0=0), отчего ровно половина ОЗУ не регенерируется.

Исправить это легко. Достаточно взять вес V4, который в текстовом режиме не обнуляется и заменить им вес V0 на входе мультиплексора. Вес V4 изменяется через очередные 16 линий и таким образом за время вывода 32-х строк растра всё ОЗУ будет полностью отрегенерировано. Длительность одной строки 64 МКСЕК, а значит 32 строки длятся 2048 МКСЕК, что на 48 МКСЕК больше требований РТМ для РУ5-тых.

Для не совсем полудохлых РУ5-тых это сработает, а для полудохлых РУ5-тых, в которых от времени увеличились токи утечки в накопительных конденсаторах и период регенерации упал ниже 2 МСЕК - регенерации не будет. Если же делать текстовый режим в 32 строки, то сгодятся и полудохые РУ5-тые, т.к период регенерации будет 1024 МКСЕК, что вдвое ниже максимально допустимого.

В данном случае замена РУ5-тых на РУ7-мые (имеющие вдвое больший период регенерации) не поможет, т.к у РУ7-мых не 7-ми битовый, а 9-ти битовый вектор регенерации и для них период регенерации получится уже 8 МСЕК, что вдвое больше их нормы в 4 МСЕК и значит РУ7-мые точно работать не смогут.

При замене весов, надо одновременно переставлять вес счётчика и соответствующий ему адрес CPU (иначе изменится архитектура экрана), значит перекидывать придётся 2 цепи, т.е надо 4 куска проволоки. Итак, меняем местами на входе мультиплексора V4 и A4 на V0 и A0. Т.е цепи на входах DD24/6 и DD24/4 меняются с DD26/5 и DD26/3 соответственно.

В оригинальном ОРИОНЕ период регенерации РУ5-тых равен всего 128 МКСЕК, отчего прекрасно работают даже полудохлые РУ5-тые. После такой переделки период регенерации ОЗУ в ОРИОНЕ возрастёт до 2048 МКСЕК, что возможно потребует отбраковки полудохлых РУ5-тых, что не тянут стандартный период регенерации. Заметим, что период регенерации РУ7-мых в ОРИОНЕ - 512 МКСЕК, но как указано выше, РУ7-мые для получения синхронного текстового адаптера непригодны.

Сигнал загрузки ИР9 (нога 1) формируется CRR-цепочкой из сигнала 96 (ёмкость 180 пф, резисторы 1 кОм и 3 кОм, так это в моём текстовом адаптере). Таким образом вся доработка до текстового режима состоит всего из 4-х микросхем, 3 из которых (2732, ИР9 и КП11) на доп.платке и одна КП11 монтируется на основной плате ОРИОНА (вторым этажом над одной из КП12). В качестве формирователя программируемого упр.сигнала для включения текстового режима удобно использовать 4-тый D-триггер в DD30, что в базовой схеме формирует сигнал НП (начальный пуск). НП проще формировать на RS-триггере из двух вентилей - по /RESET взводится, а по /WR КР580 сбрасывается. Так получается готовый управляющий бит, причём прямо в нужном порту режима. Я так делал в 1991 году для программного включения режима 768*256.

В СПЕЦИАЛИСТЕ и РК86 вектор регенерации не 8-ми битовый как в ОРИОНЕ, а 7-ми битовый (т.к изначально там стояли РУ3, а при установке РУ5 на СПЕЦИАЛИСТ-М и ЭКСПРЕСС адреса на входах мультиплексоров не сдвигали). Из-за этого при организации регенерации в текстовом режиме для СПЕЦИАЛИСТА понадобится перекидывать не 2, а 4 цепи, т.е понадобятся целых 8 кусков проволоки. Кстати, есть некоторые импортные аналоги РУ5 имеющие не 7-ми битовый вектор регенерации, а 8-ми битовый. Такие ОЗУ прекрасно работают в ОРИОНЕ, но не в СПЕЦИАЛИСТЕ или РК86.

[свернуть]