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

[ivagor]

Извините за частичный оффтоп, но если уж хочется usb-клавиатуру и некий канал связи с внешним миром, то использование для этого соответствующего микроконтроллера в принципе может позволить еще и эмулировать контроллеры fdd и hdd (и наверно еще что-нибудь, надо подумать). Как понимаю это не соответствует идеологии данного проекта, но мне подобное решение представляется очень хорошим вариантом, если нужен максимум функционала и удобства при минимуме размера. Возможно кто-нибудь использует подобный подход в своем вариант реинкарнации вектора.

[svofski]

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

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

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

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

Видеовыход, например https://github.com/holmatic/video_if_ql_vga

[megov]

Мдя. Плохо пока дизайн лезет в EPM128S. Еще нет регистра кваза (+6LC) и, собственно, маппера кваза (+?LC), 3х8 буферов временного запоминания байт видео перед сдвигами, возможные 2LC на попарно-пиксельные задержки для 512x256 и схему подстановки ПЗУ (2-3LC).
Занято 116/128LC. Пинов тоже мало остается 76/84. Поблочно ситуация следующая:
- D35/ИЕ7 - 6LC, нормально, поскольку клок не 12, а 48МГц.
- D36/РЕ3 - 9LC, средне, надо смотреть, что там Квартус напилил.
- D4-D5/старшее видео - 9LC, средне, должно быть 7 бит счетчиков и 7LC, туда я внес и D5.1 делящий до 7812.5Гц
- D6-D7/младшее видео - 9LC, триггеров 8, одна ячейка могла уйти на обратные связи.
- 4 сдвига по 8 бит - 32 LC, на симуляции пока неясно, как работают, тестбенч не написан.
- декодер IO съел 8LC, хотя чисто комбинаторный.
- мультиплексор RAM - 16LC. Фигня спорная. Втаскивать или не втаскивать всю CPU ША в CPLD - это открытый вопрос.
8 бит для декодера IO нужны все равно, для маппера кваза как RAM нужны еще минимум 2х бит адреса (A13/A14?),
дополнительно прямо тут есть идея как задешево сделать a-la Speccy 128 - 2 комплекта каждой страницы экрана.
Выводить все равно - 18 бит адреса SRAM для 512к чипа.
- счетчики скроллера D24/D25 - 16LC. Вообще на пустом месте... Понятно, конечно, что синтез на счетчиках с предзагрузкой
делает 8LC на загрузке и 8LC для счета.

Пока мысли следующие - вынести адресный мультиплексор CPU/Video и счетчики скроллера в жесткую логику,
второй кандидат - IO декодер, его отправить в GAL22V10.
Хоть и сумбурно, но, как-то так.

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

Пошел курить RTL Viewer и Chip Planner.

[backa]

RPi Pico лежат две штуки, ждут. Но это ровно тоже самое, что поставить STM32F411 (если я правильно вспомнил конкретный младший
чип с USB хостом у CТМ) - из пушки по мелким птичкам.

ну так если они уже есть в наличии - попробуйте TinyUSB. Работает как положено. Я адаптировал к спектруму в связке с CPLD - никаких вайтов и внутренних сигналов - тупо вместо родной матрицы клавиатуры..

[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Гц - не обсуждается. Должно быть.