Скорее всего, из-за размера пикселя. Даже если взять режимы 256x256 на Агате и 256x192 на Спектруме, то агатовский пиксель будет на треть шире. У Агата видимая часть строки отображается за 48.8 мкс. У Спектрума - за 36.6 мкс. То есть, на одном и том же мониторе или телевизоре ширина картинки Спектрума будет 75% от ширины картинки Агата.

А в случае режима 128x128 площадь агатовского пикселя получается в 5.33 раза больше, чем спектрумовского.

Кроме того, по моим подозрениям, тут еще и наличие бордера на Спектруме влияет. Дело в том, что у кинескопных мониторов и телевизоров размер картинки зависит от её яркости. Грубо говоря, если на черном фоне нарисовать белым цветом прямоугольник без заливки внутренней части, то его видимый размер будет меньше, чем такого же прямоугольника с заливкой.

Величина этого изменения зависит от тока лучей кинескопа и скорости реакции выходного каскада строчной развертки. А ток лучей зависит от яркости картинки.

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

Короче, вертикальные края у реальной картинки на кинескопе всегда немного волнистые. Насколько я помню, к телевизорам даже есть требование, чтобы изменение размера от яркости не превышало 5%.

И когда страницы переключаются, эти "волны" могут совпадать не точно. Как результат, и пиксели из разных фреймов могут совпадать неточно. Причем, это расхождение растет по краям экрана и исчезает в центре.

Вот тут бордер на Спектруме может улучшать ситуацию: во-первых, из-за него картинка находится дальше от края экрана где расхождение пикселей меньше. А во-вторых, поскольку бордер всегда одинаковый и занимает 25% строки, то уменьшается разность среднего тока лучей между соседними строками. В результате меньше меняется размер картинки.

Ну и возвращаясь к Агату: когда в режиме 128x128 фреймы переключаются на каждой телевизионной строке, то в два раза снижается площадь пикселя, а средняя яркость по двум строкам получается одинаковой для соседних кадров.

Надеюсь, объяснение не было слишком заумным :)

Да, ну и у ЖК мониторов этих проблем с размером просто не существует. Думаю, там переключение кадров работает лучше, хотя сам не видел.

Это программный режим.

Теперь понял, вопрос снят.

Режим 128x256 сам по себе - это аппаратный режим, или программный?

Это программный режим.
Аппаратные режимы Агат-7: 64x64 и 128x128 16 цветов и 256x256 ч/б.
Аппаратные режимы Агат-9: 128x128 16 цветов, 256x256 4 цвета, 256x256 ч/б и 512x256 ч/б. Плюс режим Apple HGR.

Спасибо!

Гигаскрина с платой палитр? Технически, там та же проблема, что и с режимом 128x256 - поскольку переключение страниц надо делать каждую телевизионную строку

Я не совсем понимаю, для чего делать переключение страниц надо делать каждую телевизионную строку. Режим 128x256 сам по себе - это аппаратный режим, или программный?

Формирование палитры для каждого блока в идеале должно происходить на основе пикселей блока. Но это приводит к тому, что палитры предыдущего блока и текущего могут сильно отличаться, и как следствие - хорошо различимые полосы. Extra lines определяет кол-во дополнительных строк сверху и снизу от текущего блока, пиксели которых участвуют в формировании палитры. Это делает палитру несколько бедней, но позволяет размыть границы между блоками.

Ок, а что по поводу гигаскрина 128x128?

Гигаскрина с платой палитр? Технически, там та же проблема, что и с режимом 128x256 - поскольку переключение страниц надо делать каждую телевизионную строку, а прерывания приходят только раз в 8 строк, то длительности надо мерять программно. И необходимость подгонки по числу тактов съедает время, которое нужно для обновления палитры. В результате тактов не хватает.

Вообще, мне кажется, режим HAM интереснее. Технически тут так же доступно до 256 цветов, как и с гигаскрином. Но этот режим должен быть более совместим с эмуляторами. И на реальном железе картинка не должна мерцать.

И еще хотел спросить, а что делает параметр Extra lines? Я вижу, что он влияет на формирование палитры, но хотелось бы знать точнее.

Сюда бы Флойда со Стейнбергом.

Можно и пресвятого Флойда использовать. Верхний ряд - обычный режим без/с Флойдом, нижний ряд - новый режим (я обозвал его HAM):

Ок, сделал.

На выходе FIL файл размером 9256 байт:

-заголовок - 44 байта.
-непосредственно пиксели - 8192 байта. Первые четыре строки используют нижние восемь цветов палитры, следующие четыре используют верхние восемь цветов палитры, следующие четыре снова используют нижние восемь цветов, и т.д.
-палитра, состоящая из 32 блоков - 768 байт. Каждый блок состоит из 8 цветов, записанных последовательно: R0, G0, B0, R1, G1, B1, R2, G2, B2, ...
-футер 252 байта в специальном формате (с) garnizon. В качестве кода палитры используется недокументированное значение 0xE.

Конвертер. Он может не только создавать FIL файлы, но и открывать их для импорта. Также FIL графику можно смотреть с помощью плагина для TotalCommander.

Ок, а что по поводу гигаскрина 128x128?

Я думал будет сильно хуже, но получается довольно неплохо. Хотя, конечно, все сильно зависит от исходного изображения.

Ух ты! Очень здорово получилось! Особенно самая верхняя и самая нижняя четверти картинки. Я думал, что этот подход будет нормально работать только с картинками типа заставки Buena Vista https://www.closinglogos.com/page/Buena … Television.
То есть, градиент на фоне, плюс не слишком сложная картинка на переднем плане. А тут практически фотография.

В середине картинки, конечно, ограничение на 8 цветов сказалось - бандинг полез. Сюда бы Флойда со Стейнбергом. Правда, большой вопрос, как тут выбирать исходные цвета. Просто брать самые частотные цвета плохо - на мелких деталях цвета будут теряться. Надо как-то учитывать, используется ли цвет для отображения контрастных деталей, и поднимать ему приоритет. Ну или можно попробовать просто взять и принудительно включать в палитру самый темный цвет из блока.

Изменения палитры можно сохранять просто как массив из 32 элементов по 24 байта (8 записей R, G, B). Упаковывать не нужно, все равно для показа картинки придется распаковывать, а экономия нескольких сотен байт при объеме картинки 8 Кб, мне кажется, смысла не имеет. Удобнее сохранять все в один файл, чтобы потом не потерять ничего.

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

Для сравнения слева на право сверху вниз
1) Оригинальное изображение
2) Обычный режим 128x128 с Флойдом
3) Обычный режим 128x128 без Флойда
4) Новый режим

В каком формате сохранять изменения палитры? В виде отдельного файла или вместе с картинкой? Что по поводу 128x256?

Так, вроде это моя идея была

Ок, не буду оспаривать авторство :) Просто увидел я это предложение у garnizon.

8 цветов это прям не очень густо. Но я попробую реализовать.

Не совсем понял. В строке можно менять произвольные 8 цветов или только последовательно идущие 8?

Так, вроде это моя идея была http://forum.agatcomp.ru//viewtopic.php?pid=3136#p3136. Вот только надо вспомнить, что я там 4 года назад придумал :)

Речь вроде бы шла про режим 128x128 16 цветов при наличии платы цветовых палитр. У платы палитр есть 48 регистров цвета. Их можно перепрограммировать в процессе отображения кадра.

С этим есть проблема - время обратного хода луча в графическом режиме - 12,8 мкс. Этого мало даже для перепрограммирования одного регистра палитры (один вызов IRQ требует 7 мкс). А если мы начнем менять палитру во время прямого хода луча, то, во-первых, это будет видно, а во-вторых, не факт, что мы будем успевать поменять цвет до того момента, когда он понадобится. Результатом будет картинка с неправильными цветами и "снегом" на экране.

Но есть обходной путь:
1) разбить изображение на блоки строк
2) картинку подготовить так, чтобы в каждом блоке строк использовалась только половина палитры (8 цветов)
3) во время отображения очередного блока менять цвета в другой половине палитры, которая текущим блоком не используется

Время отображения 4 строк в режиме 128x128 - 512 мкс. Должно с запасом хватить на перепрограммирование половины палитры (около 300 мкс). Размер в 4 строки еще выбран потому, что IRQ будет приходить каждую 4 строку.

Итого:
1) надо побить картинку на блоки (полоски) 128x4 пикселя
2) в каждом блоке разрешить использовать не более 8 цветов
3) порядок цветов строго не задан, но менять его на протяжении всего кадра нельзя: всегда 8 записей (24 регистра) палитры будут заняты в отображении текущего кадра, поэтому менять можно будет только оставшиеся 8.

Ну и спрашивается, зачем усложнять процесс обновления палитры, если можно просто выбрать 8 последовательных цветов (0-7 для четных полосок, 8-15 для нечетных)? Ведь смена порядка никаких выгод не дает?

Можно даже круче фокус сделать - палитру ведь можно менять по прерываниям. IRQ, по моему, генерируется на каждую текстовую строку. Проблема правда в том, что все 48 регистров за время обратного хода луча по строке перезагрузить не удастся - быстродействия не хватит. Но если поделить палитру на 2 части по 8 цветов, а картинку подготовить так, чтобы больше 8 цветов в смежных строках не использовалось, то можно обновлять палитру блоками по 8 цветов.

Не совсем понял. В строке можно менять произвольные 8 цветов или только последовательно идущие 8?

Я не имею ни одной идеи, как автоматически конвертировать во что-то более менее адекватное в Hires, поэтому отложено на неопределенное будущее.

http://forum.agatcomp.ru//viewtopic.php?id=416