Не реклама, просто создан канал в телеграме по вопросам изготовления современной реплики ПК-6128ц++, кому интересно -- подключайтесь: t.me/Vektor6128Cpp
Вид для печати
Не реклама, просто создан канал в телеграме по вопросам изготовления современной реплики ПК-6128ц++, кому интересно -- подключайтесь: t.me/Vektor6128Cpp
Сделал ещё одну доработку ПК-6128ц -- заменил-таки резисторный видеоЦАП на чип. Но не на ADV7120, который стоит достаточно дорого, а на его дешёвый китайский аналог SDA7123, упоминание о котором я случайно встретил в инете. Аналог, кстати, на али стоит раз в 10 дешевле оригинала, примерно как набор резисторов для того же видеоЦАП Вектора.
Вот так сейчас выглядит эта тестовая доработка:
https://s1.hostingkartinok.com/uploa...58b8be57dc.png
Фото изображения на телевизоре после доработки
https://s1.hostingkartinok.com/uploa...9ef030048f.png https://s1.hostingkartinok.com/uploa...1198d93b52.png https://s1.hostingkartinok.com/uploa...d8f3cf0c8c.png https://s1.hostingkartinok.com/uploa...b0d962700f.png
Уточню, что подключение было через S-Video.[свернуть]
Что сразу заметно: изображение стало насыщенней, полностью пропали "просветки" отключённых плоскостей. Всё-таки в этих "просветках" была виновата сама схема ЦАП Вектора, и даже не погрешность резисторов, а, скорее, характеристики микросхемы К155РУ2 -- её ячейки имеют разные токи утечки, токи при передаче данных, что приводит к тому, что при равных записанных значениях яркость пикселей отличается. Не предназначена она, в общем, для работы в аналоговых цепях.
Да, после доработки палитра стала немного отличаться -- это заметно на градиенте серых цветов, некоторые стали немного "синить", а некоторые наоборот, "желтить", готов в этом направлении получить неодобрение от сторонников истинной Векторовской палитры, но, считаю, что эти искажения несущественны, доработка того стоила. Кстати, в Вектор-Турбо тоже используется чип ADV7120.
Проект на гитхабе (схема, разводка) обновлён, но релиз там не делал -- ещё пока рано...
В это сложно поверить так сразу, по-хорошему надо проверять. Но для вектора или 6128 это получается уже не нужно, возможно кто-нибудь займется этой отдельной задачей.
С другой стороны можно вспомнить про разные задержки из разных ячеек при использовании некоторых пзу для замены плм. Если тут также, то получается вместо озу с ОК лучше было использовать озу+тактируемый регистр с ОК на выходе данных.
По факту, чипы ADV7123 как раз и имеют внутри такой регистр...
Интересно, почему разработчики эмуляторов не обратили внимание на эту особенность Вектора? В эмуляторах есть всякие фильтры, делающие изображение похожим на старый телевизор, а эмуляции "просветки" нет... :)
- - - Добавлено - - -
Кстати, тактируемый регистр на входе ЦАП даёт ещё один плюс: с ним чётные и нечётные пиксели становятся совершенно одинаковыми по ширине (фоток для подтверждения не делал, но, думаю, и так понятно).
В эмуляторах кроме VV нет даже такой обязательной для (всех?) векторов штуки как эмуляция зон непрограммируемости палитры. Ну а оригинальных зон для 06Ц и .02 нет ни в одном эмуляторе.
А вот разные точки режима 512 и просветы я бы поставил на 2 и 3 место по значимости неподдерживаемых фич. Отсутствие поддержки некоторых непринципиальных особенностей изображения характерно не только для вектора, но для таких монстров, как С64. Эмуляторы с поддержкой jailbars надо еще поискать. Хотя я давно не погружался в комод, может ситауция изменилась.
Да, они шире и так и должно быть, т.к. в VV зоны непрограммируемости по моему бывшему реалу, который был модифицирован по методу Tim0xи. Соответственно укоротились ССИ и зоны непрограммируемости. А полный тест немодифицированных 06Ц и .02 никто не делал. Или делал, но результатами не поделился.
То, что я написал, может выглядит как упрек эмуляторостроителям, но конечно тут комплексная задача.
1. Нужен продвинутый и заинтересованный реальщик, который напишет и прогонит тесты, а потом выложит результат, доступный для реализации и проверки. Казалось бы тесты может написать и кто-то другой, но задача объяснения, как ими пользоваться может оказаться сравнимой по сложности с тем, чтобы написать самому.
2. Реализация в эмуляторах. Пример VV показывает, что это вполне возможно.
Если фантазировать без привязки к реальности, то можно например придумать вариант переделки вектора для возможности чтения из РУ2. Тогда можно сделать автоматический тест, но этот вариант уж совсем из области фантастики.
Теоретически, можно написать тест, который будет менять палитру в каждой строке, причём в каждой строке задержки делать разными со сдвигом, а по картинке судить, в каких строках палитра не программируется. Тогда этот тест сможет запустить каждый обладатель реала, и не вникая в тонкости просто показать фото экрана...
Не все так просто.
1. Есть разные варианты строк по паттернам непрограммируемости. В моем модифицированном реале (и в VV) 4 "типа" строк (или 3 с половиной, смотря как считать).
2. Часть строк не отображается на экране. И как раз там "особенные" паттерны непрограммируемости.
- - - Добавлено - - -
В принципе возможен тест, результаты которого записываются на видео, так можно восстановить полную картину.
Да, можно и видео. Примерно так: рисуем 16 полосок (квадратиков) по цветам, обнуляем палитру и пишем по одному цвету в прерывание, каждый раз с разной задержкой. Потом снова обнуляем и снова пишем, с другими задержками, пока не пройдём весь диапазон. Ну ещё какая-нибудь метка с номером теста на экране не помешает, чтобы не гадать потом по кадрам видео.
Про 16 цветных полосок/квадратиков я не понял.
Для ориентировки на экране надо отображать два числа: номер строки и позицию в строке, в которой программировали РУ2 в данном прерывании.
Поясню свою мысль... Области непрограммирования палитры находятся же в пределах КСИ, значит можно сделать до 16 записей за кадр, посмотреть результат, какие записи прошли, какие нет на этих 16 полосках/квадратиках/строчках, каждой из которых назначен свой цвет из 16. Допустим, мы знаем, что цвет №5 записывался в палитру через N мкс после прерывания, и если квадратик остался чёрным, значит это место непрограммируемости. Потом сделать паузу для снятия скриншота и повторить с другими смещениями... Наверно, можно количество таких замеров за один кадр увеличить, если использовать мультиколор, но я не особо представляю, как.
Понял, речь о "пакетном" тестировании для ускорении теста, чтобы видео было покороче. Я бы сам не стал, так сложнее сделать правильный тест и сложнее интерпретировать результаты, но это мои субъективные предпочтения.
Немного занудства - не только в пределах КСИ, но и ССИ, если речь про 06Ц и .02.
Я посмотрел схему -- похоже, зоны непрограммируемости палитры определяются наличием "1" на сигнале синхронизации, значит для первого Вектора без доработок они будут выгядеть так:
Вложение 82135 Вложение 82136 Вложение 82137
Вверху сигнал 50Гц, внизу -- синхронизация, сигнал снят с выв.2 К155РУ2 (Д32 / Д39). Зоны непрограммируемости, получаются, по ~10мкс и ~27мкс при КСИ с частотой следования строк.
- - - Добавлено - - -
Для 02 Вектора ССИ будет в два раза меньше, но подтвердить измерениями не могу в связи с его отсутствием у меня. А на ПК-6128ц я тут приводил расчётный график непрограммируемости -- он тоже свой. ПК-6128ц++ таких зон не имеет.
Продвижения по проекту:
- Собрал внутренний контроллер НЖМД, причём сразу в двух вариантах, с разъёмом IDE и под CF-card.
https://s1.hostingkartinok.com/uploa...b85ea16803.png https://s1.hostingkartinok.com/uploa...581e857c58.png
В ходе сборки пришлось переписать TESTHDD -- никак не мог разобраться, почему контроллер глючит, а оказалось в итоге, что это просто брак пайки. :)
Свежая версия: Вложение 83346, и она же с исходниками выложена тут: github.com/ImproverX/TESTHDD-for-Vector06c
- Опубликовал альтернативную схему блока памяти с регистрами на 74HC597, что даёт возможность разнести такты обращения графической подсистемы к ОЗУ.
Установка данного модуля взамен стандартного возможна в любой версии плат ПК-6128ц++, но в схемах до 27.01.2025, из-за отсутствия в схеме ОЗУ-Т2 сигнала /CAS, не будут работать внешние квази-диски (на ВУ).
По тестам, выравнивание с кратностью равной двум тактам (вместо стандартных четырёх), даёт основное преимущество на командах:
- CALL, C*-Y/N
- DAD
- DCX, INX
- PUSH
- R*-Y/N
- SPHL
- RST*
А также на недокументированных командах процессора 8085:
- DSUB
- LDHI, LDSI
- RDEL
- RSTV
Всё, что относится к проекту, выложено на гитхаб.