Новый реверс Вектора 06Ц.01 и возможная реинкарнация

[megov]

Если уж менять процессор, то может сразу на z80?

Как один из вариантов. Но Z80 с точки зрения логики шины сильнее отличается от BM80, могу не осилить.
8085 явно ближе и, кроме того, прямо сейчас у меня уже есть 1821ВМ85. Поэтому как только распаянный Вектор
соберется обратно, можно попробовать посмотреть на работы орионовцев на этом направлении.
Там был дизайн, который пин-в-пин вставлятся в панельку ВМ80, вот его и можно быстро развести и попробовать.
Вплоть до МГТФа на макетке.

[Advertiser]

[ivagor]

Поэтому как только распаянный Вектор
соберется обратно, можно попробовать посмотреть на работы орионовцев на этом направлении.
Там был дизайн, который пин-в-пин вставлятся в панельку ВМ80, вот его и можно быстро развести и попробовать.

На мой взгляд проще отталкиваться от векторовских вариантов (1,2,3) замены на z80.

Но Z80 с точки зрения логики шины сильнее отличается от BM80, могу не осилить.
8085 явно ближе и, кроме того, прямо сейчас у меня уже есть 1821ВМ85.

Есть пара серьезных проблем одинаковых при замене в векторе 8080 хоть на 8085 и z80:
1. Сигнал "СТЕК" (его отсутствие)
2. Другие тайминги некоторых критичных для программирования палитры и обмена с магнитофоном команд.
Если уж бороться с этими проблемами, то 1) для z80 есть примеры решения и 2) z80 дает больше плюшек в программном плане.
Хотя при замене на 8085 можно плюнуть на квазидиск и ориентироваться на ПК-6128Ц, но это уже совсем другая история.

[megov]

Мда. Посидел в KiCad часа три-четыре, накидал и начал разводить замечательные pin-to-pin схему/схемы включения 8085 в сокет 8080, найденные у орионовцев.
Параллельно думал над указанной ivagor проблемой со STACK, который теоретически хотелось бы тоже эмулировать на 8085.
И как-то одно с другим совпало, и я прифигел, что у орионовцев не подключены на сокете 8080 INT/INTE,
а потом прифигел еще больше, увидев на 8085 никуда не идущие IO/~M, S0 и S1!!!

Фиг с ним с INT/INTЕ, мало ли компов без прерываний, но как без IO/~M то в порты писать!!! Неужели?!
И таки да, у них MMIO на 64 кбайтах адресного пространства!
Потом нашел описание, где говорилось, что нет контроллера прерываний, нет декодирования слова состояния
и нет отдельного IO, оно отображается на память. И все - для упрощения конструкции. Нет, с точки зрения элементной базы
создатели Ориона правы, как и были правы создатели Вектора - куча доступной рассыпухи решает, я тоже в 88-90 году будучи
школьником в областном центре офигевал от ВВ55/ВТ57/ВГ75/ВН59/ГФ24 в "простом радиолюбительском компьютере всего
на 29 микросхемах".

В результате возвращаемся к тому, что интел правильно писал тогда в MCS80/85 Reference Manuals о том, что замена одного CPU на другой
проходит не на уровне pin-to-pin (или около) замены, а поперек набора системной логики. И, если STACK можно попробовать вытащить
на мелкой ПЛИС из сигналов цикла шины и (!) опкодов на этапе Opcode Fetch, то "вталкивать фарш обратно", пытаясь выставить на шину
данных под активный SYNC собранное из разных источников синтетическое слово состояния - я не готов.

А без этого невозможна замена в сокете 8080 на 8085. Ну кроме отдельных, специфических машин.

[ivagor]

Один из плохо исследованных векторов усовершенствования Вектора — изготовление pin-to-pin совместимой замены 8080 на ПЛИС.

Вектора - да, но в принципе успешный эксперимент был, только там сейчас похоже ссылки протухли. Но проц Vslava остался, если что.

у орионовцев не подключены на сокете 8080 INT/INTE

Насколько помню в варианте радио они формировали INTE для совместимости по звуку. В вариантах установки z80 в вектор формируют (с той или иной степенью успешности) все необходимые сигналы, в т.ч. стек. Для 8085 это тоже более-менее возможно, но тут я лучше дальше не буду развивать, чтобы на слове не поймали (в плисе я бы скорее всего сделал, но в плисе то все сделают). Вопрос скорее в другом, сколько времени будет потрачено на проект. Одно дело реверс и воспроизведение, а тут уже модификация.

[megov]

Спасибо ivagor, svofski и backa за пинки в стороны RP2040/STM32F401.

Исходная идея с CH558/559 была найти максимально дешевый USB хост под клавиатуру. По пять штук чипы с али стоили по 80 рублей за старший. Оттого и занялся.
Сейчас курю даташит на RP2040, очень интересно они там напилили. Я не сильно шарю в контроллерах, но есть ощущение, что разработчики туда "дрожжей-то подкинули".
Выделенная QSFP под флеш с прямым исполнением, два M0 Core (и я пока не понимаю как там с ними работать, особенно при синхронизации), ну и PIO приколен изрядно.

Дабы не уходить от темы, вкину идею, применительно к Вектору (сама идея не моя, где-то встречал а просторах): что, если ловить конечным автоматом на PIO все записи
в видеопамять (как делал коллега Improver) и получить, тем самым, зеркало видеопамяти в SRAM RP2040. А отдавать оттуда куда-нибудь в UVC device. Там правда в спеке UVC 1.5
я не нашел прямых RGB форматов, поэтому придется в YUV конвертить, видимо.

Нафига? Уйти от стандартного видеовыхода и не пытаться вложить 312p/15625/50 в какой-то из VGA/VESA форматов (тем более что с 50 герцами кадровой и у ZX Evo были трудности
с подбором мониторов). Дрова для видеокамеры есть в любой системе сейчас, отдельного моника/ТV не надо. Компы есть везде.

Посему, вопросов к коллегам ровно два:
- стоит ли идея воплощения?
- сохранить ли при этом классический видеовыход?

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

Вдогонку. Вчера прикидывал простой апскейлинг разрешений Вектора на VGA/VESA форматы. Как там в мультике про щенка в деревне? "Много думал" (С)
Если я правильно понимаю задумку Темиразова с Соколовым, то оба растра, и 256x256 и 512x256 должны быть квадратными, с соотношением сторон 1:1
и квадратными пикселями для основного разрешения и 1:2 для 512 pix. Что ложится на стандартные 4:3 и целочисленный дабблинг не очень хорошо.

Из того, что более-менее целочисленно подошло для основного разрешения - 1024x768@60Hz с пиксельклоком в 65MHz, что уже напрягает. Вертикально - 3x,
горизонтально тоже 3x c полями по 128 точек слева и справа. Соотношение сторон должно сохраниться. Но в эту схему плохо помещается 512х256.
Горизонтально можно сделать 2х и попасть нормально, но уплывет соотношение сторон.
Есть еще VESA 768x576@60Hz. По вертикали имеем двойное сканирование в 512 линий всегда и по 32 неиспользуемых линии сверху и снизу.
По горизонтали - 512 точек в 512 режиме 2x для 256 точек и по 128 точек поля. Вроде в обоих случаях растр будет 1:1. Но вот какова поддержка
такого разрешения на устройствах?

Так и возникла идея хватать записи в видеопамять и делать из них нечто типа video-over-usb, которое в стандарте зовется UVC.

[svofski]

Вектор это только 50Гц. Любая попытка прикрутить его к 60 Гц приведет к морю слез. Зачем это нужно? Все телевизоры, которые понимают PAL сигнал, понимают 50Гц. Внутри себя они наверняка все приводят к 60, потому что они родом из NTSC-вселенной, где все кратно 60. Это крайне досадно, но раз уж они это делают -- пусть их, зачем самому пытаться в это встрять? Лучше никак не получится.

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

Про QSPI (не уверен, что такое QSFP) под флеш в пипико не стоит особенно мечтать, логически она вся суть внутренний ресурс и присосаться к ней по-моему никак особенно не получится. Но можно реализовать что-то свое на PIO. Сделать дополнительную память на PSRAM по-моему тоже не получится. Вернее это можно, но будет страшно медленно. Если надо больше памяти, все-таки с esp32 сейчас трудно поспорить.

Два ядра на rp2040 -- проще не бывает. Берешь и запускаешь функцию во втором ядре и она там работает, пока не перестанет. Все настолько просто. Разумеется у двух ядер полная свобода вставлять друг другу палки в колеса. Чтобы было аккуратно для синхронизации есть специально оборудованные очереди.

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

Сделать из Вектора USB-вебкамеру, это было бы ржачно.

[megov]

> Сделать из Вектора USB-вебкамеру, это было бы ржачно.

Дык идея-то и пришла, именно в таком воплощении.

За QSPI vs QSFP, сорри, опечатался. В наших краях это как раз SFP/SFP+/QSFP/SFP28 и всё такое вплоть до ста гигабит в одной струе
Тут, скорее про то, что разработчики поступили правильно - совсем обособив флеш. Везде, где встречал - наоборот: втащить! А ежели не лезет,
так у нас и постарше камушки есть... Сегментация рынка, туды её.

Я еще не весь мануал скурил, но с помощью PIO переварить обращения, я думаю, что можно.
Никто не запрещает воткнуть 3х 74164 на входе и латчить их по обращениям CPU, а уж из них последовательно добывать адрес и данные на запись.
Я так пытался эмулировать slave-side интеловские 8041/42 на атмеге...

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

Да, 50Гц - не обсуждается. Должно быть.