Смешно. При импульсном потреблении другая "математика". В тех же классических платах Орионов дороги питания более 1мм, и этого мало - приходится дублировать толстыми проводами.Цитата:
Сообщение от andreil
Вид для печати
Смешно. При импульсном потреблении другая "математика". В тех же классических платах Орионов дороги питания более 1мм, и этого мало - приходится дублировать толстыми проводами.Цитата:
Сообщение от andreil
Этот "1мм" - это на пачку микросхем. Я же говорю о питании 4-х корпусов мелкой логики, а не памяти и процессора ;)Цитата:
Сообщение от Denn
Само собой, что к этим "группам" питание будет подводиться намного "жирнее".
- - - Добавлено - - -
Быстренько добавил счётчики по вертикали, сделал отводы для мультиплексоров от всех счётчиков. Разводка счётчиков ещё не 100%-ая, остались подтяжки и сигналы для вертикали.
До полной схемы генератору осталось всего-то 5 корпусов, которые разместятся сверху от счётчиков - туда как раз и выходы ориентированны.
https://image.prntscr.com/image/_kLM...GJamoBvDjQ.png
Добавил в схему формирование сигналов по вертикали, "начерно" разместил новые корпуса на плате. Если использовать имеющуюся половинку DD12, то будут длинные трассы от него(нижний левый угол платы) в верхнюю часть фрагмента. Если добавить новую ТМ2, будет +1 корпус, но свободная половинка DD22 будет использована в дальнейшем для формирования сигнала переключения пар плоскостей (для вывода изображения из 3-х или 4-х плоскостей). Так что и так и так, одна половинка ТМ2 будет свободна.
Итого - получилось 3 счётчика и 6 корпусов логики для формирования вертикали.
Завтра буду компоновать элементы и корпуса для упрощения трассировки и начну собственно трассировку.
PS: На фрагменте платы заметны места для "широких" шин питания - заведу их позже, как закончу разводку сигналов в текущем фрагменте. Так же, скорее всего, верхний ряд корпусов будет сдвинут вверх для прокладки шины питания - по краям общий и плюс будут разведены по разным слоям друг над другом, а в центральной части платы они будут идти столбцами, чередуясь друг с другом ("общий", ряд корпусов, плюс, ряд корпусов и т.д.).
PPS: В схеме мелкая ошибка - входа DD22A неверно названы. Завтра исправлю у себя, а пока неохота трогать проект в сонном состоянии ;)
По поводу питания - сейчас собрал на макетке начало схемы (генератор, инвертор, счётчик) и посмотрел осциллографом. По питанию получилось около 54мА в пике и около 22мА в среднем - измерял на шунтирующем резисторе 10Ом в разрыве питания. Генератор - SPXO на 25МГц, инвертор - HCT04, счётчик - F163. Подожду переходников SOIC->DIP для сборки более полноценной схемы на макетке и посмотрю ещё раз на почти полной схеме генератора. Заодно и на глитчи проверю схему ;)
С генератором на 1533 серии, кстати, проблема - работает на грани (25МГц из 34 максимальных). В итоге на осциллографе наблюдаем такую картину (желтый - выход генератора, зелёгый - выход первого разряда счётчика):
Фото
По питанию при 1 блокировочном конденсаторе напряжение, снятое с шунта 10Ом в питании:
Фото
Один счётчик 74F163 на потребляет 30мА в пике, с генератором (на фото выше) - 42мА.
В итоге имеем на 2 корпуса 100мА в прыжке, при наличии блокировочных емкостей. Без оных - всё намного хуже, пульсации получаются с амплитудой до 52мА.
Фото макетки
- - - Добавлено - - -
Исправил ссылки на фото :)
Интересная макетка вышла.
Тоже не решился у себя LS на 21.47Мгц ставить. Поставил AS.
Ну, мне проще заказать детали одной-двух серий. В итоге выбор сошелся на HCT, ACT и частично F (те же 163-и счётчики нашел только в таком исполнении в магазине).Цитата:
Сообщение от OrionExt
Закончил предварительную трассировку генератора.
Эскизы
2 связи, оставшиеся по питанию, будут прокинуты сверху, где пока что идёт граница фрагмента ;)
По углу на верхнем слое (красным) видна широкая (2мм) трасса питания - она будет идти по всему периметру платы, полным кольцом. Общий разведён полигонов с обеих сторон, с максимальным заполнением по площади, а самые шумящие участки по возможности проперфорированны "общим" полигоном.
Сегодня-завтра ещё подумаю над оптимизацией трасс, потом буду клепать мультиплексоры и память.
PS: Фрагмент имеет размеры 42х50мм... Плотность зашкаливает:v2_dizzy_punk:
Итак, сделал черновую схему управления памятью. Буферы для видео и формирование видеосигналов дорисую потом, как будет готов данный участок. Как видно по масштабам схемы, места на листе А3 уже впритык для формирователей видеосигналов осталось :)
Нумерация элементов управления памятью пока что временная (начинается со 100).
По схеме возможна установка двух банок 256Кх16, для реализации 512К требуется только первая банка (U1).
Так же разместил 2 системных разъёма - стандартный из Орион-ПРО и расширение к нему, для передачи сигналов от процессорного модуля к видео (так же там 8 линий в резерве, часть уйдёт на селекторы PPI).
По сигналам в схеме:
SR16 - бит порта FA, отвечающий за режим 480/512 точек;
WS - сигнал с DIP-переключателя, отвечающий за формат изображения - 4:3/16:9 (WideScreen);
DSn - /DSYN из оригинальной схемы. При наличии 0 сигнализирует о обращении процессора к оперативной памяти;
MWn, MRn - инверсные сигналы записи/чтения в/из банки памяти. Оба стробированы по DSn;
VA14-VA19 - MA14-MA19 из схемы Орион-ПРО. По VA16 переключаются половинки памяти (младшая/старшая);
YR - сигнал окончания кадра. Для формирования прерывания для Z80;
UBn/LBn - инверсные сигналы выборки старших/младших разрядов памяти. При адресации от процессора зависят от VA16, иначе - оба активны (в лог. 0).
Если что-то пропустил - пишите, добавлю.
Просьба глянуть незамыленным глазом, может где-то ошибся. Конкретно интересует корректность формирования следующих сигналов: UBn, LBn, WE0n, WE1n, OEn, MB0n, MB1n (все находятся чуть выше банок памяти). По этой схеме будет составлена симуляция в FPGA с реальной памятью, но плата для этого теста ещё в Китае висит...
PS: Регистры портов F8 и FA перенёс на эту плату - сигналы используются только здесь, незачем лишние шлейфы тягать через разъёмы. Так же в порту FA разведены биты 2-5 - для выбора шрифта в будущем псевдографическом режиме, который будет реализован только после отладки логики на реальной памяти, для уменьшения объёмов проекта.
Так же позже добавлю подтяжки к питанию для инверсных сигналов от процессорного модуля, что бы можно было с одной этой платой в реале отладить её работу ;)
- - - Добавлено - - -
Исправил обозначение временных элементов на схеме.
Почему ты ставишь две банки 256Кх16? Ставь две банки 512Кх8. При том же объеме имеем: Более широко распространенные и более дешевые чипы, меньше ног (можно найти PLCC с нормальным размером и шагом ног), меньше нагрузка на ШД, проще выбирать плоскости.
- - - Добавлено - - -
Очевидные же вещи, за которые нам при проектировании минус балл ставили.
Или цель заюзать какие-то уже имеющиеся чипы из коллекции неликвида?
Тут вспоминается, как авторы Ориона-ПРО везде где ни попадя совали ТМ8 (видимо у них был запас).
Да, делаю плату под "то, что есть". И заодно на полноценный вариант нужен только 1 чип памяти. А при использовании 8-битной памяти обязательна установка обеих чипов - ведь для видео в цветных режимах всегда необходимо 16 бит данных ;) В итоге при 8 битной памяти имеем два чипа вместо одного, а стоят они примерно одинаково дорого (не на алике, а "здесь и сейчас").Цитата:
Сообщение от Error404
Из доступных локально чипов статики на 8 бит, с питанием 5В нашлась только CY7C1049B-15VI (SOJ). В основном как раз 16-битные чипы встречаю в магазине. Я понимаю, что с алика можно заказать почти всё, но ждать очень долго придётся =/
- - - Добавлено - - -
Я уже всерьёз подумываю над 4-х слойной платой, что бы избавиться от гемороя с разводкой питания - оба внутренних слоя выделить под питание, а сигналы развести на внешних слоях :)
Ох.
Размести элементы чуть свободнее, и шины питания разведутся.
ОЗУ все равно желательно 1Мб или более, в этом уже все убедились кто плотно пользуется хоть DSDOS, хоть доработанными CP/M.
Плату же все равно заказывать "оттуда"? Заказать заодно и ОЗУ, столько же по времени, да и 3 недели никого не устроят. Что-нить типа такого если подешевле (50р. штука). А если подороже (150р. штука), то bs62lv4006sip55 или другие (напр. K6T4008C1B/K6T4008C1C) - там выбор уже шире.
Все же Орион делается, а не РК-86. Для Ориона принцип всегда был "простая конструкция на распространенных элементах", а не производственный маргинализм выполненный из ассортимента военного завода. :)
- - - Добавлено - - -
Кстати, "огласите пожалуйста весь список" - ссылочку на ценник планируемых ОЗУ 256Кх16
1:1 как имеющаяся, только корпус другой (SOJ vs TSSOP).Цитата:
Сообщение от Error404
К нам вообще долго идёт - с перевалочным пунктом в Москве. В итоге получается, что 3 недели - почти недостижимый идеал для авиа, обычно недель 4-5 идёт в среднем. А вот если через Финляндию морем и по суше - 3-4 недели. И это с учётом задержек на нашей таможне - 4 дня минимум, при попадании на ручной досмотр сразу на 1,5 недели может застыть =/Цитата:
Заказать заодно и ОЗУ, столько же по времени, да и 3 недели никого не устроят.
- - - Добавлено - - -
Кстати, по расширению ПРО, есть замечание :)
Вообще-то там 4 бита дополнительных в адрес, что соответствует адресации 1Мб. При расширении с ТМ9 получаем до 4Мб, а не 2Мб.Цитата:
Было:использовалась ТМ8 (4 бита), что адресовалотолько 512кб ОЗУ портом 0F9h, никакоерасширение не было предусмотрено
Всё просто же - каждый бит удваивает количество адресов, в базисе имеем 64Кб. Итого - 64*2*2*2*2=1024 (для ТМ8).
И стоит ли в таком случае вводить расширение адресов 20-21 памяти для последующего расширения или 1Мб "хватит всем"?
- - - Добавлено - - -
Тут уже скорее всего видео не сможет успеть прочитать данные, поскольку придётся вводить задержки на 1-2 такта для чтения/записи. Они сейчас по 100нс, но с учётом задержек на логике вполне может выйти меньше 50нс. И если ввести задержки, время доступа к памяти растянется до 150-200нс, а это означает что при активной работе с памятью видео имеет 90% шанс пропустить пачки пикселей.Цитата:
Сообщение от Error404
С текущими таймингами (100нс на доступ процессора к памяти, вывод из 4--х плоскостей - 2 раза по 16 бит) уже впритык по времени успевает сделать 2-3 обращения к видеопамяти за время вывода предыдущих 8 пикселей. Если увеличим время доступа, получится 1-2 обращения, что хватит только при работе с 2 плоскостями (1 раз по 16 бит).
- - - Добавлено - - -
Не забываем, что у нас пиксельклок 25МГц, то есть время вывода 8 пикселей составляет 40*8=320нс.
За этот период по тестам процессор может обратиться к памяти до 2-х раз(!!!), то есть свободного времени остаётся всего-то 120нс на работу с видеопамятью. А с учётом всех задержек на логике - и того меньше...
- - - Добавлено - - -
По памяти - из доступных имею только 2 типа - AS7C4098A (SOJ, 256Кх16) и CY7C1049B (SOJ, 512Кх8). Могу попытаться развести сразу на оба чипа, по схеме изменений не много получится.
- - - Добавлено - - -
И да - нагрузка на ШД от ширины памяти никак не изменится, всё равно надо 2 АП6, поскольку шина по памяти всегда 16 бит.
Очень правильный вектор мысли.Цитата:
Сообщение от andreil
Да, в курсе.Цитата:
Сообщение от Denn
Питание развести сейчас не особо-то и сложно. Куда хуже дело обстоит с шумами - в любом случае имеем перекрестия дорожек с очень высокой частотой (25М, 13.5М и т.д.) что однозначно приведёт к шумам.
А добавление слоя "общего" и плюса питания обеспечит экранирование подобных перекрестий с очень высоким качеством...
Одно но - цена фрагмента 100х100мм вырастает до 32$ (за 10шт), а увеличение размеров увеличивает стоимость ещё больше (например, 150х150мм 4 слоя стоят уже $70 за те же 10шт). Да, стоимость одного экземпляра ещё оптимальна, да и цена при пропорциональном увеличении площади увеличивается не столь значительно (коэффициент примерно 0,889).
Но если не "взлетит" с традиционной 2-сторонней разводкой, то масштаб потерь будет слишком большой. А решение с отдельными питающими слоями 100%-ое, имхо.Цитата:
Сообщение от andreil
Ну, детали феном "сдуть" недолго вообще. Но вот времени будет жалко. Сейчас дорисую копуса для памяти и посмотрю по компоновке.Цитата:
Сообщение от Denn
Ещё 1 аргумент в пользу большего размера - разъёмы. Если использовать с шагом 2.54мм, то в 100мм укладывается только стандартный на 64 пина (32 в 2 ряда), а надо разместить ещё и дополнительный на 34 пина (16 по 2 ряда), да ещё и с зазором между ними... В итоге и получается, что можно взять плату шириной 150-200мм в 4 слоя - выйдет примерно 60-67$ (и до 20$ за доставку, хотя тут можно ускоренными попробовать уже, вместе с деталями от того же поставщика - всё сразу в 1 посылке).
габариты разъёма
Так и платы уйдут в помойку - а это затраты (время, деньги, нервы).Цитата:
Сообщение от andreil
На все расчеты могу сказать одно: Орион-ПРО c честными 5МГц прекрасно работает на РУ7 середины прошлого века (150нc и это еще оптимистично учитывая их деградацию, у меня например стоят 565РУ7В 1989 года выпуска) и винигретом из 1533/555 серии. Я не совсем понимаю как с применением ОЗУ 70нс (которые по факту быстрее т.к. это отбраковки от техпроцесса выпуска 55нс, мне кстати часто слали 55 вместо 70) и логики 74F / 74HCT (которая вдвое быстрее) должно не запуститься.
- - - Добавлено - - -
Вот это вот что сейчас было? Попытка обучить старичка двоичной арифметике? Чтобы он значит не лез с советами по технологии? :DЦитата:
Сообщение от andreil
Ладно, пойду перечитаю учебники арифметики за 3-й класс.
Тут не такая "арифметика". Логика 74HCT - это быстрые КМОП, а у них:Цитата:
Сообщение от Error404
- круче фронты = ядрёнее помехи переключения;
- огромное входное сопротивление = шикарная восприимчивость к наводкам.
Соответственно, требования к плате намного выше.
П.С. мне хватило секаса с винбондом, чтобы прочувствовать все прелести быстрых КМОП. Замечу, это всё на скоростях обычного О-128 @ ВМ80.
Нет, это просто был когнитивный диссонанс от прочитанного ;)Цитата:
Сообщение от Error404
- - - Добавлено - - -
Одно но - для РУ7 сделаны такты ожидания. По схеме -Цитата:
Сообщение от Error404
на 2 такта по 10МГц(вывод 7 D87). Получается одна только задержка обращения уже200нс, сюда плюс ещё время фронта записи (которое меньше чем у чтения) в200нсна 10МГц без ожиданий. Вот и имеем400нсна запись/чтения памяти процессором.
И не стоит забывать о частоте чтения из видеопамяти - в оригинале пиксельклок 10МГц, здесь уже 25МГц. Соотвественно и время доступа к видеопамяти в 2,5 раза меньше.
- - - Добавлено - - -
О габаритах памяти - накидал имеющиеся корпуса без оптимизаций (посадочные сразу под оба варианта - 256Кх16 и 512Кх8). Скриншот с габаритами 100х100м:
Скрин
Даже при текущих габаритах места вполне достаточно для реализации всего модуля (остались только регистры видеоданных, сдвиговые регистры для цветов, мультиплексоры и 1-3 корпуса логики). Вся проблема в разъёме... Или увеличивать размер платы или делать на шлейфе...
- - - Добавлено - - -
Ошибся - в ПРО задержка идёт на 1 такт - для памяти на такте T2, для IO - на такте T3 (TW в ДШ). И цикл записи длится 1 такт, 100нс. Итого получается на 10МГц время обращения к памяти составляет 200нс.
- - - Добавлено - - -
Кстати, возвращаясь к размеру плат.
Если делать 4-х слойку (с питанием и общим в средних слоях, ест), то вполне имеет смысл увеличить плату до, например, 100х200мм. В таком случае на данном участке разместится процессорная часть компьютера и не нужен будет дополнительный разъём. Естественно, что ПЗУшки будут в PLCC. Периферия (клавиатура и прочее) на плате не уместятся 100% (если только не сделать клавиатуру сразу на STM'ке какой-либо вместо ВВ55 - сразу с USB на данные отдавать результат).
Так же имеет смысл заменить ВВ55 на пары регистров с защёлками (что бы и писало и читало). Тогда и ожидание для PPI не придётся вводить :)
Меня, честно говоря, удивляет, почему авторы изначально так не сделали? Хотя может в плане габаритов одна ВВ55 выигрышнее..Цитата:
Сообщение от andreil
В DIP-корпусах - однозначно выгоднее по габаритам.Цитата:
Сообщение от Denn
Кстати, посмотрел в задержки логики серии 74HCT и приуныл... 74F на порядок шустрее, но и ценник почти в 2 раза выше :) Из вариантов - AHCT.
andreil, я для системы с тактом 20 МГц для себя выбрал серию 74ACTxxx. Самая требовательная часть (синхроген) взлетела, из чего делаю вывод о пригодности этой серии.
Ну да, по характеристикам почти аналогичны эти серии.Цитата:
Сообщение от Denn
Вся беда в том, что счётчики (ИЕ18, они же 74x163) имеются только серии F, задержки только здесь по факту около 15нс по фронтам сигналов при периоде сигнала 40нс - может и прокатит ещё. Вся проблема в том, что получаются довольно длинные цепочки логики, состояние которых защёлкивается по отрицательному спаду такта, то есть через 20нс.
andreil, я в синхрогене использовал 74AC163. Соотношение сигналов (компенсация задержек) выравнивал холостыми цепочками инверторов и свободными элементами 2И (там, где инверсия не требовалась).
Да, сегодня по схеме посчитаю примерные задержки и гляну, где надо такие цепочки вводить у себя.Цитата:
Сообщение от Denn
Очень они их любили, вспомнить хотя бы Орион-ПРО, где даже диспетчер по 16к сделан на ВВ55 где вместо её и кучки логики просто просится схема с двумя ИР26 (не ограничивающая быстродействие и дающая полноценный диспетчер, а не 3 окна из четырех). Думаю, в 1995 году на Тушино уже можно было купить любые TTL в практически неограниченных количествах. С другой стороны, применение ВВ55 где ни попадя это было стандартной практикой в СССР, а всю линейку ТТЛ возможно знал и не каждый проектировщик-любитель (а так и было).Цитата:
Сообщение от Denn
- - - Добавлено - - -
OMG, какое упрямство. :) Ну ладно, не Орион-ПРО (допустим, пример не очень, авторы себе облегчили жизнь урезав скорость), но и Орион-128 тоже в 90х турбировали до честных 5М на 565РУ7В все времянки фактически умножая на 2. 150нс и 5Мгц вполне сочетались, т.е. нисколько не убедили, что 10М и 70нс (тем паче что на самом деле никто не мешает поставить 55нс) несочетаемы.Цитата:
Сообщение от andreil
- - - Добавлено - - -
Да чего там, даже на РУ5 (200нс) делали честные 5М, вон barsik не даст соврать.
Посмотрим в модели ;)
Актуальный вопрос - делать 2 модуля с шлейфом (на 34 контакта) между ними или в 1 плату 100х200мм уместить?
- - - Добавлено - - -
Писал уже об этом:
Цитата:
Сообщение от andreil
Если решили за 4-слойку и жирные шины питания уходят, то может всё поместится в 10х10 если полностью задействовать под размещение элементов и вторую сторону п.п. ?Цитата:
Сообщение от andreil
Максимально уменьшить габаритные части - например системный разъем вынести в виде укороченного по длине контактов краевого (примерно как на девбордах прототипов). На такой краешек чудесно "встык" паяются 2-рядные разъемы будь то хоть IDC, хоть PLC, хоть DIN41612. Единственно, проследить чтобы все что потенциально идет в панельки, попало строго на одну сторону.
Порты ВВ55 (в т.ч. клавиатура, ром-диск, F600) вообще на эту плату не тащить (тем более не ясно ставить там ВВ55 или контроллер на ARM64 100500Ггц или ТТЛ-регистры), под это дело сделать отдельную дешевую 2-слойную плату 10х10 с ВВ55 и сразу с RS-232, SPI, {предлагайте прочее}. Понятно, что запускать эти платы можно будет по отдельности.
При таком концепте, когда модуль цпу не будет жить без модуля видео как-то делить их, на мой взгляд, не имеет особого смысла. По мне размер модуля должен вписываться в 100х100(или 160). Две отдельные платы или две платы - бутерброд или одна плата (все равно это единое целое по факту). В общем надо исходить только из стоимости (считать).Цитата:
Сообщение от andreil
А может и задумываться не надо делать все по мин цене (платы 100х100). А если что-то из этой затеи вырастит работоспособное тогда и задуматься о финальном варианте. Я так и поступаю у себя и не пытаюсь объять необъятное и впихнуть невпихуемое. Пускай дольше выходит путь до какой-то идеальной цели, зато промежуточный результат работы виден достаточно быстро. И главное его можно уже пощупать и понять, куда двигаться дальше.
Да, буду в 4 слоя делать. Питание с сигнальных слоёв уже убрал - буду перемещать и блокировочные ёмкости, а так же оптимизировать ближайшие проводники для прохождения питания к микросхемам.Цитата:
Сообщение от Error404
НО плотности - ну, так плотно вряд ли получится - на промежуточных слоях только питание. Сигнальные линии как были в 2 слоя, так и останутся. Часть генератора и так уже достаточно плотная, хотя есть определённые места, где можно что-либо сдвинуть.
А вот по разъёму очень дельное предложение. Вот примерная компоновка на текущий момент:
Скрин
Вырезы под разъём сделаются как устаканится всё, так что пока работает "в квадрате". Мультиплексоры адресов сдвинуться вниз, на их место попадёт часть логики с верхней части. Ещё в правой части пару чипов на каждой стороне можно уместить - надо смотреть, что бы не было больших частот, поскольку там будут длинные петли на мультиплексоры и видевыход.
Места для видевыхода вполне достаточно на плате, но вот под псевдографику на ПЗУшке может и не хватить места - надо смоделировать ещё, а то непонятно что по схеме переделывать придётся даже.
- - - Добавлено - - -
По стоимости - 2 платы 100х100 и одна 100х200 в 4 слоя стоят почти одинаково.Цитата:
Сообщение от OrionExt
При размере 100х100 получается около 4$ за плату в 4 слоя (без доставки, ест).
Но, скорее всего, так и буду делать модулями, как и задумывалось изначально.
- - - Добавлено - - -
По компоновке памяти - чипы расположены "будербродом". На одной стороне 256*16, на другой - 512*8.
Разработку платы пока поставлю на паузу - буду работать над клавиатурой, пока не придут макетки для памяти. Потом вернусь сюда, проверив функционирование видеовыхода на всех режимах...
Пока можно в видео добавить и отладить алфавитно-цифровой дисплей (8x8, 8x16) соответственно по восьмым или шестнадцатым строкам экрана. Обсудим?
А что не так с клавиатурой? Чтобы над ней работать? :)
Еще у меня была идея сделать SPI-клавиатуру. Матрица 8x8 и 8 бит отдельностоящих управляющих кнопок (в частном виде - это клавиатура РК86 где 8x8 + 3 бит). Прицепить можно к SPI-адаптеру из соседней темы (параллельно SD и прочим SPI-устройствам). Аппаратно в РК-SPI-клавиатуре 2 регистра ИР8 и ИР9 (а лучше 74595), мультиплексор КП11/16 "матрица/функциональные" и счетчик до 8 (ИЕ5) для управления мультиплексором. Опрос такой:
out (SPI), a # scancode
in a, (SPI) # control keys (8 bit = 8 key status)
in a, (SPI) # other keys (through matrix depending pressed key)
Сканируется так: в из SPI одновременно выводятся и вводятся в него данные (идеология кольца), поэтому при первом OUT по сдвигу первого бита наружу, во входящий регистр защелкиваются биты кнопок управления и задвигаюся в SPI (откуда потом и прочитываются хостом) в первом IN, а далее клава записывает в свой выходной сдвиговый регистр уже код по матрице (ко второму байту сканкод уже перетёк в клаву) что прочитывается хостом во втором IN. Причем при желании это даже можно замапить на порт F400, управляя от его обращений селектом spi-устройства (клавиатуры).
- - - Добавлено - - -
т.е. если хорошо обмозговать, можно сделать почти (или совсем) совместимо с клавой RК86 Ориона, причем без ВВ55 и на минимуме рассыпухи (считаем что SPI-контроллер уже есть).
Я сейчас на STM32 делаю контроллер USB клавиатуры. Уже оба девайса сразу можно использовать, если оба "висят" на одном "свистке". С PS/2 у меня проблема - единственная сейчас не работает (нет тактов от неё вообще, но при включении мигает светодиодами).Цитата:
Сообщение от Error404
В перспективе этот контроллер можно использовать как с ВВ55, так и вместо ВВ55, то есть сразу подключив к управляющим шинам. А если надо прочие интерфейсы - прокинуть ещё пару проводков (чип-селектов) и реализовать их софтварно в МК.
По видео - можно, но не раньше чем в понедельник.
По реализации псевдографического режима есть идея. Ограничение - знакоместо 8х8 или 8х16.
Подключение ПЗУ с шрифтами/графикой: А0-А7 - VD0-VD7 (видео-данные из первого банка), А8-А11 - Y0-Y3 (счётчик пикселя по вертикали, первые 4 бита), А12 - выбор высоты шрифта (8/16), А13-А16 - FNT0-FNT3 (выбор шрифта).
Выбор режима осуществляется битом 5 порта F8, битом 4 выбирается режим 8/16 (8х8/8х16).
Выбор шрифта (FNT0-FNT3) - биты 2-5 порта FA. Бит 6 по схеме Про отключает регенерацию, а бит 7 - расширенный режим (у меня 6 бит игнорируется). Биты 0-1 по-прежнему переключают видео-банки.
Итого имеем ПЗУ на 128Кб, в которую можно записать 16 шрифтов. Можно использовать и меньшие ПЗУшки, просто будет доступно меньше шрифтов.
Примерная реализация в схеме.
Итого - добавляется ПЗУ, 2 мультиплексора (надо же "вклиниваться" в разрыв видеоданных между защёлками и сдвиговыми регистрами).
По биту переключения 8/16 - может его взять из порта видеорежима? Например, любой бит из 0-3.
- - - Добавлено - - -
Забыл ещё один мультиплексор - он будет коммутировать сигналы Y0-Y3.
При включенной псевдографике Y0-Y2 всегда садятся в "0", а Y3 - только при высоте шрифта 16 пикселей.
PS: И нужен ли режим высотой 16 пикселей или хватит только 8? Без него логика несколько упроститься, ПЗУ можно поменьше использовать (на 32Кб для 16 шрифтов).
Фонтов в твоем решении получается не 16, а 32, если аппаратно не увязывать сигнал G16 к переключению Y{2} Y{3} (т.е. режим фонта 8/16), а ставить G16 независимо. Да, тут возможен эффект когда получается режим где фонт на 8 рисуется половинками букв по 16, или фонт на 16 рисуется из двух букв по 8 (ничего страшного, об этом должен позаботиться автор ПО конфигурирующего порты F8 и FA), но зато при меньшем обязательном количестве адресных ног ПЗУ получаем возможность иметь, к примеру, 3 шрифта высотой 16pix и 5 шрифтов на 8pix. Итого в сумме 8 и освобождается 2 адресных ноги ПЗУ.Цитата:
Сообщение от andreil
Освобождаются для чего: Вместо абстрактной ПЗУ на 128к ставим конкретную быстродействующую W28С512-45Z в 28-ногом корпусе (в Китае по рублю пучок) и ножку А15 заводим на бит включения алфавитно-цифрового дисплея. При этом нижняя (А15=0) половина ПЗУ прошивается константным кодом VD{0..7}=GD{0..7} (т.е. передавать входные данные на выход без изменений), за счет чего исключаются 2 КП11 с твоего рисунка (которые ниже ПЗУ), а верхняя половина ПЗУ прошивается фонтами (их получается 8 на оба режима). Останется 1 мультиплексор для зануления Y0-Y2 (он на схеме не изображен).
- - - Добавлено - - -
По включению режима алфавитно-цифрового дисплея: вот тут мы под это дело сделали на будущее задел битом D6, только что-то я не помню это порт F8 или порт FA. Хотелось бы чтобы у тебя было включение этого режима аналогичным битом. Остальные биты бери свободные какие угодно, только учти что в Орионе-ПРО есть дополнительные режимы относительно Ориона-128 (занято на 2 бита больше в режимах цветности), не хотелось бы с ними пересечься. Кстати, один из этих двух дополнительных битов включает режим "Цветного монохрома" когда цветовые атрибуты задаются на весь экран значением порта FC. Полезный режим, он у нас будет? Особенно было бы интересно если бы этот порт при включенном его бите в цветных режимах добавлял бы смещение к штатному RGBI - этакие микропалитры (на ПРО этого нет, а зря).
Сигналом G16 переключаются банки шрифтов 8/16. Если его убирать, то нужно делать только 1 высоту шрифта. Он задаётся битом порта F8. Формировать шрифт из "половинок" не получится, ИМХО.Цитата:
Сообщение от Error404
"Цветной монохром" будет - видеовыход я взял из ПРО, на ПЛИС меню Прошки показывается отлично, а она именно в этом режиме идёт. По смещению - это будет сложнее реализовать и надо продумывать уже сейчас. Пока что не соображаю, как это сделать даже.Цитата:
Сообщение от Error404
Сигнал G16 это всего-лишь адресная ножка ПЗУ и делитель на 2 для набора шрифтов. Только нам решать в какой момент какой сигнал на этой ножке. Я не предлагал формировать шрифт из половинок, я наоборот писал что если программист не понимает связи между размером шрифта и адресом (оффсетом в ПЗУ) шрифта, то при G16 просто заведенной на бит порта FA/F8 (как предлагаю я, и уже это будет не G16 а тупо адрес фонта) он получит на экране половинки букв или задвоенные по вертикали буквы вместо ожидаемого.Цитата:
Сообщение от andreil
А если он понимает что делает, то прекрасно можно совместить 8-байтовые и 16-байтовые шрифты в общем массиве (а не отводить половину ПЗУ под одни и половину под другие где в половине ПЗУ с 8pix шрифтами половина емкости пропадает). И тогда 8 шрифтов достаточно с запасом (у меня например для режима 8х8 на орионе имеется всего 3 шрифта, а шрифтов на 16 нет вообще), шрифты влезут в 32к, и вместо "27С010+2хКП11" можно иcпользовать только одну W28С512 (где половина её прошита под pass-through кодом с 128-ю повторяющимися блоками перечисления 0..FF).
Как-нибуть диодами и резисторами, которые будут добавлять смещение когда регистр порта FC не находится в Z (т.е. включен битом порта). Как в VGA делают R2R весА для многобитного RRRRGGGGBBB ? Вот примерно так же: старший бит вЕса это RGBI точки (из видеопамяти второй страницы - атрибутов цвета), а младшие веса - с регистра порта FC.Цитата:
Сообщение от andreil
- - - Добавлено - - -
Причем набор из 8 фонтов это для размерности 16pix, для 8pix этих фонтов будет уже 16 штук, ну или комбинации шрифтов разной размерности (пакуй их в ПЗУ в какой угодно последовательности, просто помни что как сделал и так и используй в ПО - в итоге придем к общему для всех устаканившемуся набору смеси из 8 и 16 битных шрифтов, записанных в ПЗУ "впритык"). Т.е. нужно аппаратно никак не связывать между собой режим сканирования символа (8/16) и офсет в ПЗУ (адрес фонта кратно 2кб - задается отдельно 4 битами какого-нить порта F8/FA).
По шрифтам - в Орионе они идут 7-битные или полные, 8-битные?
Если 7-битные, то этот "лишний" бит можно использовать как раз вместо сигнала G16.
По моей реализации с сигналом G16: адрес Y2 пропускаем через AND с G16 - получаем, что он будет активен только при "1" на G16. А для памяти Y2 - через OR. И не будет ни половинок, ни раздвоений. На схеме это не изобразил, потому что рисовал на скорую руку на обеде :)