Так что я бы взял регистр на 4 бита (ТМ8, ТМ9).

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

А то боюсь новая байка может родится :)

Тут все-таки важно с водой ребенка не выплеснуть :)
1) Изначально была взята оригинальная программа и реальный Агат, все это подключили к GBS и возникла проблема - срывы синхронизации.
2) В программе убрали переключение режимов и проблема исчезла.

Если бы все работало отлично, то никакие патчи ничего бы не изменили. Значит, как минимум, проблема существует.
Я сам время от времени наблюдаю такие "уплывания" картинки на своей плате и на платах, которые попадают на ремонт. Значит, это не проблема одного конкретного Агата.
Ну и если посмотреть схему, то можно даже найти конкретное место, которое может вызывать сбои в работе ДК.

Для начала надо вспомнить, как работает ПЗУ. Это матрица ячеек. Когда на ПЗУ подается адрес, с помощью дешифратора выбирается строка матрицы, а с помощью мультиплексора - столбец. В тот момент, когда входной адрес меняется, предыдущие строка и адрес выключаются, а новые включаются.

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

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

Так, теперь к дисплейному контроллеру :)
Он в девятке весь собран на автоматах, использующих ПЗУ.
Но это полбеды. Беда в том, что ДК имеет свой тактовый генератор, а ЦП - свой (режим Apple не рассматриваем!).
Теперь смотрим схему. На входы 1, 2, 3 ПЗУ D84 и входы 1, 2, 3, 4 ПЗУ D85 приходят сигналы с регистра управления ДК (РУПДК), а на входы 23 - сигнал ПА. А на входы 5-8 приходят сигналы с регистра D87.

Сигналы с регистра D87 в режиме Агат привязаны к тактовому генератору 10.5 МГц. А сигналы с РУПДК привязаны к тактовой частоте ЦП (14.3/14 МГц). В результате:
1) момент изменения режима ДК никак не синхронизирован по времени с работой автомата
2) этот момент все время плавает. Между моментом, когда процессор запишет данные и моментом, когда регистр D87 защелкнет данные с выхода ПЗУ может пройти меньше времени, чем требуется ПЗУ. И в этом случае в регистр попадет мусор. Потом этот мусор попадает на вход генераторов синхронизации D61 и D62 и вот мы получаем сбой синхронизации.

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

Кстати, тому, что "всё работает отлично" может быть объяснение. Не исключено, что разработчики в каких-то поздних версиях девятки эту проблему пытались "лечить". Странно только, что от этих версий не осталось ни схем, ни прошивок.

А то боюсь новая байка может родится :)

Главное - чтобы эти исправленные программы не пошли в мир - тогда бардак ещё усилится. Есть компьютер, есть программы, написанные под определённую конфигурацию компьютера. В эту же конфигурацию входит и дисплей. И если это работает нормально, а с изменённой конфигурацией - нет, то и причину нужно искать не в программе. Это всё равно, что лупить лошадь, которая не может сдвинуть повозку вместо того, чтобы убрать часть груза - лошадь ведь не виновата, в том, что на неё навалили слишком много.

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

P.S. Даже сам заголовок "Реально ли исправить софт Бадера, чтобы не дергался экран GBS82XX ?" подразумевает, что нужно что-то исправлять. А зачем исправлять, что там не так?

А то боюсь новая байка может родится :)

https://t.me/agatcomp/22519

Сами программы исправленные вот тут можно скачать, в HFE, для Готека: https://disk.yandex.ru/d/xreeQhHXe5ObiQ и часики там же в AIM.

Реально кстати при переключении из текстового в графический режим на часиках видно тоже подергивание кратковременное. РЕально при переключении режима есть незначительный срыв синхронизации. Но это уже не страшно, страшно когда постоянно )))

electroscat: откуда ты берёшь синхронизацию ? Всё только с "RGB"-коннектора Агата или с "Видео" ?
Нет ли какого -то подмешивания видеосигнала в синхро ?

Доброго времени !
Синхру я беру с сигнала видео, но от него отрезаны резюки в которых цвета и яркость, то есть там исключительно синхронизация без примесей. Все это у меня подается на разьем RGB вместо сигнала яркости, я его не использую, а пин у меня задействован под синхронизацию.

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

Если здесь тот же эффект и на него даже реагирует CRT-моник, то это очень любопытное наблюдение.
Ведь для девятки были проги с режимом совмещения видео, а значит, у их авторов всё работало чисто. Почему-то.

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

Речь идет про девятку и систему the BEST (http://agatcomp.ru/agat/Software/OsDos/TheBest.shtml).
На семерке действительно синхроимпульсы генерируются счетчиками, при смене режима ДК их работа не меняется и срывов синхронизации там быть не может.

Но в девятке синхроимпульсы генерируются автоматами, сделанными на ПЗУ. Одновременно эти автоматы делают кучу другой работы, поэтому их работу приходится менять при переключении режима ДК. И иногда это загоняет их в неправильное состояние. Причем, это видно и на ЭЛТ тоже (картинка "прыгает").

По большому счету, это недоработка в схеме девятки. Там не хватает логики, которая переключала бы режим ДК только в "безопасные" моменты. Ну или нужно что-то исправлять в прошивках, чтобы синхронизация не терялась.

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

2electroscat: откуда ты берёшь синхронизацию ? Всё только с "RGB"-коннектора Агата или с "Видео" ?
Нет ли какого -то подмешивания видеосигнала в синхро ?

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

Благодарю за ваш ответ !
Да, у меня и такие мысли были тоже, что при переключении режима вероятно происходит какая то задержка синхронизации, или типа того. GBS вообще очень плохо реагирует на подобные вещи.
Сам не разберусь, но один хороший человек взялся, говорит что уже нашел прерывания, и вполне сможет убрать переключения. Опубликую тут если получится, мало ли может у кого то еще проблемы подобные возникнут.

Таким устройствам удвоение количества пикселов, причем только в семи - восьми строках кадра - как удар по голове...

Вообще-то для таких устройств как GBS совершенно по барабану число пикселей в строке. У него внутри есть свой тактовый генератор и GBS сам решает, где во входной строке пиксели.
Вот на что ему не по барабану - так это на равномерность поступления синхроимпульсов. Если синхроимпульсы не идут через строго одинаковые интервалы (64 мкс для горизонтальных и 20 мс для вертикальных), то картинку будет "срывать".

Мне кажется, что проблема тут в переключении режима Т32/Т64. Синхронизация в этих режимах совершенно одинаковая, но в сам момент переключения может сбиваться работа дисплейного контроллера. ЭЛТ монитор в силу инерционности развертки обычно не успевает на это среагировать (хотя иногда успевает и это видно), а GBS, видимо, реагирует всегда.

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

https://t.me/agatcomp/22365
https://t.me/agatcomp/22369
https://t.me/agatcomp/22385