Очень правильный вектор мысли.Сообщение от andreil
Я уже всерьёз подумываю над 4-х слойной платой, что бы избавиться от гемороя с разводкой питания - оба внутренних слоя выделить под питание, а сигналы развести на внешних слоях
Очень правильный вектор мысли.Я уже всерьёз подумываю над 4-х слойной платой, что бы избавиться от гемороя с разводкой питания - оба внутренних слоя выделить под питание, а сигналы развести на внешних слоях
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Да, в курсе.
Питание развести сейчас не особо-то и сложно. Куда хуже дело обстоит с шумами - в любом случае имеем перекрестия дорожек с очень высокой частотой (25М, 13.5М и т.д.) что однозначно приведёт к шумам.
А добавление слоя "общего" и плюса питания обеспечит экранирование подобных перекрестий с очень высоким качеством...
Одно но - цена фрагмента 100х100мм вырастает до 32$ (за 10шт), а увеличение размеров увеличивает стоимость ещё больше (например, 150х150мм 4 слоя стоят уже $70 за те же 10шт). Да, стоимость одного экземпляра ещё оптимальна, да и цена при пропорциональном увеличении площади увеличивается не столь значительно (коэффициент примерно 0,889).
Последний раз редактировалось andreil; 16.03.2018 в 11:15.
"Байт-48"
Но если не "взлетит" с традиционной 2-сторонней разводкой, то масштаб потерь будет слишком большой. А решение с отдельными питающими слоями 100%-ое, имхо.
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
Ох.
Размести элементы чуть свободнее, и шины питания разведутся.
ОЗУ все равно желательно 1Мб или более, в этом уже все убедились кто плотно пользуется хоть DSDOS, хоть доработанными CP/M.
Плату же все равно заказывать "оттуда"? Заказать заодно и ОЗУ, столько же по времени, да и 3 недели никого не устроят. Что-нить типа такого если подешевле (50р. штука). А если подороже (150р. штука), то bs62lv4006sip55 или другие (напр. K6T4008C1B/K6T4008C1C) - там выбор уже шире.
Все же Орион делается, а не РК-86. Для Ориона принцип всегда был "простая конструкция на распространенных элементах", а не производственный маргинализм выполненный из ассортимента военного завода.
- - - Добавлено - - -
Кстати, "огласите пожалуйста весь список" - ссылочку на ценник планируемых ОЗУ 256Кх16
Последний раз редактировалось Error404; 16.03.2018 в 10:26.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
1:1 как имеющаяся, только корпус другой (SOJ vs TSSOP).
К нам вообще долго идёт - с перевалочным пунктом в Москве. В итоге получается, что 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% шанс пропустить пачки пикселей.
С текущими таймингами (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 бит.
Разработку платы пока поставлю на паузу - буду работать над клавиатурой, пока не придут макетки для памяти. Потом вернусь сюда, проверив функционирование видеовыхода на всех режимах...
Пока можно в видео добавить и отладить алфавитно-цифровой дисплей (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-контроллер уже есть).
Последний раз редактировалось Error404; 17.03.2018 в 14:58.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Я сейчас на STM32 делаю контроллер USB клавиатуры. Уже оба девайса сразу можно использовать, если оба "висят" на одном "свистке". С PS/2 у меня проблема - единственная сейчас не работает (нет тактов от неё вообще, но при включении мигает светодиодами).Пока можно в видео добавить и отладить алфавитно-цифровой дисплей (8x8, 8x16) соответственно по восьмым или шестнадцатым строкам экрана. Обсудим?
А что не так с клавиатурой? Чтобы над ней работать?
Еще у меня была идея сделать SPI-клавиатуру. Матрица 8x8 и 8 бит отдельностоящих управляющих кнопок (в частном виде - это клавиатура РК86 где 8x8 + 3 бит). Прицепить можно к SPI-адаптеру из соседней темы (параллельно SD и прочим SPI-устройствам). Аппаратно в клавиатуре 2 регистра: ИР8 и ИР9 (а лучше 74595) и мультиплексоре "матрица/функциональные". Опрос такой:
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-контроллер уже есть).
В перспективе этот контроллер можно использовать как с ВВ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 адресных ноги ПЗУ.
Освобождаются для чего: Вместо абстрактной ПЗУ на 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 - этакие микропалитры (на ПРО этого нет, а зря).
Последний раз редактировалось Error404; 10.04.2018 в 15:04.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
