Еще один Орион на ПЛИС [Архив] - Страница 2 - Speccy

andreil

07.03.2018, 20:01

Уважаемый Denn, тут надо сделать, а не проектировать. Если автор сделает не хитрый Орион на 3 платках, я куплю платку. Это ново. Если автор уйдет во все тяжкие, тут даже не знаю.
Для пробы - сделаю на планарке и паре платок, что бы выловить все косяки.
Или ты тоже хочешь на планарках собрать? Просто стоимость плат больше 100х100 вырастает очень резко :) Для примера, 10 плат размером 150х200 стоят $35, а до 100х100 - всего $5. В обоих случаях ещё и доставка отдельно идёт.

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

OrionExt, ПРОшка - это и есть "турба", Z80 и все остальные плюшки. Только вылизанные и отлаженные.
У меня и так в текущем варианте Z80. Только тайминги некоторые надо проверить на реале, опирался на ДШ Z80 при составлении логики.

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

Намекаешь тут, а схема все растет С5 (блин):)
Ну, она не росла уже давно, вообще-то. Последний скачок - из-за переделки выхода на ПРОшный вариант, а сам генератор (который постом выше) по корпусам без изменений почти (пара элементов не в счёт) уже около месяца.

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

Раскидал предварительно по печатке все элементы, отвечающие за формирование сигналов по горизонтали - уже 18 корпусов... Но горизонталь раза в 2 компактнее, там логика проще за счёт того, что жёстко от 0 до 255 тикает видимая часть.
Нашел ещё пару мест в логике, которые можно сократить, "вынеся общий знаменатель за скобки" :)

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

Просьба к знатокам оптимизаций логики - подскажите, может ещё что-то можно переиначить по части горизонтальных сигналов? Формируется на элементах с номерами до 100 ;)
Схема для просмотра (https://andreil.by/orion/orion_video_tg.pdf).
Ну или схема из Квартуса (https://image.prntscr.com/image/SuiAH_JhQyy4xowTqml4NQ.jpg), здесь связи проще прослеживать.
Текущий вариант схемы полностью функционален в FPGA.
Я уже даже не знаю, что тут ещё можно оптимзировать, но 100% уверен, что у меня просто не хватает опыта в таких делах =/
PS: Цепочку формирования сигнала HS не предлагайте сделать на XNOR - оно и так на ней было, но целый корпус ради одного элемента - шик...

andreil

07.03.2018, 23:05

Раскидал предварительно по печатке все элементы, отвечающие за формирование сигналов по горизонтали - уже 18 корпусов... Но горизонталь раза в 2 компактнее, там логика проще за счёт того, что жёстко от 0 до 255 тикает видимая часть.
После оптимизации - 14 корпусов. Уже лучше...
Выход HS пропустил через мультиплексор - там банально надо менять полярность сигнала в зависимости от режима отображения.

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

Грубая компоновка компонентов для горизонтали:
https://image.prntscr.com/image/BeFVgojIRjmAVkQrKmCNKw.png
https://image.prntscr.com/image/uBPqGazdRxuORGT_70UxSA.png
https://image.prntscr.com/image/ZjahC93QSnqJtr-Au7CseA.png
Габариты фрагмента - 45х30мм :v2_dizzy_roll:
Почти все элементы расположены в "2 яруса", за исключением области с частью генераторов - там будет большой полигон "земли" для экранирования, размещать там что либо - подвергать это место сильным ВЧ помехам...
Если U5 сместить в свободное место над U4, то данная часть платы будет самой минималистичной :)
Завтра попробую это дело ещё по элементам поменять, в зависимости от длины связей у них и начну трассировать. С нормами 0.16/0.16 вполне реально развести в таких габаритах, всё упрётся в разводку питания.

andreil

11.03.2018, 18:17

Развёл часть генератора.
Вид сверху (https://image.prntscr.com/image/Qym_GWtNR46FKdlGfNSm6g.png).
Вид снизу (https://image.prntscr.com/image/s8ynPa50Rf6BbmndlxJCvw.png).
Места на использованном фрагменте ещё хватает, но часть его будет использована для счётчиков второй половинки генератора. Размеры на картинках - 40х42мм.
Разводку ещё не оптимизировал сильно, питание не разводил.
В ходе разводки выкинул ещё корпус, в итоге получилось 13 корпусов.

andreil

12.03.2018, 12:35

Для приверженцев ГОСТовских обозначений перерисовал уже готовую часть схемы (https://andreil.by/orion/orion_video.pdf), заодно свернул пару элементов в большой И.
Одногейтовые элементы - пока для примера. Но может часть логики ими и реализую. Очень сильно упрощается трассировка...

OrionExt

12.03.2018, 14:09

Я для себя выбрал IEC стандандарт. Похож на наш. А что там, в рамочках для микрух сложнее ЛА3 писать? Функцию ножки, а стольное не особо то и нужно. Только захламляет. Игнорят это правило часто, в том и беда.

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

А по поводу блюстителей гостов, которые еще умудрились сюда негров приплести:)

Все просто. Посчитайте сколько времени займет (на единицу времени) у инженера стоящего у чертежной доски куярить элементы 2И-НЕ по нашим и ихним враждебным гостам (под трафарет). А их надо тысячами рисовать.

Один кружек инверсии чего стоит:) Аккурат в разрез линии.

!---!
--! & !
! о--
--! !
!---!

andreil

12.03.2018, 14:24

Я для себя выбрал IEC стандандарт. Похож на наш. А что там, в рамочках для микрух сложнее ЛА3 писать? Функцию ножки, а стольное не особо то и нужно. Только захламляет. Игнорят это правило часто, в том и беда.
Там посложнее надпись, поскольку одногейтовые.
Сейчас вот бился с сетью на работе, еле обновился. Сейчас попробую такой вариант протрассировать.

OrionExt

12.03.2018, 14:32

Уж сори разбавил тему, на около тему.

Ага, большие микрухи сложней. Я такой приспособленец:v2_tong2:
Для примера (http://www.msxarchive.nl/pub/msx/mirrors/hanso/service_manuals/philipsvg8230sm.pdf) как Philips, выкручивался (то, что в серединке символов можно пропустить).

Error404

12.03.2018, 14:54

Все просто. Посчитайте сколько времени займет (на единицу времени) у инженера стоящего у чертежной доски куярить элементы 2И-НЕ по нашим и ихним враждебным гостам (под трафарет). А их надо тысячами рисовать.

Один кружек инверсии чего стоит:) Аккурат в разрез линии.

Рисование от руки займет времени и затрат ровно столько же. Кривые IEC рисовать сложнее чем квадраты (а инверсия и тут и там). Вот сложные элементы по ГОСТ (средняя степень интеграции) - там да, на несколько линий и обозначений больше получается чем в безликих квадратах IEC. Но ГОСТ в разы более читаемый (а чтение важнее записи - чертежи для того и и придуманы чтобы посторонний их мог прочитать), тут и спорить глупо (на ГОСТ еще работает общее зрительное восприятие, а в IEC обязательно надо вглядываться в буковки ибо ничем более элементы там не различаются). Тем паче чертить в КБ всегда сажают девочек, так что это вообще не наша проблема, наша - читать.

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

Колбасу тоже если беру, то всегда по ГОСТ, причем чем старше ГОСТ, тем лучше. :)

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

Обещаю больше не офтопить.

OrionExt

12.03.2018, 15:43

Ой, еще разок. Оффтопним. А так скучно сухари есть(кушать) в теме:)

Рисование от руки займет времени и затрат ровно столько же. Кривые IEC рисовать сложнее чем квадраты (а инверсия и тут и там).
Никто это руками не рисовал в промышленных маштабах, только по трафарету не хитрому. Быстро и всем понятно. Прогресс епть.

Колбасу тоже если беру, то всегда по ГОСТ, причем чем старше ГОСТ, тем лучше. :)
У нас с колбасой беда. Придумали типа местный гост (у кого денег на гост хватит). Поэтому каждый крупный производитель лепет (покупает) свой гост. И сам не отравяся и собака не ест.

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

Ну и по делу. Ой, тяжко автору будет смд монтаж (плотный) разруливать на прототипе. Я один раз попробовал и сказал, да ну нафиг. Это померяй щупом, и присандаль чего, откуси и перепаяй. Это же логика, а ни некий современный элемент(супер-чип) с 2-мя точками чтобы логику работы подправить.

andreil

12.03.2018, 16:01

Ну и по делу. Ой, тяжко автору будет смд монтаж (плотный) разруливать на прототипе. Я один раз попробовал и сказал, да ну нафиг. Это померяй щупом, и присандаль чего, откуси и перепаяй. Это же логика, а ни некий современный элемент(супер-чип) с 2-мя точками чтобы логику работы подправить.
Ну, тогда видео-часть на 2 платы надо делить минимум.
Отказался от одногейтовых элементов - при мешанине они только лишнее место отжирают...

OrionExt

12.03.2018, 16:26

Да не большой специалист я, вот так чтобы сразу видео-тик просчитать и вести его по экрану. Сложно все это для любителя. Таки я за упрощение. Оставить ток часть от Ориона. А может даже на прототипе оставить только ч/б часть (аля Специалист).

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

И оптимизировать будет проще, а вообще меня интересует один момент. Надо это впихивать в телевезионый стандарт, тогда это будет не только конкурентно способно, а и доступно в современном мире (Тут 8бит таки а не PC ATOM).

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

Меня лет 10 назад тоже интересовал вопрос (не только меня)? А как бы это адаптировать на VGA. Прошло время, и придумали (стали доступы) чипы, лепи чего хочешь на 400МГц (на выхлопе 2,5МГц).
Это уже не интересно и неспортивно.
Так что мне видится любой 8-битный комп в рамках ТВ-стандарта (CGA).

Error404

12.03.2018, 16:27

Надо это впихивать в телевезионый стандарт, тогда это будет не только конкурентно способно, а и доступно в современном мире (Тут 8бит таки а не PC ATOM).

В HDMI что ли?
В развертки полвека назад придуманные под CRT расширенный экран Ориона не полезет КМК.

OrionExt

12.03.2018, 16:35

Между прочим, я еще V5899 тут хочу прикрутить. Даешь СТАНДАРТ:)
Вот зачем вам HDMI. Принесите старый TFT телик – дети даже рады будут (или внуки).

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

В развертки полвека назад придуманные под CRT расширенный экран Ориона не полезет КМК.
Все полезет. Ток кварцев тогда было у нас не достать.

andreil

12.03.2018, 16:38

OrionExt

12.03.2018, 16:47

Для совместимости с телевизором можно поставить микросхему от AD - из VGA сразу композитный видеосигнал готовы.
коокой АD (чего там? считываем по строчно в ОЗУ и потом разворачиваем на двойной сточной частоте)

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

ой. Наоборот. Не то это. А как-же мульти колор. Мечтаю увидеть на Орионе:)

andreil

12.03.2018, 17:15

коокой АD (чего там? считываем по строчно в ОЗУ и потом разворачиваем на двойной сточной частоте)

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

ой. Наоборот. Не то это. А как-же мульти колор. Мечтаю увидеть на Орионе:)
Я про конвертер VGA -> TV (http://www.analog.com/media/en/technical-documentation/data-sheets/AD724.pdf). На выходе - композит, PAL/NTSC выбирается кварцем.
Мультиколор - это что? Схема видеовыхода с ПРО в текущем варианте и так есть.

OrionExt

12.03.2018, 17:21

Мультиколор - это что?
Это штука (нуб объясняет) когда допустим за 25Гц меняем два цвета – получаем третий. Снова на оборот меняем частоту:)

andreil

13.03.2018, 13:23

Это штука (нуб объясняет) когда допустим за 25Гц меняем два цвета – получаем третий. Снова на оборот меняем частоту:)
Банальное переключение экранных областей в каждом кадре? Для вывода изображения из 4-х плоскостей в ПРО почти такой подход и используется - там переключение пар плоскостей идёт каждые 4 пикселя, меняя младший бит номера экрана.

По плате, нужен совет гуру.
По питанию ставлю по конденсатору (керамика, 0805, 0,1мкФ, 50В) на каждые 2 корпуса, дорожка питания получилась 0,25мм. По расчётам, вывозит около 0,35А в худшем случае (а при толщине меди в 1oz/0.0347мм будет больше 0,6А). У более шумных микросхем (генератор, счётчики) - по 1 конденсатору на корпус.
И я вот думаю - нормально ли будет сделать заливку полигонами - каждую сторону своим питанием (общий и +5В)? Особо х частот и аналоговых цепей нет, что бы емкость дорожек с питанием играла роль...

Error404

13.03.2018, 14:00

Банальное переключение экранных областей в каждом кадре? Для вывода изображения из 4-х плоскостей в ПРО почти такой подход и используется - там переключение пар плоскостей идёт каждые 4 пикселя, меняя младший бит номера экрана.

По плате, нужен совет гуру.
По питанию ставлю по конденсатору (керамика, 0805, 0,1мкФ, 50В) на каждые 2 корпуса, дорожка питания получилась 0,25мм. По расчётам, вывозит около 0,35А в худшем случае (а при толщине меди в 1oz/0.0347мм будет больше 0,6А). У более шумных микросхем (генератор, счётчики) - по 1 конденсатору на корпус.
И я вот думаю - нормально ли будет сделать заливку полигонами - каждую сторону своим питанием (общий и +5В)? Особо х частот и аналоговых цепей нет, что бы емкость дорожек с питанием играла роль...

Какие серии МСХ планируется использовать? Если HCT, то для них дорожка питания 0,25мм потянет (по самому краешку достаточности), для более жрущих серий думаю надо питание разводить толще как минимум вдвое (а лучше втрое).

andreil

13.03.2018, 14:02

Какие серии МСХ планируется использовать? Если HCT, то для них дорожка питания 0,25мм потянет (по самому краешку достаточности), для более жрущих серий думаю надо питание разводить толще.
Планирую HCT, ACT, F.
0,35А - это мало для 4-х корпусов мелкой логики этих серий? оО
Вот пример разводки фрагмента:
https://image.prntscr.com/image/ogdOL2MlSFm68GCJOGWEtw.png
Одна дорожка на 4 корпуса, по 1 конденсатору на 2 корпуса.

Error404

13.03.2018, 15:46

Дело же тут не только в амперах. Там не постоянный ток течет, а потребление скачет причем с высокой частотой. С тонкими проводниками питания никакие 0,1 конденсаторы не помогут, система потонет в собственных наводках по питанию. Тем более на прожорливых ТТЛ-сериях типа F. У Ориона-ПРО например с проводниками питания 1мм (а чаще и более) и серией 1533 (которая шумит по питанию меньше чем F=1531), всем пришлось дублировать разводки питания (хотя бы частично).

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

Также, я бы многократно продублировал переходные отверстия в местах перехода питания со стороны на сторону (ну, по возможности).

По хорошему еще бы форму дорожек выверить - чтобы без углов.

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

Уже в процессе плата, а что с алфавитно-цифровым режимом что обсуждали ранее (ПЗУ между памятью и ИР13 с фонтами 8х8), он будет?
Такую микроплатку добавочно МГТФ-ить крайне сложно.

Denn

13.03.2018, 15:51

дорожка питания получилась 0,25мм. По расчётам, вывозит около 0,35А в худшем случае (а при толщине меди в 1oz/0.0347мм будет больше 0,6А)....

Смешно. При импульсном потреблении другая "математика". В тех же классических платах Орионов дороги питания более 1мм, и этого мало - приходится дублировать толстыми проводами.

andreil

13.03.2018, 16:23

Смешно. При импульсном потреблении другая "математика". В тех же классических платах Орионов дороги питания более 1мм, и этого мало - приходится дублировать толстыми проводами.
Этот "1мм" - это на пачку микросхем. Я же говорю о питании 4-х корпусов мелкой логики, а не памяти и процессора ;)
Само собой, что к этим "группам" питание будет подводиться намного "жирнее".

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

Быстренько добавил счётчики по вертикали, сделал отводы для мультиплексоров от всех счётчиков. Разводка счётчиков ещё не 100%-ая, остались подтяжки и сигналы для вертикали.
До полной схемы генератору осталось всего-то 5 корпусов, которые разместятся сверху от счётчиков - туда как раз и выходы ориентированны.
https://image.prntscr.com/image/_kLMOus-QH27GJamoBvDjQ.png

andreil

13.03.2018, 21:06

Добавил в схему (https://andreil.by/orion/orion_video.pdf) формирование сигналов по вертикали, "начерно" разместил новые корпуса на плате (https://image.prntscr.com/image/0VGDG4uoTva9cK2yBmmPvg.png). Если использовать имеющуюся половинку DD12, то будут длинные трассы от него(нижний левый угол платы) в верхнюю часть фрагмента. Если добавить новую ТМ2, будет +1 корпус, но свободная половинка DD22 будет использована в дальнейшем для формирования сигнала переключения пар плоскостей (для вывода изображения из 3-х или 4-х плоскостей). Так что и так и так, одна половинка ТМ2 будет свободна.
Итого - получилось 3 счётчика и 6 корпусов логики для формирования вертикали.
Завтра буду компоновать элементы и корпуса для упрощения трассировки и начну собственно трассировку.

PS: На фрагменте платы заметны места для "широких" шин питания - заведу их позже, как закончу разводку сигналов в текущем фрагменте. Так же, скорее всего, верхний ряд корпусов будет сдвинут вверх для прокладки шины питания - по краям общий и плюс будут разведены по разным слоям друг над другом, а в центральной части платы они будут идти столбцами, чередуясь друг с другом ("общий", ряд корпусов, плюс, ряд корпусов и т.д.).
PPS: В схеме мелкая ошибка - входа DD22A неверно названы. Завтра исправлю у себя, а пока неохота трогать проект в сонном состоянии ;)

andreil

14.03.2018, 09:56

По поводу питания - сейчас собрал на макетке начало схемы (генератор, инвертор, счётчик) и посмотрел осциллографом. По питанию получилось около 54мА в пике и около 22мА в среднем - измерял на шунтирующем резисторе 10Ом в разрыве питания. Генератор - SPXO на 25МГц, инвертор - HCT04, счётчик - F163. Подожду переходников SOIC->DIP для сборки более полноценной схемы на макетке и посмотрю ещё раз на почти полной схеме генератора. Заодно и на глитчи проверю схему ;)

andreil

14.03.2018, 16:37

С генератором на 1533 серии, кстати, проблема - работает на грани (25МГц из 34 максимальных). В итоге на осциллографе наблюдаем такую картину (желтый - выход генератора, зелёгый - выход первого разряда счётчика):
https://pp.userapi.com/c834200/v834200427/e527e/3BCZx1FpZtc.jpg
По питанию при 1 блокировочном конденсаторе напряжение, снятое с шунта 10Ом в питании:
https://pp.userapi.com/c834200/v834200427/e52a8/PSsFIZgXcro.jpg
Один счётчик 74F163 на потребляет 30мА в пике, с генератором (на фото выше) - 42мА.
В итоге имеем на 2 корпуса 100мА в прыжке, при наличии блокировочных емкостей. Без оных - всё намного хуже, пульсации получаются с амплитудой до 52мА.
https://pp.userapi.com/c834200/v834200427/e526b/6g9YcEHc1F4.jpg

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

Исправил ссылки на фото :)

OrionExt

14.03.2018, 19:51

Интересная макетка вышла.

Тоже не решился у себя LS на 21.47Мгц ставить. Поставил AS.

andreil

14.03.2018, 20:03

Тоже не решился у себя LS на 21.47Мгц ставить. Поставил AS.
Ну, мне проще заказать детали одной-двух серий. В итоге выбор сошелся на HCT, ACT и частично F (те же 163-и счётчики нашел только в таком исполнении в магазине).

andreil

15.03.2018, 14:41

Закончил предварительную трассировку генератора.
https://image.prntscr.com/image/5J6OrB79SUmiuISXj4RhHg.png
https://image.prntscr.com/image/bmRgstlbR0C6VX0vsl4fkA.png
2 связи, оставшиеся по питанию, будут прокинуты сверху, где пока что идёт граница фрагмента ;)
По углу на верхнем слое (красным) видна широкая (2мм) трасса питания - она будет идти по всему периметру платы, полным кольцом. Общий разведён полигонов с обеих сторон, с максимальным заполнением по площади, а самые шумящие участки по возможности проперфорированны "общим" полигоном.
Сегодня-завтра ещё подумаю над оптимизацией трасс, потом буду клепать мультиплексоры и память.
PS: Фрагмент имеет размеры 42х50мм... Плотность зашкаливает:v2_dizzy_punk:

andreil

15.03.2018, 22:09

Итак, сделал черновую схему управления памятью (https://andreil.by/orion/orion_video.pdf). Буферы для видео и формирование видеосигналов дорисую потом, как будет готов данный участок. Как видно по масштабам схемы, места на листе А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 - для выбора шрифта в будущем псевдографическом режиме, который будет реализован только после отладки логики на реальной памяти, для уменьшения объёмов проекта.
Так же позже добавлю подтяжки к питанию для инверсных сигналов от процессорного модуля, что бы можно было с одной этой платой в реале отладить её работу ;)

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

Исправил обозначение временных элементов на схеме.

Error404

15.03.2018, 23:54

andreil

16.03.2018, 08:49

Почему ты ставишь две банки 256Кх16? Ставь две банки 512Кх8. При том же объеме имеем: Более широко распространенные и более дешевые чипы, меньше ног (можно найти PLCC с нормальным размером и шагом ног), меньше нагрузка на ШД, проще выбирать плоскости.

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

Очевидные же вещи, за которые нам при проектировании минус балл ставили.
Или цель заюзать какие-то уже имеющиеся чипы из коллекции неликвида?
Тут вспоминается, как авторы Ориона-ПРО везде где ни попадя совали ТМ8 (видимо у них был запас).
Да, делаю плату под "то, что есть". И заодно на полноценный вариант нужен только 1 чип памяти. А при использовании 8-битной памяти обязательна установка обеих чипов - ведь для видео в цветных режимах всегда необходимо 16 бит данных ;) В итоге при 8 битной памяти имеем два чипа вместо одного, а стоят они примерно одинаково дорого (не на алике, а "здесь и сейчас").
Из доступных локально чипов статики на 8 бит, с питанием 5В нашлась только CY7C1049B-15VI (SOJ). В основном как раз 16-битные чипы встречаю в магазине. Я понимаю, что с алика можно заказать почти всё, но ждать очень долго придётся =/

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

Я уже всерьёз подумываю над 4-х слойной платой, что бы избавиться от гемороя с разводкой питания - оба внутренних слоя выделить под питание, а сигналы развести на внешних слоях :)

Error404

16.03.2018, 10:10

Ох.
Размести элементы чуть свободнее, и шины питания разведутся.
ОЗУ все равно желательно 1Мб или более, в этом уже все убедились кто плотно пользуется хоть DSDOS, хоть доработанными CP/M.
Плату же все равно заказывать "оттуда"? Заказать заодно и ОЗУ, столько же по времени, да и 3 недели никого не устроят. Что-нить типа такого (https://ru.aliexpress.com/item/HM628512-HM628512ALFP-7/32787468972.html?spm=a2g0v.search0104.3.2.10af6636 ODZiTH&ws_ab_test=searchweb0_0,searchweb201602_2_10152_10 151_10065_10344_10068_10342_10343_10340_10341_1054 3_10696_10084_10083_10618_10307_10301_5711215_1031 3_10059_10534_100031_10103_10624_10623_10622_57113 15_10621_10620_5722415_10125,searchweb201603_25,pp cSwitch_4&algo_expid=fb517a9c-83dc-487e-9fa5-bcac191f86ea-0&algo_pvid=fb517a9c-83dc-487e-9fa5-bcac191f86ea&priceBeautifyAB=0) если подешевле (50р. штука). А если подороже (150р. штука), то bs62lv4006sip55 или другие (напр. K6T4008C1B/K6T4008C1C) - там выбор уже шире.

Все же Орион делается, а не РК-86. Для Ориона принцип всегда был "простая конструкция на распространенных элементах", а не производственный маргинализм выполненный из ассортимента военного завода. :)

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

Кстати, "огласите пожалуйста весь список" - ссылочку на ценник планируемых ОЗУ 256Кх16

andreil

16.03.2018, 11:03

Кстати, "огласите пожалуйста весь список" - ссылочку на ценник планируемых ОЗУ 256Кх16
1:1 как имеющаяся (https://ru.aliexpress.com/item/AS7C4098-15TI-AS7C4098-15TI/1093536006.html), только корпус другой (SOJ vs TSSOP).

Заказать заодно и ОЗУ, столько же по времени, да и 3 недели никого не устроят.
К нам вообще долго идёт - с перевалочным пунктом в Москве. В итоге получается, что 3 недели - почти недостижимый идеал для авиа, обычно недель 4-5 идёт в среднем. А вот если через Финляндию морем и по суше - 3-4 недели. И это с учётом задержек на нашей таможне - 4 дня минимум, при попадании на ручной досмотр сразу на 1,5 недели может застыть =/

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

Кстати, по расширению ПРО, есть замечание :)

Было:использовалась ТМ8 (4 бита), что адресовалотолько 512кб ОЗУ портом 0F9h, никакоерасширение не было предусмотрено
Вообще-то там 4 бита дополнительных в адрес, что соответствует адресации 1Мб. При расширении с ТМ9 получаем до 4Мб, а не 2Мб.
Всё просто же - каждый бит удваивает количество адресов, в базисе имеем 64Кб. Итого - 64*2*2*2*2=1024 (для ТМ8).
И стоит ли в таком случае вводить расширение адресов 20-21 памяти для последующего расширения или 1Мб "хватит всем"?

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

Что-нить типа такого (https://ru.aliexpress.com/item/HM628512-HM628512ALFP-7/32787468972.html?spm=a2g0v.search0104.3.2.10af6636 ODZiTH&ws_ab_test=searchweb0_0,searchweb201602_2_10152_10 151_10065_10344_10068_10342_10343_10340_10341_1054 3_10696_10084_10083_10618_10307_10301_5711215_1031 3_10059_10534_100031_10103_10624_10623_10622_57113 15_10621_10620_5722415_10125,searchweb201603_25,pp cSwitch_4&algo_expid=fb517a9c-83dc-487e-9fa5-bcac191f86ea-0&algo_pvid=fb517a9c-83dc-487e-9fa5-bcac191f86ea&priceBeautifyAB=0) если подешевле (50р. штука). А если подороже (150р. штука), то bs62lv4006sip55 или другие (напр. K6T4008C1B/K6T4008C1C) - там выбор уже шире.
Тут уже скорее всего видео не сможет успеть прочитать данные, поскольку придётся вводить задержки на 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 бит.

Denn

16.03.2018, 11:05

Я уже всерьёз подумываю над 4-х слойной платой, что бы избавиться от гемороя с разводкой питания - оба внутренних слоя выделить под питание, а сигналы развести на внешних слоях :)

Очень правильный вектор мысли.

andreil

16.03.2018, 11:12

Очень правильный вектор мысли.
Да, в курсе.
Питание развести сейчас не особо-то и сложно. Куда хуже дело обстоит с шумами - в любом случае имеем перекрестия дорожек с очень высокой частотой (25М, 13.5М и т.д.) что однозначно приведёт к шумам.
А добавление слоя "общего" и плюса питания обеспечит экранирование подобных перекрестий с очень высоким качеством...
Одно но - цена фрагмента 100х100мм вырастает до 32$ (за 10шт), а увеличение размеров увеличивает стоимость ещё больше (например, 150х150мм 4 слоя стоят уже $70 за те же 10шт). Да, стоимость одного экземпляра ещё оптимальна, да и цена при пропорциональном увеличении площади увеличивается не столь значительно (коэффициент примерно 0,889).

Denn

16.03.2018, 11:37

Одно но - цена фрагмента 100х100мм вырастает до 32$ (за 10шт), а увеличение размеров увеличивает стоимость ещё больше ...

Но если не "взлетит" с традиционной 2-сторонней разводкой, то масштаб потерь будет слишком большой. А решение с отдельными питающими слоями 100%-ое, имхо.

andreil

16.03.2018, 11:50

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

Ещё 1 аргумент в пользу большего размера - разъёмы. Если использовать с шагом 2.54мм, то в 100мм укладывается только стандартный на 64 пина (32 в 2 ряда), а надо разместить ещё и дополнительный на 34 пина (16 по 2 ряда), да ещё и с зазором между ними... В итоге и получается, что можно взять плату шириной 150-200мм в 4 слоя - выйдет примерно 60-67$ (и до 20$ за доставку, хотя тут можно ускоренными попробовать уже, вместе с деталями от того же поставщика - всё сразу в 1 посылке).
https://image.prntscr.com/image/-B2Ren2FS2OUn6KBqSC3ow.png

Denn

16.03.2018, 11:54

Ну, детали феном "сдуть" недолго вообще. Но вот времени будет жалко.

Так и платы уйдут в помойку - а это затраты (время, деньги, нервы).

Error404

16.03.2018, 12:05

На все расчеты могу сказать одно: Орион-ПРО c честными 5МГц прекрасно работает на РУ7 середины прошлого века (150нc и это еще оптимистично учитывая их деградацию, у меня например стоят 565РУ7В 1989 года выпуска) и винигретом из 1533/555 серии. Я не совсем понимаю как с применением ОЗУ 70нс (которые по факту быстрее т.к. это отбраковки от техпроцесса выпуска 55нс, мне кстати часто слали 55 вместо 70) и логики 74F / 74HCT (которая вдвое быстрее) должно не запуститься.

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

Всё просто же - каждый бит удваивает количество адресов, в базисе имеем 64Кб. Итого - 64*2*2*2*2=1024 (для ТМ8).

Вот это вот что сейчас было? Попытка обучить старичка двоичной арифметике? Чтобы он значит не лез с советами по технологии? :D
Ладно, пойду перечитаю учебники арифметики за 3-й класс.

Denn

16.03.2018, 12:16

На все расчеты могу сказать одно: Орион-ПРО c честными 5МГц прекрасно работает на РУ7 середины прошлого века (150нc и это еще оптимистично учитывая их деградацию, у меня например стоят 565РУ7В 1989 года выпуска) и винигретом из 1533/555 серии. Я не совсем понимаю как с применением ОЗУ 70нс (которые по факту быстрее т.к. это отбраковки от техпроцесса выпуска 55нс, мне кстати часто слали 55 вместо 70) и логики 74F / 74HCT (которая вдвое быстрее) должно не запуститься.

Тут не такая "арифметика". Логика 74HCT - это быстрые КМОП, а у них:
- круче фронты = ядрёнее помехи переключения;
- огромное входное сопротивление = шикарная восприимчивость к наводкам.

Соответственно, требования к плате намного выше.

П.С. мне хватило секаса с винбондом (http://zx-pk.ru/threads/25287-problema-s-programmirovaniem-w27c512.html), чтобы прочувствовать все прелести быстрых КМОП. Замечу, это всё на скоростях обычного О-128 @ ВМ80.

andreil

16.03.2018, 15:24

Вот это вот что сейчас было? Попытка обучить старичка двоичной арифметике? Чтобы он значит не лез с советами по технологии? :D
Ладно, пойду перечитаю учебники арифметики за 3-й класс.
Нет, это просто был когнитивный диссонанс от прочитанного ;)

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

На все расчеты могу сказать одно: Орион-ПРО c честными 5МГц прекрасно работает на РУ7 середины прошлого века (150нc и это еще оптимистично учитывая их деградацию, у меня например стоят 565РУ7В 1989 года выпуска) и винигретом из 1533/555 серии. Я не совсем понимаю как с применением ОЗУ 70нс (которые по факту быстрее т.к. это отбраковки от техпроцесса выпуска 55нс, мне кстати часто слали 55 вместо 70) и логики 74F / 74HCT (которая вдвое быстрее) должно не запуститься.
Одно но - для РУ7 сделаны такты ожидания. По схеме - на 2 такта по 10МГц (вывод 7 D87). Получается одна только задержка обращения уже 200нс, сюда плюс ещё время фронта записи (которое меньше чем у чтения) в 200нс на 10МГц без ожиданий. Вот и имеем 400нс на запись/чтения памяти процессором.
И не стоит забывать о частоте чтения из видеопамяти - в оригинале пиксельклок 10МГц, здесь уже 25МГц. Соотвественно и время доступа к видеопамяти в 2,5 раза меньше.

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

О габаритах памяти - накидал имеющиеся корпуса без оптимизаций (посадочные сразу под оба варианта - 256Кх16 и 512Кх8). Скриншот с габаритами 100х100м:
https://image.prntscr.com/image/X4ihN2s3QtahTWQypxarmg.png
Даже при текущих габаритах места вполне достаточно для реализации всего модуля (остались только регистры видеоданных, сдвиговые регистры для цветов, мультиплексоры и 1-3 корпуса логики). Вся проблема в разъёме... Или увеличивать размер платы или делать на шлейфе...

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

Ошибся - в ПРО задержка идёт на 1 такт - для памяти на такте T2, для IO - на такте T3 (TW в ДШ). И цикл записи длится 1 такт, 100нс. Итого получается на 10МГц время обращения к памяти составляет 200нс.

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

Кстати, возвращаясь к размеру плат.
Если делать 4-х слойку (с питанием и общим в средних слоях, ест), то вполне имеет смысл увеличить плату до, например, 100х200мм. В таком случае на данном участке разместится процессорная часть компьютера и не нужен будет дополнительный разъём. Естественно, что ПЗУшки будут в PLCC. Периферия (клавиатура и прочее) на плате не уместятся 100% (если только не сделать клавиатуру сразу на STM'ке какой-либо вместо ВВ55 - сразу с USB на данные отдавать результат).
Так же имеет смысл заменить ВВ55 на пары регистров с защёлками (что бы и писало и читало). Тогда и ожидание для PPI не придётся вводить :)

Denn

16.03.2018, 15:35

Так же имеет смысл заменить ВВ55 на пары регистров с защёлками (что бы и писало и читало). Тогда и ожидание для PPI не придётся вводить :)

Меня, честно говоря, удивляет, почему авторы изначально так не сделали? Хотя может в плане габаритов одна ВВ55 выигрышнее..

andreil

16.03.2018, 15:45

Меня, честно говоря, удивляет, почему авторы изначально так не сделали? Хотя может в плане габаритов одна ВВ55 выигрышнее..
В DIP-корпусах - однозначно выгоднее по габаритам.

Кстати, посмотрел в задержки логики серии 74HCT и приуныл... 74F на порядок шустрее, но и ценник почти в 2 раза выше :) Из вариантов - AHCT.

Denn

16.03.2018, 15:55

andreil, я для системы с тактом 20 МГц для себя выбрал серию 74ACTxxx. Самая требовательная часть (синхроген) взлетела, из чего делаю вывод о пригодности этой серии.

andreil

16.03.2018, 16:00

andreil, я для системы с тактом 20 МГц для себя выбрал серию 74ACTxxx. Самая требовательная часть (синхроген) взлетела, из чего делаю вывод о пригодности этой серии.
Ну да, по характеристикам почти аналогичны эти серии.
Вся беда в том, что счётчики (ИЕ18, они же 74x163) имеются только серии F, задержки только здесь по факту около 15нс по фронтам сигналов при периоде сигнала 40нс - может и прокатит ещё. Вся проблема в том, что получаются довольно длинные цепочки логики, состояние которых защёлкивается по отрицательному спаду такта, то есть через 20нс.

Denn

16.03.2018, 16:32

andreil

16.03.2018, 16:41

andreil, я в синхрогене использовал 74AC163. Соотношение сигналов (компенсация задержек) выравнивал холостыми цепочками инверторов и свободными элементами 2И (там, где инверсия не требовалась).
Да, сегодня по схеме посчитаю примерные задержки и гляну, где надо такие цепочки вводить у себя.

Error404

16.03.2018, 19:04

Меня, честно говоря, удивляет, почему авторы изначально так не сделали? Хотя может в плане габаритов одна ВВ55 выигрышнее..

Очень они их любили, вспомнить хотя бы Орион-ПРО, где даже диспетчер по 16к сделан на ВВ55 где вместо её и кучки логики просто просится схема с двумя ИР26 (не ограничивающая быстродействие и дающая полноценный диспетчер, а не 3 окна из четырех). Думаю, в 1995 году на Тушино уже можно было купить любые TTL в практически неограниченных количествах. С другой стороны, применение ВВ55 где ни попадя это было стандартной практикой в СССР, а всю линейку ТТЛ возможно знал и не каждый проектировщик-любитель (а так и было).

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

Ошибся - в ПРО задержка идёт на 1 такт - для памяти на такте T2, для IO - на такте T3 (TW в ДШ). И цикл записи длится 1 такт, 100нс. Итого получается на 10МГц время обращения к памяти составляет 200нс.

OMG, какое упрямство. :) Ну ладно, не Орион-ПРО (допустим, пример не очень, авторы себе облегчили жизнь урезав скорость), но и Орион-128 тоже в 90х турбировали до честных 5М на 565РУ7В все времянки фактически умножая на 2. 150нс и 5Мгц вполне сочетались, т.е. нисколько не убедили, что 10М и 70нс (тем паче что на самом деле никто не мешает поставить 55нс) несочетаемы.

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

Да чего там, даже на РУ5 (200нс) делали честные 5М, вон barsik не даст соврать.

andreil

16.03.2018, 19:15

Посмотрим в модели ;)

Актуальный вопрос - делать 2 модуля с шлейфом (на 34 контакта) между ними или в 1 плату 100х200мм уместить?

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

Писал уже об этом:

О габаритах памяти - накидал имеющиеся корпуса без оптимизаций (посадочные сразу под оба варианта - 256Кх16 и 512Кх8). Скриншот с габаритами 100х100м:
https://image.prntscr.com/image/X4ihN2s3QtahTWQypxarmg.png
Даже при текущих габаритах места вполне достаточно для реализации всего модуля (остались только регистры видеоданных, сдвиговые регистры для цветов, мультиплексоры и 1-3 корпуса логики). Вся проблема в разъёме... Или увеличивать размер платы или делать на шлейфе...

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

Кстати, возвращаясь к размеру плат.
Если делать 4-х слойку (с питанием и общим в средних слоях, ест), то вполне имеет смысл увеличить плату до, например, 100х200мм. В таком случае на данном участке разместится процессорная часть компьютера и не нужен будет дополнительный разъём. Естественно, что ПЗУшки будут в PLCC. Периферия (клавиатура и прочее) на плате не уместятся 100% (если только не сделать клавиатуру сразу на STM'ке какой-либо вместо ВВ55 - сразу с USB на данные отдавать результат).

Error404

16.03.2018, 20:05

Посмотрим в модели ;)
Актуальный вопрос - делать 2 модуля с шлейфом (на 34 контакта) между ними или в 1 плату 100х200мм уместить?

Если решили за 4-слойку и жирные шины питания уходят, то может всё поместится в 10х10 если полностью задействовать под размещение элементов и вторую сторону п.п. ?
Максимально уменьшить габаритные части - например системный разъем вынести в виде укороченного по длине контактов краевого (примерно как на девбордах прототипов (https://ru.aliexpress.com/item/2Pcs-Double-Side-5x7-cm-Prototype-Universal-FR-4-Glass-Fiber-PCB-Board/32224652823.html?spm=a2g0v.10010108.1000013.4.4fd1 bed3bk8Kdh&traffic_analysisId=recommend_2088_2_-1_iswistore&scm=1007.13339.90158.0&pvid=194f1da4-6a54-4d61-b481-d2a802c75f42&tpp=1)). На такой краешек чудесно "встык" паяются 2-рядные разъемы будь то хоть IDC, хоть PLC, хоть DIN41612. Единственно, проследить чтобы все что потенциально идет в панельки, попало строго на одну сторону.
Порты ВВ55 (в т.ч. клавиатура, ром-диск, F600) вообще на эту плату не тащить (тем более не ясно ставить там ВВ55 или контроллер на ARM64 100500Ггц или ТТЛ-регистры), под это дело сделать отдельную дешевую 2-слойную плату 10х10 с ВВ55 и сразу с RS-232, SPI, {предлагайте прочее}. Понятно, что запускать эти платы можно будет по отдельности.

OrionExt

16.03.2018, 20:48

Актуальный вопрос - делать 2 модуля с шлейфом (на 34 контакта) между ними или в 1 плату 100х200мм уместить?
При таком концепте, когда модуль цпу не будет жить без модуля видео как-то делить их, на мой взгляд, не имеет особого смысла. По мне размер модуля должен вписываться в 100х100(или 160). Две отдельные платы или две платы - бутерброд или одна плата (все равно это единое целое по факту). В общем надо исходить только из стоимости (считать).

А может и задумываться не надо делать все по мин цене (платы 100х100). А если что-то из этой затеи вырастит работоспособное тогда и задуматься о финальном варианте. Я так и поступаю у себя и не пытаюсь объять необъятное и впихнуть невпихуемое. Пускай дольше выходит путь до какой-то идеальной цели, зато промежуточный результат работы виден достаточно быстро. И главное его можно уже пощупать и понять, куда двигаться дальше.

andreil

16.03.2018, 21:30

Если решили за 4-слойку и жирные шины питания уходят, то может всё поместится в 10х10 если полностью задействовать под размещение элементов и вторую сторону п.п. ?
Максимально уменьшить габаритные части - например системный разъем вынести в виде укороченного по длине контактов краевого (примерно как на девбордах прототипов (https://ru.aliexpress.com/item/2Pcs-Double-Side-5x7-cm-Prototype-Universal-FR-4-Glass-Fiber-PCB-Board/32224652823.html?spm=a2g0v.10010108.1000013.4.4fd1 bed3bk8Kdh&traffic_analysisId=recommend_2088_2_-1_iswistore&scm=1007.13339.90158.0&pvid=194f1da4-6a54-4d61-b481-d2a802c75f42&tpp=1)). На такой краешек чудесно "встык" паяются 2-рядные разъемы будь то хоть IDC, хоть PLC, хоть DIN41612. Единственно, проследить чтобы все что потенциально идет в панельки, попало строго на одну сторону.
Порты ВВ55 (в т.ч. клавиатура, ром-диск, F600) вообще на эту плату не тащить (тем более не ясно ставить там ВВ55 или контроллер на ARM64 100500Ггц или ТТЛ-регистры), под это дело сделать отдельную дешевую 2-слойную плату 10х10 с ВВ55 и сразу с RS-232, SPI, {предлагайте прочее}. Понятно, что запускать эти платы можно будет по отдельности.
Да, буду в 4 слоя делать. Питание с сигнальных слоёв уже убрал - буду перемещать и блокировочные ёмкости, а так же оптимизировать ближайшие проводники для прохождения питания к микросхемам.
НО плотности - ну, так плотно вряд ли получится - на промежуточных слоях только питание. Сигнальные линии как были в 2 слоя, так и останутся. Часть генератора и так уже достаточно плотная, хотя есть определённые места, где можно что-либо сдвинуть.
А вот по разъёму очень дельное предложение. Вот примерная компоновка на текущий момент:
https://image.prntscr.com/image/g4GCj8wsSC_azyCz1c6NtQ.png
Вырезы под разъём сделаются как устаканится всё, так что пока работает "в квадрате". Мультиплексоры адресов сдвинуться вниз, на их место попадёт часть логики с верхней части. Ещё в правой части пару чипов на каждой стороне можно уместить - надо смотреть, что бы не было больших частот, поскольку там будут длинные петли на мультиплексоры и видевыход.
Места для видевыхода вполне достаточно на плате, но вот под псевдографику на ПЗУшке может и не хватить места - надо смоделировать ещё, а то непонятно что по схеме переделывать придётся даже.

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

При таком концепте, когда модуль цпу не будет жить без модуля видео как-то делить их, на мой взгляд, не имеет особого смысла. По мне размер модуля должен вписываться в 100х100(или 160). Две отдельные платы или две платы - бутерброд или одна плата (все равно это единое целое по факту). В общем надо исходить только из стоимости (считать).

А может и задумываться не надо делать все по мин цене (платы 100х100). А если что-то из этой затеи вырастит работоспособное тогда и задуматься о финальном варианте. Я так и поступаю у себя и не пытаюсь объять необъятное и впихнуть невпихуемое. Пускай дольше выходит путь до какой-то идеальной цели, зато промежуточный результат работы виден достаточно быстро. И главное его можно уже пощупать и понять, куда двигаться дальше.
По стоимости - 2 платы 100х100 и одна 100х200 в 4 слоя стоят почти одинаково.
При размере 100х100 получается около 4$ за плату в 4 слоя (без доставки, ест).
Но, скорее всего, так и буду делать модулями, как и задумывалось изначально.

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

По компоновке памяти - чипы расположены "будербродом". На одной стороне 256*16, на другой - 512*8.

andreil

17.03.2018, 14:18

Разработку платы пока поставлю на паузу - буду работать над клавиатурой, пока не придут макетки для памяти. Потом вернусь сюда, проверив функционирование видеовыхода на всех режимах...

Error404

17.03.2018, 14:46

Пока можно в видео добавить и отладить алфавитно-цифровой дисплей (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-контроллер уже есть).

andreil

17.03.2018, 14:57

Пока можно в видео добавить и отладить алфавитно-цифровой дисплей (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-контроллер уже есть).
Я сейчас на STM32 делаю контроллер USB клавиатуры (http://zx-pk.ru/threads/28958-kontroller-usb-klaviatury.html). Уже оба девайса сразу можно использовать, если оба "висят" на одном "свистке". С PS/2 у меня проблема - единственная сейчас не работает (нет тактов от неё вообще, но при включении мигает светодиодами).
В перспективе этот контроллер можно использовать как с ВВ55, так и вместо ВВ55, то есть сразу подключив к управляющим шинам. А если надо прочие интерфейсы - прокинуть ещё пару проводков (чип-селектов) и реализовать их софтварно в МК.

По видео - можно, но не раньше чем в понедельник.

andreil

10.04.2018, 12:28

Error404

10.04.2018, 15:12

По реализации псевдографического режима есть идея. Ограничение - знакоместо 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 шрифтов. Можно использовать и меньшие ПЗУшки, просто будет доступно меньше шрифтов.
Примерная реализация в схеме (https://image.prntscr.com/image/zogu_zsbSN228KGbQJvv7g.png).
Итого - добавляется ПЗУ, 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 (http://zx-pk.ru/threads/27462-sborka-nastrojka-platy-orion-128(uknts)-ps-2(caro)-fdd-ide-z80card2.html?p=956297&viewfull=1#post956297), только что-то я не помню это порт F8 или порт FA. Хотелось бы чтобы у тебя было включение этого режима аналогичным битом. Остальные биты бери свободные какие угодно, только учти что в Орионе-ПРО есть дополнительные режимы относительно Ориона-128 (занято на 2 бита больше в режимах цветности), не хотелось бы с ними пересечься. Кстати, один из этих двух дополнительных битов включает режим "Цветного монохрома" когда цветовые атрибуты задаются на весь экран значением порта FC. Полезный режим, он у нас будет? Особенно было бы интересно если бы этот порт при включенном его бите в цветных режимах добавлял бы смещение к штатному RGBI - этакие микропалитры (на ПРО этого нет, а зря).

andreil

10.04.2018, 16:07

Фонтов в твоем решении получается не 16, а 32, если аппаратно не увязывать сигнал G16 к переключению Y{2} Y{3} (т.е. режим фонта 8/16), а ставить G16 независимо. Да, тут возможен эффект когда получается режим где фонт на 8 рисуется половинками букв по 16, или фонт на 16 рисуется из двух букв по 8 (ничего страшного, об этом должен позаботиться автор ПО конфигурирующего порты F8 и FA), но зато при меньшем обязательном количестве адресных ног ПЗУ получаем возможность иметь, к примеру, 3 шрифта высотой 16pix и 5 шрифтов на 8pix. Итого в сумме 8 и освобождается 2 адресных ноги ПЗУ.
Сигналом G16 переключаются банки шрифтов 8/16. Если его убирать, то нужно делать только 1 высоту шрифта. Он задаётся битом порта F8. Формировать шрифт из "половинок" не получится, ИМХО.

По включению режима алфавитно-цифрового дисплея: вот тут мы под это дело сделали на будущее задел битом D6 (http://zx-pk.ru/threads/27462-sborka-nastrojka-platy-orion-128(uknts)-ps-2(caro)-fdd-ide-z80card2.html?p=956297&viewfull=1#post956297), только что-то я не помню это порт F8 или порт FA. Хотелось бы чтобы у тебя было включение этого режима аналогичным битом. Остальные биты бери свободные какие угодно, только учти что в Орионе-ПРО есть дополнительные режимы относительно Ориона-128 (занято на 2 бита больше в режимах цветности), не хотелось бы с ними пересечься. Кстати, один из этих двух дополнительных битов включает режим "Цветного монохрома" когда цветовые атрибуты задаются на весь экран значением порта FC. Полезный режим, он у нас будет? Особенно было бы интересно если бы этот порт при включенном его бите в цветных режимах добавлял бы смещение к штатному RGBI - этакие микропалитры (на ПРО этого нет, а зря).
"Цветной монохром" будет - видеовыход я взял из ПРО, на ПЛИС меню Прошки показывается отлично, а она именно в этом режиме идёт. По смещению - это будет сложнее реализовать и надо продумывать уже сейчас. Пока что не соображаю, как это сделать даже.

Error404

10.04.2018, 16:53

Сигналом G16 переключаются банки шрифтов 8/16. Если его убирать, то нужно делать только 1 высоту шрифта. Он задаётся битом порта F8. Формировать шрифт из "половинок" не получится, ИМХО.

Сигнал G16 это всего-лишь адресная ножка ПЗУ и делитель на 2 для набора шрифтов. Только нам решать в какой момент какой сигнал на этой ножке. Я не предлагал формировать шрифт из половинок, я наоборот писал что если программист не понимает связи между размером шрифта и адресом (оффсетом в ПЗУ) шрифта, то при G16 просто заведенной на бит порта FA/F8 (как предлагаю я, и уже это будет не G16 а тупо адрес фонта) он получит на экране половинки букв или задвоенные по вертикали буквы вместо ожидаемого.

А если он понимает что делает, то прекрасно можно совместить 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.

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

Причем набор из 8 фонтов это для размерности 16pix, для 8pix этих фонтов будет уже 16 штук, ну или комбинации шрифтов разной размерности (пакуй их в ПЗУ в какой угодно последовательности, просто помни что как сделал и так и используй в ПО - в итоге придем к общему для всех устаканившемуся набору смеси из 8 и 16 битных шрифтов, записанных в ПЗУ "впритык"). Т.е. нужно аппаратно никак не связывать между собой режим сканирования символа (8/16) и офсет в ПЗУ (адрес фонта кратно 2кб - задается отдельно 4 битами какого-нить порта F8/FA).

andreil

10.04.2018, 18:18

По шрифтам - в Орионе они идут 7-битные или полные, 8-битные?
Если 7-битные, то этот "лишний" бит можно использовать как раз вместо сигнала G16.

По моей реализации с сигналом G16: адрес Y2 пропускаем через AND с G16 - получаем, что он будет активен только при "1" на G16. А для памяти Y2 - через OR. И не будет ни половинок, ни раздвоений. На схеме это не изобразил, потому что рисовал на скорую руку на обеде :)

Error404

10.04.2018, 19:36

По шрифтам - в Орионе они идут 7-битные или полные, 8-битные?
Если 7-битные, то этот "лишний" бит можно использовать как раз вместо сигнала G16.

В Орионе фонты 8-битные (256 символов), к счастью не догадались это как-нибудь аппаратно или "стандартами" урезать до 7 бит как в i8275. В порядке убывания популярности: KOI8-R, CP866, CP1251. Как частный случай (для экономии ОЗУ и совместимости с РК) - 7-битный KOI7-R который по дефолту в Мониторе F800.

По моей реализации с сигналом G16: адрес Y2 пропускаем через AND с G16 - получаем, что он будет активен только при "1" на G16. А для памяти Y2 - через OR. И не будет ни половинок, ни раздвоений. На схеме это не изобразил, потому что рисовал на скорую руку на обеде :)

Какие-то лишние действия, не? И все равно есть зависимость (или пререквизит) 16pix фонты размещать в ПЗУ сообразно кратности 4кб? Или делить пополам и класть в две страницы? Что-то без схемы не до конца понял твою идею. Все же я бы никак не связывал между собой сканер 8/16 точек и адрес офсета в ПЗУ (который ставил бы напрямую с порта) т.к. не вижу в этом каких-то очевидных минусов, а комбинаторно вариантов получаем больше (кто-нить еще и DEMO слепит из половинок букв :) ) и схемно проще.

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

По предложению "вместо 2х КП11 иcпользовать только одну W28С512 (где половина её прошита под pass-through кодом с 128-ю повторяющимися блоками перечисления 0..FF)." нет возражений? По-моему достаточно красиво (идея barsik-а, кстати, достаточно очевидное решение для оптимизации).

andreil

10.04.2018, 21:14

Какие-то лишние действия, не? И все равно есть зависимость (или пререквизит) 16pix фонты размещать в ПЗУ сообразно кратности 4кб? Или делить пополам и класть в две страницы? Что-то без схемы не до конца понял твою идею. Все же я бы никак не связывал между собой сканер 8/16 точек и адрес офсета в ПЗУ (который ставил бы напрямую с порта) т.к. не вижу в этом каких-то очевидных минусов, а комбинаторно вариантов получаем больше (кто-нить еще и DEMO слепит из половинок букв :) ) и схемно проще.
Может тогда делать только шрифты 8х8? ИМХО, если использовать как спрайты (например, сделать доступной запись этой МС, использую не-УФ-стираемую, а EEPROM) 256 спрайтов должно "хватить всем".
Если поставить EEPROM, то можно шрифты грузить динамически, сделав парочку из них "пользовательскими", а основные зашить намертво (можно даже сделать защиту от записи на паре логических элементов).

По предложению "вместо 2х КП11 иcпользовать только одну W28С512 (где половина её прошита под pass-through кодом с 128-ю повторяющимися блоками перечисления 0..FF)." нет возражений? По-моему достаточно красиво (идея barsik-а, кстати, достаточно очевидное решение для оптимизации).
Да, тут ничего против не имею.
Итого, для шрифтов 8х8 имеем: 1 ПЗУ, 1 КП11 (для адресов видеопамяти). Ну и ещё небольшая схемка для записи в ПЗЦ "на лету", если будем делать.

Error404

10.04.2018, 22:22

Может тогда делать только шрифты 8х8? ИМХО, если использовать как спрайты (например, сделать доступной запись этой МС, использую не-УФ-стираемую, а EEPROM) 256 спрайтов должно "хватить всем".
Если поставить EEPROM, то можно шрифты грузить динамически, сделав парочку из них "пользовательскими", а основные зашить намертво (можно даже сделать защиту от записи на паре логических элементов).

Да, тут ничего против не имею.
Итого, для шрифтов 8х8 имеем: 1 ПЗУ, 1 КП11 (для адресов видеопамяти). Ну и ещё небольшая схемка для записи в ПЗЦ "на лету", если будем делать.

Можно и только 8x8 оставить. Вроде как такой режим реализуем в Орионе128/512 с DRAM. Получится типо для совместимости (ну, и для простоты).
А вот с записью - там наверно тогда проще поставить SRAM-ину на 64к и инициализировать ее при загрузке той ОС, что будет уметь работать с этим алфавитным дисплеем? Или программкой для ОРДОС (если пользоваться этим режимом под Ордос). В любом случае понадобится добавить 3 КП11 (12 адресных, 4 с порта адреса фонта можно не трогать) и один буфер с Z типа АП5 (для записи в то ОЗУ с ШД) плюс какую-то логику выборки этих КП11 и АП5 через какие-то порты. Не сложновато ли?

andreil

10.04.2018, 22:44

А вот с записью - там наверно тогда проще поставить SRAM-ину на 64к и инициализировать ее при загрузке той ОС, что будет уметь работать с этим алфавитным дисплеем? Или программкой для ОРДОС (если пользоваться этим режимом под Ордос). В любом случае понадобится добавить 3 КП11 (12 адресных, 4 с порта адреса фонта можно не трогать) и один буфер с Z типа АП5 (для записи в то ОЗУ с ШД) плюс какую-то логику выборки этих КП11 и АП5 через какие-то порты. Не сложновато ли?
Это чисто теоретическое изыскание.
Завтра попробую поколдовать над клавиатурой, может получиться через Linux USB-шную прокинуть на плате - сейчас я ничего не могу сделать, поскольку порт спалил-таки, судя по всему. Как сделаю - буду проверять видеорежимы с ПРОшки, которые будут и в моём варианте схемы.

andreil

11.04.2018, 10:57

По реализации псевдографики - набросал в Квартусе:
https://image.prntscr.com/image/TKRwop55RNOrD08mLxA8iw.png
https://image.prntscr.com/image/qlQoDB3oRpKwbfhzDzy8yA.png
Итого, добавлен мультиплексор на сканирование видеопамяти, и ПЗУ в разрыве vdata.
По поводу смешивания с результатом порта FC - а имеет ли это смысл? Всё равно оттенки меняются сразу на всём экране, а не независимо.

Error404

11.04.2018, 12:38

По реализации псевдографики - набросал в Квартусе:
Итого, добавлен мультиплексор на сканирование видеопамяти, и ПЗУ в разрыве vdata.

Я правильно понимаю, что мультиплексор ma_0 и латчи mvdata0+mvdata1 - это корпуса не относящиеся к доработке по АЦД (т.е. просто кусок схемы стандартного Ориона?). Буфера(латчи?) на входе и выходе ПЗУ, стробируемые неким сигналом clk/inst2 - это нечто для внуренней логики квартуса? Мы же ничего такого не планировали.

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

Оттенки (4 градации интенсивности в дополнении к еще одной формируемой по сигналу I) можно будет менять отдельно для каждого из сигналов RGB. Т.е. сейчас у нас в знакоместе есть RGB (8 цветов) куда на диодах замешан четвертый бит I (получаем 16 цветов на точку). Если аналогично (как делается в Орионе-128 для I) туда на диодах же замешать еще по 2 бита отдельно к каждому из R-G-B подав по два бита с порта FC который RGBIRGBI (только с весами мЕньшими чем у I - например 4:2:1, где I=4), то получим 16 цветов на точку (в знакоместе) из палитры 64 цвета (это если оставить I 1-битным). Можно будет например рисовать не вырвиглазными красным и бирюзовым, а их более мягкими оттенками.
Реализуемо такое? А том может это сложнее чем мне кажется, и сделать в RGB добавку многобитных весов не получится как сделано для I на диодах и резисторах?

andreil

11.04.2018, 12:56

Я правильно понимаю, что мультиплексор ma_0 и латчи mvdata0+mvdata1 - это корпуса не относящиеся к доработке по АЦД (т.е. просто кусок схемы стандартного Ориона?). Буфера(латчи?) на входе и выходе ПЗУ, стробируемые неким сигналом clk/inst2 - это нечто для внуренней логики квартуса? Мы же ничего такого не планировали.
По АЦД - это только мультиплексор ma_pg и ROM.
В ПЛИС ROM выполнена как On-Chip-Memory, поэтому там требуется тактирование (синхронная память с латчами, все дела).

Оттенки (4 градации интенсивности в дополнении к еще одной формируемой по сигналу I) можно будет менять отдельно для каждого из сигналов RGB. Т.е. сейчас у нас в знакоместе есть RGB (8 цветов) куда на диодах замешан четвертый бит I (получаем 16 цветов на точку). Если аналогично (как делается в Орионе-128 для I) туда на диодах же замешать еще по 2 бита отдельно к каждому из R-G-B подав по два бита с порта FC который RGBIRGBI (только с весами мЕньшими чем у I - например 4:2:1, где I=4), то получим 16 цветов на точку (в знакоместе) из палитры 64 цвета (это если оставить I 1-битным). Можно будет например рисовать не вырвиглазными красным и бирюзовым, а их более мягкими оттенками.
Реализуемо такое? А том может это сложнее чем мне кажется, и сделать в RGB добавку многобитных весов не получится как сделано для I на диодах и резисторах?
Хмм... У меня несколько другое предложение. Выхода мультиплексоров подключаем к АП13 (или ещё чему, главное - развязать сигналы, в оригинале это было на диодах, но для R2R такое решение не подходит), выхода которых выводим на R2R ЦАП:
https://image.prntscr.com/image/od_QjK9kTsenH4j45R9I-g.png
(Сейчас у меня сделано так для выхода на ЦАП, имеющийся на плате)
Сюда же на входа АП-шек можно будет завести выходы порта FC, смешав их с цветом, как и яркость. Для совместимости сигналы от порта надо будет подтянуть к +5, что бы не портило картинку при прочих режимах.

Конечно, можно эту же схему реализовать и на резисторах с диодами, но я тут мало соображаю, к сожалению :(

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

Между делом добавил в схему (https://andreil.by/orion/orion_video.pdf) формирователь видеосигнала - выше и правее памяти. Осталось определиться с формированием аналогового RGB и дорисовать этот кусочек схемы. Ну и с АЦД решить ещё - пока что не вносил в схему.
Лист А3 забит битком...

Error404

11.04.2018, 13:09

Хмм... У меня несколько другое предложение. Выхода мультиплексоров подключаем к АП13 (или ещё чему, главное - развязать сигналы, в оригинале это было на диодах, но для R2R такое решение не подходит), выхода которых выводим на R2R ЦАП:
(Сейчас у меня сделано так для выхода на ЦАП, имеющийся на плате)
Сюда же на входа АП-шек можно будет завести выходы порта FC, смешав их с цветом, как и яркость. Для совместимости сигналы от порта надо будет подтянуть к +5, что бы не портило картинку при прочих режимах.
Конечно, можно эту же схему реализовать и на резисторах с диодами, но я тут мало соображаю, к сожалению :(

Можно и на АП сделать. Только поставить что-то попроще типа 555АП3 (SN74LS240 - два 4битных инвертирующих шинника в одном корпусе) или 555АП4 (SN74LS241 - два 4битных неинвертирующих) в зависимости от логики что там надо на выходе: инвертировать или нет. Т.е. всего 2 доп. корпуса для RGBI, получив до четырех битов на каждый сигнал.

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

Причем кому это будет не надо (или при поэтапной наладке), вместо этих двух шинников и кучки резисторов достаточно будет 4 перемычки запаять.

andreil

11.04.2018, 14:58

Можно и на АП сделать. Только поставить что-то попроще типа 555АП3 (SN74LS240 - два 4битных инвертирующих шинника в одном корпусе) или 555АП4 (SN74LS241 - два 4битных неинвертирующих) в зависимости от логики что там надо на выходе: инвертировать или нет. Т.е. всего 2 доп. корпуса для RGBI, получив до четырех битов на каждый сигнал.
ИМХО, разницы никакой - можно и в нынешней схеме обрезать до 4 бит на канал. Просто мне надо для АЦП 8 бит.

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

Добавил выход на АП13 и R2R АЦП (https://andreil.by/orion/orion_video.pdf).
Место для АЦД на схеме придётся уже выигрывать перестановками и уплотнениями.

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

Схема почти завершена (https://andreil.by/orion/orion_video.pdf).
Осталось проверить в её в ПЛИС и исправить ошибки.
Кроме имеющегося будет добавлен только разъём питания. Конденсаторы по питанию - остались за кадром, негде уместить.

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

Кстати, по размеру схемы - распечатал на листе А4, всё отлично видно, масштаб примерно как и в публикациях журнальных. Хотя в KiCAD'е стоит лист А3 :)

Error404

11.04.2018, 18:07

А вот интересно: можно ли сделать так, когда в АЦД для хранения кодов символов в ОЗУ используются строки не кратные 8 (0, 8, 16, ...), а (0+1, 8+1, 16+1, ...) или (0+2, 8+2, 16+2, ...) или...
Хотя бы для этого и отображение первой видимой строки пикселей на экране начиналось со сдвигом вниз на 1 или 2 или ... строк пикселей. Т.е. сделать чтобы 7 строк по 64 байта в ОЗУ не пропадали в недоступности закрытые зануляющим мультиплексором, а в них можно было хранить еще несколько текстовых "экранных областей"?

andreil

11.04.2018, 18:19

Error404

11.04.2018, 19:01

Можно, если с какого-либо или нового порта завести 3 бита на мультиплексор. Оба экранных порта уже полностью заняты...

А можешь написать что в итоге получилось на битах портов F8 и FA ?

andreil

11.04.2018, 21:03

А можешь написать что в итоге получилось на битах портов F8 и FA ?
На схеме в предыдущем посте всё видно :) - надо искать ИР35 с номерами больше 100. Все порты, отвечающие за видео, вынесены в эту схему, что бы минимизировать шину.
F8 - 0-4 управление видеорежимами (128+ПРО), 6 бит на АЦД, 7 бит свободен.
FA - 0-1 на видеобанки, 2-5 номер шрифта АЦД, 6 выключение регенерации (из ПРО), 7 расширенный экран (512 точек, так же из ПРО).
Не уверен по 6 биту F8 - может имелся в виду 6-ой при отсчёте с 1?

Error404

11.04.2018, 22:31

На схеме в предыдущем посте всё видно :) - надо искать ИР35 с номерами больше 100. Все порты, отвечающие за видео, вынесены в эту схему, что бы минимизировать шину.
F8 - 0-4 управление видеорежимами (128+ПРО), 6 бит на АЦД, 7 бит свободен.
FA - 0-1 на видеобанки, 2-5 номер шрифта АЦД, 6 выключение регенерации (из ПРО), 7 расширенный экран (512 точек, так же из ПРО).
Не уверен по 6 биту F8 - может имелся в виду 6-ой при отсчёте с 1?

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

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

TomaTLAB

11.04.2018, 22:53

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

andreil

11.04.2018, 23:27

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

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

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

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

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

TomaTLAB

12.04.2018, 00:06

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

andreil

12.04.2018, 08:55

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

Error404

12.04.2018, 13:36

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

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

Порт 0F8H:

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

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

Порт 0FAH:

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

andreil

13.04.2018, 15:17

Error404

13.04.2018, 16:21

Есть ли прошивки теста памяти для Орион-ПРО? Собрал память на платке, подключил. Но где-то ошибка с таймингами, судя по всему - не показывается меню. Клавиатуры, что бы "в слепую" выбрать пункт меню, нет.

Вроде вот такой тест должен работать:
http://zx-pk.ru/attachment.php?attachmentid=50235&d=1418316129
И выдавать вот такую картинку:
http://zx-pk.ru/attachment.php?attachmentid=45051&d=1389740514

Но у меня в эмуляторе оно почему-то не заработало (может баг в эмуляторе - ХЗ).

andreil

13.04.2018, 18:34

Вроде вот такой тест должен работать:
http://zx-pk.ru/attachment.php?attachmentid=50235&d=1418316129
И выдавать вот такую картинку:
http://zx-pk.ru/attachment.php?attachmentid=45051&d=1389740514

Но у меня в эмуляторе оно почему-то не заработало (может баг в эмуляторе - ХЗ).
Точно, как я мог о нём забыть...
На FPGA с внутричиповой памятью в текущем варианте работал 100%.
Для его работы на картинку надо правильно выставить переключатели - это есть в мануале по ПРО:
https://image.prntscr.com/image/_hAcnD5_Q2mPFyM7xWG1Vg.png

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

Да, проблема с таймингами, буду разруливать - видны артефакты.

Error404

13.04.2018, 19:09

Точно. Подзабыл уже, что для него надо еще и DIP-switch переставлять (как по мне - совершенно лишнее, т.к. потом еще надо вспомнить как оно было).

andreil

13.04.2018, 20:34

Это да, вспоминать всегда тяжело :)
По памяти - такое ощущение, что необходимо полностью менять схему работы с ней. По работе теста видно, что иногда в память пишется мусор.
С OnChipMemory такого не было, потому что она очень быстрая и там были разные порты для чтения и записи. А с реальной заметны переходные процессы на пинах данных - в момент переключения с чтения на запись там идёт случайный мусор. И этот мусор имеет некоторый шанс успеть записаться в память по адресу видеоданных, сканируемых до начала цикла обращения CPU к памяти.
В общем, надо делать дополнительный сигнал отключения памяти на 20нс перед обращением. Сейчас цикл занимает 100нс, можно его разбить на 2 части:
1) выключаем CE, выключаем OE, выставляем адрес, выставляем данные - пауза 20нс (1 такт клока);
2) включаем CE, включаем WE - держим до окончания обращения.
Жирным выделил то, что и так есть, а вот дополнительное управление CE/WE надо дополнить...

andreil

14.04.2018, 10:31

Нашел ещё одно проблемное место - сигнал DSYN формируется асинхронно, из-за чего наблюдается "иголка", мешающая записи в память. Буду переделывать и этот узел.
Заметил, только синхронизировав анализатор по частоте 300МГц.

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

Модификация доступа к ОЗУ сделана, но этого недостаточно:
https://image.prntscr.com/image/5rg6UjIGSGum7CC3FzV_cw.png
Фронт обращения к памяти значительно увеличился, раньше по длительности было равно длительности сигнала WR от Z80 - схему формирования обращения к памяти взял от ПРОшки, придётся модифицировать.

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

Уменьшил фронт обращения памяти к прежнему варианту (100нс).
Да, работа процессора с памятью теперь нормализована, но порой видео не может достучаться до памяти - где-то ещё проблема с таймингами... Это заметно при зажатии сброса - картинка идеальная, без артефактов.

Из проблем - при переходе на реальную память в правой части изображения непонятная фигня творится - а должна быть нормальная картинка.

andreil

14.04.2018, 20:46

Как-то всё запутанно с этим косяком - во время заливки памяти есть левые данные в видео, а после заливки всё идеально.
Такое ощущение, что для памяти ещё и после записи надо передёргивать CE, судя по мусору:
https://image.prntscr.com/image/nvD3UEz9SNe0eTZERhpGIA.png
CE поднимаю только перед началом записи.
SA - шина адреса памяти, SD - её же данные. SOE - нога OE, SWE - и так понятно, что WE памяти.
DSYN_N - негативный строб обращения CPU к памяти.
По тесту - в память пишется строго 2 байта - 0xFF и 0x00, весь мусор только от переходных процессов на шине. Если делать "передёргивание" CE и в конце записи, то цикл обращения сократиться до 60нс...

Error404

15.04.2018, 00:08

andreil

15.04.2018, 11:49

"Моргать" CE это как-то не согласуется со схемой Ориона - там же ОЗУ всегда выбрано (Активно), а потребитель (ШД/видео) переключаются соответствющими выходными регистрами/буферами. Раз на запись с ШД хватается что-то не то (почему DRAM, в разы более медленные, кстати, так не хватали? Скорость то не на порядок выше) то я бы посмотрел в сторону того как работает буфер ШД, как вариант дополнительно в нужный момент защелкивать правильное состояние ШД латчем, а уже из него писать в ОЗУ. Чем щелкать СЕ дело не в дело, да еще и срезая запасы по времени обращения. Как такой вариант?
У меня ШД на память и так защёлкивается латчем (самописный аналог АП6, готового в кактусе не было):

-- altera vhdl_input_version vhdl_2008

library ieee;
use ieee.std_logic_1164.all;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity bidir_buf is
port (
A : inout std_logic_vector(7 downto 0);
B : inout std_logic_vector(7 downto 0);
AB : in std_logic;
OEn: in std_logic;
clk: in std_logic
);
end entity;

architecture rtl of bidir_buf is

begin

process (clk)
begin
if (rising_edge(clk)) then
if (OEn = '1') then
A <= (others => 'Z');
B <= (others => 'Z');
else
if (AB = '0') then
B <= (others => 'Z');
A <= B;
else
A <= (others => 'Z');
B <= A;
end if;
end if;
end if;
end process;

end rtl;
Тактирую я его очень высокой частотой (100МГц и более), так что он точно успевает.
Буду "ковырять" позже, попробую разные варианты...
А вот участок формирования сигналов для памяти (https://image.prntscr.com/image/RphgczvrQr2oCZFsM0DFGg.png).
MA16 - это МА16 из ПРОшки. MRDn, MWEn - чтение и запись для памяти, ест, формируются как в ПРОшке, только без различий по банкам - это формируется здесь, в зависимости от типа памяти (для 16 битной - MA16 выбирает половинку слова, а MA19 выбирает чип, для 8 битной - MA16 выбирает чип). clk_mem - тактирование для OnChipMemory, сейчас 250МГц.

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

По поводу памяти - есть Verilog/VHDL модель от производителя (https://www.alliancememory.com/datasheets/as7c4098a/), можно понять внутреннюю логику работы. Как понимаю, она примерно одинакова для всех SRAM.

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

По записи - надо как минимум восходящий фронт WE делать более ранним, поскольку запись идёт именно по нему - а там адрес ещё защёлкнут старый, но на данных защёлка уже переключилась, из-за чего и возможен мусор.
Аналогично и с нисходящим фронтом WE - внутри защёлкнут адрес видео-ячейки, появляется WE и данные для записи, МС успевает их записать. Более медленная память просто не успевает этого сделать.
Всё это моё ИМХО, просьба поправить ошибки - выводы сделал на основании анализа кода модели памяти.

Error404

15.04.2018, 12:00

andreil

15.04.2018, 19:47

АП6 это шинник, он когда открыт траслирует весь мусор как есть. Латч - это ИР22, там есть защелкивание управляемое по входу загрузки. Как вариант ИР23, но на ней будет бОльшая задержка из-за того что это честный регистр а не латч.
На момент активации этого элемента это не важно - ШД со стороны процессора уже давно стабилизированна, мусора там нет.
Я говорю о мусоре в момент ухода записи от ЦП, когда в памяти на адресе ещё висит адрес записи, а на данных висит Z-состояние - данные от процессора уже "ушли", а новые ещё не прочитались.
А память во время записи по фронту любого из сигналов (данных, адреса, CE, WE) пишет новые данные:

always @(posedge WE_n ) begin
WE_dly <= WE_n;
read_WE_n_start_time <=$time;
if (($time - write_WE_n_start_time) >=twp1)
begin
if ( (CE_n == 1'b0) && ( ($time - write_CE_n_start_time) >= tcw) )
begin
Address_write2 <= Address_write1;
dummy_array0[Address_write1] <= dataIO1[7:0];
dummy_array1[Address_write1] <= dataIO1[15:8] ;
activate_webar <= 1'b1;
end
else
activate_webar <= 1'b0;
end
else
begin
activate_webar <= 1'b0;
end
end

always@(CE_n or WE_n or OE_n or Address or DataIO )
begin
if ((CE_n==1'b0) && (WE_n ==1'b0))
begin
Address_write1 <= Address;
Address_write2 <= Address_write1;
dataIO1 <= DataIO;
dummy_array0[Address_write1] <= dataIO1[7:0] ;
dummy_array1[Address_write1] <= dataIO1[15:8] ;
end
end

Error404

15.04.2018, 19:59

А память во время записи по фронту любого из сигналов (данных, адреса, CE, WE) пишет новые данные:

Ну и правильно, и будет писаться мусор если писать его по фронту любого сигнала вместо того чтобы писать по сигналу WR процесссора который гарантированно внутри периода присутствия на ШД данных. Не пойму - в чем вопрос? И не пойму для чего так сделано.

andreil

15.04.2018, 20:20

Так сделано для последовательной записи, как понимаю - зажал управление с данными и щёлкай адресом только.
Глянул для CY7C1049B - всё аналогично по диаграммам.

Error404

15.04.2018, 20:57

Так сделано для последовательной записи, как понимаю - зажал управление с данными и щёлкай адресом только.
Глянул для CY7C1049B - всё аналогично по диаграммам.

Какой такой последовательной записи? Сейчас речь об Орионе, где там такое? Там нет блиттера (а на слух это только на него и похоже), там все пишется так:
единичная запись (только такая и есть) = выставил адрес (это делает CPU) -> выставил данные (это делает CPU) - выдать сигнал WE (это делашь ты от сигнала WR CPU ) - снять данные (это делает CPU) - снять адрес (это делает CPU)
CE может быть всегда выбран т.к. отсечка от шин делается регистрами и шинниками (если схема осталась 1:1 от Ориона).

andreil

15.04.2018, 20:59

Какой такой последовательной записи? Сейчас речь об Орионе, где там такое? Там нет блиттера (а на слух это только на него и похоже), там все пишется так:
единичная запись (только такая и есть) = выставил адрес (это делает CPU) -> выставил данные (это делает CPU) - выдать сигнал WE (это делашь ты от сигнала WR CPU ) - снять данные (это делает CPU) - снять адрес (это делает CPU)
CE может быть всегда выбран т.к. отсечка от шин делается регистрами (если схема осталась 1:1 от Ориона), которые в принципе можно и сократить.
Я про саму память говорю, а не конкретный случай.
У меня пока что проблема без отсечки по CE, попробую с ней сделать вариант и посмотрю на результаты.

Error404

15.04.2018, 21:07

асинхронная SRAM на то и асинхронная, что там всё управление в полтора сигнала, и делается как угодно.

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

И у нее цикл записи/чтения обычно совпадает с тем что я написал для CPU и ничем не отличается от чтения/записи в любые МСХ-регистры или регистры каких-то БИС типа, к примеру, ВВ55

andreil

15.04.2018, 21:10

Сейчас вот собрал версию без задержки WE на 20нс - и на экране сразу на порядок больше мусора стало. Вернул назад - мусор есть только во время записи. Так что попробую ещё и в конце сделать отсечку, сейчас примерно так получается по таймингам:
https://image.prntscr.com/image/sLkpKJ1SQhmSfsLcWWfnWg.png
Думаю, как бы этот фронт укоротить.

andreil

17.04.2018, 10:21

И всё-таки надо память делать на отдельной подплате - там сразу и ОЗУ и ПЗУ и ROM-диск поместятся.
Сейчас лепить на оставшееся место видеоплаты память означает сразу загнать себя в 4 слоя, поскольку монтаж будет очень плотным. А если их разделить, то и места станет намного больше, как раз для питания хватит.
И подумываю - может на скоростной памяти сэмулировать двухпортовую память? То есть разместить там свой кварц для тактирования (скажем, на 50МГц) и кусок логики для такого фокуса. Подобное решение как раз можно в текущей схеме на ПЛИС проверить.

Error404

17.04.2018, 13:11

andreil

17.04.2018, 13:17

На еще более скоростной? Как я понимаю, CY7C1049B это 12..15нс (когда по расчетам проходила 55нс), да и та что-то не работает.
Нет, на этой как раз. Сейчас прикинул на бумажке, получилось при такте 100МГц полный цикл в 80нс, из них 2 цикла обращения к памяти по 20нс. Попробую такое смоделировать.
Пока что, в теории, обращения к памяти идут циклом. То есть будет стоять синхронный счётчик для тактов и мелкая логика для управляющих сигналов. Адреса и данные для записи защёлкиваются на входе, а прочитанные данные - на выходе.
Логики будет достаточно много, но в основном это будут регистры на данных (раздельные линии чтения и записи).

Error404

17.04.2018, 13:26

А дорогое удовольствие. CY7C1049B на Али в среднем (в партии от 5 штук) по over 200руб за штуку.

andreil

17.04.2018, 23:08

Вот, как-то так пока что получилось (https://image.prntscr.com/image/yDZmWhCnSqeuYZ3c9jBydg.png).
Порт А - процессор, порт B - видео. Адреса показаны не полные, ругался кактус на синтезе. Но суть уже видна.
Для проверки таймингов временно затактировал от частоты 20МГц, поэтому фронт записи такой "куцый" получился - по факту он будет растянут минимум на 1 полный такт памяти при частоте процессора 10МГц.
Сигнал PS - Port Selector, по нему переключаются адресные мультиплексоры и буферы.
Сигналы SCE и SWE становятся активными только при стабильных адресе и данных по обеим сторонам - до них и после них (на крине изменение адреса - это процессор просто уже "перещёлкнул его, а заводить защёлки ещё и на адреса - жирнота уже, хотя может и придётся).
А вот и схема на данный момент (https://image.prntscr.com/image/7_qDkl4GTNO-ajAUQoaatA.jpg).
Основную часть занимают мультиплексоры и триггеры с защёлками. Управляет всем зоопарком синхронный счётчик и половинка триггера - на нём выполнен счётчик селектора портов.

Применительно к Ориону - адресные мультиплексоры мигом перебрались сюда. Остальное - плата за двухпортовость.
Завтра буду тестировать на полной частоте и в штатном режиме, но теоретически должно заработать :) По факту - поменяю так, что бы заработало.

andreil

18.04.2018, 15:27

Двухпортовая память готова и работает вполне сносно.
На частоте процессора 10МГц видео-подсистема в худшем случае имеет 2 обращения к памяти за вывод пикселя, так что всё ОК.
Процессор спокойно пишет/читает.
Сейчас ещё оптимизирую сигналы и выложу схему.
И да - можно (и даже скорее всего и буду) делать эту память в виде самостоятельной платы. Конструктивно будет выполнено в виде узкой платы с разъёмами по сторонам платы - с каждой свой порт.
Пока что основная оптимизация - увеличение окна обращения к памяти, которое на данный момент составляет 20нс. Вызвано это было очень простым схемным решением, что бы не привносить лишние помехи.

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

По поводу памяти - нашел на алике сравнительно дешевую SRAM 5-вольтовую. Ищется на Алике по следующим наименованиям: CY7C1049 (https://www.aliexpress.com/item/1PCS-CY7C1049D-10VXI-CY7C1049D-CY7C1049-7C1049/32832431789.html), AS7C4098 (https://www.aliexpress.com/item/AS7C4098-15TI-AS7C4098-15TI/1093536006.html), AS7C4096A (https://www.aliexpress.com/item/5pcs-lot-AS7C4096A-12TCN-AS7C4096A/32281198826.html).
ИМХО, $3 за корпус ещё не так-то и много, а первые 2 лота вообще при покупке от 10шт стоят около $2.

andreil

18.04.2018, 22:51

Итак, вот готовая схема двухпортовой памяти (https://image.prntscr.com/image/8vl6mDmQTqKzFfk2XifxmQ.jpg).
Во вложении - краткая временная диаграмма.
Как писал ранее, PS - Port Selector. При лог. "0" выбран порт А (процессор), иначе - В (видео).
На диаграмме представлено два цикла обращения процессора - запись в первую половину памяти (MA16=0) и чтение из второй половины памяти (MA16=1).
Из оптимизаций - вместо половинки 7474 можно использовать цепочку из пары инверторов. Задача узла - задержать сигнал F[2] для формирования сигнала PS - достаточно нескольких наносекунд.
А вот как растянуть фронт сигнала SCE - надо думать. При его увеличении увеличиться и диапазон применяемых чипов памяти. Главное - что бы длительность SCE была меньше длительности PS (особенно на восходящем фронте SCE, иначе непредсказуемое поведение).
Защёлки на входные сигналы порта А ставить пришлось для стабилизации - во избежание исчезновения старого состояния прямо в момент обращения к памяти (память и процессор между собой асинхронны, не забываем).
Если делать запись и из порта B, то нужно ещё три таких же защёлки на 74273-их. Если нет - можно убрать 2 латча с записи этого порта.
Думаю, в виде платы оно всё разведётся очень даже красиво :)

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

Кто в курсе цен на двухпортовую SRAM объёмом 256х16 или 512х8?
У меня пока что получается около $3+$2=$5 за детали для текущего решения, не в курсе сколько одночиповые стоят. Нашел только в начале темы - 64Кх16 - около $10 за корпус. Уже выигрыш какой-то есть.

Error404

18.04.2018, 23:01

Судя по тому, что 16Kx8 DPSRAM стоит примерно 15$ если брать поштучно, то одна 512Kx8 будет стоить 100$ и при этом иметь корпус с 96 выводами, а 256Kx16 будет уже 120$ за штуку (т.к. корпус там будет уже со 144 выводами) :) :)

andreil

18.04.2018, 23:04

Если плата востребована, могу выпустить отдельным девайсом, тут вообще ничего сложного нет. Только модель надо "вылизать" по таймингам.

LeoN65816

19.04.2018, 08:11

Кто в курсе цен на двухпортовую SRAM объёмом 256х16 или 512х8?

1. 512Kх8 - таких вообще не выпускали...
2. 256Кх16 - таких тоже не выпускали. Есть 256Кх18, но они трёхвольтовые, редкие и дорогие (IDT70V631).
3. 512 килограмм двухпортовки в Орионе ни к чему... Только первые 128К нужно окучить двухпортовкой, причем с организацией 64Кх16 (по 4 экранных страницы битмапов из основного банка и аттрибутов из дополнительного банка одновременно), остальное накрывается обычной сраминой. Однако пятивольтовые IDT7028 и CY7C028 на али и ибэе довольно редки и дороги... Есть шанс попытать удачу на Купинатао (https://kupinatao.com/pages/search_results.aspx?keyword=idt7028&cid=0&&sort=price%3Aasc).

PS. В своем проекте я пользую трёхвольтовую двухпортовку IDT70V28 и трёхвольтовую же срамину IS61WV20488 в качестве дополнительной памяти, так как и проц у меня 1.8-5V, а шина на слотах расширения юзается через трансляторы 74ALVC164245.

Error404

19.04.2018, 12:18

Есть шанс попытать удачу на Купинатао (https://kupinatao.com/pages/search_results.aspx?keyword=idt7028&cid=0&&sort=price%3Aasc).

Я как-то попробовал заказать на Купинатао как раз двухпортовки, но они кинули. Т.е. деньги с карты списали, а потом такие "ой, а микросхем-то нету, ваши денежки на счете, а зачтенные бонусы обратно не возвращаются", и вывести те деньги со счета обратно в кэш - целая история (требуется подтверждение из ФСБ и налоговой). Пришлось купить на них что-то ненужное, это оказалось проще. Ну и фирменная фишка Купинатао - доставки стоимостью менее 7$ просто нет, дороже выбрать можно.

Я давно присматриваюсь к двухпортовкам DRAM, у меня их есть на платах с игровых автоматов (надо сдувать) - там в видеомодуле быстродействующие чипы 256Кх16 ЕМНИП (в корпусах SOJ с приемлимом количеством ног порядка 40 т.к. DRAM т.е. с мультиплексированным адресом), но не нравится что надо заморачиваться со схемой регенерации (хотя и регенерация там целыми строками, т.е. возможно хватило бы встроенного регенератора Z80).

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

Если эмулированная двухпортовка будет покрывать все ОЗУ, то сравнительно малой кровью можно сделать фоновый аппаратный блиттер :)
Но это конечно уже будет не Орион.

andreil

20.04.2018, 08:26

Если эмулированная двухпортовка будет покрывать все ОЗУ, то сравнительно малой кровью можно сделать фоновый аппаратный блиттер :)
Но это конечно уже будет не Орион.
Покрывает всю, естесно.

Раздумываю над организацией разделения памяти - оставить на видео-части двухпортовку 64К*16, а основную отдать только процессору...
Проблема в работе теста для ПРОшки. На OnChip памяти (для аналогии взял двухпортовую) всё идеально отрабатывает на тесте. А с мои вариантом - последние три столбца не заливаются. Сигналы в обоих вариантах абсолютно одинаковые используются.
Посмотрел анализатором - в обоих случаях запись в цикле идёт до адреса 0xECFF. дальше пауза и новый цикл. Но у нас же видеопамять до 0xEFFF! Вообще нихрена не понял :(
Картинка 1 (https://image.prntscr.com/image/f1YYNVnWRbyC-jY_2FXAVg.png)
Картинка 2 (https://image.prntscr.com/image/hcvImoVFQN6WG_2KSO_iiA.png)

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

И вот так это смотрится на экране (https://yadi.sk/i/nbzFA9Os3Ub4pn).

Error404

20.04.2018, 12:24

Я давно присматриваюсь к двухпортовкам DRAM, у меня их есть на платах с игровых автоматов (надо сдувать) - там в видеомодуле быстродействующие чипы 256Кх16 ЕМНИП (в корпусах SOJ с приемлимом количеством ног порядка 40 т.к. DRAM т.е. с мультиплексированным адресом), но не нравится что надо заморачиваться со схемой регенерации (хотя и регенерация там целыми строками, т.е. возможно хватило бы встроенного регенератора Z80).

Вот такие у меня динамические двухпортовки ан платах от автоматов: TMS55160dgh (http://www.alldatasheet.com/datasheet-pdf/pdf/163428/TI/TMS55160-70DGH.html?) 5-вольтовые TTL-совместимые.
Таки 256Кх16 (с возможностью доступа и побайтно), но наворочено в них - кошмар. И разные режимы построчного доступа, и сериализация (готовый сдвиговый регистр для видеовывода уже в ОЗУ ?) и разная регенерация, и все это в моих глазах только запутывает от понимания как там можно по простому ее регенерировать и заюзать например совместимо с твоей платкой квази-DP ОЗУ.

andreil

20.04.2018, 12:42

Вот такие у меня динамические двухпортовки ан платах от автоматов: TMS55160dgh (http://www.alldatasheet.com/datasheet-pdf/pdf/163428/TI/TMS55160-70DGH.html?) 5-вольтовые TTL-совместимые.
Таки 256Кх16 (с возможностью доступа и побайтно), но наворочено в них - кошмар. И разные режимы построчного доступа, и сериализация (готовый сдвиговый регистр для видеовывода уже в ОЗУ ?) и разная регенерация, и все это в моих глазах только запутывает от понимания как там можно по простому ее регенерировать и заюзать например совместимо с твоей платкой квази-DP ОЗУ.
С такой памятью в нашем случае обвес будет примерно равнозначен эмулятору двухпортовки :)
И да - можно попробовать в эмуляторе сделать 3-х вольтовую память, с логикой вроде бы ничего сложного нет особо, только данные надо буферизировать, но это делается 1 корпусом. А на входных сигналах (адреса и управление) нет Z-состояния, так что примерно совпадает по уровням, только диоды навесить для снижения верхнего порога.

LeoN65816

20.04.2018, 14:22

и сериализация (готовый сдвиговый регистр для видеовывода уже в ОЗУ ?)
Для битмапа может и подойдет, но, опять же, в Орионе по 8 точек, а не по 16...
А для аттрибутов сериализатор с какого боку?
А стоимость и доступность смотрели?
А какой геморрой с обвязкой, подумали?
И чем это чудо-чудное лучше натуральной DPSRAM?
Бросайте вы эту траву... ;)

Error404

20.04.2018, 15:50

Для битмапа может и подойдет, но, опять же, в Орионе по 8 точек, а не по 16...
А для аттрибутов сериализатор с какого боку?
А стоимость и доступность смотрели?
А какой геморрой с обвязкой, подумали?
И чем это чудо-чудное лучше натуральной DPSRAM?
Бросайте вы эту траву... ;)

Обвязку там надо только для правильной регенерации и мультиплексор для адресных ног. Сдвиговый выходной регистр можно не использовать, там и прямые выходы есть (для каждого бита есть как выход Sn - сдвиговый, так и DQn - обычный прямой вход/выход). Да вот это "только" выльется в приличную схему, или надо приспосабливать уже имеющуюся журнальную орионовскую регенерацию от которой Андрей ушел при переходе на SRAM (а по факту родил еще больше корпусов для имитации двухпортовости). Собственно, грандиозный плюс у тех чипов только в том, что они у меня есть. :) Как есть (и много) обычной СРАМ на 50-70нс. И я очень надеялся, что ее и можно будет в итоге применить. А вот быстрой и при том ёмкой (512кб) SRAM или реальной двупортовой SRAM нету.

andreil

20.04.2018, 16:38

Обвязку там надо только для правильной регенерации и мультиплексор для адресных ног. Сдвиговый выходной регистр можно не использовать, там и прямые выходы есть (для каждого бита есть как выход Sn - сдвиговый, так и DQn - обычный прямой вход/выход). Да вот это "только" выльется в приличную схему, или надо приспосабливать уже имеющуюся журнальную орионовскую регенерацию от которой Андрей ушел при переходе на SRAM (а по факту родил еще больше корпусов для имитации двухпортовости). Собственно, грандиозный плюс у тех чипов только в том, что они у меня есть. :) Как есть (и много) обычной СРАМ на 50-70нс. И я очень надеялся, что ее и можно будет в итоге применить. А вот быстрой и при том ёмкой (512кб) SRAM или реальной двупортовой SRAM нету.
Я сейчас пытаюсь уйти от двухпортовости, как раз. Где-то накосячил при отделении памяти, в итоге в тесте всё ОК, а вот ПРОшная менюшка приветствует синим экраном :)

OrionExt

21.04.2018, 20:24

andreil

21.04.2018, 22:53

Вот так сразу с коня. Все это интересно конечно. Предлагаю автору задуматься о 2-портовой (одно портовой) памяти для MSX в разрезе VDP. Вот интересная задача) А то авторы зажмакали в 90г. этот момент. А работало ли оно? Теперь можно проверить=).

У меня просто времени не хватает (в одно лицо) все проверить (и ума), занят (как минимум) переселением.
Чутка не понял - попытаться реализовать 2 банки памяти? 1 для видео, двухпортовую, и 1 для CPU? Такое можно сделать, только двухпортовая даже 64К*16 стоит достаточно много даже сейчас...

andreil

24.04.2018, 16:19

Error404

24.04.2018, 18:57

И всё-таки вынесу память на отдельную плату, иначе видеочасть ещё не скоро увидит свет...
По псевдографике - надо окончательно определиться с портами и схемой.
Бит 6 порта FA отвёл под активация ПДГ, биты 2-5 этого же порта отвечают за выбор шрифта.
Биты 5-7 порта F8 отвечают за выборку байта для символа - на мультиплексор заводятся вместо Y0-Y2 (сигналы P0-P2 на схеме).
Вот схема (https://andreil.by/orion/orion_video.pdf) на данный момент, фрагмент с разъёмами пока не затрагивал - надо поменять значительно, уберутся почти все сигналы от процессора. Думаю отойти от "корзины" и делать "бутербродом", с разъёмами между платами "по этажам".

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

Под местом для ПЗУ думаю сделать мелкие перемычки для данных - если не нужен ПГД, тогда просто по капле припоя на каждую.

А чего на схеме опять 28C256 (вместо ранее обсуждавшейся W28C512 где на A15 заводится PGD чтобы младшей половиной ПЗУ с прошивкой "вход=выход" делать передачу данных 1:1 для исключения лишних коммутаторов - т.е. ПЗУ всегда между ОЗУ и выходным сдвиговым регистром)? Не понятно как тут выключается текстовый экран (исключается текстовое ПЗУ). За счет использования OE ПЗУ и дополнительного буфера с Z (без которого можно обойтись)? В схеме где одни шины быстро сориентируется только автор.

И дефицитные ИР33/ИР37 предлагаю менять на ИР22/ИР23 соответственно. Или они с какой-то спец. целью там? Даже импортные аналоги для ИР33/ИР37 (574 и чего-то еще) дороже и куда менее распространены чем 373/374. ИР35 конечно тоже не сахар, но их нечем заменить (других таких более-менее доставаемых регистров со сбросом не знаю).

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

И вместо АП13 (what is this???) ставить АП3..АП5 (они дешевы и их у каждого есть в закромах)

andreil

24.04.2018, 19:10

А чего на схеме опять 28C256 (вместо ранее обсуждавшейся W28C512 где на A15 заводится PGD чтобы младшей половиной ПЗУ с прошивкой "вход=выход" делать передачу данных 1:1 для исключения лишних коммутаторов - т.е. ПЗУ всегда между ОЗУ и выходным сдвиговым регистром)? Не понятно как тут выключается текстовый экран (исключается текстовое ПЗУ). За счет использования OE ПЗУ и дополнительного буфера с Z (без которого можно обойтись)? В схеме где одни шины быстро сориентируется только автор.

И дефицитные ИР33/ИР37 предлагаю менять на ИР22/ИР23 соответственно. Или они с какой-то спец. целью там? Даже импортные аналоги для ИР33/ИР37 (574 и чего-то еще) дороже и куда менее распространены чем 373/374. ИР35 конечно тоже не сахар, но их нечем заменить (других таких более-менее доставаемых регистров со сбросом не знаю).

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

И вместо АП13 (what is this???) ставить АП3..АП5 (они дешевы и их у каждого есть в закромах)
1) Мой косяк, не обновил сей момент.
2) ИРки тут непринципиальны, это да.
3) 74541 - взял "что было" из библиотеки :) Вообще пофиг что будет, можно даже на неинвертирующих элементах сделать.

andreil

26.04.2018, 16:26

ПО поводу памяти в текущей схеме - при текущем пиксельклоке и прочем-прочем для вывода 2-х плоскостей видеопамяти по 16 бит чипы со временем доступа 75нс проходят впритык.
Сейчас вот взял самый худший случай и посмотрел по таймингам - получается около 78нс на чтение данных. А если учесть все промежуточные задержки (переключение адресов, защелки на данных), то уже в пролёте.
Частота выборок - 300МГц:
https://image.prntscr.com/image/pQy0OnizRlKpt5I5rSFOgg.png

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

И да - сейчас полностью переделываю схему обращения к этим плоскостям - ПРОшный вариант годится только если обе подсистемы в одном клоковом домене, а у нас разные, в итоге тайминги не выдерживаются вообще.

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

Вот предварительный вариант 100% синхронного формирователя всех сигналов для работы с видеобанками:
https://image.prntscr.com/image/tf9_6QCTSg2n7hDcelAFEg.png
И вот диаграмма работы:
https://image.prntscr.com/image/XUyEHOnaTc_C3AvStQVu3Q.png
По положительным фронтам сигналов cc1 и cc3 идёт запись половинок видеоданных. Так же сигнал cc1 используется как переключатель банок видеопамяти (по схеме ПРО - это сигнал 44 от ТГ, коммутирующий сигналы 121 и COL1/COL2).
Если есть предложения по оптимизации данного узла - буду готов выслушать.
Сам я сейчас вижу пару косяков, но общий принцип понятен.

andreil

01.05.2018, 00:05

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

andreil

02.05.2018, 00:03

Кручу-верчу организацию памяти здесь и уже понятно, что надо делать псевдо-двухпортовую память для конкретно данного случая (и схожих с ним).
Проблема, собственно, заключается в асинхронности процессора и видео - в ПРОшке это всё тактировалось от 1 кварца.
Если в Орионе к частоте процессора ничего не привязано, то можно её и изменить, но это будет уже не Орион :) Исходить в таком случае надо от частоты 25МГц и получаем частоты 3.125/6.25/12.5МГц...
А для самой памяти придётся делать схему с удвоением частоты на 2-х инверторах и XOR'е для получения 50МГц - необходимо для организации "двухпортовости".
Сейчас ещё попробую текущий вариант покрутить, не меняя частоты, но корректной работы, без конфликтов процессора и видео, не получается - во время работы тесты видно пропуски при массовой записи в память.

Error404

02.05.2018, 10:13

andreil

02.05.2018, 11:22

От тактовой частоты в Орионе ничего не зависит такого за что стоило бы цепляться.

В соседнем разделе лет десять назад был проект hardwareman-а где Специалист на 8080 и Z80 (можно было ставить как тот так и другой) и РУ5 (тут не помню, может статика там была?) нативно выводил на VGA (тайминги были соответствующие). Может оттуда "списать" как надо? А то выходит какой-то монстр (по требуемым компонентам) с довольно скромными преимуществами (2-3 раза по скорости совершенно теряются если для этого надо память работающую на на 50Мгц)
Если убрать переключение видеорежимов (384/512, широкий экран), то схема видеотракта будет такого же уровня сложности.
В МХ2 используется видеорежим 800x600@60Hz с удвоением пикселей - пиксельклок 40МГц. Но это 4:3, а где сейчас найти такой монитор? Везде 16:9, так что надо реализовывать и такой видеорежим, а значит нужно подобрать оба с одинаковым пиксельклоком. Я таких нашел только 2 (http://tinyvga.com/vga-timing):

VGA 640x350@70 Hz (pixel clock 25.175 MHz) (http://tinyvga.com/vga-timing/640x350@70Hz)
VGA 640x480@60 Hz Industry standard (pixel clock 25.175 MHz) (http://tinyvga.com/vga-timing/640x480@60Hz)

И да, расширенный экран Ориона с удвоением пикселей НЕ ВЛЕЗЕТ ни в один из упомянутых видеорежимов - напомню, что там получится картинка размером 512х256 пикселей (да даже 480х256 не влезет уже). Тут и стандартный экран (384х256) впритык на 800х600 поместится с удвоением-то.

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

Если я не прав, и есть 2 подходящих по пиксельклоку видеорежима - ткните в их времянки, я не находил такового...

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

А по памяти - я не говорил, что она будет работать на 50МГц ;) Эта частота нужна для управляющей логики, что бы максимизировать время доступа. По факту получается 2 такта на обращение к памяти, то есть 25МГц (40нс).

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

Я вот подумываю о применении GAL в видеотракте - сократит логику до минимума, если времянки позволят.

OrionExt

02.05.2018, 14:11

Вот апять не понятны шатания автора (надо делать реал). Дальше - это мое личное мнение.

Очень полезно для меня выходит и подтвердило (были попытки, месяца 2 мучался, и просто забил), что сделать Орион-128 с разбросом частоты 20..2,5мГц очень маловероятно на стандартной логике (или как будет угодно на FPGA с простым подходом).
И не важно, на какой видео-выхлоп (VGA лежит в рамках - LS, хоть и с натягом.) это делается, соль в другом=)

Кстати, вот та макетка с дешевым FPGA и прикрученным (МГТФ) 3.3В ОЗУ выдавала аж 50Мгц для простого CP/М компьютера.

andreil

02.05.2018, 14:35

Тут проблема не в помехах на линиях данных/адреса/прочих, а асинхронность частей.
Процессор у нас тактируется на 2.5/5/10Мгц, а видео - 25МГц. В итоге у нас нет 100% окна, как в ПРО - что бы в определённый такт открыть доступ процессора к памяти по необходимости и потом через пару тактов назад на видео переключиться. В текущем варианте обращение процессора к памяти может произойти абсолютно в любой момент относительно видеовывода.
Посмотрите на ПРО - триггеры D28.2/D115.2 как раз отвечают за арбитраж памяти и происходит это на строго фиксированных тактах (конкретно - по сигналу 42).

В общем, буду крутить что получится, к сожалению. Не умею я такие вещи расписывать толком...

А по реалу - у меня проц и память и так реальные, только внутренняя логика на данный момент в ПЛИС, что бы её обкатать.

Error404

02.05.2018, 20:04

Тут проблема не в помехах на линиях данных/адреса/прочих, а асинхронность частей.
Процессор у нас тактируется на 2.5/5/10Мгц, а видео - 25МГц. В итоге у нас нет 100% окна, как в ПРО - что бы в определённый такт открыть доступ процессора к памяти по необходимости и потом через пару тактов назад на видео переключиться. В текущем варианте обращение процессора к памяти может произойти абсолютно в любой момент относительно видеовывода.

Очень запросто для тактирования ЦПУ с кратностью к пиксельклоку можно использовать такие частоты:
25/8=3.125
25/4=6.25
25/2=12.5

Повторюсь, на Орионе не было критичности к частоте ЦПУ, и 3.125 будет вполне достаточно чтобы ордосовские игры не сильно были быстрее оригинала (+ поправить константу автоповтора клавиатурной п/п Монитора), и для игр ZX хватало (которые не синхронизируются по кадровому гасящему СИ). А вот которые синхронизируются по КГСИ, то тут ХЗ (у нас ведь будет 60Гц а не 50Гц), но навскидку особенных проблем (кроме чуть более быстрого проигрывания AY и убегания аппаратных часов, я не вижу). А если получится каждый шестой ГКСИ не доводить до INT процессора, то и проблемы никакой не будет.

TomaTLAB

02.05.2018, 20:43

Либо взять гену на 50МГц и получить с него нужную сетку, хоть 50/25/12,5/6,25/3,125 хоть 50/10/5/2,5. Городить огород с удвоением не вижу никакого смысла.

andreil

02.05.2018, 22:06

Очень запросто для тактирования ЦПУ с кратностью к пиксельклоку можно использовать такие частоты:
25/8=3.125
25/4=6.25
25/2=12.5

Повторюсь, на Орионе не было критичности к частоте ЦПУ, и 3.125 будет вполне достаточно чтобы ордосовские игры не сильно были быстрее оригинала (+ поправить константу автоповтора клавиатурной п/п Монитора), и для игр ZX хватало (которые не синхронизируются по кадровому гасящему СИ). А вот которые синхронизируются по КГСИ, то тут ХЗ (у нас ведь будет 60Гц а не 50Гц), но навскидку особенных проблем (кроме чуть более быстрого проигрывания AY и убегания аппаратных часов, я не вижу). А если получится каждый шестой ГКСИ не доводить до INT процессора, то и проблемы никакой не будет.
Вот, это мне и нужно было.
Просто я с софтом особо дел не имел, потому и не в курсе по поводу подобных привязок.
Попробую на выходных сделать с такой частотой - завтра-послезавтра еду по делам, не до того будет...

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

Кстати, ещё вопрос по железу, на перспективу - что на счёт использования GAL вместо кучи мелкой логики? При их использовании, в идеале, синхрогенератор для видео "схлопнется" в 6 счётчиков и 2 GAL'ки.

andreil

03.05.2018, 00:44

Да, сделал части синхронными - и проблем с памятью почти нет. Осталось только фронт обращения к памяти укоротить до 80нс. А так - вроде бы даже работает.
Проблемы мелкие есть, но только из-за того, что циклы не подогнал ещё к таймингам реальным.

Denn

03.05.2018, 11:49

Повторюсь, на Орионе не было критичности к частоте ЦПУ

Самое фатальное - опрос клавиатуры ((
Также приходит на ум организация программных задержек при работе с никому не нужной 1818ВГ93, но это не столь фатально, конечно.

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

В МХ2 используется видеорежим 800x600@60Hz с удвоением пикселей - пиксельклок 40МГц. Но это 4:3, а где сейчас найти такой монитор? Везде 16:9, так что надо реализовывать и такой видеорежим, а значит нужно подобрать оба с одинаковым пиксельклоком. Я таких нашел только 2 (http://tinyvga.com/vga-timing):

VGA 640x350@70 Hz (pixel clock 25.175 MHz) (http://tinyvga.com/vga-timing/640x350@70Hz)
VGA 640x480@60 Hz Industry standard (pixel clock 25.175 MHz) (http://tinyvga.com/vga-timing/640x480@60Hz)

И да, расширенный экран Ориона с удвоением пикселей НЕ ВЛЕЗЕТ ни в один из упомянутых видеорежимов - напомню, что там получится картинка размером 512х256 пикселей (да даже 480х256 не влезет уже).

При удвоенной точке по обеим координатам неродное разрешение смотрится вполне нормально на любом мониторе. С режимом 512х256 имхо можно не заморачиваться..

Error404

03.05.2018, 13:07

Самое фатальное - опрос клавиатуры ((
Также приходит на ум организация программных задержек при работе с никому не нужной 1818ВГ93, но это не столь фатально, конечно.

С ВГ93 должно нормально прокатить увеличение частоты, там критично наоборот - если вдруг будет не хватать (2,5М это минимум на котором возможно прочитать сектора 5х1024), с любой схемой Турбо ВГ нормально сочеталась на известном мне софте.

А с клавиатурой надо будет или поправить константу автоповтора в Мониторе, или просто привыкнуть. Даже на старых схемах 3,9М (Турбо 5М с Wait) было терпимо без исправления константы автоповтора, а этот режим в сравнении с штатными 2,5М был заметно быстрее нового получающегося 3,125М (25/8). Что до более скоростных режимов турбирования новой платы (25/4=6.25, 25/2=12.5), то их можно использовать софтом, который опрос клавы делает в привязке к INT50Гц (так например делают многие игры портированные на Орион от ZX, или консольный драйвер CPM) и там уже это не будет критично (или в более скромном варианте - софт может ставить другие константы автоповтора).

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

Denn

03.05.2018, 13:54

С ВГ93 должно нормально прокатить увеличение частоты, там критично наоборот - если вдруг будет не хватать (2,5М это минимум на котором возможно прочитать сектора 5х1024)

ЕМНИП, там история такая. После выдачи команды (позиционирования или вообще всех), делается программная задержка, т.к. ВГ93 нужно некоторое время, чтобы "схватить" команду. Если сразу после выдачи команды идти проверять рег. статуса, то случаются некорректные вылеты. Вариант с ожиданием флага занятости на практике почему-то не всегда прокатывает, работает именно небольшая задержка.

andreil

03.05.2018, 14:41

При удвоенной точке по обеим координатам неродное разрешение смотрится вполне нормально на любом мониторе. С режимом 512х256 имхо можно не заморачиваться..
Точно можно выкинуть расширенный экран? Тут многие наоборот, просят именно его :)

Denn

03.05.2018, 15:01

andreil

03.05.2018, 16:06

andreil, "широкоэкранные" мониторы хороши разве что для просмотра киношек, и то там 16:9 (=1,7), а тут диспропорция аж в 2 раза и ни разу не кино. Какой смысл в такой картинке?
Потом, стандартное расположение экранной области (включается по-умолчанию при сбросе) с C000h, т.о. "киношный" экран своими 16 Кб сжирает всё непереключаемое ОЗУ ПРК и залезает на ПЗУ Монитора. Неудобный он, что аппаратно, что программно.
Имхо, неразумная плата за лишние 16 символов в в строке. Используется только в PRODOS на Орионе-ПРО. Если упираться в спортивный интерес, то поддержать можно, а практически смысла не вижу.
Ну, если оставить только 384х256 и поддержку широкого экрана, то приличная часть логики сразу исчезает:
https://image.prntscr.com/image/WMfgD4zUQ7_gHtKVxbWMMA.png
Жаль, что счётчики не уменьшить, разве что по вертикали можно оптимизировать, выкинув последние 2 разряда и заменив их ТМкой.

Error404

03.05.2018, 16:35

Потом, стандартное расположение экранной области (включается по-умолчанию при сбросе) с C000h, т.о. "киношный" экран своими 16 Кб сжирает всё непереключаемое ОЗУ ПРК и залезает на ПЗУ Монитора. Неудобный он, что аппаратно, что программно.
Имхо, неразумная плата за лишние 16 символов в в строке. Используется только в PRODOS на Орионе-ПРО. Если упираться в спортивный интерес, то поддержать можно, а практически смысла не вижу.

Фигассе ты рубанул, прямо как приснопамятный barsik ("я не пользуюсь, поэтому общеизвестно(с) что это никому не нужно да и вообще неудобно"). :) К расширенному экрану пришли все кто реально использовал текстообработку на Орионе, причем не на ассемблере "в столбик" (где действительно достаточно и полэкрана - 40 от стандартных 80 символов о чем кстати barsik тоже мечтал в последних его постах - там и про достаточность 16 строк было и кварц на 9М чтобы "не плющить экран"), а работая с нормальной текстовкой где важны и количество символов и их достаточное качество (ширина знакоместа) - от чтения книг до ЯВУ с их сложными констукциями операторов. Поэтому примерно с 1993 года обкатывались разные варианты расширенного экрана (схема 400 точек, схема 480 точек, схема 512 точек), которые были поддержаны во всех релизах CP/M - московской, лениградской, Альтаир-Дос (питерской и владимирской), причем Орион-софт с его ПРО-ДОС тут были последними, позже всех, т.е. когда решение уже само себе пробило дорогу и не иметь его на борту уже было конкурентным недостатком (а не оттого что они любили текстообработку, ЯВУ или что-то там еще, как раз не особенно преуспели).

А в нашем случае, когда на борту еще алфавитно-цифровой дисплей (ценой всего трех микросхем) где ширина символа фиксирована в 8 точек, расширение экрана необходимо, иначе останемся с 48 символами в строке. Редакторов под такой режим в CP/M тоже было (например MED Бутылкина), но они были неудобны - не видно строк (мало символов), да еще и большинство было написано по-любительски - редактировались только файлы влезающие в память вместе с редактором. А с 64 символами уже повеселее. Все нормальные редакторы (файлы любого размера, функциональные навороты) в CP/M заточены под количество символов в строке не менее 64 (а обычно 80), при этом сама строка обычно больше (скроллится горизонтально).

Экран при этом (таки придется отдавать под него 16к) удобно использовать с 0000h, при этом код запускается в другой странице памяти и экран не мешает, либо можно накрыть эту область окном диспетчера (хоть в ПРО, хоть в Z80 CardII) и иметь под код все 60к страницы 0.

TomaTLAB

03.05.2018, 17:11

"широкоэкранные" мониторы хороши разве что для просмотра киношек, и то там 16:9 (=1,7), а тут диспропорция аж в 2 раза и ни разу не кино. Какой смысл в такой картинке? Да ну! С нашими парнокопытными, когда хочется остаться в ТВ стандарте, вылезает ограничение на количество строк растра (и как не крути оптимально 256).
При этом хочется 80 символов в строке, с человеческим знакоместом в 8 точек. Ну и получаем разрешение 640х256, которое ну никак не похоже на 4:3, зато просто шикарно выглядит на телеке 16:9 :)

Denn

04.05.2018, 14:37

Фигассе ты рубанул, прямо как приснопамятный barsik ("я не пользуюсь, поэтому общеизвестно(с) что это никому не нужно да и вообще неудобно")

Я ничего не "рубил", а высказал своё мнение, как реальный пользователь Ориона. Не более того.

К расширенному экрану пришли все кто реально использовал текстообработку на Орионе

Насколько мне известно, все что-либо делающие для 8-биток уже давно пришли к написанию кода на писи. Там - ваще халява шире и длиннее ))
Не думаю, что сильно ошибусь, сказав, что на Орионе никто никогда не будет заниматься текстообработкой. Никто и никогда. Да и раньше не сильно занимались, как выясняется...

причем не на ассемблере "в столбик" (где действительно достаточно и полэкрана - 40 от стандартных 80 символов о чем кстати barsik тоже мечтал в последних его постах - там и про достаточность 16 строк было и кварц на 9М чтобы "не плющить экран"), а работая с нормальной текстовкой где важны и количество символов и их достаточное качество (ширина знакоместа) - от чтения книг до ЯВУ с их сложными констукциями операторов.

Я хотел бы посмотреть на живого человека, который собрал новодельный Орион ради чтения книг или ЯВУ.

Поэтому примерно с 1993 года обкатывались разные варианты расширенного экрана (схема 400 точек, схема 480 точек, схема 512 точек), которые были поддержаны во всех релизах CP/M - московской, лениградской, Альтаир-Дос (питерской и владимирской)

Я так понимаю, типа стандартом в итоге стал 512х256, который воплотили в ПРОшке. Точнее, не стандартом, а альтернативным вариантом, т.к. по-умолчанию всё равно включается базовый 384х256.

Ещё вспомним про быстродействие Ориона, которого для обслуживания родного 12 Кб экрана катастрофически не хватает (даже на ПРО@10 МГц).

А в нашем случае, когда на борту еще алфавитно-цифровой дисплей (ценой всего трех микросхем) где ширина символа фиксирована в 8 точек, расширение экрана необходимо, иначе останемся с 48 символами в строке.

Если делать текстовую экранную область, то там можно выдумывать всё, что угодно - это уже совсем другой компьютер получается. Вопрос только - для кого такое нужно?

...но они были неудобны - не видно строк (мало символов)

По сравнению с писи ;)
На спектруме 32 символа в строке, но танцорам это не мешает.

Все нормальные редакторы (файлы любого размера, функциональные навороты) в CP/M заточены под количество символов в строке не менее 64 (а обычно 80), при этом сама строка обычно больше (скроллится горизонтально).

Вот именно, горизонтальный скролл вполне решает "проблему" малого кол-ва символов в строке, если прямо так уж очень нужно.

Экран при этом (таки придется отдавать под него 16к) удобно использовать с 0000h, при этом код запускается в другой странице памяти и экран не мешает, либо можно накрыть эту область окном диспетчера (хоть в ПРО, хоть в Z80 CardII) и иметь под код все 60к страницы 0.

Все эти диспетчеры и прочие "турбы" - неплохой бонус, но это не базовый функционал Ориона, и затачивать строго под него ПО = оставить за бортом бόльшую часть пользователей.

Error404

04.05.2018, 15:36

А что, от наличия давно прижившихся расширений куда-то денется базовый функционал? Никуда не денется, 8080 правда там не будет. А что до новодела и кто что на них запускает, так большинство их включает после сборки один-два раза. И никакое ПО не пишет - ни на РС ни на реале. Давайте тогда просто делать проц+светодиод: помигал и счастлив, "лишнего" паять не надо.

Denn

04.05.2018, 16:39

Давайте тогда просто делать проц+светодиод: помигал и счастлив, "лишнего" паять не надо.

К тому и идёт вся эта ардуень ((

andreil

05.05.2018, 13:20

Ради пробы собрал в Протеусе схему для симуляции и обкатки GAL'ок.
Результаты неутешительные для схемы на рассыпухе - при использовании счётчиков 74S163 (как самых быстрых в библиотеке) и GAL с задержкой 15ns (что равносильно 2-м логическим элементам серии 74ACT) по таймингам идём уже впритык (внимание на восходящий фронт сигнала сброса, он идёт по линии А1, А0 - тактирование 25МГц):
https://image.prntscr.com/image/boliQbiORKOU8bezVO3Mng.png
Так что логику для счётчиков по X имеет смысл полностью впихнуть в GAL'ку для оптимизации скорости, а так же для упрощения платы - будет 1 корпус вместо штук 5 (даже при GAL в DIP, а логике в SOIC, уже имеем преимущество).
https://image.prntscr.com/image/bNuYpw1ERfqyBdpHjOy1xg.png

andreil

05.05.2018, 18:25

А вот и прошивка для первой GAL'ки, обкатанная в Протеусе:

Name orion_gal_test ;PartNo 00 ;
Date 05.05.2018 ;
Revision 01 ;
Designer andreil ;
Company ;
Assembly ;
Location ;
Device g22v10;

PIN [1,2,3,4,5,6,7,8,9,10] = [x0..9];
PIN 11 = sr16;
PIN 13 = wen;

PIN 23 = xresn;
PIN 22 = ben;
PIN 21 = bh3;
PIN 20 = bh5;
PIN 19 = bh;
PIN 18 = xle;
PIN 17 = hs3;
PIN 16 = hs5;
PIN 15 = hs;

xresn = !(x9 & x8 & x4 & x3 & x2 & x1 & x0);
ben = !(x2 & x1 & x0);
bh3 = !x9 & ((!x8 & x7) # (!x7 & (x6 # x5 # x4 # x3)) # (x8 & !x6 & !x5 & !x4 & !x3));
bh5 = (!x9 & (x8 # x7 # x6 # x5 # x4 # x3)) # (x9 & !x3 & !(x8 # x7 # x6 # x5 # x4));
bh = (!sr16 & bh3) # (sr16 & bh5);
xle = ((!sr16 & !x6) # (sr16 & x6)) & (x9 & !x8 & x7 & x5 & !x4 & !x3 & x2 & x1 & x0);
hs3 = x9 & !x8 & !x7 & ((x6 & !x5) # (x5 & (!x3 # !x4)) # (!x6 & x4 & x3));
hs5 = x9 & !x8 & ((!x7 & x6 & ((x4 & x3) # x5)) # (x7 & !x6 & (!x5 # !x4 # !x3)));
hs = wen $ ((!sr16 & hs3) # (sr16 & hs5));

Формирует все необходимые инмпульсы для видео по горизонтали. Схема - под спойлером выше.
По логике - решил обойтись без триггеров, поскольку с ними надо для каждого свой клок иметь. А так - куча логики, отрабатывающей строго по таймингам (проверял по логическому анализатору).
Буду писать аналогичную для горизонтали.

PS: Для макетки купил 10 GAL'ок, буду собирать программатор :)

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

А вот и прошивка для GAL по вертикали:

Name orion_gal_y ;PartNo 00 ;
Date 05.05.2018 ;
Revision 01 ;
Designer andreil ;
Company ;
Assembly ;
Location ;
Device g22v10;

PIN [1,2,3,4,5,6,7,8,9,10] = [y0..9];
PIN 11 = wen;
PIN 13 = bh;

PIN 23 = yresn;
PIN 22 = bl;
PIN 21 = vs;

yresn = !((!wen & y9 & y3 & y2) # (wen & y8 & y7 & y6));
bl = bh & !y8 & !y9;
vs = !((!y9 & y8 & !y7 & y6 & y4) & ((!wen & (y5 & y3 & !y2 & y1)) # (wen & (!y5 & !y3 & y2 & (y1 $ y0)))));
Здесь логики почти нет, но в схемном варианте требуется минимум 5 корпусов (половинка триггера берется из логики горизонтали).
Итого, на весь синхрогенератор получили 8 корпусов - 6 счётчиков и 2 GAL.

OrionExt

06.05.2018, 15:25

Вот это давно пора. И смд в лес. Должно на 2-х платках 100х100 (бутер) все поместиться от видео-части. Конечно, речь идет только об Орион -128.

andreil

06.05.2018, 15:57

Вот это давно пора. И смд в лес. Должно на 2-х платках 100х100 (бутер) все поместиться от видео-части. Конечно, речь идет только об Орион -128.
Совсем от SMD не уйти - память и кварцы как минимум. Ну и резисторы с конденсаторами проще в таком исполнении.

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

Единственная проблема - программатор для GAL. Нашел на ардуине проект для прошивки 22V10, попробую адаптировать на STM32. Будет сразу с USB программатор, прикидывающийся COM-портом (или HID устройством, если разберусь).

OrionExt

06.05.2018, 16:03

andreil

06.05.2018, 16:59

Я достаточно давно не был в теме. Когда стал вопрос, что брать для запрограммировать. Питань не було. MiniPro. Штука не без тучи глюков и с такими возможностями, но за такие денге маст хэв.
$53 пока что земноводное не даст заплатить :)
Да и GAL'ки ещё с месяц будут идти...

А пока суть да дело надо на них попереносить мелкую логику и добить-таки диспетчеризацию памяти...

Кстати, счётчики у меня "под боком" только в SOIC'ах есть в наличии. в DIP'ах только 74AC и в 2 раза дороже :)
Да они даже на алике стоят по $.5 за корпус...

andreil

07.05.2018, 11:52

В ходе "упаковки" логики в GAL очень сильно переработал выходной видеокаскад - теперь там одна GAL и пачка регистров. Ну и 1 корпус 4*2AND для формирования смеси цветов. Всю логику переключения видеорежимов и выходные мультиплексоры впихнул в 1 GAL'ку - посмотрим, насколько оно ещё влезет потом, может надо будет оптимизировать ещё потом.
Регистры остались только для защелкивания видеоданных (4 ИР33) и сдвиговые регистры видеоданных (4 ИР10).
Дальше надо будет по таймингам смотреть, какие сигналы и как "вытягивать" - с GAL это попроще будет и более фиксированные рамки получатся.

L Juriy

07.05.2018, 12:05

andreil, Немного офтоп. Есть содержимое РЕ3, можно как то , без особых затрат перевести ее в GAL?
Если можно , то примером подробным для профанов.

TomaTLAB

07.05.2018, 12:56

MiniPro Ага, а 22V10, 20V8 оно шьет? Дулю с маком.
Только 16V8 получается. Говорят когда то шило (через задницу, правда), потом там что-то окончательно испортили в процессе улучшений.

andreil

07.05.2018, 13:10

andreil, Немного офтоп. Есть содержимое РЕ3, можно как то , без особых затрат перевести ее в GAL?
Если можно , то примером подробным для профанов.
Можно, но для этого надо её дамп снять. Потом по дампу прогнать оптимизатором, что бы минимизировать функцию для каждого выхода..
Дам снимать просто - снимаем состояние выходов при всех возможных комбинациях входов (32 состояния).

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

Ага, а 22V10, 20V8 оно шьет? Дулю с маком.
Только 16V8 получается. Говорят когда то шило (через задницу, правда), потом там что-то окончательно испортили в процессе улучшений.
Ну, значит будем варганить свой программатор.

А между делом уже "нарисовалась" прошивка для GAL формирователя видеосигнала:

Name gal_vmux ;PartNo 00 ;
Date 06.05.2018 ;
Revision 01 ;
Designer andreil ;
Company None ;
Assembly None ;
Location ;
Device g22v10;

PIN [1..5] = [vm0..4];
PIN 6 = BL_n;
PIN 7 = p1;
PIN 8 = p2;
PIN 9 = p3;
PIN 10 = p4;
PIN [11,13..19] = [ps0..7];
PIN 20 = R;
PIN 21 = G;
PIN 22 = B;
PIN 23 = I;

I = BL_n & (((!vm4 & vm1) & ((p1 & ps3) # (!p1 & ps7)))/* pseudocolors mode */
# (vm4 & p2));
R = BL_n & (((!vm4 & !vm1) & ((p2 & p1) # (!p2 & (p1 & vm0))))/* standart mode */
# ((!vm4 & vm1) & ((p1 & ps2) # (!p1 & ps6))) /* pseudocolors mode */
# (vm4 & p3));
G = BL_n & (((!vm4 & !vm1) & (!p2 & (p1 & !vm0))) /* standart mode */
# ((!vm4 & vm1) & ((p1 & ps1) # (!p1 & ps5))) /* pseudocolors mode */
# (vm4 & p1));
B = BL_n & (((!vm4 & !vm1) & ((p2 & !p1) # (!p2 & (p1 & vm0))))/* standart mode */
# ((!vm4 & vm1) & ((p1 & ps0) # (!p1 & ps4))) /* pseudocolors mode */
# (vm4 & p4));
По сигналам:

vm0..4 - видеорежим, напрямую с регистра;
BL_n - инверсный сигнал гашения экрана;
p1, p2, p3, p4 - сигналы с выхода сдвиговых регистров;
ps0..7 - сигналы с регистров псевдоцветных режимов;
R, G, B, I - собственно выходные данные, далее преобразуются в аналоговые RGB.

Логику работы реализовал по схеме видеовыхода от Орион-Power v3.10.

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

Данную прошивку для стандартного режима (монохром, зелёный) проверил на ПЛИС. Остальное позже будет проверяться.

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

А сейчас буду рисовать черновик схемы "обновлённого" Ориона...

TomaTLAB

07.05.2018, 13:22

...Потом по дампу прогнать оптимизатором...
А оно надо?
... при всех возможных комбинациях входов (32 состояния).
Проще как есть LUT'ом описать.

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

Нашел на ардуине проект для прошивки 22V10, А где, если не секрет? :) Интересно глянуть...

OrionExt

07.05.2018, 13:40

Ага, а 22V10, 20V8 оно шьет? Дулю с маком.Я и говорил, что глюкавая штука. 16V8 пробовал шить. Шьется. Остальное не пробовал, но мне пока и не надо. С другой стороны, что можно приобрести за такие деньги с таким функционалом? Ничего.

Вообще интересно существуют современные решения для работы с GAL-ми за вменяемые деньги?

andreil

07.05.2018, 13:42

Я и говорил, что глюкавая штука. 16V8 пробовал шить. Шьется. Остальное не пробовал, но мне пока и не надо. С другой стороны, что можно приобрести за такие деньги с таким функционалом? Ничего.

Вообще интересно существуют современные решения для работы с GAL-ми за вменяемые деньги?
Я буду на основании этого проекта (https://github.com/RobertBaruch/atf22v10c) делать полноценный программатор на USB... Просто вменяемые программаторы не-LPT, которые поддерживают все GAL, стоят вообще дофига денег :( А покупать их ради пары чипов не вижу смысла.

OrionExt

07.05.2018, 13:52

Я буду на основании этого проекта (https://github.com/RobertBaruch/atf22v10c) делать полноценный программатор на USB... Просто вменяемые программаторы не-LPT, которые поддерживают все GAL, стоят вообще дофига денег :( А покупать их ради пары чипов не вижу смысла.
Конечно, ради одной GAL-ки MiniPro никому не сдался. Тем более там, что не ладно происходит.

А ардуино это молодежно и достаточно универсально:) Делал на нем ного-дрыг для TMS9918, все просто и понятно.

andreil

07.05.2018, 14:01

Конечно, ради одной GAL-ки MiniPro никому не сдался. Тем более там, что не ладно происходит.

А ардуино это молодежно и достаточно универсально:)
Ну, тот проект я думаю только за основу брать. И делать полноценный программатор на STM32 - ардуину ещё покупать надо, а так у меня всё есть уже готовое :) В теории - можно будет все GAL шить...

OrionExt

07.05.2018, 14:09

Ну, STM, так STM. Если проект реализуется, будет, думаю полезен многим. А то LPT уж больно древнючая штука и не у каждого она есть.

andreil

07.05.2018, 14:11

Кстати, по деталям.
ИР33, ИР37 и ИР35 - какие из них труднее достать? Или разницы особой нет?
Думаю, что и как поменять в схеме...

L Juriy

07.05.2018, 14:26

Потом по дампу прогнать оптимизатором,
Вот это для меня темный лес. Какой оптимизатор или вернее где он?
Дамп есть, РЕ3 нечем прошить. Есть пару GAL16V8 и есть чем их прошить.
Подробно по шагам, как это сделать?

Error404

07.05.2018, 14:32

Кстати, по деталям.
ИР33, ИР37 и ИР35 - какие из них труднее достать? Или разницы особой нет?
Думаю, что и как поменять в схеме...

ИР33 и ИР37 предлагаю менять на ИР22 и ИР23 как более доставаемые (посмотреть какие там вместо каких по функционалу) - там отличие в цоколевке (у ИР33 и ИР37 вроде поудобнее на "человеческий" взгляд). Ходили слухи что ИР33 и ИР37 чуть побыстрее, но я в такое не верю. А ИР35 менять вроде не на что, других 8-битных регистров со сбросом в серии 1533 я не знаю.

andreil

07.05.2018, 14:55

Вот это для меня темный лес. Какой оптимизатор или вернее где он?
Дамп есть, РЕ3 нечем прошить. Есть пару GAL16V8 и есть чем их прошить.
Подробно по шагам, как это сделать?
В данном случае оптимизировать не обязательно - малое количество комбинаций, при компиляции GAL'ки всё влезет 100%.
То есть достаточно для каждого выхода прописать что-то наподобие следующего: "D0 = a0 & !a1 & a2 & a3 &!a4". Естественно, по таблице истинности.

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

ИР33 и ИР37 предлагаю менять на ИР22 и ИР23 как более доставаемые (посмотреть какие там вместо каких по функционалу) - там отличие в цоколевке (у ИР33 и ИР37 вроде поудобнее на "человеческий" взгляд). Ходили слухи что ИР33 и ИР37 чуть побыстрее, но я в такое не верю. А ИР35 менять вроде не на что, других 8-битных регистров со сбросом в серии 1533 я не знаю.
Да, на ИР22/23 меняется без проблем. Только цоколёвка другая, не более того - нам это не так-то и важно, длина проводников не сильно мешает в нашем случае :)

TomaTLAB

07.05.2018, 15:10

То есть достаточно для каждого выхода прописать что-то наподобие следующего: "D0 = a0 & !a1 & a2 & a3 &!a4". Естественно, по таблице истинности.
Да накой шут? С РЕшки же будет готовый LUT снят. Под спойлером пример из WinCupl'a

Name Lookup;
Partno CA0017;
Revision 01;
Date 3/10/85;
Designer T. Kahl;
Company Assisted Technology, Inc.;
Location San Jose, CA.;
Assembly Example;
Device g22v10;

/************************************************** **************/
/* */
/* This is an example of the TABLE format for CUPL. The lookup */
/* table input consists of a 6 bit number for the radius of a */
/* circle (R0-5) and the output is the value for the perimeter */
/* (2 x Pi x Radius) of the circle (P0-7). */
/************************************************** **************/
/* */
/************************************************** **************/

/** Inputs **/

/* Pin [2..3,9..12] = [R0..5]; Radius of Circle */
Pin [1..6] = [R0..R5];
/*Pin [9..12] = [R2..R5];*/

/** Outputs **/

Pin [14..21] = [P0..P7]; /* Perimeter of Circle */
/*Pin 21 = P3;
Pin 23 = P0;
Pin [24..25] = [P2..P1];
Pin 26 = P6;
Pin 18 = P7;
*/
/** Declarations and Intermediate Variable Definitions **/

Field Radius = [R5..0];
Field Perimeter = [P7..0];

/** Logic Equations **/

Table Radius => Perimeter {

/* Radius Perimeter Radius Perimeter */
/* ------ --------- ------ --------- */
'd'00 => 'd'000; 'd'01 => 'd'006;
'd'02 => 'd'013; 'd'03 => 'd'006;
'd'04 => 'd'025; 'd'05 => 'd'019;
'd'06 => 'd'040; 'd'07 => 'd'031;
'd'08 => 'd'050; 'd'09 => 'd'044;
'd'10 => 'd'063; 'd'11 => 'd'069;
'd'12 => 'd'075; 'd'13 => 'd'082;
'd'14 => 'd'088; 'd'15 => 'd'094;
'd'16 => 'd'101; 'd'17 => 'd'107;
'd'18 => 'd'113; 'd'19 => 'd'119;
'd'20 => 'd'126; 'd'21 => 'd'132;
'd'22 => 'd'138; 'd'23 => 'd'145;
'd'24 => 'd'151; 'd'25 => 'd'157;
'd'26 => 'd'163; 'd'27 => 'd'170;
'd'28 => 'd'176; 'd'29 => 'd'182;
'd'30 => 'd'188; 'd'31 => 'd'195;
'd'32 => 'd'201; 'd'33 => 'd'207;
'd'34 => 'd'214; 'd'35 => 'd'220;
'd'36 => 'd'226; 'd'37 => 'd'232;
'd'38 => 'd'239; 'd'39 => 'd'245;
'd'40 => 'd'251;
}

можно прямо его подправить будет по данным с дампа.
Меньше вероятность накосячить в самом начале такой замены.
Это уже потом, если возникнет необходимость что-то подправить/дополнить, можно будет вдумчиво разобрать логику и переписать по человечески.

andreil

07.05.2018, 15:31

По делу - дорисовал кусок схемы, работу с памятью пока не менял, поскольку активно работаю на ней...
Схема видеоплаты (https://andreil.by/orion/orion_video.pdf). Видео - до участка с мультиплексорами адреса.
В принципе. входную цепочку с инверторами можно смело убирать - смысла в ней уже нет.
Из мелкой логики осталась только 1 ЛИ1, да и то она осталась банально из-за нехватки ног на GAL'ке, формирующей видеосигнал :) Но и тут можно "сделать красиво", если с входов убрать сигналы VM2 и VM3 - в таком случае при выключении экрана (активный бит 2 при сотальных 0-х) на экран будут выводиться данные из регистров псевдоцветного режима.

L Juriy

07.05.2018, 15:40

TomaTLAB, Спасибо попробую.

TomaTLAB

07.05.2018, 15:52

andreil

07.05.2018, 18:06

На VGA-разъеме на 9 пин советую завести +5/+3,3 через легкодоступный для пайки резистор/перемычку.
Если приспичит перекроить плату под ТВ то в тот же самый VGA-разъем втыкается шнурок DB-15 <-> SCART где будем иметь сигнал для переключения в RGB.
Как по мне - весьма удобно, тем более, что на 9 пине по стандарту с видяхи +5В может выходить.
Да, так и сделаю.
Благо, что схему с учётом GAL'ок можно вообще на любой видеовыход переделать при желании :)

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

Из мелкой логики осталась только 1 ЛИ1, да и то она осталась банально из-за нехватки ног на GAL'ке, формирующей видеосигнал :) Но и тут можно "сделать красиво", если с входов убрать сигналы VM2 и VM3 - в таком случае при выключении экрана (активный бит 2 при сотальных 0-х) на экран будут выводиться данные из регистров псевдоцветного режима.
По этому пункту нужно ваше мнение - допускается ли так вот игнорировать бит 2 видеорежима или нет...
Если допускается - вся логика работы с цветом будет находиться в GAL.

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

По этому пункту нужно ваше мнение - допускается ли так вот игнорировать бит 2 видеорежима или нет...
Если допускается - вся логика работы с цветом будет находиться в GAL.
Вопрос неактуален - при использовании АП5 можно его выходами разрешения управлять. Достаточно 1 логического элемента. Завтра в ПЛИС этот вариант просимулирую.

andreil

08.05.2018, 13:42

Проверил данный вариант схемы в ПЛИС - всё ОК, работает отлично.
Осталось посчитать задержки в цепях и посмотреть, куда потребуется ставить задерживающие цепочки...

andreil

08.05.2018, 23:19

Уф, исправил макетку для подключения реального Z80 - сильно много косяков всплыло :( У преобразователей уровней для второй половинки про общий забыл вообще, для буферов адреса и данных направление попутал...
Вот так сейчас выглядит сама "макетка". (https://yadi.sk/i/teDormjJ3VZbXr)
Буду теперь под самые реальный тайминги и на разных процессорах ровнять процесс :)

andreil

09.05.2018, 19:25

О УВВ и ожиданиях - при работе с периферией Z80 автоматом добавляет 1 цикл ожидания в любом случае. И получаем минимальную длительность сигнала IORQ в 2 такта, а не 1 ;)
ДШ, страница "Input or Output Cycles", такт Twa (https://ru.mouser.com/datasheet/2/450/ps0178-19386.pdf)
Сижу над таймингами - много магии. В ПРОшке эта магия пряталась за WAIT'ами, потому память и успевала. А без них всё "впритык" и далеко не по фронтам тактирования. И у более медленных версий процессора эта разбежка только ещё больше:
https://image.prntscr.com/image/5usuU6JqT9m-LTmzPqzqoQ.png
Частота опроса - 300МГц.
В итоге строб записи "не попадает" в цикл доступа к памяти целиком.
Если сделать доступ к памяти более частым, то это будет уже 40нс - сейчас 80нс.
В общем, буду дальше смотреть что тут можно сделать...

Error404

10.05.2018, 13:20

Может получилось бы сделать такт CPU 6,25 без Wait, а 12,5 уже c Wait ?

OrionExt

10.05.2018, 14:24

Давайте уже продукцию. А то мои баллоны не сдюжат (с)

andreil

10.05.2018, 14:29

Может получилось бы сделать такт CPU 6,25 без Wait, а 12,5 уже c Wait ?
Я пока попробую вообще без ожидания - экспериментирую с формированием стробов сигнала доступа к памяти - для симметричности необходимо и чтение и запись свести к одинаковому интервалу времени. Да и ожидание проблематично будет включить - у меня на него не осталось выводов на гребёнке GPIO :) Я даже не все сигналы от CPU смог пропихнуть - сейчас идут только /RFSH, /M1, /MREQ, /IORQ, /RD, /WR, CLK, /INT, /RESET. Остальное - только если отрезать старшие адреса памяти (A17, A18). Дальше резать уже некуда. Хотя, можно подключиться через соседний коннектор (LTC CON) - там 7 сигналов есть через коммутатор.
Генерация тактов для процессора будет перенесена в видеомодуль и будет выполнена в виде 1 GAL - сейчас над её прошивкой и сижу как раз.
На плате процессора всю логику дешифрации адресов для ПЗУ/портов/прочего так же выкину в GAL (кроме IC непосредственно дешифраторов).

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

Давайте уже продукцию. А то мои баллоны не сдюжат (с)
Терпение, мой друг, только терпение ;)
Сильно масштабные переделки получились. С учётом того, что вся мелкая логика будет в GAL, то плату видеомодуля можно делать уже сейчас. Надо только посмотреть места, где может понадобиться вставлять цепочки задержек сигналов.
И да, если нужен псевдографический режим, то нужна прошивка ПЗУ для его тестирования. Потому что кроме ПЗУ пока что никаких путей запуска программ не имеется...

PS: И да - эта версия, как и ПРО, only Z80...

andreil

10.05.2018, 22:26

Итак, на частоте 12,5МГц без WAIT'ов время доступа к памяти получается очень малым - но я частоту переключения пока что "задрал" очень высоко - период вышел 20нс. Работает почти идеально, но есть и конфликты - при работе теста видны артефакты.
В основном сейчас занимался упаковкой логики для дальнейшего переноса в GAL. Пока что получилось 6 корпусов на оба модуля:

GAL_X - формирование сигналов на основании сигналов от счётчиков горизонтали экрана (горизонтальное гашение, импульс для отсчёта строк, горизонтальная синхронизация, счётчик столбцов 16-битных видеоданных, арбитраж доступа к памяти, сигнал на чтение из видеопамяти);
GAL_Y - формирование сигналов на основании сигналов от счётчиков вертикали экрана (гашение урана, горизонтальная синхронизация, конец кадра - для прерывания);
GAL_VMUX - формирование видеовыхода на основании сигналов от сдвиговых регистров, битов 0, 1 и 4 видеорежима, данных регистров псевдоцветных режимов;
GAL_CPU - формирование сигналов для процессора и не только (тактовые импульсы CPU, стробирование сброса, укорачивание сигнала чтения - необязательно и потом может быть и уберу);
GAL_ADDR - формирование сигналов для дешифраторов портов (два сигнала для выборки дешифраторов стандартных портов F4-FB, разрешение на включение мультиплексоров адресов MA14-MA19, сигналы доступа к памяти на чтение и запись);
GAL_MEM - формирование сигналов доступа к ROM1 и ROM2, блокировки оперативной памяти, переключения адресов MA14-MA19.

В процессорном модуле есть ещё пачка мелкой логики, но там всё тяжело и некоторые места ещё не проверялись толком.

Ну, а поскольку с GAL'ками более-менее готово, надо решать проблему с артефактами записи в память :)

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

Кстати, о портах ввода-вывода - длительность чтения равна 197нс. Запись не проверял ещё, но если судить по циклу записи в память и дополнительному циклу ожидания по умолчанию, получается около 117нс.
Всё это без учёта задержек в реальной логике. Но, если цепочку выстроить правильно, то они будут нивелироваться ;)

andreil

11.05.2018, 09:16

Добавилась ещё одна GAL: управляет основными сигналами SRAM (A16, A17, CE0, CE1, UB, LB, WE, OE, старшие адреса видеопамяти). Она же заменяет 2 КП11 по старому варианту схемы, переключающей эти сигналы.
По конструктиву - думаю память сделать отдельной платкой. вставляющейся в разъем на видеомодуле. Это позволит в дальнейшем использовать прочие чипы, кроме 2-х уже заложенных мною.

andreil

11.05.2018, 16:20

Дорисовал текущую схему видеомодуля (https://andreil.by/orion/orion_video.pdf).
Не хватает ещё 2-х инверторов - думаю поставить полноценный корпус 2NOR вместо 1-гейтового и пару элементов использовать как инверторы.
Ну и ещё разъёмы перепроверить системные.
Память будет вынесена на отдельную плату - пока ещё на листе находится, что бы было перед глазами. Конструктивно думаю выполнить в виде платы с 2-х рядными разъёмами с противоположных сторон, закреплённые на стойках.
Посмотрим, как ещё скомпоновать получится это всё :)

andreil

11.05.2018, 19:41

Оптимизирую схему - сделал выходной R2R DAC 2-битным (симулировал в Протеусе на нагрузке 75Ом). В итоге получилось выкинуть оставшиеся 2 корпуса мелкой логики и выходные АП5. В качестве 2-х инверторов использовал свободные IO GAL_Y - там как раз 4 вывода были свободными :)

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

И дополнение по памяти - на один из входов GAL, отвечающей за сигналы управления памятью, подаётся сигнал с пина "планки" памяти. По сути - или лог.0 или лог.1, в зависимости от ширины памяти в чипе (8 или 16 бит). В зависимости от этого будет меняться логика формирования сигналов (а может и нет, надо строить модели, но лень - а так максимально гибкое решение) :)

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

Обновил схему (https://andreil.by/orion/orion_video.pdf).
Свободных выводов у GAL'ок уже нет - только 2 у GAL_Y, но туда нечего подключать уже :)
Просьба глянуть схему незамыленным взглядом, особенно разъемы:

SYS_PRO - собственно, попиновый аналог системного разъёма ПРОшки;
SYS_EXT - расширение разъёма с сигналами для мультикарты и резервом на будущее.

Так же добавил +5В на 9 пин разъёма VGA.

andreil

11.05.2018, 22:16

Грубо раскидал компоненты в новом варианте. 4 корпуса на второй стороне, а так на лицевой стороне всё разместилось. Так же не раскидывал кондёры по питанию (на каждый корпус по 1 :) ) и резисторы для подтяжек.
За счёт использования GAL разводка значительно упроститься - ведь можно перекидывать сигналы для упрощения трасс :)
https://image.prntscr.com/image/ByuvuXhbTxCD6erB4CjDMA.png
Габариты стандартные - 100х100мм.
На одних только DIP-компонентах плата вышла бы значительно крупнее, а так у меня пачка МС без дела лежит :)
Так же уместил и компоненты для псевдографического дисплея - ПЗУ DD18 и мультиплексор DD17. Так же есть колодка джамперов для обхода ПЗУ (возле оной) - если режим не нужен или по прочим причинам туда просто вешается 8 перемычек.

bigmal

12.05.2018, 07:02

Круто!! :v2_dizzy_punk:

andreil

12.05.2018, 11:42

Error404

12.05.2018, 23:39

Так, пара вопросов по разъёмам:

Оставлять ли совместимость с ПРО/128 или делать "свой" разъём для корзины?
Какое конструктивное исполнение разъёма брать - краевой "папа" для установки в корзину, угловая PLS'ка для корзины или прямая PLS'ка для сборки плат "бутербродом?

Если есть возможность, то почему бы не сделать системный разъем в формате ПРО. Под него есть хоть какая-то периферия (пускай и с высосанными из пальца портами, это поправимо). Краевые разъемы (которые ламели на печатке) я не люблю: у нас нет возможности их позолотить, а без того это не надежно. Надежнее всего DIN (вместо которого небогатые орионщики смогут поставить и PLS).

А так же какую ПЗУ закладывать? время доступа критично, а из быстрых чипов у нас только OTP или в DIP-корпусе... Да и те только некоторые укладываются в 45нс, остальные 70нс и более, что в нашем случае уже критично.
Без конкретного типа ПЗУ сейчас даже компоновку не получится сделать.

Я за W27C512-45Z во всех случаях (ПЗУ F800, ПЗУ_Фонты). Пускай они и в DIP, но доставаемы и дешевы. А что до компановки, то давно уже принято внутри панельки такой DIP-ПЗУ ставить еще какие-то корпуса.

andreil

13.05.2018, 00:08

Если есть возможность, то почему бы не сделать системный разъем в формате ПРО. Под него есть хоть какая-то периферия (пускай и с высосанными из пальца портами, это поправимо). Краевые разъемы (которые ламели на печатке) я не люблю: у нас нет возможности их позолотить, а без того это не надежно. Надежнее всего DIN (вместо которого небогатые орионщики смогут поставить и PLS).
Да, поставил посадочное место под DIN41612 на 64 пина, угловой.
Таким образом места под крепёж будут или только сверху платы или ещё и на месте разъёма (если ставить PLS). В первом случае плата корзины будет и так держать плату с 1 стороны.

Я за W27C512-45Z во всех случаях (ПЗУ F800, ПЗУ_Фонты). Пускай они и в DIP, но доставаемы и дешевы. А что до компановки, то давно уже принято внутри панельки такой DIP-ПЗУ ставить еще какие-то корпуса.
Ок, разместил её. И на А15 подал сигнал активации ПГД. Под ПЗУ разместил мультиплексор для её адресов и буфер видеопамяти, с которым она связана.

Вопрос по посадочным местам по DIP-компонентам - площадки делать мелкими или покрупнее, овальной формы? Есть выбор посадочных мест, вот и думаю. На скрине выше - с большими площадками. Но с меньшими можно 2-3 дорожки между выводами протащить при нужде :)

Сейчас буду заниматься оптимизацией пинов GAL, что бы максимально упростить разводку сигналов.
Ещё думаю у выходных пинов GAL разместить места под однорядные разъёмы - что бы в случае исправлений/модификаций было проще напаиваться. Или это уже излишнее?
И да - разъёмы для памяти с шагом 2мм, стандартные на 2.54мм сильно укрупнят данное место :(

OrionExt

13.05.2018, 17:09

andreil

13.05.2018, 17:27

W27C512-45, других вариантов не вижу. Хотя это такой китай. Есть ли там 45нс?
Даже если и нет, то времени, в принципе, достаточно и для более медленных вариантов - опрос этой части видеопамяти я вынес на самое начало цикла. В итоге получается 120нс или 280нс, в зависимости от "удачности" обращения процессора к памяти. Так что "прокатит" почти любой чип, кроме самых медленных.

OrionExt

13.05.2018, 17:28

Вопрос по посадочным местам по DIP-компонентам - площадки делать мелкими или покрупнее, овальной формы?(
Видимо нужно исходить из стандарта, а не красоты:)

andreil

13.05.2018, 17:29

1. С системным разъемом Орион-128. Да. Что делать с системным-и разъемам-и Орион-Про? Не знаю. Их там два вида.
Разъём, который в ПРО идёт для мультикарты, у меня здесь так же есть, но сигналы с него вынесены на вторую гребёнку - её расположил сверху платы. Там только уникальные для этого разъёма сигналы и новые, для связки портов с платой процессорного модуля. Остальные сигналы на простом системном разъёме имеются.

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

Видимо нужно исходить из стандарта, а не красоты:)
Не в курсе, что тут считать стандартом. Мне и мелкие "пятачки" норм, а кому-то может и неудобно будет паять.

OrionExt

13.05.2018, 17:39

Разъём, который в ПРО идёт для мультикарты, у меня здесь так же есть, но сигналы с него вынесены на вторую гребёнку - её расположил сверху платы. Там только уникальные для этого разъёма сигналы и новые, для связки портов с платой процессорного модуля. Остальные сигналы на простом системном разъёме имеются.
Две гребенки. По мне это сложно и место занимает.

Может чего забыл. Разъемы 128 и Про не совместимы. Делайте как у меня в MSX-EXT. Два ряда по 32 для дефолтной периферии, третий для экспериментаторов. Ну как говориться выбор за автором.

Не в курсе, что тут считать стандартом. Мне и мелкие "пятачки" норм, а кому-то может и неудобно будет паять.
Это зря. В Орле 20% сверху от диаметра отверстия. Как пример.

По поводу удобно паять. Мне не удобно паять китайскими паяльниками. А моим старичком сделанным 40 лет назад, паяется все (с).

andreil

13.05.2018, 17:55

Это зря. В Орле 20% сверху от диаметра отверстия. Как пример.
Это стандарт. Просто могу пихнуть увеличенные пады - они вытянуты овалом и узкая часть пошире стандартного пятака получается.

Делайте как у меня в MSX-EXT. Два ряда по 32 для дефолтной периферии, третий для экспериментаторов.
Да, скорее всего так и сделаю.

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

По поводу удобно паять. Мне не удобно паять китайскими паяльниками. А моим старичком сделанным 40 лет назад, паяется все (с).
У меня только паяльная станция сейчас. А простой паяльник лежит на полочке для работ "в поле".

OrionExt

13.05.2018, 19:21

У меня только паяльная станция сейчас. А простой паяльник лежит на полочке для работ "в поле".
Mоего старичка только в музее показывать, а потом он не разу не мобильный (к нему еще транс килограммов 10 (шучу - 5кг). Вот сейчас подымаю, что найти из нагревательного элемента (ну это просто). А вот с жалами проблема.

Error404

14.05.2018, 01:26

У меня паяльная станция с 900ми жалами. Беру медные жала, с ними паять привычно как стареньким ЭПСН, только более точная пайка т.к. жала потоньше и температура регулируется. ЭПСН-25 тоже пользуюсь где работа погрубее.

andreil

15.05.2018, 22:27

Продолжаю оптимизировать расположение компонентов:
https://image.prntscr.com/image/Ju4yqFHmQge05LmWJTy2hw.png
На нижней стороне только 5 микросхем - 1 двунаправленный буфер данных, 2 порта и 2 защёлки видеоданных.
Самый главный вопрос - системный разъём в новоделе должен следовать стандарту (оригинальный 128 или ПРО) или можно спокойно свою раскладку делать? Просто в ПРОшном сильно далеко тянуть адреса к мультиплексорам придётся, да и сданными та же песня - собраны на 1 ряду все, что не очень-то и хорошо =/

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

Даже если делать совместимость с системным разъёмом Орион-128, то будут расхождения как минимум по ширине. Но это не проблема - на дополнительные пины только новые сигналы вывести. Это всё надо смотреть, а пока непонятно.

OrionExt

16.05.2018, 07:10

Самый главный вопрос - системный разъём в новоделе должен следовать стандарту (оригинальный 128 или ПРО) или можно спокойно свою раскладку делать?
Вопрос интересный. Так что у нас уже есть?
1. Оригинальный Орион-128 – 3-х рядный DIN
2. Оригинальный Орион-Про – 2 вида 2-х рядных DIN
3. Реплика Орион-128 рев. 512 - 2-х рядный разъем (расстояние между рядами 2,54 или 5,08).
4. Остальные реплики и новоделы – сложно отследить чего там наменяли.

Ни один из перечисленных вариантов не совместим на 100% между собой. Вот и делай выводы.

Просто в ПРОшном сильно далеко тянуть адреса к мультиплексорам придётся, да и сданными та же песня - собраны на 1 ряду все, что не очень-то и хорошо =/
Оптимально разместить сигналы мало вероятно без стандарта на входную/выходную схему. Как это можно было бы сделать? Допустим картридж с ПЗУ разной емкости. Или схема буферизации системных сигналов. Не один из этих вариантов нам не подходит.

Даже если делать совместимость с системным разъёмом Орион-128, то будут расхождения как минимум по ширине. Но это не проблема - на дополнительные пины только новые сигналы вывести. Это всё надо смотреть, а пока непонятно.
Это не реплика и даже не новодел. А скорее всего новодельный клон Орион-128/Про, то и делать думаю надо исходя из особенностей этой разработки.

Error404

16.05.2018, 15:04

Вопрос интересный. Так что у нас уже есть?
1. Оригинальный Орион-128 – 3-х рядный DIN
2. Оригинальный Орион-Про – 2 вида 2-х рядных DIN
3. Реплика Орион-128 рев. 512 - 2-х рядный разъем (расстояние между рядами 2,54 или 5,08).
4. Остальные реплики и новоделы – сложно отследить чего там наменяли.

Ни один из перечисленных вариантов не совместим на 100% между собой. Вот и делай выводы.

Не совсем так. В Орионе-128 сигналы были разведены на средний и один крайний ряд 3-рядного DIN.

В Орион-128 рев. 512 системный разъем полностью совместим с Орионом-128, разница лишь в том, что в рев.512 можно ставить как 3-рядный DIN с шагом рядов 2,54 (и тогда туда без какой-либо переделки ставится периферия от Ориона-128, как и периферия от рев.512 тоже обратно совместима), так и за счет того, что запараллелен средний ряд и второй крайний, то можно как опцию ставить 2-рядный DIN с шагом рядов 5,08 (т.е. 3-рядный с пустым средним рядом, такие весьма распространены) и что самое полезное - ставить и "врубной" слот SL-xx (у всех таких слотов шаг рядов обычно 5,08).

OrionExt

16.05.2018, 16:15

Error404

16.05.2018, 16:48

Ну и где здесь совместимость?:) Когда в рев. 512 линия A и B соединена между собой. Мне прекрасно понятны причины, почему так сделали.

Да и вообще у меня не вызывает трудности не стареющий девиз "Каждому компьютеру / плате свой системный разъем":D

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

А так то в оригинальном Орион-128 задействовать линии A и B (C в резерв), но слегка промахнулись.

Совместимость в том, что по системному разъему рев. 512 совместима с Орион-128.3 выпущенной zorel тут на форуме (которая в свою очередь рисовалась по журнальной из Радио 1990/4). С оригинальной журнальной картинкой я лично не сверял, но утверждалось что это оно и было, не вижу причин не верить.
А вот на плате КНГМД разъем был установлен зеркально (так ошибочно развел камрад Gryphon в давнишние времена) и никто это перерисовывать не стал - лень, так оно и прижилось, всем было проще разъем запаять с обратной стороны. Этот контроллер одинаков в обоих проектах, и работает (при несовпадении шины не работал бы).

andreil

16.05.2018, 19:50

Итак, вижу 2 варианта:

Совместимый с оригиналом - посмотреть журнальную схему и схему варианта 512.3. Новые сигналы вывести на 3-й ряд разъёма;
Придумать свой разъём, но тогда и все устройства надо "свои" делать".

Так что вероятнее всего вариант №1...

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

Так же актуально по питанию - может делать на каждой плате с большой логикой разъём MOLEX (для дисковода) и эти же линии пускать на кросс-плату? Тогда слаботочные платы смогут питаться от кросс-платы.
Или сделать питание через кросс-плату и MOLEX'ы ставить там (штуки 3)?

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

PS: Где 3-х рядные DIN'ы подешевле можно найти? На алике вообще что-то дикое - около $4 за разъём.

OrionExt

16.05.2018, 20:22

Где 3-х рядные DIN'ы подешевле можно найти? На алике вообще что-то дикое - около $4 за разъём.
Это видимо фирма. Ищи китай. Вот (https://ru.aliexpress.com/item/9001-11961C00A-3-32P-3-rows-96-core-OUPIIN-European-socket-male-elbow-2-54-pitch/32825935184.html?ws_ab_test=searchweb0_0,searchweb 201602_2_10152_10151_10065_10344_5722918_10068_103 42_5722818_10343_10340_10341_5711416_5722618_10696 _10084_10083_10618_10307_5722718_10059_5711218_308 _100031_10103_5711318_5722518_5711515_10624_10623_ 10622_10621_10620_10125,searchweb201603_1,ppcSwitc h_5&algo_expid=a70050d9-b9de-475d-b678-0671130abbd3-0&algo_pvid=a70050d9-b9de-475d-b678-0671130abbd3&priceBeautifyAB=0) на вскидку. Думаю если еще пошукать еще дешевле будет.

И еще (https://ru.aliexpress.com/item/8-Pcs-96-Pin-Eurocard-DIN-Ccnnector-Male-Right-Angle-3-Rows-32x3-Gold-Plated/1603569372.html?ws_ab_test=searchweb0_0,searchweb2 01602_2_10152_10151_10065_10344_5722918_10068_1034 2_5722818_10343_10340_10341_5711416_5722618_10696_ 10084_10083_10618_10307_5722718_10059_5711218_308_ 100031_10103_5711318_5722518_5711515_10624_10623_1 0622_10621_10620_10125,searchweb201603_1,ppcSwitch _5&algo_expid=2c55e120-e53b-4e5a-af9a-d89f2a39db38-1&algo_pvid=2c55e120-e53b-4e5a-af9a-d89f2a39db38&priceBeautifyAB=0).

andreil

16.05.2018, 21:25

Это видимо фирма. Ищи китай. Вот (https://ru.aliexpress.com/item/9001-11961C00A-3-32P-3-rows-96-core-OUPIIN-European-socket-male-elbow-2-54-pitch/32825935184.html?ws_ab_test=searchweb0_0,searchweb 201602_2_10152_10151_10065_10344_5722918_10068_103 42_5722818_10343_10340_10341_5711416_5722618_10696 _10084_10083_10618_10307_5722718_10059_5711218_308 _100031_10103_5711318_5722518_5711515_10624_10623_ 10622_10621_10620_10125,searchweb201603_1,ppcSwitc h_5&algo_expid=a70050d9-b9de-475d-b678-0671130abbd3-0&algo_pvid=a70050d9-b9de-475d-b678-0671130abbd3&priceBeautifyAB=0) на вскидку. Думаю если еще пошукать еще дешевле будет.
Такой я находил. А вот ответные части - "папы" без изгибов - только дороже в 2 раза примерно =/
Вот (https://ru.aliexpress.com/item/9001-12961C00A-spacing-2-54mm-3-rows-96PIN-straight-hole-female-European-socket-New-Original/32825673162.html?ws_ab_test=searchweb0_0,searchweb 201602_5_10152_10151_10065_10344_10068_5722815_103 42_10343_10340_5722915_10341_5711416_5722615_10696 _10084_10083_10618_10307_5722715_5711215_10059_308 _100031_10103_5711515_10624_10623_10622_5711315_57 22515_10621_10620_10125,searchweb201603_11,ppcSwit ch_5&algo_expid=b45928f2-2385-410c-aeb3-95a72ca33a4d-1&algo_pvid=b45928f2-2385-410c-aeb3-95a72ca33a4d&transAbTest=ae803_1&priceBeautifyAB=0), в том же магазине, $3.4 за штуку.
Дорого пздц =/ Получается около $5 на плату только по разъёмам.

OrionExt

16.05.2018, 21:43

Ну, разъемы вообще штука не дешевая, там встречаются цветные металлы (иногда):D "Мамы" по определению дороже.

А вообще китайцы последнее время чутка охренели, цены все чаще попадаются дороже европейских магазинов. Только цена доставки и подкупает.

andreil

17.05.2018, 10:48

По разъёмам - нашел на тао по $0,6 за штуку. За полный разъём получается около $1,2 за полный разъём + доставка. Закажу в следующий раз, как будем оттуда партию брать :)

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

Там же нашел и память статику 256К*16 в SOJ44 по $2,2 за штуку :)

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

По системному разъёму - есть где полная распиновка?
Журнальных сканов нету сейчас под рукой, а на схеме от Прусака косяков просто табун на распиновке =/ Приходится по картинкам с Орион-512.3 смотреть все сигналы =/

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

И в продолжение о системном разъёме - проверьте распиновку, а то не уверен на 100%. Сигналы, в которых сомневаюсь, не подключены и помечены вопросом. Сигналы справа - будут заведены позже на неиспользуемые контакты. Так же уже добавил часть новых сигналов с текущую распиновку.
Схема. (https://andreil.by/orion/orion_video.pdf)

Error404

17.05.2018, 12:49

Немного опоздал к обсуждению кто где затаривает разъемы DIN. Я помнится брал в РУЭЛКОМ (они более по электрике, но если что у них есть из радио, то по вполне вменяемым ценам). Вот например нужные нам разъемы по цене примерно в доллар (в Китайских магазах доллар давно перевалил за 65 рублей): Разъем DIN41612 3*32 96 розетка 71,33руб. (http://www.energy-m.su/din/razem-din41612-332-96-rozetka/) и Разъем DIN41612 3*32 96 угл. вилка 61,58руб. (http://www.energy-m.su/din/razem-din41612-332-96-ugl-vilka/)

По разъёмам - нашел на тао по $0,6 за штуку. За полный разъём получается около $1,2 за полный разъём + доставка. Закажу в следующий раз, как будем оттуда партию брать :)

ТАО - это который https://kupinatao.com ? Более поганого магазина не найти, уже третий заказ подряд не отправилии с резюме "продавец заявил несуществующий товар, выберите другой" (продавцы заявляют товар со скидкой, а оказывается - с кидкОм, тупая самореклама без намерения продавать по той цене) причем каждый раз ожидание 2 недели (типа процессинг), и никаких репрессий по отношению к таким козлам-продавцам.

andreil

17.05.2018, 13:13

ТАО - это который https://kupinatao.com ? Более поганого магазина не найти, уже третий заказ подряд не отправилии с резюме "продавец заявил несуществующий товар, выберите другой" (продавцы заявляют товар со скидкой, а оказывается - с кидкОм, тупая самореклама без намерения продавать по той цене) причем каждый раз ожидание 2 недели (типа процессинг), и никаких репрессий по отношению к таким козлам-продавцам.
Эээ. нет :) Я напрямую на таобао тарюсь через посредников - собираем более 10кг добра и покупаем.

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

Немного опоздал к обсуждению кто где затаривает разъемы DIN. Я помнится брал в РУЭЛКОМ (они более по электрике, но если что у них есть из радио, то по вполне вменяемым ценам). Вот например нужные нам разъемы по цене примерно в доллар (в Китайских магазах доллар давно перевалил за 65 рублей): Разъем DIN41612 3*32 96 розетка 71,33руб. (http://www.energy-m.su/din/razem-din41612-332-96-rozetka/) и Разъем DIN41612 3*32 96 угл. вилка 61,58руб. (http://www.energy-m.su/din/razem-din41612-332-96-ugl-vilka/)
И работают они только с юриками...

Error404

17.05.2018, 19:24

И работают они только с юриками...

Я покупал как физлицо, было там менее чем на 1000 руб. - в общей сложности 8 разъемов (все DIN но разных типов) и мне продали без вопросов. Оплачивал карточкой на сайте, затем просто приехал в офис и забрал по накладной. Если конечно не путаю, я тогда 2 магазина сохранял в "ссылках на избранное", дело было пару лет назад, но по ценам вроде оно.

andreil

17.05.2018, 20:08

Я покупал как физлицо, было там менее чем на 1000 руб. - в общей сложности 8 разъемов (все DIN но разных типов) и мне продали без вопросов. Оплачивал карточкой на сайте, затем просто приехал в офис и забрал по накладной. Если конечно не путаю, я тогда 2 магазина сохранял в "ссылках на избранное", дело было пару лет назад, но по ценам вроде оно.
Ок, буду знать. Но для "приехать и забрать" придётся знакомых напрягать - самому сильно далеко ехать :)
Глянь распиновку разъёма, я там с парой сигналов в нижней части не могу ничего понять - сигналы ППР и ГОТОВ. ГОТОВ - это у нас /WAIT, как понимаю, причём без переделок. А ППР - /INTA из схемы ПРО, как понимаю. Или же это использется только как "бипер" и нафиг не нужен в разъёме?
Так же правильно ли посадил сигнал /INT на пин 16С?

andreil

01.06.2018, 17:37

Итак, пришли ожидаемые ATF'ки, на выходных начну собирать программатор на макетке. Потом его буду воплощать в нормальном виде, если заработает :)

andreil

16.06.2018, 21:02

Очень важный вопрос по распиновке системного разъёма - насколько корректна информация из "Радио 1993-04"? Собираюсь развести текущую плату, пока есть выходные и заказать её...
Так же важно знать ориентацию разъёма на плате - как правильнее его сориентировать.

andreil

17.06.2018, 13:35

В общем - разъём буду делать свой. Потому что так вообще нифига не понятно с текущими стандартами в этой области :(

Denn

17.06.2018, 23:34

andreil

18.06.2018, 00:27

Имхо, по О-128 имеет смысл ориентироваться на распиновку ревизии 512. А вообще, если делать современный максимально зафаршированный комп, то надобность в системном разъёме как-то сомнительна..
У меня просто почти модульная структура, с корзиной. Вот и думал о сигналах для корзины. В итоге всё своё, по мере трассировки меняется активно.
Трассировка - самое муторное... Приходится по N-ать раз всё с 0 начинать из-за неудачной компоновки...

Denn

18.06.2018, 12:39

Для разработки корзина удобнее всего. Но тут можно придумывать как угодно (как удобнее разработчику), ибо в массы такой вариант не пойдёт, простым смертным нужна будет плата, причём готовая, с покупкой "в один клик" ;)
И на этой плате должен быть максимум "фарша", т.к. сейчас никто не будет заниматься разработкой расширений для Ориона, кмк.

andreil

18.06.2018, 17:35

OrionExt

18.06.2018, 18:18

Ну не знаю. Системный разъем один - РАДИО №1,1990. Все остальное от лукавого. Хотя конечно кривоват, ну так 1990г. таки (это вам не господин, которому дали чего-то там (установку и …). Чтобы он по миру путешествовал и взял самое лучшее из своего путешествия. MSX.). На него и смотреть. А если свой сделал. Смотри, чтобы было не сложно переходник сбацать. Ну, и логику сигналов оригинала не поломать.

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

Тут еще конечно нужна спецификация на шину OPИОН. Но ее не было и не будет уже.

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

А разводка сигналов на шине, типо шина в ряд, хорошо бы в два ряда. Это мелочи. Частоты не те. Вот нет у меня таких трудностей:)

andreil

18.06.2018, 18:30

А разводка сигналов на шине, типо шина в ряд, хорошо бы в два ряда. Это мелочи. Частоты не те. Вот нет у меня таких трудностей:)
В три ряда. Уже и так почти всё занято - резервных от силы 15 пинов осталось. Питания поболее впихнул - что бы оно бралось именно с корзины.
Вот кусок разъёма (https://image.prntscr.com/image/9uRwKWPxQraUQWbpkcbvew.png). Тут верхние адреса памяти (в ПРО это MA14-MA19), селекторы портов, ШД, управляющие сигналы к/от процессора и логики около него.

OrionExt

18.06.2018, 19:50

Вот не знаю, что тут сказать. Не издеваюсь. Схема у тебя получилась очень сложная. Такое собирать? Впихнул туда Орион и ПРО. Свое. Зачем? Получился не Орион, а как построить видео плату . Аля ЦЖА. А просто собери Орион?

Мне как то все виделось в разы проще. Тем боле в двух портовой памяти . Сейчас проблем нет. Сделать поле ЦПУ и Видео - общим.

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

Ах разъем, уж много ему внимания:)

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

А кто говорит, что память стоит очень дорого. Не верь. Оригинальный Z80 (сейчас) стоит дороже.

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

Что теперь делать? Все просто. Или забить, профитом получить знания о полной структуре до детальки о Орион. Или дальше фаршировать системный разъем.
Там контактов для 8-битки 50 шт., если с претензиями 64.

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

Ага, 3 вариант забыл. Таки сделать Орион из журнала (со своими идеями, как все упростить, GAL в тему, 2-х портовая память в тему ( можно кешь от 486, со схемой), блин интересно:v2_dizzy_roll:

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

И не понятно, почему все пишут нам нужен VGA на новоделе? Не работает схема у ретро компов на VGA. Вот ни как. Может отписавшиеся о VGA c эмулятором попутали? Всполнил уважаемого Denn, забавный персонаж. Значит, его не смущает VGA, а смущает Z80 и остальные прелести мира. Логика ее понятна.

Denn

18.06.2018, 20:44

И не понятно, почему все пишут нам нужен VGA на новоделе?

Потому что мониторов с ТВ-входом или с RGB нет уже. Совсем нет. А если у кого-то и есть, то портить глаза об 50 гц кадровой нет никакого смысла. Скоро и VGA-мониторы вымрут.
Аналогично с клавиатурой. Проще поставить PS/2.
Да, это всё не феньшуйно, но это не творческая часть 8-битки, поэтому можно закрыть глаза.

П.С. У меня все Орионы с честными ТВ-выходами, но все подключены через довольно дорогостоящие конвертеры к ЖК-мониторам, и на CRT я не вернусь никогда, какого-то бы "феньшуя" это не стоило! Просто потомучто (С)

andreil

18.06.2018, 21:01

Мне как то все виделось в разы проще. Тем боле в двух портовой памяти . Сейчас проблем нет. Сделать поле ЦПУ и Видео - общим.
Откуда взялась двухпортовка? оО У меня стандартная SRAM вообще-то.

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

Потому что мониторов с ТВ-входом или с RGB нет уже. Совсем нет. А если у кого-то и есть, то портить глаза об 50 гц кадровой нет никакого смысла. Скоро и VGA-мониторы вымрут.
Аналогично с клавиатурой. Проще поставить PS/2.
Да, это всё не феньшуйно, но это не творческая часть 8-битки, поэтому можно закрыть глаза.
Вот именно поэтому я и переделывал на VGA - мне вообще некуда подключать это всё, только если через такие же преобразователи (которые ещё и купить надо).

OrionExt

18.06.2018, 21:22

Ладно. Честно. Не ну мне то что. Прикольно наблюдать над тупиковой веткой. Где будут потенциальные последователи F – серию?)

andreil

25.06.2018, 23:28

Ну, раз уж делаю "только для себя", тогда "гулять так гулять!".
Вот эскиз прототипа. (https://image.prntscr.com/image/x48jPmQWRP6QBzRzmRtLZQ.png) Россыпь счётчиков и логики спрятал в CPLD:

Счётчики видео части и их логика - 44 ноги, занята полностью;
Диспетчер памяти (мультиплексоры, арбитраж памяти и ещё парочка "мелочей" - 100 ног, ещё вполне хватает места для дополнительной логики;
Порты процессорной части и вся логика около них - 100 ног - ещё не выделил отдельно, но должно остаться место.

Вне их остались регистры видеовыхода, регистры видеорежимов и банок памяти, а так же сам видеовыход (ATF22V10).
Процессор Z80 в корпусе TQFP-44. ПЗУ представлено чипом 29F040 в панельке. Память - один или два чипа AS7C4098A (512/1024Кб соответственно).
Так же добавил свою разработку - мультикарту. Часть логики будет в CPLD №3, часть - в STM32F407. Функционал - клавиатура, SD-карта, эмуляция ROM-диска (в виде файла на SD-карте или флешке), сетевой интерфейс (отдельной платой с физическим интерфейсом уровня MAC).

Ничего не убралось, всё реализовано как в ПРО (кроме ТГ и работы с памятью).

PS: Засим откланиваюсь и пошел разводить плату. Как понимаю, никому не нужно будет, но штук 8 будут свободны.

Denn

26.06.2018, 12:41

Ну, раз уж делаю "только для себя", тогда "гулять так гулять!"

И это правильно! Живём один раз же :)

OrionExt

26.06.2018, 18:04

Ну чего тут сказать. Господин Волков за вас рад (предположение. что дело простого компа на 2.5Мгц переросло в плоскость выше сотня мега герц).

Как бы еще проще решение. Зачем год своей жизни тратить по вечерам?)

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

И самое что печальное. Заниматься творчеством (там потыкать чего, перепаять) с СМД нет ни какой возможности. Эти чипы только под фен. Попоял и забыл (на полку).

Не я могу и блоху, запаять. Но томогочить (кормить, ноги чесать паяльником) с ней уж увольте:v2_crazy:

andreil

26.06.2018, 19:39

И самое что печальное. Заниматься творчеством (там потыкать чего, перепаять) с СМД нет ни какой возможности. Эти чипы только под фен. Попоял и забыл (на полку).

Не я могу и блоху, запаять. Но томогочить (кормить, ноги чесать паяльником) с ней уж увольте:v2_crazy:
оО А я разве феном паяю? Феном только если сдувать уже запаянное, а так - паяльник в руки и под лупой на штативе и с подсветкой...
Вот кстати - https://yadi.sk/i/YD-wZQNH3YJaMH Собрано за вечер. В цепи USB стоят резисторы типоразмера 0402 (они за проводами) и пара синфазных дросселей чуть побольше. Вполне паябельно паяльником :)

OrionExt

26.06.2018, 20:20

Без обит. Ты сделай прототип, а не мозги поласкай. Аминь.

andreil

01.07.2018, 09:29

Такой вопрос - какие сигналы от Z80 следует подтягивать к +5В, кроме шины данных?
Неактуально - всё это описано в Z80-UM...

andreil

06.07.2018, 23:35

Для тестирования корректности функционирования подсистем пишу более расширенный тест, чем стандартный для ПРО.
На данный момент готовы проверки 6 видеорежимов из 8 - остались только 3-х и 4-х битные.
Результаты 4-х и 16-и цветных режимов:
65691656926569365694
Заодно выводится номер столбца-знакоместа для проверки корректности широкоэкранного режима.
Выбор теста осуществляется DIP-переключателями конфигурации ПРО (не инверсные значения, то есть "флажок" в эмуляторе означает "0" в бите):

Биты 0-2 - номер проверяемого видеорежима;
Бит 3 - активация турбо-режима;
Бит 4 - активация широкого экрана;
Биты 5-7 - не используются. Резерв для тестирования PIO.

Пишу на С, собираю через SDCC, поэтому выходной код не самый оптимальный. Но зато легко и быстро пишутся программы).

PS: Жду CPLD'шки для сборки макетки. А пока - вот таким вот тестом буду проверять симуляцию в FPGA...

andreil

07.07.2018, 21:28

В продолжение темы о тесте - перевёл полностью на ASM. Не требует памяти, работает чисто на регистрах.
6 тестов из 8 уместил в 2Кб - без агрессивных оптимизаций и сжатия, включая шрифт 8*8 для 128 символов.
Собственно, текущая версия теста (исходник и бинарник) - в аттаче, если кому интересно.
65698
О назначении переключателей было написано выше, потому не дублирую.
Прошивается вместо ROM1, которая на 8Кб.

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

PS: Это мой первый опыт на ASM'е Z80, просьба тапками не закидывать -_-

OrionExt

09.07.2018, 18:34

Этаж сколько эта мини платка с смд халявными микрухами (из прошлой жизни) жрет на один см квадратный. Орион-Про отдыхает:v2_dizzy_roll:

andreil

11.07.2018, 11:39

Такой вопрос - насколько актуален объём памяти в 1Мб? Или "всем хватит" 512Кб?
Просто пытаюсь максимально впихнуть в ресурсы по видеопортам и не хватает ячеек из-за "жирного" диспетчера памяти. А выносить часть портов, относящихся к памяти, в другой корпус - не очень хорошо, поскольку они только внутри и коммутируются всё равно.

Denn

11.07.2018, 14:19

Такой вопрос - насколько актуален объём памяти в 1Мб? Или "всем хватит" 512Кб?

Готового ПО под такой объём ОЗУ в природе нет. И ситуация тут следующая. Если бы в Орионе был 1 Мб, то это было бы классно, и, например, я бы в своей ОС с удовольствием поддержал (а точнее сказать, в таком случае вообще пересмотрел бы архитектуру ОС). Но, есть "но"... при условии популярности такой платформы среди пользователей. А мы все понимаем, что этого не случится.. увы.
Поэтому, если технически сложно сделать "метр", то я бы оставил 512 Кб.

andreil

11.07.2018, 16:32

Готового ПО под такой объём ОЗУ в природе нет. И ситуация тут следующая. Если бы в Орионе был 1 Мб, то это было бы классно, и, например, я бы в своей ОС с удовольствием поддержал (а точнее сказать, в таком случае вообще пересмотрел бы архитектуру ОС). Но, есть "но"... при условии популярности такой платформы среди пользователей. А мы все понимаем, что этого не случится.. увы.
Поэтому, если технически сложно сделать "метр", то я бы оставил 512 Кб.
Не то, что сложно, просто я пытаюсь вырезать до минимума необходимого, что бы уместить в 1 чип почти всё, касающееся памяти (порты F9, 08, 04, 05, 06 - стандартный, Z80-Card, Pro). Если порт F9 ещё можно вынести "наружу", то остальные будут реализованы "в чипе", что бы избавиться от ожиданий при обращении к ВВ55, на которых они реализованы в оригинале. Сооружать "эмулятор" ВВ55 на рассыпухе не вижу смысла вообще.

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

Очень много ячеек занимают синхронные счётчики - использовать внешние не позволит количество выводов.
Синхронность релизована "в лоб" - выдачей данных по ниспадающему фронту (счёт - по восходящему фронту). То есть на 10 битный счётчик тратится 20 ячеек, таких у нас 2...

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

Кстати, по портам - порты диспетчера памяти (04-06) софтом только пишутся или ещё и читаются?
Порт 0А, например, читается - тут само его назначение предписывает это (управление RAM, ROM). иначе приходилось бы это же состояние хранить отдельно в памяти для модификации отдельных битов.

LeoN65816

12.07.2018, 07:56

Синхронность релизована "в лоб" - выдачей данных по ниспадающему фронту (счёт - по восходящему фронту). То есть на 10 битный счётчик тратится 20 ячеек, таких у нас 2...
Немножко перефразирую: "Странно как-то ты, дядя Фёдор, бутерброд кушаешь..." (C)
Для синхронного n-битного счётчика необходимо и достаточно n триггеров/ячеек. "Ведущий-ведомый" триггеры в ОРИОНЕ, и уж тем более в счётчиках строк/столбцов, ИМХО, совершенно не нужны...

andreil

12.07.2018, 08:19

Немножко перефразирую: "Странно как-то ты, дядя Фёдор, бутерброд кушаешь..." (C)
Для синхронного n-битного счётчика необходимо и достаточно n триггеров/ячеек. "Ведущий-ведомый" триггеры в ОРИОНЕ, и уж тем более в счётчиках строк/столбцов, ИМХО, совершенно не нужны...
Делал так - в итоге получаю глитчи в реале из-за асинхронности счётчиков и полный разлад всего видеотракта, поскольку возникают "левые" импульсы для счётчика строк. Первоначально я так и было, но при проверке оно работало через раз - наблюдалась вот такая вот картина на счётчиках:
https://image.prntscr.com/image/DsjfHwtwQfS4qxbEubihhg.png

LeoN65816

12.07.2018, 09:16

На картинке не вижу ничего "нехорошего", нет других сигналов, от которых зависят счётчики...

Делал так - в итоге получаю глитчи в реале из-за асинхронности счётчиков и полный разлад всего видеотракта, поскольку возникают "левые" импульсы для счётчика строк.
На всякий случай напомню о синхронности: у счётчиков строк и столбцов должен быть один (!), единственный (!!), общий (!!!) клок, и это должен быть пиксельклок. А вот разрешения клока у счётчиков столбцов и строк должны быть разными, являющимися комбинаторной функцией от предыдущего состояния. Причём, функция разрешения счёта/сброса счётчика столбцов должна являться переменной для функции разрешения счёта/сброса счётчика строк. Вот посмотри и проникнись ;) :

module HVSync (
input wire PixClock,
output reg HSync,
output reg VSync,
output reg [2:0] R,
output reg [2:0] G,
output reg [2:0] B);

parameter HVA = 1024; // Visible Area
parameter HFP = 24; // Front Porch
parameter HST = 136; // Sync Time
parameter HBP = 160; // Back Porch

parameter VVA = 768; // Visible Area
parameter VFP = 3; // Front Porch
parameter VST = 6; // Sync Time
parameter VBP = 29; // Back Porch

//variables
reg [10:0] PC = 0; // Pixel Counter (Column, X)
reg [9:0] LC = 0; // Line Counter (Row, Y)

wire VA = (PC <HVA) & (LC < VVA); // Visible Area on screen

always @(posedge PixClock)
begin
// VA <= ((PC < HVA-1) | (PC == HVA+HFP+HST+HBP-1)) & ((LC < VVA) | (LC == VVA+VFP+VST+VBP-1));

HSync <= (PC >= HVA+HFP-1) & (PC < HVA+HFP+HST-1);

if (PC < (HVA+HFP+HST+HBP-1))
PC <= PC + 1'b1;
else begin
PC <= 0;
VSync <= (LC >= VVA+VFP-1) & (LC < VVA+VFP+VST-1);
if (LC < (VVA+VFP+VST+VBP-1))
LC <= LC + 1'b1;
else
LC <= 0;
end
end

// Color Image

always @(posedge PixClock)
begin
if (VA)
begin
if ((PC[7:0]==0) | (PC[7:0]==255) | (LC[7:0]==0) | (LC[7:0]==255))
begin
R <= 7;
G <= 7;
B <= 7;
end
else begin
if (LC[7:6]==0)
begin
R <= ~PC[9:7];
G <= 0;
B <= 0;
end
if (LC[7:6]==1)
begin
R <= 0;
G <= PC[8:6];
B <= 0;
end
if (LC[7:6]==2)
begin
R <= 0;
G <= 0;
B <= ~PC[7:5];
end
if (LC[7:6]==3)
begin
R <= PC[6:4];
G <= PC[6:4];
B <= PC[6:4];
end
end
end
else begin
R <= 0;
G <= 0;
B <= 0;
end
end

endmodule
Результат здесь (https://yadi.sk/d/sFluusw_3GXZqs).

Error404

12.07.2018, 12:13

Такой вопрос - насколько актуален объём памяти в 1Мб? Или "всем хватит" 512Кб?

В 90-х я заложил в Альтаир-ДОСе карту памяти до 1Mб, при том на реальных клонах у нас было по 512к, которые при наличии электронного диска (он в этом же ОЗУ порта F9) занимали всю память так, что электронный диск был меньше желаемого (т.к. пользовались еще большим количеством разных прог - драйверов, мониторов, плееров и т.п., а они все сидят в памяти доп. страниц). Но тогда у всех были только дисководы и без электронного диска было никак. Сейчас есть IDE, SD - более быстрые и емкие, делай нехочу, и можно обойтись без эл.диска. А вот для UZIX иметь хотя бы 1Мб крайне желательно, ибо там каждый процесс по 60к и на 512к можно одновременно иметь только 5 процессов (из которых один init, т.е. по факту четыре, а если еще иметь и cron, так и вообще - три). Кароче, я за 1Мб в базе и с опцией расширения (если не шибко усложнит).

andreil

12.07.2018, 13:42

В 90-х я заложил в Альтаир-ДОСе карту памяти до 1Mб, при том на реальных клонах у нас было по 512к, которые при наличии электронного диска (он в этом же ОЗУ порта F9) занимали всю память так, что электронный диск был меньше желаемого (т.к. пользовались еще большим количеством разных прог - драйверов, мониторов, плееров и т.п., а они все сидят в памяти доп. страниц). Но тогда у всех были только дисководы и без электронного диска было никак. Сейчас есть IDE, SD - более быстрые и емкие, делай нехочу, и можно обойтись без эл.диска. А вот для UZIX иметь хотя бы 1Мб крайне желательно, ибо там каждый процесс по 60к и на 512к можно одновременно иметь только 5 процессов (из которых один init, т.е. по факту четыре, а если еще иметь и cron, так и вообще - три). Кароче, я за 1Мб в базе и с опцией расширения (если не шибко усложнит).
Посмотрим, но вариант с памятью >1Мб не укладывается в GAL, если рассматривать такой вариант. И в CPLD на 128 ячеек так же не укладывается уже.
В CPLD впихнул почти весь видеотракт:

Счётчики горизонтали и вертикали - 20 ячеек + 8 на логику;
Переключение турбо-режима (и бит порта 10);
Порт видеобанков - 4 ячейки (номер "банки" + бит широкого экрана);
Мультиплексирование адреса для памяти - 19 ячеек;
Арбитраж памяти - 10 ячеек (вместе с управлением буферами к Z80);
Дешифрация портов видео - 3 ячейки;
Порты управления памятью - 44 ячейки.

Расчёты примерные, и не включают в себя ячейки на формирование выходов (ШД + ещё пара), вот и получается "внатяг".

PS: Китайцы-посредники крупно кинули с CPLD - в их фотографиях они были, а к нам не пришли. Будем ругаться по этому поводу, потому что я в минусе на 100$ по ним только. А пока - начал паять макетку на дискретках и ATF (как раз позавчера программатор для них пришел).

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

Кстати, посчитал на бумажке примерные временные задержки в случае использования ATF и быстрой памяти (как у меня, 10нс) - видеоданные будут отставать от синхронизации на 7-40нс, то есть до 1 пикселя смещение.
И очень плохо получается с безвейтовой работой процессора с памятью на частоте процессора 12,5МГц (кстати, мой Z84C0020PEC такую частоту тянет, но греется ощутимо). Дело в том, что длительность импульса записи составляет около 80нс. С учётом задержек в логике и прочем, получаем около 60нс.В итоге, что бы гарантированно иметь доступ к памяти на такой частоте без ожиданий, частота переключения "видео-процессор" для памяти должна составлять 12,5МГц. В противном случае будут "промахи" по записи - в симуляции это было очень хорошо заметно, когда идёт заливка экрана - при первом проходе что-то пропустило и залило потом.

andreil

13.07.2018, 16:01

Из неявных проблем конструкции - буфер между памятью и процессором не получится выполнить на АП6 и прочих буферах. При текущих параметрах необходимы защёлки как минимум на чтение (как это реализовано в ПРО), иначе конец чтения может попасть на интервал доступа видео к памяти. И потеряем байт(ы). В итоге получается сразу 4 корпуса вместо 2-х - по 2 на каждое направление, оба защелки (например, ИР22 или аналогичные).
2-мя защелками, как в ПРО, не обойтись - шина памяти двунаправленная.

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

По поводу памяти - как на счёт использования SDRAM?
Да, для инициализации придётся ставить хоть какую-то CPLD для реализации конечного автомата. Но такую память сейчас можно найти в любом магазине с комплектующими по копеечным ценам.
Из плюсов - большие объёмы с минимальными затратами (легко организовать объёмы от 8Мб и больше, нам интересны только до 4Мб, дальше порты ПРО не дадут адресовать уже).
Минусы:
1) Повышенная тактовая частота - для тактовой процессора 12,5МГц и длительности сигнала записи в 1 такт требуется тактовая частота памяти в 50МГц (работаю над уменьшением до 25МГц, курю ДШ);
2) Менее "паябельные" корпуса для обычных паяльников.

Error404

13.07.2018, 16:05

Из неявных проблем конструкции - буфер между памятью и процессором не получится выполнить на АП6 и прочих буферах. При текущих параметрах необходимы защёлки как минимум на чтение (как это реализовано в ПРО), иначе конец чтения может попасть на интервал доступа видео к памяти. И потеряем байт(ы). В итоге получается сразу 4 корпуса вместо 2-х - по 2 на каждое направление, оба защелки (например, ИР22 или аналогичные).
2-мя защелками, как в ПРО, не обойтись - шина памяти двунаправленная.

ЕМНИП в любом Орионе с Z80 всегда обращение процессора попадает на интервал доступа диспетчера памяти (если поделить время работы с памятью как 50:50). В журнальном Орионе связано с тем, что у Z80 на 20% длиннее сигналы обращения к памяти чем у 8080 под который составлена журнальная схема. Для этого делали доработку "в один порез" на арбитре D13 изменяя эту пропорцию 50:50 на более подходящую. Это чтоб обойтись без регистров (хотя до того были варианты и с дополнительной ИР82 как самое очевидное "решение в лоб". Орион ПРО тут не может быть ориентиром, он весь собран из "решений в лоб" и поэтому в нем 150 корпусов против 65 в оригинальном Орионе).

andreil

18.07.2018, 13:41

Примерная структурная схема текущего варианта Ориона, без части портов, ПЗУ и всех УВВ. Память в обоих направлениях буферизирована регитрами/защёлками для обеспечения корректности данных.
Реализована работа с SDRAM - ради этого пришлось увеличить частоту. По факту память будет тактироваться от 100МГц (через фазосдвигающую цепочку и XOR). В противном случае память не успевает отработать в отведённое время (для чтения и записи требуется 8 тактов). Очень тормозят циклы ожидания - их тут половина, иначе память не успевает по факту (всё по ДШ).

Error404

18.07.2018, 17:20

По факту память будет тактироваться от 100МГц (через фазосдвигающую цепочку и XOR). В противном случае память не успевает отработать

«Ученье - вот чума, ученость - вот прична,
Что нынче, пуще, чем когда,
Безумных развелось людей, и дел, и мнений.»
А. С. Грибоедов «Горе от ума»

Сорян, я не удержался. :)

Не, ну правда, в Спектрумы ставят любую статику на простой защелке CAS (или RAS) на одном регистре. И оно там работает на частотах 3.5 и 7 МГц вот уже как пару десятилетий (это стали делать сразу как статика подешевела) в тысячах экземплярах у нас и за рубежом. При этом базовая схема остается совсем не переработанной, без каких либо изменений. Ну не читали они даташиты - и слава богу, все работает.

Понятно, что тут VGA и поэтому частоты видеоконтроллера вдвое большие, но не вдесятеро же.

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

Думаю, если все так критично, то оправдан уход от "прозрачного ОЗУ" (вейтить проц в угоду видеоконтроллеру, или выправлять плавающей растактовкой проца - на Орионе и такое было в Ташкентском Турбо). Это всяко лучше, чем как в старые времена организовываить рейд на оборонное предприятие дабы выкрасть секретную космическую разработку-ОЗУ, работающую на таких частотах.

Denn

18.07.2018, 17:24

Да уж, ради 10 МГц такта (для ПРО) реального компа вдувать 100 МГц - это жёстко. Я бы пошёл по пути МПС сама по себе, а "видяха" сама по себе. Разумеется через двухпортовку. Как-то сразу всё проще и логичнее выходит. Но это просто мысли вслух, своего мнения ТС не навязываю.

andreil

18.07.2018, 18:36

Думаю, если все так критично, то оправдан уход от "прозрачного ОЗУ" (вейтить проц в угоду видеоконтроллеру, или выправлять плавающей растактовкой проца - на Орионе и такое было в Ташкентском Турбо). Это всяко лучше, чем как в старые времена организовываить рейд на оборонное предприятие дабы выкрасть секретную космическую разработку-ОЗУ, работающую на таких частотах.
Ввод SDRAM - это чистейший эксперимент. И да, они на каждом углу сейчас есть - выпаиваются с любых планок памяти со старого компьютера. На любой барахолке можно купить пачку планок. Так что совсем не дефицит ;)
И да - её имплементация - чистейший эксперимент. Думаю сейчас назад на SRAM вернуть. Думал сэкономить на пинах за счёт мультиплексирования адреса, но не получилось, по сути.

PS: Если не тормозить процессор, то на максимальной частоте (12,5МГц) строб записи получается всего 80нс (сигнал /WR от Z80). SDRAM за это время должна отработать все 7 тактов цикла записи (IDLE, RAS, NOP, NOP, CAS, NOP, NOP). Без NOP'ов не получится (даже без 1) - сразу не работает и всё. Если тактирование скинуть до 50МГц, тогда можно выкинуть их часть - завтра с этим и буду крутить, как получится.
Пока что работает стабильно, но чтение памяти процессором не проверял вообще...