Просмотр полной версии : Еще один Орион НЕ на ПЛИС или калинка-малинка по-русски
Хочу предложить тусовке следующий концепт: использование платформы Орион-128(ПРО) в качестве МПС-конструктора.
Вкратце суть в следующем. Мы имеем на 97% феньшуйный, "тот самый" Орион, с его прекрасной и любимой архитектурой, выполненный на трушной рассыпухе, который включает в себя всё базовое, кроме видео-части; при этом собран на КМОП-логике (в т.ч. ЦП - Z80 "PEC", это и есть те самые минус 1% феньшуйности), в качестве основного ОЗУ - один чип статики 512Кх8 (вторые минус 1%), плюс SROM-диск на ещё одном таком же чипе СОЗУ и COM-порт.
Также на основной плате имеем классический системный разъём для подключения всевозможных "свистелок" и специальный разъём для подключения видео-части (в виде платы-дочки) и т.о. возможности "лёгким движением руки" получения полноценного ПРК.
Основной упор на малый размер (в "запущенном варианте" если ставить SOIC'и с обеих сторон платы, то будет вообще кроха, кмк) и ничтожное потребление главной платы, т.е. возможности её использования в качестве контроллера для управления различным оборудованием или для каких-либо других радиолюбительских задач, не требующих подключения к монитору. В МПС-варианте возможна работа на популярные символьные ЖК-индикаторы (соотв. поддержка в ПО уже есть).
Видеокарта-дочка для простоты может быть реализована на двухпортовом СОЗУ, со своим независимым от основной платы синхрогенератором и SVGA-выходом (режим 800x600@60Гц). Эта часть конечно отъедает ещё 1% по феньшую, но организация расшаривания основного ОЗУ вылетит в хороший комок россыпи и загубит на корню идею минимализма и простоты. Впрочем, ничто не мешает заморочиться... но только как нибудь без РУ5-ых :)
Загрузка ПО проще всего производится через COM-порт (в т.ч. по радиоканалу). Для этого в ОС встраивается специальный механизм (протокол), который активируется при загрузке, и если платформа подключена к хосту (например, другому Ориону) и тот ответил (готов засылать обновление), то автоматически производится загрузка данных с последующей записью в SROM и рестарт.
Разумеется возможны варианты загрузки ПО с жёсткого диска, SDHC-карты и даже, прости господи, с дискеты. Для этого подключаются "видеокарта" с монитором, полноценная клавиатура, плата поддержки соответствующего накопителя.
На базе такого семейства устройств возможны варианты организации трушного полностью 8-битного комплекса: полноценный Орион в качестве сервера и управляемые терминальные МПС-клиенты. Связь по каноничной RS-232 (или как её там по-русски.. СТЫК Цэ Два ? :)).
Разработка полностью отечественная, никакой копипасты с пиндосских платформ и ПО, никаких "плисок", "галок" и прочей антитворческой халявы. Могла быть запросто реализована в те далёкие 90-ые, без интернетов, даташитов, САПР и т.п.. Канонично, феньшуйно, и в то же время относительно современно и свежо :)
Интересно мнение общественности касательно востребованности такого решения.
OrionExt
19.03.2019, 15:06
Видеокарта-дочка для простоты может быть реализована на двухпортовом СОЗУ, со своим независимым от основной платы синхрогенератором и SVGA-выходом (режим 800x600@60Гц).
Разработка полностью отечественная, никакой копипасты с пиндосских платформ и ПО, никаких "плисок", "галок" и прочей антитворческой халявы.
Что то тут не вяжется:D
Error404
19.03.2019, 15:28
Концепция прикольная, к похожему итогу как я понимаю должен был прийти andreil вот в этой теме (https://zx-pk.ru/threads/28763-eshche-odin-orion-na-plis.html), но там пока всё заглохло (а до того были шатания и в сторону ПЛИС, и в сторону более мелких GAL, варианты с однопортовым и двухпортовым ОЗУ на диких тактовых частотах).
Я в свое время собирался сделать микро-Орион чуть усложнив 4-чиповую схему Гранта Сирла (главным образом, расширив ОЗУ до 512кб на одном статическом ОЗУ на порту F9 и внедрив между страницами область связи F000..FFFF что моментально дает совместимость с Орионом, по крайней мере для терминальных прог и ОСей), и работать с этим контроллером без видевыхода (сугубо терминалом по RS-232), но не одолел пайку на макетке (уже на первой сотне устал проводнички резать и зачищать). Так что если наберется группа на выпуск микроплаток, я бы поучаствовал. Но так ли уж нужны подслеповатые soic-и? Может, всё же DIP? Такой формфактор тоже можно сделать компактым, разместив небольшие DIP-чипы (их будет немного если унести видеовывод вместе с DP ОЗУ на внешнюю VGA-платку) внутри 40-ногих панелек .
- - - Добавлено - - -
Вот еще один микрокомп Сирла, в EasyEDA, в качестве старта
https://easyeda.com/Herman/Grant_Searle_56K_Z80-U3ZTN5Zhy
OrionExt
19.03.2019, 15:40
Тут как бы одна не решаемая проблема. Это привязка ЦПУ к синхрогенератору для вывода видео. Решение стандартное и дешевое для компов тех лет.
andreil пошел по пути? Ничего не буду говорить на эту тему.
- - - Добавлено - - -
Дык нужна асинхронная работа любого подключаемого узла (на MSX все апробировано в железе). Вот и все. И тогда …
Что то тут не вяжется:D
Не надо вырывать из контекста, там дальше написано:
"Эта часть конечно отъедает ещё 1% по феньшую, но организация расшаривания основного ОЗУ вылетит в хороший комок россыпи и загубит на корню идею минимализма и простоты. Впрочем, ничто не мешает заморочиться... но только как нибудь без РУ5-ых"
OrionExt
19.03.2019, 16:10
Не надо вырывать из контекста, там дальше написано:
"Эта часть конечно отъедает ещё 1% по феньшую, но организация расшаривания основного ОЗУ вылетит в хороший комок россыпи и загубит на корню идею минимализма и простоты. Впрочем, ничто не мешает заморочиться... но только как нибудь без РУ5-ых"
Не ну опус прикольный. Я просто сократил:)
Но так ли уж нужны подслеповатые soic-и? Может, всё же DIP?
Разумеется - не принципиально. На SOIC'ах если нужна суперкомпактность, что-то типа "малинок". Можно как угодно реализовать, пока что процесс на этапе разжёвывания идеи и понимания нужно ли оно вообще :)
OrionExt
19.03.2019, 16:17
Разумеется - не принципиально. На SOIC'ах если нужна суперкомпактность, что-то типа "малинок". Можно как угодно реализовать, пока что процесс на этапе разжёвывания идеи и понимания нужно ли оно вообще :)
О, я представляю. Когда человек за 40-50 лет. Тыкает по SOIC щупом и занимается отладкой. Заканчивай веселить:D
Так нет у тебя идеи. Вот пиндосы уже все придумали в 70 годах прошлого века и малинка – пындосы, сволочи. Где твоя идея?
Концепция прикольная, к похожему итогу как я понимаю должен был прийти andreil вот в этой теме, но там пока всё заглохло (а до того были шатания и в сторону ПЛИС, и в сторону более мелких GAL, варианты с однопортовым и двухпортовым ОЗУ на диких тактовых частотах).
вроде не заглохло, паяется...
https://vk.com/csm_andreil?z=photo18564428_456239673%2Fwall185644 28_810
OrionExt
19.03.2019, 16:30
О, я представляю. Когда человек за 40-50 лет. Тыкает по SOIC щупом и занимается отладкой. Заканчивай веселить:D
Так нет у тебя идеи. Вот пиндосы уже все придумали в 70 годах прошлого века и малинка – пындосы, сволочи. Где твоя идея?
О, Форум глюканул
Error404
19.03.2019, 17:17
вроде не заглохло, паяется...
https://vk.com/csm_andreil?z=photo18564428_456239673%2Fwall185644 28_810
не знал про вконтактик автора, а тут он что-то не пишет.
Платка выглядит похожей на Орион-2010 (https://radiokot.ru/circuit/digital/pcmod/32/) (как я понимаю, будут схожие параметры + USB), только посложнее. Альтера BGA, а мы тут soic-ов пугаемся. :)
OrionExt
19.03.2019, 17:32
Denn, ты такое иногда мечешь. Я бы поверил в не меняемого, но я обладаю исходниками твоей ДОС из 90х, вполне пытливый ум молодого человек это писал.
Аминь. Поразмыслить, это вообще трагедия умов о строительстве ЭВМ и реализации своих идей в СССР.
О, я представляю. Когда человек за 40-50 лет. Тыкает по SOIC щупом и занимается отладкой.
Сейчас не делают платы утюгом. Платы заводского изготовления работают из коробки, отлаживать там нечего. Паяется SOIC с помощью оптики прекрасно; у кого тремор, те довольствуются пайкой DIP'ов. Ленивые развлекаются в виртуальном домене.
Так нет у тебя идеи... Где твоя идея?
Перечитай тему с начала, может поможет.
Вот пиндосы уже все придумали в 70 годах прошлого века и малинка – пындосы, сволочи.
Я рад за них. Мне их путь не интересен.
- - - Добавлено - - -
..это вообще трагедия умов о строительстве ЭВМ и реализации своих идей в СССР.
Нет. Трагедия это писатели на форумах, у которых нет своих идей, но и другим шоб нефиг..
Альтера BGA, а мы тут soic-ов пугаемся.
BGA паять ещё проще :) Немного оснастки и никаких проблем.
Сообщение от OrionExt Посмотреть сообщение
О, я представляю. Когда человек за 40-50 лет. Тыкает по SOIC щупом и занимается отладкой
Мне 62 , и что списать себя в утиль ? А мелочь паяется очень даже и легко. Слегка даже и набрежно, затем лишнее олово убираем оловоотсосом.
Коллеги, давайте не будем обсуждать типы корпусов микросхем, суть темы не в этом. Придираться к фразам о степени соответствия феньшуйности тоже.
Сабж мог бы быть реализован средствами, доступными в 90-ых, но это не означает, что таковые обязательно нужно использовать сейчас. Лично я сегодня не сяду за ламповый телевизор и не буду делать БП на 50-герцовом преобразовании, равно как изготавливать плату по технологии ЛУТ, потому что слишком стар для таких подвигов, разумно ленив и имею некоторое излишество средств на хобби. Но и выходить за рамки олдскула не хочется, ибо круг 8-битных интересов остался там, в 90-ых.
Вот такое:
https://pp.userapi.com/c824700/v824700160/151f5e/6YPpFoNoZ0I.jpg
https://pp.userapi.com/c623900/v623900793/530b/7cG5F8Khvl4.jpg
паяется без проблем, и это при том, что зрение уже совсем ни к чёрту. Также считаю, что это вполне вписывается в рамки феньшуя, впрочем тут каждый решает для себя сам, свою позицию нисколько не навязываю.
не знал про вконтактик автора, а тут он что-то не пишет.
Платка выглядит похожей на Орион-2010 (https://radiokot.ru/circuit/digital/pcmod/32/) (как я понимаю, будут схожие параметры + USB), только посложнее. Альтера BGA, а мы тут soic-ов пугаемся. :)
Ну, я как бы делаю "для себя", потому и решил не ограничиваться :)
Если убрать СТМку, то можно сразу треть платы вырезать по площади. А если забить и на преобразователи уровней - ещё почти треть :)
У пробного макета с прошивкой "недо-Орион-ПРО-MAX" (ПРОшка, но с полным портом FB, переключением видеорежимов и прочими плюшками) вполне получается на 2-х плоскостях выдавать видео 1920*1080@60Hz без торможения, при частоте процессора около 9,3МГц. YНо это тестировалось только на макетке, где были большие шумы на памяти - потому пришлось растягивать тайминги. Здесь планирую при тех же параметрах в 4 плоскости вывод сделать уже - по норме это вполне осуществимо, и даже с запасом.
На СТМку переложил следующее: клавиатура, HDD, FDD (в виде образов на карте памяти или USB-флешке), управление видеовыходом, формирование оверлея (меню СТМки в виде оверлея поверх основной картинки, ага).
Для интересующихся, вот схема текущего варианта :)68539
Так же будет (возможно) вторая платка попроще - уже в 2 слоя всего (основная плата 4-х слойная, иначе BGA не развести). Там пока что планируется HDMI, индикация работы и пара кнопок. Остальные "хотелки" будут дописываться по факту по мере реализации прошивки.
Error404
20.03.2019, 14:13
Вот такое:
{IMAGES}
паяется без проблем, и это при том, что зрение уже совсем ни к чёрту. Также считаю, что это вполне вписывается в рамки феньшуя, впрочем тут каждый решает для себя сам, свою позицию нисколько не навязываю.
Если шаг выводов 1,25, то вполне терпимо, согласен. мЕньшие размеры я уже не запаяю наверное (чтобы с первого раза, без лупы, т.е. комфортно).
Кстати, статические ОЗУшки в планарных корпусах (с теми самыми 1,25 мм шага ног) обычно раза в два дешевле, чем в DIP
...чтобы с первого раза, без лупы...
А зачем паять мелочь без лупы? Комфортно - это когда комфортно :)
Кстати, статические ОЗУшки в планарных корпусах (с теми самыми 1,25 мм шага ног) обычно раза в два дешевле, чем в DIP
И это тоже!
А зачем паять мелочь без лупы? Комфортно - это когда комфортно :)
Вот кстати - да. С лупой даже что покрупнее лучше паяется - и точнее отпозиционировать и соплей меньше.
По своей платке - после сборки текущего варианта всё равно буду перезаказывать, уже есть достаточно мест по улучшению. Особенно по пайке и организации крепления для теплоотвода (сейчас плату чересчур сильно будет выгибать.
Итак, продолжим по сабжу. Делаю черновые наброски схемотехники.
Полагаю, проектировать новый комп в 2019-ом году с тактом 3,5/5 МГц было бы как минимум издевательством. В природе давно существуют КМОП-версии Z80 на 20 МГц, а сейчас скорее всего только они и продаются (из КМОП), логично заложить в схемотехнику их поддержку.
В связи с этим тактовый генератор будет таким:
https://pp.userapi.com/c850636/v850636216/de4f7/fAu_1qrPHAk.jpg
Идея в следующем. По-умолчанию (при сбросе) включен родной орионовский клок = 2,5 МГц. Программно через порт #FC активируется т.н. режим "турбо", который с помощью джамперов конфигурится исходя из установленного экземпляра процессора.
Этим процессом рулит новое ПО (например, ОС), старое ПО про это не знает, но ему и не нужно, оно работает на родных 2,5 МГц.
При опросе клавиатуры также придётся "падать" на 2,5 МГц, т.к. ВВ55 и МК физически не смогут даже на 10 МГц, а уж на 20 - и подавно. Заодно не придётся адаптировать код (программные задержки) под различные клоки.
Выборка ПЗУ/ОЗУ и организация начального старта (ПЗУ @ 0000h) и верхнего непереключаемого ОЗУ:
https://pp.userapi.com/c845322/v845322888/1d5da4/Wr6AwlwQKAQ.jpg
До кучи сюда же попала реализация "матюгальника" :)
К сожалению, у Z80 нет выходного сигнала "INTE", поэтому придётся идти по пути Z80-card (
Едем далее. Обращения к системным портам Ориона и эмуляция натягивания портов на память:
https://pp.userapi.com/c845322/v845322888/1d5dbf/eIR8GXuw7sI.jpg
Не нравятся мне эти две КП11 ради того, чтобы IN/OUT копировали LDA/STA... тут надо будет подумать ещё..
Небольшое ноу-хау: совмещение Монитора и ROM-диска в одной микросхеме ПЗУ WB27C512:
https://pp.userapi.com/c845322/v845322888/1d5dad/sekW4jOFx2o.jpg
Смысл в том, что делать сегодня на РФ2 как-то смешно, нынче проще достать "винбонд", и для базового варианта в принципе будет достаточно 62 Кб под ROM-диск. Упаковав оба два мы получаем экономию места и проводки, а заодно избавляемся от лишней ВВ55, для эмуляции которой достаточно защёлкивать адрес (2хИР23), а данные буду выдаваться на ШД МПС напрямую от ПЗУ.
А в случае применения МП на 20 МГц, для работы в режиме "турбо" винбонд вообще без вариантов!
В общем-то, и всё. Это почти вся материнка! МП, ПЗУ и СОЗУ не нарисованы, но там всё понятно. Позже разрисую узел клавиатуры, порт пользователя и СОМ-порт.
Сигналы активации портов видеочасти можно вывести на свободные линии системного разъёма (их там есть и достаточно много), а также чипселекты порта клавиатуры и пула портов расширения (#F7xx).
С клавиатурой пока вопрос открытый, тут у меня три варианта:
1. Классическая связка ВВ55 + МК;
2. Разъём порта расширения с чипселектом #F4, и т.о. исключить собственно ВВ55 (отдать МК и её эмуляцию);
3. Прямая поддержка клавиатуры PS/2.
С первым вариантом всё понятно, он самый каноничный и пожалуй универсальный, но некрасивый (для 21-го века) и громоздкий.
Второй - более красивый - позволит при желании воткнуть платку с ВВ55 и подключить труъ-клаву, но разработка соотв. ПО для МК под вопросом.
Третий вариант грубо нарушает феньшуй: потребуется "перепил" кода монитора (и поддержка PS/2 скорее всего в 2 Кб не влезет) и кондовое ПО, которое напрямую обращается к клавиатуре, не будет работать. В случае использования конструктора в качестве МПС без видеокарты это всё не проблемы, но для "классики" такой вариант однозначно не подойдёт.
Раз уж у нас Z80, то можно добавить и диспетчер ОЗУ (от Z80-card), но конструкцию это усложнит, а нужен ли он на практике - х/з.
Прерывания. Наверное неплохо заложить. Но в виду вынесения "за скобки" видеочасти возникает небольшое неудобство. В случае использования без видео, прерывания (50 Гц?) нужно генерить интернально, а в случае подключения видеокарты хотелось бы их получать от пятки кадровых импульсов. Нужно мутить схему коммутации, автодетект подключения видео-части с переключением на прерывания от неё...
Можно сразу заложить возможность расширения ОЗУ до 1024 Кб (или даже до 4 Мб?!), но опять же вопрос - нужно ли?
Также витает мысль "положить на бутер вторым слоем" СОЗУ (512 или 1024 Кб), подпёртое батарейкой, т.о. получится быстрый и почти "халявный" RAM-диск, находящийся в адресном пространстве МП (доступ также, как и к доп. страницам ОЗУ, активация например старшим битом порта #F9).
Но для работы с таким RAM-диском придётся переключаться на клок 2,5 МГц, т.к. малопотребялющее СОЗУ на клоке 20 МГц работать не будет. В общем-то, такая же история и с клавиатурой, но с ней это по барабану, в её случае скорость и не требуется.
Третий вариант грубо нарушает феньшуй: потребуется "перепил" кода монитора
Если уж Z80, то можно добавить возможность генерирования NMI при обращении к несуществующим (или старым) портам. Тогда классический софт тоже будет работать, за исключением того, который первые 128 байт от начала использует. Но и тут исхитриться можно, если параллельно с генерацией NMI включать другую карту памяти. Вобщем, аналогично тому, как сделана эмуляция ZX-клавиатуры в Арго. Правда, такие костыли непросто в железе реализовывать.
b2m, хочется простоты и минимума корпусов. Очень хочется. Даже вот пара КП11 ради IN/OUT и ещё пара ради мифического диспетчера ОЗУ ну очень глаза мозолят...
Костылей тоже хотелось бы по-минимуму.
Error404
22.03.2019, 15:41
Когда я порывался сделать миникомп с оглядкой на Орион, то ROM/RAM планировал так:
http://www.picshare.ru/uploads/190322/FhwMyihGM2.gif (http://www.picshare.ru/view/9964559/)
Тут все пространство порта F9 (16Мб максимум) делится пополам, в нижней половине (с F9.D7=0 как делает любое ПО Ориона) имеем страницы ОЗУ, в верхней - страницы ПЗУ.
Нулевая страница ПЗУ включается по сбросу (ЦПУ стартует с нуля работая с ПЗУ, копирует код ROM-BIOS-F800 в область F800..FFFF и делает jp F800), затем любая запись в порт F9 с D7=0 (а Монитор обычно делает это первыми командами) включает в адресном пространстве процессора ОЗУ вместо ПЗУ. Т.е. получается как в Орионе-ПРО в режиме совместимости с О-128. В расширенных страницах ПЗУ можно хранить ROM-DISK. Такое включение позволяет на одной ТМ9 подключить сразу 2Мб ОЗУ+ 2Мб ПЗУ (конечно, еще нужна схема реализующая "всегда ОЗУ некоей страницы" в области связи F000 и выше).
Из недостатков:
- несовместимость с ПО Ордос лазающим в ROM-диск A: напрямую через ВВ55 (от ВВ55 тут получается избавиться). Как по мне не очень критичный, т.к. ПО в-основном напрямую лазает в ОЗУ-квазидиски Ордос, а не в ПЗУ ROM-диска.
- Саму Ордос тоже надо поправить в части работы с RОМ.
- Если не делать доработки из Z80Card-II, то читать можно только 60кб из каждой страницы ПЗУ (теряем 6,25% емкости ПЗУ).
Error404, а тоже хорошая мысль! В плане работы с ПЗУ напрямую в адресном пространстве. И не надо изгаляться с эмуляцией ROM-диска. Минус четыре здоровенных корпуса ИР22/23. Только получается "проколотый" ROM-диск, т.к. в F800..FFFF нужно иметь Монитор, причём непереключаемый.
- - - Добавлено - - -
у ТМ9 "вверху" два "лишних" бита, с их помощью получается четыре варианта:
1. Основное ОЗУ
2. ПЗУ (RD / Монитор)
3. СОЗУ (RAM-диск)
4. ххх
В последнем варианте можно посадить например гламурную видеокарту (четырёх плоскостную от ПРОшки), как доработку.
- - - Добавлено - - -
"Старинную" ТМ9 можно махнуть на ИР22, и тогда потенция по объёму ЗУ вырастает до 4 Мб.
- - - Добавлено - - -
Только придётся делать обратку (плюс 1х АП6), чтобы можно было читать состояние порта номера банки. Например, мне нужно слазить в ROM/RAM-диск, но мы не знаем из какой страницы основного ОЗУ это делается, т.е. нужно узнать, сохранить, а после восстановить правильную банку.
Копейкин
22.03.2019, 20:33
Интересный проект. Вот вопросы.
1) Видео планируется сразу на VGA или ТВ?
2) Будет таймер ВИ53 на основной плате?
3) Будут разъемы расширения с системной шиной?
PS про видео уже понял. Вот только 2-х портовое ОЗУ смущает.
Может просто сделать отдельную память для видео?
Error404
22.03.2019, 23:01
"Старинную" ТМ9 можно махнуть на ИР22, и тогда потенция по объёму ЗУ вырастает до 4 Мб.
Там еще идея была в использовании входа сброса (чтобы процессору гарантированно по включении питания или Reset включалось ПЗУ, причем определенная страница), тогда регистр надо не ИР22 (у него начальное состояние негарантированное) а какой-то со сбросом (такой есть, но на память не помню).
тогда регистр надо не ИР22
ИР35?
LeoN65816
23.03.2019, 01:46
Denn, несколько советов.
По схеме тактового генератора: в момент записи в порт #FC у сигнала CLK (на выходе 2И-НЕ) в случае разных фаз переключаемых частот однозначно будут глитчи и как их прохавает проц ты, наверное, догадываешься... Поэтому засинхронь сигнал CLK еще одним D-триггером теми же 40 МГц.
т.к. ВВ55 и МК физически не смогут даже на 10 МГц, а уж на 20 - и подавно.
Возьми NEC D8255AC-2, D82C55AC-2, КР1834ВВ55А (https://yandex.ru/search/?lr=11091&clid=9403&msid=1553295204.24623.139811.72032&oprnd=1088335287&text=%D0%BA%D1%801834%D0%B2%D0%B255%D0%B0&suggest_reqid=159343588151285150451976044886331&csg=1085%2C10468%2C11%2C11%2C0%2C0%2C0) (длительность nRD >= 150 нс [3 такта 20 МГц], длительность nWR >= 100 нс [2 такта 20 МГц]).
Но для работы с таким RAM-диском придётся переключаться на клок 2,5 МГц, т.к. малопотребялющее СОЗУ на клоке 20 МГц работать не будет.
Цикл чтения/записи памяти от 2 тактов. При 20 МГц это от 100 нс. Сейчас полно низкопотребляющей статики с доступом 35, 55, 70 нс, в том числе и в DIP-корпусе.
По схеме тактового генератора: в момент записи в порт #FC у сигнала CLK (на выходе 2И-НЕ) в случае разных фаз переключаемых частот однозначно будут глитчи и как их прохавает проц ты, наверное, догадываешься... Поэтому засинхронь сигнал CLK еще одним D-триггером теми же 40 МГц.
Насколько я знаком с МП, в них все действия привязаны к тактовым импульсам. Соответственно, программное переключение портов также происходит по клоку.
Прошу пояснить, откуда могут взяться глитчи?
Возьми NEC D8255AC-2, D82C55AC-2
Я возьму, а другие посмотрят и скажут "да ну его нафик", ещё какие-то дефицитные микросхемы нужно, побираться по китайским аукционам...
Впрочем, на порт пользователя таки придётся ставить быструю "ВВ55", но он далеко не всем нужен.
Цикл чтения/записи памяти от 2 тактов. При 20 МГц это от 100 нс. Сейчас полно низкопотребляющей статики с доступом 35, 55, 70 нс, в том числе и в DIP-корпусе.
У меня есть ОРИОН-ПРО и я знаю вот что. В нём есть два варианта работы ПЗУ Монитора: прямой и с вэйтами. Выбирается джамперами на плате. В аннотации написано, что если ПЗУ "медленная", то нужно выбирать второй вариант. У меня импортная УФ ПЗУ с реакцией 120нс, при прямом подключении, на тактовой 5 МГц комп работает с глюками, а на тактовой 10 МГц не стартует вообще! При переводе на вэйтовый вариант комп работает без проблем. Из чего я делаю вывод, что 120нс не достаточно для МПС с клоком ЦП 10 МГц и даже 5 МГц (нестабильная работа).
Дальше по аналогии: 70нс памяти не достаточно для 20 и даже 10 МГц.
Можно конечно собрать на макете и проверить, но мне результатов на Орионе-ПРО достаточно. Это не теория, а честная практика.
Поэтому для беспроблемной работы на 20 МГц я предпочту ставить 10нс СОЗУ CY7C1049D-10VXI.
OrionExt
25.03.2019, 17:22
уточню, а то вдруг на собственную рубашку примут, теоретик тут топик кастер пока.
ПОЧИСТЬ. Ну, в целом ожидаемо, ждем прототип (ну почти) объявленный в начале темы.
Как он собрался обеспечить 20МГц, хотя бы структурную схему предоставил. И еще VGA (ой HDMI, шутка).
- - - Добавлено - - -
В дальнейшем, злостных теоретиков О-128 буду критиковать и стебаться над ними. Пусть выпиливают.
LeoN65816
25.03.2019, 18:39
Прошу пояснить, откуда могут взяться глитчи?
в момент записи в порт #FC у сигнала CLK (на выходе 2И-НЕ) в случае разных фаз переключаемых частот однозначно будут глитчи
1. Смотрим вложение. Длительность глитчей меньше минимально допустимых длительностей единицы или нуля тактовой, во вложении пример для 20 МГц процика. На меньших турбах (10, 5) эти глитчи проц на 20 МГЦ прохавает.
2. Задержка положительного фронта nPC от текущей тактовой (от положительного фронта? от отрицательного фронта? запись в порт? или триггер маппируется на память? от этого всего и зависит задержка) во вложении идеализирована. В натуре все будет под еще большим вопросом.
3. Поэтому тут надо делать даже не так, как в начале предложил, а по принципу мастер-помощник. Прямой выход с твоего триггера (мастер) турбы подается на второй D-триггер (помощник) и тактируется nLCLK (то есть загоняем момент переключения в зеленую зону вложения). А уже с него прямой и инверсный по-твоему на вилку комбинаторики. И желательно еще CLK (все-таки это клок) засинхрить теми же 40 МГц (хоть и задержка получается, зато надежно для клока).
LeoN65816, спасибо за предметный интерес к теме и картинки. Насколько я понял, суть поднятой проблемы в задержках распространения сигнала от порта до логики коммутации.
Я вижу работу этого узла следующим образом:
https://pp.userapi.com/c850136/v850136064/10fc71/v3C4wSrhPFE.jpg
В моём варианте глитчи не получаются. Если где-то неправ, поправьте.
LeoN65816
26.03.2019, 12:44
В моём варианте глитчи не получаются. Если где-то неправ, поправьте.
Не прав. Нарисуй растактовку счёта ИЕ7 и сравни со своим рисунком. Увидел ошибку?
А теперь разрисуй все возможные варианты 20 <-> 2.5 (то есть на каждом положительном фронте с учетом задержки nPC). Увидел глитчи?
PS. Я весь день потратил на рисование того вложения, там все наглядно видно. Но ты, почему-то, упорно не хочешь видеть очевидные вещи... :confused:
LeoN65816, теперь я понял, о чём речь.
Не прав. Нарисуй растактовку счёта ИЕ7 и сравни со своим рисунком. Увидел ошибку?
Это не ошибка, а рассмотрены не все возможные ситуации ;)
Хорошо, а какой вред возможен от паразитной "иголки" в случае переключения при разных "фазах" ?
Если время импульса клока будет короче возможностей процессора, то он (процессор) изменений сигнала просто не заметит (перезарядка паразитной ёмкости не произойдёт и лог. уровень сигнала для МП не изменится).
Можно сделать привязку переключения к фазе низшей частоты, и таки да это потребует двух ступеней триггера, но вопрос: насколько оправдано это усложнение схемы?
В момент той самой "иголки" МП будет завершать отработку команды записи в порт #FC, нам в общем-то без разницы с какой скоростью он отработает один такт машинного цикла.
- - - Добавлено - - -
П.С. "глитчем" я всегда называл коллизию на шине, когда "0" на короткое время "ударяется" с "1"... впрочем, не суть..
LeoN65816
26.03.2019, 13:39
теперь я понял, о чём речь.
Дык, а что спасибку-то не пнул... :rolleyes:
Это не ошибка, а рассмотрены не все возможные ситуации ;)
Ошибка №1: фазы тактовых
Ошибка №2: "рассмотрены не все возможные ситуации" - так я тебе об этом сразу же и указал (и разрисовал!!!)... :confused:
Хорошо, а какой вред возможен от паразитной "иголки" в случае переключения при разных "фазах" ?
Если время импульса клока будет короче возможностей процессора, то он (процессор) изменений сигнала просто не заметит (перезарядка паразитной ёмкости не произойдёт и лог. уровень сигнала для МП не изменится).
Как минимум, некорректное исполнение текущей инструкции (которая сразу за переключением), а то и вообще висяк.
Можно сделать привязку переключения к фазе низшей частоты, и таки да это потребует двух ступеней триггера, но вопрос: насколько оправдано это усложнение схемы?
Плюс один триггер и один инвертор - это усложнение схемы?... Денис, я тебя таки умоляю! ;)
В момент той самой "иголки" МП будет завершать отработку команды записи в порт #FC, нам в общем-то без разницы с какой скоростью он отработает один такт машинного цикла.
Уф-ф-ф, Денис, ты ошибаешься.
П.С. "глитчем" я всегда называл коллизию на шине, когда "0" на короткое время "ударяется" с "1"... впрочем, не суть..
Глитч (https://ru.wikipedia.org/wiki/Глитч) - короткий вредный импульс.
Дык, а что спасибку-то не пнул... :rolleyes:
Лови :)
Ошибка №1: фазы тактовых
Я рассмотрел вариант "зелёная зона", там фазы такие.
Ошибка №2: "рассмотрены не все возможные ситуации" - так я тебе об этом сразу же и указал (и разрисовал!!!)... :confused:
Да, не заметил(
9 лет назад, когда я активно проектировал VGA-синхроген, картина выхлопа ИЕ7 была в оперативной памяти, сейчас подзабылось уже..
Как минимум, некорректное исполнение текущей инструкции (которая сразу за переключением), а то и вообще висяк.
"Не верю" (С)
Механику расписал выше.
Плюс один триггер и один инвертор - это усложнение схемы?... Денис, я тебя таки умоляю! ;)
Есть такое понятие "критическая масса". Каждый новый корпус добавляет клубок проводки и объём заморочек по компоновке разводке платы.
Данные проект на т.н. "рассыпухе", и с увеличением кол-ва корпусов его красота падает в геометрической прогрессии, поэтому буду отчаянно бороться за каждый корпус!!!
Уф-ф-ф, Денис, ты ошибаешься.
В чём именно? Момент смены клока - это один такт.
- - - Добавлено - - -
Версия "зелёная зона":
https://pp.userapi.com/c855416/v855416522/e8b3/Z_ppQyKuvkw.jpg
Тогда Орион без звука остаётся.. (
В любом случае узлы будут сначала макетироваться, если вдруг будут обнаружены проблемы с переключением клока, пойдём "зелёным" путём.
LeoN65816
26.03.2019, 15:54
Я рассмотрел вариант "зелёная зона", там фазы такие.
Какие "такие"? Как на твоем рисунке (https://zx-pk.ru/threads/30253-eshche-odin-orion-ne-na-plis-ili-kalinka-malinka-po-russki.html?p=1004851&viewfull=1#post1004851)?
Версия "зелёная зона":
Ты так и не понял свою ошибку с фазами... Эх-х-х... :(
Ты так и не понял свою ошибку с фазами... Эх-х-х... :(
Безопасная зона на спаде такта "2.5", соответственно этот сигнал нужно инвертировать. Свободный инвертер есть, но, как писал выше, необходимость этого огорода имеет смысл проверить на макете.
Я, конечно, понимаю, что
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
поэтому не в плане критики, а так, замечание вскользь. За многие годы просмотра тем по "Ориону" наблюдаю одну и ту же тенденцию - даёшь мегагерцы и мегабайты, сокращай число корпусов и их размеры и прочие тенденции из мира настольных ПК, планшетов и телефонов. Совместимость со всем зоопарком старых схем и особенно старого ПО - всенепременно! Но нет обоснования, для чего реально это нужно. Неужели кто-то сейчас играет в старые игрушки на "Орионе" или использует всю "мощь" CP/M?
Свой железный "Орион" я использую в основном как программатор РФ2, а не в основном - для своего дилетантского программирования и ковыряния в железе. И для меня более важным кажется сохранение простоты и доступности для понимания как железа, так и ПО. Мне вообще не нужна для этого CP/M и все "мощи" её программ. А вот простое добавление нужной железочки и простота написания для неё примитивного ПО - важны. Когда мне нужно сделать что-то быстрое, компактное и лёгкое в изготовлении, я беру Ардуину и готовое железо и библиотеки для неё. А идеальный "Орион" для меня выглядит так:
- ВМ80 на частоте 2,5 или даже 2МГц;
- возможность простого без переделок схемы введения контроллеров прерываний и ПДП;
- видео - функционально отдельно от собственно схемы компа, возможно, даже первоначально комп должен иметь в качестве консоли обычный ПК; позже - быстрый текстовый режим; графика? - ну, тоже можно, ещё позже;
- нормальная схемотехника - буферированные шины, полные дешифраторы, прерывания и ПДП везде, где это рационально - использовать по максимуму возможности 580-го комплекта (потому и не Z80, у которого со своими контроллерами не густо и малодоступно);
- никаких дорогостоящих покупок на аукционах, лучше использовать по максимуму "подножный корм";
- ток потребления и габариты не имеют большого значения.
Мне не видится большой проблемы переделать небольшое количество ПО, если оно станет несовместимым с таким железом, или даже написать новое, более лучшее. Речь не идёт о новой CP/M, а лишь о "Мониторе" или максимум - ORDOS.
VituZz, мне кажется CP/M на Орионе давно никто серьезно не использует. С тем же, что концептуально компьютер устарел - не спорю. Сам хотел бы видеть что-то на 580 комплекте с блекдж ПДП и прерываниями. А видеоадаптер, например, на CPLD - всегда можно что-то доработать или изменить. И дух старины сохранится :)
За многие годы просмотра тем по "Ориону" наблюдаю одну и ту же тенденцию - даёшь мегагерцы и мегабайты, сокращай число корпусов и их размеры и прочие тенденции из мира настольных ПК, планшетов и телефонов. Совместимость со всем зоопарком старых схем и особенно старого ПО - всенепременно! Но нет обоснования, для чего реально это нужно.
Р - развитие. Люди так устроены, что им всегда, везде и во всём требуется развитие. Если его нет, то интерес пропадает.
Мне интересно было бы автоматизировать некие процессы в жизни, но совершенно нет желания изучать и применять МК и прочие ардуени, а хочется оставаться в "домене" Ориона, его архитектуры, и писать программы с использованием Ориона. В этой связи хотелось бы иметь универсальную и гибкую платформу, без ненужного (для некоторых применений) довеска в виде синхрогенератора, схем регенерации ДОЗУ и т.п..
Если увлекаться программированием именно под ПК, то "челендж" в виде 2,5 МГц уже надоел, все мыслимые и немыслимые трюки оптимизации кода перепробованы, хочется двигаться дальше, и 20 (а лучше 40 МГц) это реально очень интересно и желаемо.
Свой железный "Орион" я использую в основном как программатор РФ2, а не в основном - для своего дилетантского программирования и ковыряния в железе. И для меня более важным кажется сохранение простоты и доступности для понимания как железа, так и ПО.
В данной теме как раз речь об упрощении исходной конструкции, при максимальном сохранении совместимости. Опять же, без ДОЗУ и схемы его регенерации схемотехника становится доступнее и понятнее, и архитектура ПК логичнее. В плане ПО вообще ничего не меняется!
Мне вообще не нужна для этого CP/M и все "мощи" её программ.
Совершенно никакого прицела на СР/М нет.
А вот простое добавление нужной железочки и простота написания для неё примитивного ПО - важны.
В этом плане сабжевый вариант ничего не меняет относительно оригинального Ориона.
А идеальный "Орион" для меня выглядит так:
- ВМ80 на частоте 2,5 или даже 2МГц;
Не могу согласиться в данном вопросе. Даже родное ПО, написанное под 2,5 МГц - дико тормозит по части всего, что связано с выводом информации на экран.
У Ориона очень неоптимальное (мягко говоря) соотношение размера экранной области и производительности процессора.
Для такого графического экрана интерес начинается от ЦП @ 20 МГц, имхо. Недо- 10МГц на ОРИОН-ПРО неплохо, местами даже очень неплохо, но всё равно не хватает для комфортной работы.
...возможно, даже первоначально комп должен иметь в качестве консоли обычный ПК; позже - быстрый текстовый режим; графика? - ну, тоже можно...
Отклонения по железу от базового влекут за собой изменение ПО, а делать это некому. Придумать такой вкусный новый Орион, несовместимый с базовым, чтобы все захотели выкинуть оригиналы и перейти на новодельную вкусняшку - нереально. А значит любое новое ПО придётся писать как минимум под два варианта платформ - оно надо?
Мне не видится большой проблемы переделать небольшое количество ПО, если оно станет несовместимым с таким железом, или даже написать новое, более лучшее.
Проблема в мотивации. И она очень серьёзная. Технически ничего сложного нет.
Речь не идёт о новой CP/M, а лишь о "Мониторе" или максимум - ORDOS.
Всё зависит от задач. Функционала ORDOS мне перестало хватать в 1995 году, да так сильно, что пришлось писать свою ОС.
никаких дорогостоящих покупок на аукционах, лучше использовать по максимуму "подножный корм";
По какой причине?
Интересующиеся данным разделом форума на 99% являются мужчинами от 40 лет, для них не представляет какой либо трудности купить процессор Z80 или заказать печатную плату, это далеко не бедные студенты.
Из "подножного корма" можно собирать оригинальный Орион-128, в этом плане ничего не меняется. Только по-моему это уже пройденный этап.
По сабжу - примерно так я сейчас и делаю - всё вылилось с моего проекта в FPGA в соседнем треде.
На данный момент заканчиваю проработку модуля видео:
Двухпортовое СОЗУ (64К*16);
Основная логика реализована на ATF22V10 для упрощения модификаций;
Свой кварц (25МГц);
Несколько режимов формирования сигнала - пока экспериментально, сколько влезет.
По п.3 - возможна замена на 75МГц, что бы получилось сформировать сигнал для разрешения 1920*1080 с удвоением. Но здесь и по схемотехнике будут отличия - проще 2 версии платы или один каскад через мультиплексоры коммутировать. Скорее выберу второй вариант, если всё влезет в PLD'шки - это будет происходить с достаточно медленными сигналами, до 1МГц.
По п.4 - для "пробы пера" впихиваю 4 режима: 640x350@70, 640x400@70, 640x480@60, 1920x1080@60. С последним пока беда, ещё обкатываю на FPGA.
На плате будут установлены свои "чипы" видео-портов - то есть через разъём с основной платы будут идти 3 сигнала-строба для записи в них (просто с дешифраторов сигналы).
Так же все защёлки данных, сдвиговые регистры - всё это на мелкой логике 74x573+74x166.
Собственно, схема во вложении. Она уже чутка устарела, но концепт останется тем же. Сейчас на FPGA обкатываю последний режим, после чего буду впихивать всё в PLD'шки и обновлю схему.
- - - Добавлено - - -
Интересующиеся данным разделом форума на 99% являются мужчинами от 40 лет, для них не представляет какой либо трудности купить процессор Z80 или заказать печатную плату, это далеко не бедные студенты.
Из "подножного корма" можно собирать оригинальный Орион-128, в этом плане ничего не меняется. Только по-моему это уже пройденный этап.
Я, кстати, отношусь как раз к этому 1%. Вернее - относился, когда начинал ту тему :) 7 лет назад только выпустился из универа...
FPGA - это, конечно, уже совсем другая эпоха...
По п.3 - возможна замена на 75МГц, что бы получилось сформировать сигнал для разрешения 1920*1080 с удвоением...
А для чего такое большое разрешение? Орионовский экран прекрасно вписывается в SVGA-режим 800х600@60, заодно и кварц "ровный" - 40 (по факту 20) МГц.
Я, кстати, отношусь как раз к этому 1%. Вернее - относился, когда начинал ту тему :) 7 лет назад только выпустился из универа...
Если не секрет, по каким причинам выбран Орион в качестве объекта интереса?
FPGA - это, конечно, уже совсем другая эпоха...
На ней только проверяю тайминги и всю логику, не более того. Сильно много косяков было сделано в первом варианте платы по части миксера цветов...
А для чего такое большое разрешение? Орионовский экран прекрасно вписывается в SVGA-режим 800х600@60, заодно и кварц "ровный" - 40 (по факту 20) МГц.
Можно и без него, просто это нативное разрешение большинства мониторов. Те же режимы 640x350 и 640x400 у меня интерпретируются как 720x400 и часть вертикальных строк удваивается самим монитором...
Если не секрет, по каким причинам выбран Орион в качестве объекта интереса?
Отец его собирал по публикациям журнала в своё время, связывался с авторами письмами. Был полноценный Орион-128 с CP/M - дальше в нашей тьмутаракани стало тяжко, процветал бандитизм и финансово сразу всё покатилось вниз :( Тяжёлые были времена, наш город ещё прославился как "нарко-столица" Беларуси тех времён, до сих пор все это помнят.
Сейчас, кстати, с BYTEMAN'ом вместе работаю :) И он чутка моложе меня вообще-то ;)
- - - Добавлено - - -
Орионовский экран прекрасно вписывается в SVGA-режим 800х600@60, заодно и кварц "ровный" - 40 (по факту 20) МГц.
Это только если делать 384-ый экран. Если брать ПРО, там ширина экрана идёт 512 пикселей, то есть надо именно 40МГц пиксель-клока. Удвоение здесь "не прокатит".
Error404
01.06.2020, 00:12
Я, конечно, понимаю, что
поэтому не в плане критики, а так, замечание вскользь. За многие годы просмотра тем по "Ориону" наблюдаю одну и ту же тенденцию - даёшь мегагерцы и мегабайты, сокращай число корпусов и их размеры и прочие тенденции из мира настольных ПК, планшетов и телефонов. Совместимость со всем зоопарком старых схем и особенно старого ПО - всенепременно! Но нет обоснования, для чего реально это нужно. Неужели кто-то сейчас играет в старые игрушки на "Орионе" или использует всю "мощь" CP/M?
Эффект "дорвались до ресурса", "эх мне бы это в 90х". :) Хотя строго говоря, большой объем оперативки позволяет делать на Орионе то, что было в 90-х реализуемо только на больших машинах - и это круто, про остальное не скажу. Чисто для понтов (которые как известно дороже денег). Просто раньше понты были "догнать IBM PC, ну ладно хотябы АТМ", а теперь "глянь, я туда впихнул невпихуемое". И это, откуда все же запускать 10Мб игр (ну ладно, прошивок ПЗУ)? Не ахти какой объем, но даже он Ордос не по зубам.
Свой железный "Орион" я использую в основном как программатор РФ2, а не в основном - для своего дилетантского программирования и ковыряния в железе. И для меня более важным кажется сохранение простоты и доступности для понимания как железа, так и ПО. Мне вообще не нужна для этого CP/M и все "мощи" её программ. А вот простое добавление нужной железочки и простота написания для неё примитивного ПО - важны. Когда мне нужно сделать что-то быстрое, компактное и лёгкое в изготовлении, я беру Ардуину и готовое железо и библиотеки для неё. А идеальный "Орион" для меня выглядит так:
- ВМ80 на частоте 2,5 или даже 2МГц;
- возможность простого без переделок схемы введения контроллеров прерываний и ПДП;
- видео - функционально отдельно от собственно схемы компа, возможно, даже первоначально комп должен иметь в качестве консоли обычный ПК; позже - быстрый текстовый режим; графика? - ну, тоже можно, ещё позже;
- нормальная схемотехника - буферированные шины, полные дешифраторы, прерывания и ПДП везде, где это рационально - использовать по максимуму возможности 580-го комплекта (потому и не Z80, у которого со своими контроллерами не густо и малодоступно);
- никаких дорогостоящих покупок на аукционах, лучше использовать по максимуму "подножный корм";
- ток потребления и габариты не имеют большого значения.
Мне не видится большой проблемы переделать небольшое количество ПО, если оно станет несовместимым с таким железом, или даже написать новое, более лучшее. Речь не идёт о новой CP/M, а лишь о "Мониторе" или максимум - ORDOS.
Это все здорово, но зачем совсем другой компьютер который получится, называть Орионом, оно ближе к RК-86 получается - я давно предлагал в RК-86 добавить страничную память over32к и тогда там можно будет программировать не только РФ2, но и более емкие ПЗУ. И другое ПО написать безусловно тоже можно. Концепция Ориона как раз и состояла в том, чтобы не применять ничего из труднодоступного (в сельской местности в то время), прожорливого и тормозного комплекта 8080, ходили слухи что там и проц изначально другой планировался (но отказались по бедности), а в монитор-2 кроме изначальной совместимости с СР/M и VT52 (которую знали и ценили) добавить п/п до совместимости с RК-86 заставил исключительно ж-л Радио.
И мне кажется, вы просто не хотите научиться готовить Z80. Даже на 10 лет в более позднем ПРО прерывания прекрасно обрабатываются им самим. Z80 тем и хорош, что позволяет избавиться от кучи дополнительной обвязки, и после чего в простом ПК в большинстве случаев становится не нужным и буферизирование даже.
По п.4 - для "пробы пера" впихиваю 4 режима: 640x350@70, 640x400@70, 640x480@60, 1920x1080@60. С последним пока беда, ещё обкатываю на FPGA.
Симуляция на FPGA закончилась успешно, завтра начну впихивать в PLD'шки логику.
Для разрешения 1920x1080 выбрал режим утроения пикселей - тогда можно использовать генератор на 50МГц. Логику для деления на 3 вполне возможно запихнуть в PLD, места там хватает.
Итого, в схеме будет 4 PLD:
PLD_X - все сигналы по оси X. Самая шустрая должна быть, на входа поступают сигналы сразу после делителей и кварца;
PLD_Y - все сигналы по оси Y. Можно грейд "послабее", частота тут до сотен килогерц;
PLD_LO - вспомогательная логика. Переключение банков видеопамяти (вместе с их защёлкиванием из регистра в конце кадра), формирование номера видеорежима;
PLD_V - микширование видеосигнала.
PLD_LO необходима для экономии пинов у PLD_V - 5 сигналов видеорежима будет кодировать в 3 бита (пока что у нас только 8 режимов + режим "нет изображения"). Выключение изображения будет сделано тем же сигналом, который гасит изображение за пределами отображаемой области.
И мне кажется, вы просто не хотите научиться готовить Z80. Даже на 10 лет в более позднем ПРО прерывания прекрасно обрабатываются им самим. Z80 тем и хорош, что позволяет избавиться от кучи дополнительной обвязки, и после чего в простом ПК в большинстве случаев становится не нужным и буферизирование даже.
В чём-то, наверное, Вы правы. Сам не могу чётко объяснить, почему у меня к нему душа не лежит. Может, просто потому, что ВМ80 был первым. Но точно не только поэтому. 580-й комплект обладает какой-то логической завершённостью и позволяет многие задачи, пусть даже легко решаемые программно, переложить на железо. Как не-программисту, мне это нравится.
Это все здорово, но зачем совсем другой компьютер который получится, называть Орионом
Можно не называть "Орионом", просто делать его максимально совместимым с ним. Сделать, как предлагает Denn, из него контроллер. При необходимости и по желанию расширять. В проектировании железного ядра проще достичь консенсуса разных точек зрения.
Концепция Ориона как раз и состояла в том, чтобы не применять ничего из труднодоступного (в сельской местности в то время), прожорливого и тормозного комплекта 8080
Сегодня К580 есть, наверное, у всех, а у кого нет, то ему даже китайцы не нужны, чтобы купить его реально за гроши.
Не могу согласиться в данном вопросе. Даже родное ПО, написанное под 2,5 МГц - дико тормозит по части всего, что связано с выводом информации на экран.
У Ориона очень неоптимальное (мягко говоря) соотношение размера экранной области и производительности процессора.
Для такого графического экрана интерес начинается от ЦП @ 20 МГц, имхо. Недо- 10МГц на ОРИОН-ПРО неплохо, местами даже очень неплохо, но всё равно не хватает для комфортной работы.
Если мы согласны немного откусывать от феншуйности, то вот пусть обработкой видео занимается отдельное устройство. А какие ещё приложения бескомпромиссно требуют от проца 20МГц? Если железо слабо, то история показывает, что текстовой консоли нет конкурентов. И множество задач на "Орионе" быстрым текстовым режимом вполне удовлетворятся. Я так думаю.
Интересующиеся данным разделом форума на 99% являются мужчинами от 40 лет, для них не представляет какой либо трудности купить процессор Z80 или заказать печатную плату, это далеко не бедные студенты.
Из "подножного корма" можно собирать оригинальный Орион-128, в этом плане ничего не меняется. Только по-моему это уже пройденный этап.
Предложенный вариант предполагает покупку как платы, так и всех микросхем. По крайней мере, у меня нет КМОПов, работающих на 20 или даже на 5МГц. Как по деньгам, так и по времени на покупку - это не пренебрежимо мало.
Если мы согласны немного откусывать от феншуйности
Если предполагается развитие (а оно предполагается, писал выше), то придётся. ПЛИС конечно нет, а вот всевозможное в DIP-корпусах почему бы и да!
то вот пусть обработкой видео занимается отдельное устройство.
А что (и как) в этот момент будет делать ЦП?
Простой пример: текстовый редактор. Я печатаю текст, жму [ВК] и у меня должен выполниться скроллинг графического экрана (двух экранов по 12кб в случае цветного текста!),
обновиться служебная информация о кол-ве свободного места в ОЗУ, координатах курсора и т.п.. При этом в идеале нам бы хотелось моментально приступить к опросу клавиатуры, выводу следующего символа на экран...
А какие ещё приложения бескомпромиссно требуют от проца 20МГц?
Из банального и раздражающего:
- обновление информации на экране;
- перенос информации в ОЗУ объёмом до 40 Кб (чтение/запись файлов, вставка фрагмента текста, графики);
- хотя бы примитивное сжатие графики (оконный интерфейс без диких тормозов);
- эффективная работа с быстрыми накопителями (HDD, CF, SDHC, LAN);
- обработка/вывод потокового видео;
- воспроизведение звука вменяемого качества;
- возможность работы с железом через программные драйвера;
- в перспективе - ЯВУ (комфортная работа).
Если железо слабо, то история показывает, что текстовой консоли нет конкурентов. И множество задач на "Орионе" быстрым текстовым режимом вполне удовлетворятся.
Орион - графический ПК, и в этом его фишка. Чисто текстовый терминал это другая история, тут скорее надо присматриваться к РК86...
Предложенный вариант предполагает покупку как платы, так и всех микросхем. По крайней мере, у меня нет КМОПов, работающих на 20 или даже на 5МГц. Как по деньгам, так и по времени на покупку - это не пренебрежимо мало.
Я понимаю, что у всех ситуации и истории разные. У меня в среднем на все хобби (электроника, аудиофилия, музыка) ненапряжно тратится в районе 10 тыр в месяц. У знакомых примерно также, плюс-минус. Всевозможные 8-битные покупки не напрягают вообще никак, они же совсем не частые.
Собственно, отрисовал черновой вариант генераторной части видео-адаптера.
Вышло 3шт ATF22V10, источником тактирования служит генератор на 50МГц.
В PLD'шки получилось впихнуть все 4 разрешения, и даже осталось место под дальнейшее расширение - хватает выходных сигналов для формирования более сложной логики (в том числе и для добавления других разрешений).
3-я PLD является вспомогательной, что бы разгрузить остальные и заодно спокойно вписать всё "как надо".
По конструктиву - все компоненты будут в SOIC/SOT, иначе не впишусь в размеры платы. Монтаж будет достаточно плотным...
Осталось отрисовать один лист - там будут системные регистры (P8, PA, PC), защёлки видео-данных и собственно формирование пикселей.
PS: Как лучше рисовать - так, как в аттаче, либо длинные связи рисовать логически (именованными сигналами).
Орион - графический ПК, и в этом его фишка. Чисто текстовый терминал это другая история, тут скорее надо присматриваться к РК86...
были компы на 8080 и без 580вг75, работали по COM-порту на видеомонитор или телетайп. Зато процессор был разгружен
andreil, а в чем фишка использования именно двухпортовой памяти? Она редкая, дорогая. В конце концов можно же просто регистр поставить, чтобы конфликты разруливать.
andreil, а в чем фишка использования именно двухпортовой памяти? Она редкая, дорогая. В конце концов можно же просто регистр поставить, чтобы конфликты разруливать.
Ну, при пиксель клоке 50МГц у нас 8*20/2=80нс для выборки слова из видеопамяти. В это же время надо уложиться и с доступом КП к памяти. Больше - нельзя, будет пропуск в видеоряде. При частоте процессора 10МГц 1 машинный цикл (минимальное время доступа к памяти) составляет 100нс - уже гарантированный промах.
Можно, конечно, усложнить схему доступа процессора к памяти, сделав его буферированным (на чтение и запись, 2 регистра). Такой вариант я уже пробовал, но всё упирается в задержки в логических элементах - 80нс одного чтения видеоданных делим ещё на 2 (видео и процессор). Получаем 40нс. При памяти с грейдом "10" на прочую логику у нас остаётся МАКСИМУМ 30нс. А это, на секундочку, далеко не один пункт. Распишу по-подробнее, цифры беру минимальные для серии 74F (зачастую они выше):
Арбитраж доступа к памяти - 5нс;
Переключение мультиплексоров адреса - 5нс;
Чтение/запись ячейки памяти - 12нс;
Защёлкивание данных в регистре для чтения - 10нс.
Итого, получается 5+5+12+10=32нс в идеале. По факту же - сигнал записи надо выставлять позже выставления адреса как раз на эти самые 10нс, иначе запись будет произведена по 2-м адресам (который был до переключения и адресу от ЦП). Этот момент я выловил только на симуляции на FPGA с внешним чипом памяти. Несколько месяцев потратил на такие варианты, прежде чем выкинул их нафиг - всегда получалось или криво или очень требовательно к задержкам, на мелкой логике такое реализовать будет очень тяжело. На CPLD - ещё можно, но это наш вариант.
Итого - чем городить огород с таким арбитражом доступа к памяти, проще поставить двухпортовку и не париться. Тем более, я затарился 20 чипами оной - хватит надолго...
Дорисовал черновой вариант схемы. Отображены все элементы, меняться будет только назначение сигналов по пинам микросхем с целью упрощения трассировки - она достаточно плотная будет, 28 корпусов на платке 100*100мм...
А что (и как) в этот момент будет делать ЦП?
Если не ориентировать процессор исключительно на обслуживание пользователя, а добавить ему больше функций контроллера, то занять его есть чем.
- эффективная работа с быстрыми накопителями (HDD, CF, SDHC, LAN);
- обработка/вывод потокового видео;
- воспроизведение звука вменяемого качества;
- обслуживание клавиатуры и т. д.;
- возложить это на отдельные контроллеры, максимально освобождающие ЦП от рутины и в то же время быстро и эффективно решающие свои задачи, параллельно с другими контроллерами.
Простой пример: текстовый редактор. Я печатаю текст, жму [ВК] и у меня должен выполниться скроллинг графического экрана (двух экранов по 12кб в случае цветного текста!),
обновиться служебная информация о кол-ве свободного места в ОЗУ, координатах курсора и т.п.. При этом в идеале нам бы хотелось моментально приступить к опросу клавиатуры, выводу следующего символа на экран...
Использовать ПДП для повышения производительности передачи данных в ОЗУ, но скроллинг должен выполнять видеоконтроллер. В это же время контроллер клавиатуры должен приготовить в своём буфере введённые символы, а задача ЦП - лишь передать их видеоконтроллеру.
Орион - графический ПК, и в этом его фишка. Чисто текстовый терминал это другая история, тут скорее надо присматриваться к РК86...
РК дальше от идеала 8-битного компьютера, чем "Орион". В то же время "графичность" "Ориона", как мне кажется, несколько переоценена. В некотором смысле широкие графические возможности даже вредны, поскольку авторы ПО больше уделяют (уделяли) внимания внешним эффектам ПО, нежели надёжности и эффективности выполнения возложенных на него задач. В этом плане мне нравится принцип разработки ПО в Линухе - функции выполняет консольная программа с минимальными требованиями к ресурсам, а уж если нужны "шашечки", так для того пишется графическая "обёртка" к консольной программе. Как следствие - и эффективность написания сценариев. А если ещё ПО будет поддерживать невытесняющую многозадачность...
В общем, я понимаю, что "тут Остапа понесло", но "Ориону", как мне кажется, не помешает и некая новая идея развития как железа, так и ПО, потому как простое повторение авторской схемы и простое использование уже существующего ПО - это всё и так уже есть. Мегагерцы же к идее ничего не дают.
У меня в среднем на все хобби (электроника, аудиофилия, музыка) ненапряжно тратится в районе 10 тыр в месяц.
Лично для меня это совершенно неприемлемо. Я один такой "нищеброд"? :-)
"Ориону", как мне кажется, не помешает и некая новая идея развития как железа, так и ПО, потому как простое повторение авторской схемы и простое использование уже существующего ПО - это всё и так уже есть. Мегагерцы же к идее ничего не дают.
Для существующего - не нужно. Мне интересно делать своё новое, и оно требует мегагерцев. Отход от авторского концепта (введение принципиально иного клавиатурно-экранного железа) считаю неверным, это уже будет не Орион. Дополнительные мегагерцы разумеется будут опциональным режимом, штатно при сбросе будет 2,5 МГц, т.е. честный Орион.
- - - Добавлено - - -
- возложить это на отдельные контроллеры, максимально освобождающие ЦП от рутины и в то же время быстро и эффективно решающие свои задачи, параллельно с другими контроллерами.
Это всё неподъёмная идеализация, и по сути речь о другом ПК, не Орионе. Для этого нужно:
- проработать новый концепт
- собрать и отладить
- сделать легко повторяемым
- написать ПО
- замотивировать критическую массу народа подсесть на данное изделие
- не забрасывать проект, постоянно развивать, дополнять, обновлять, всячески удерживать и привлекать публику.
Что-то из области фантастики.
Denn, а в DSDOS есть простейший консольный режим? Например, если не определяется наличие видеоконтроллера, стандартного для Ориона, весь вывод система станет делать в какой-то стандартный последовательный порт.
Denn, а в DSDOS есть простейший консольный режим? Например, если не определяется наличие видеоконтроллера, стандартного для Ориона, весь вывод система станет делать в какой-то стандартный последовательный порт.
Таковая возможность будет в 4-ом поколении DSDOS, третее насмерть прибито к конкретному железу (так изначально задумывалось).
В общем-то, видеомодуль почти готов. Осталось провести пару дорожек, да провести оптимизацию трассировки :)
На плате даже нашлось место под 2 резервных чипа - эдакое "монтажное поле", на всякий случай.
Самые важные для наладки сигналы вывел на тестовые пины, что бы проще припаиваться было.
Ну и неиспользуемые пины системных регистров и программируемой логики так же вывел на тестовые пины.
Итого - получилось 27 корпусов, из них 2 одногейтовых инвертора и 4 ATF22V10.
https://image.prntscr.com/image/NF2A-wTeTR2oh9dMHoqTug.png
Ссылка на картинку не нажимается.
Чтобы было ))
https://image.prntscr.com/image/NF2A-wTeTR2oh9dMHoqTug.png
Это KiCad?
Да, именно в нём рисую давно уже.
По сабжу - пока сижу, доразвожу последние дорожки. Но времени нету - работа, будь она неладна :)
А что авторазводчиком не пользуешься?
А что авторазводчиком не пользуешься?
1) При такой плотной компоновке он выдаст такие загогулины, что потом распутывать дольше буду.
2) Клок 50МГц - надо самые шустрые линии от остальных землёй отделить максимально.
3) Хочется красоты. Авторазводчик выдаст фигню полную. Я лучше угроблю пару недель своего времени, но будет красивая плата с ровными дорожками, а не "взрыв на макаронной фабрике" ;)
И да - решил вернуться к расположению части элементов с обратной стороны - сильно плотный монтаж, не получается нормально развести всё без макаронин через периметр. Да и с 2-х сторон будет только видеовыход - там архитектура просто сама по себе напрашивается на такое расположение.
https://image.prntscr.com/image/NF2A...h9dMHoqTug.png
403 Forbidden
Не скажи... https://uploads.tapatalk-cdn.com/20200619/d7a5591fb54b2a5bdd1b864711c2e745.jpghttps://uploads.tapatalk-cdn.com/20200619/3e5caa2303a12626109bf1778d1a41d9.jpghttps://uploads.tapatalk-cdn.com/20200619/303fb297a8a2f1ce0eaa8dd066e51c8d.jpghttps://uploads.tapatalk-cdn.com/20200619/0f406c1c379c5ef139adda2fdb01c716.jpg
Не сравнивай плотность монтажа :)
Вот, глянь кусочек платы (https://image.prntscr.com/image/V5DPTXRATnOA74YHOGkXpg.png). Стандартный SOIC зазоры порой меньше 0.2 приходится делать, что бы всё уместить.
Коллеги, последние 2+ страницы обсуждений каким-то образом относятся к теме топика?
Коллеги, последние 2+ страницы обсуждений каким-то образом относятся к теме топика?
Мой модуль можно отнести к данному обсуждению? Или выделить в отдельный топик.
Вроде бы Орион, на мелкой логике и современных комплектующих.
Заказал платку-переходник для своей демо-борды с FPGA, где обкатываю текущие решения. На борде будет только Z80 с level-трансляторами.
Думаю уйти от двухпортовки, но при асинхронности работы процессора и видео приходится жертвовать таймингами, загоняя из в самый минимум. С реальным процессором проще проверить корректность работы во всех случаях :)
andreil, а если запихать схему не в ATFки, а в EPM7128? Они доступные и недорогие. Чаще всего 15нс экземпляры попадаются, но есть и на 7нс. Если их скрестить c 61512, как думаешь, на какой частоте удасться Z80 запустить?
andreil, а если запихать схему не в ATFки, а в EPM7128? Они доступные и недорогие. Чаще всего 15нс экземпляры попадаются, но есть и на 7нс. Если их скрестить c 61512, как думаешь, на какой частоте удасться Z80 запустить?
На плате с процессором 100% будет EPM7 - в ATF там логику не впихнуть уже :) Проц спокойно можно на 10МГц запустить, и даже на 20 - всё будет упираться в арбитраж видео-ОЗУ. Если оставить двухпортовку, то все частоты открыты и сложностей 0.
Внутри EPM'ки будут все системные порты, а это ведь куча регистров и дешифрующей логики.
Пока идёт плата с процессором, как раз буду обкатывать логику процессорного модуля в симуляции. Но для этого сперва придётся всё-таки дописать прошивку для МК, к которому будет подключена клавиатура - подключения PS/2 у меня штатно не предусмотрено вообще. Да и нету таковых в наличии, а искать уже влом.
По видео-модулю - думаю вместо части логики всё-таки впихнуть EPM'ку, поскольку сильно много "если". На логике останутся защёлки видеоданных, сдвиговые регистры видеоданныхи ATF'ка видеовыхода и буферный элемент на ШД (что бы создавать нагрузку в "1 вход" со стороны платы).
Так что думаю пока как быть - или оставить в видеомодуле ATF'ки и трахаться с ними или впихнуть EPM'ку и получить готовую плату уже через пару недель (развести в таком варианте легко, пару дней от силы).
ATF - кошерно и более-менее аутентично, EPM - некошерно.
andreil, я бы лично предпочел EPMки.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot