dos33c2

Класс! Замечательная утилита становится ещё замечательнее!

> Вот, кстати, хотел вопрос задать: а как просмотрщик в DOS33C2 определяет, что файл является картинкой?
И можно ли как-то это определение отключить?

Образы видеопамяти определяются по типу файла, его точному размеру и смещению загрузки.
Этот алгоритм - не точный, но сделать более точный было бы сложно. Например, вычислить спектры по X и Y и ввести какой-то критерий, вроде "мало высоких частот, много низких частот". Хотя и такой алгоритм будет работать неуверенно, если картинка будет содержать какой нибудь дизеринг.

Но если файл неправильно определяется как картинка, его всё равно можно посмотреть как бинарник кнопками 'b' и 'B' (для B-файлов) и 'К' (для ошибочно распознанных K-файлов). Фактически, всё меню "Просмотр файла" как раз предназначено для использования в случае ошибок работы автомата распознавания.

{
Определение типа файла построено на наборе процедур, которые по всевозможным косвенным признакам пытаются распознать содержимое. Учитываться может всё, включая фрагменты имени файла, заданный в каталоге тип, адреса загрузки, размеры, отдельные байты в содержимом файла.
}

>Так вроде так и есть ? Там всё уже размещено в соответствии направлений стрелок и текущий режим выводится в рамке >окна или где-то в центре ?

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

>В коде проги имя для картинки (windows) формируется так: img-<исходное имя><номер>.bmp
>Что неправильно ?

Картинку эту попытался сохранить, в аттаче результат 4-х нажатий на F2, только последние сохранились нормально.

Немного заметок про Уникод

Он возник очень давно, но долго не мог стать популярным.
Основная идея: расширить количество символов в знакогенераторах свыше 256.

Но очевидно, что это потребует введения больше чем одного байта на символ.
Т.е. увеличение объёма данных/файлов на тот же объём текста.

Отсюда вылезли разные идеи о том, как уникод должен хранится и передаваться.
Идей много, около десятка, а может и больше. Обычно кодировки уникода
(способы хранения и передачи символов) обозначаются как UTF (Uncode Transfer Format)
и дальше цифры и буквы. Хотя есть и более старые обозначения: например, UCS (Universal Character Set), UCS-2.

В целом, разница между разными UTF в том, насколько больший объём данных требуется
для хранения одного и того же текста и насколько удобно обрабатывать такую кодировку.
Всё как обычно: или обработка простая, но тогда объём данных больше или наоборот.

Здесь я опишу только три, самых ходовых типа UTF:

UTF-8 - очень распространнёная в протоколах Интернета и в современных *NIX'ах.
Всякие JavaScript, JSON и прочее - везде она крутится как основная и, нередко, как единственно
возможная.

Особенность UTF-8 в том, что символы с кодами меньше 128 хранятся тут как 1 байт,
но если значение кода растёт, требуется уже 2 - 3 - 4 байта.

UTF-16, наследник UCS-2 - её любят в GSM (СМС-ки в ней передаются, если содержат не латиницу,
и моя любимая Motorola 3788 шибко на это ругается). Её также любит MicroSoft.
Строго говоря, я не знаю кого любит MicroSoft: UCS-2 или UTF-16 ?
Эти кодироки для символов в диапазоне символов $0000..$CFFF совпадают по формату
и требуют всегда минимум двух байт на символ.

UTF-16 делится на два подвида: BE и LE - они отличаются порядком байт в словах.
Microsoft предпочитает вариант LE. *NIX считает, что более правильная - BE.

Поскольку единого предпочтения нет, хорошие проги, поддерживающие уникод, стремятся к тому, чтобы хотя бы читать любую из кодировок.
Но склонности к той или иной кодировке могут проявлятся мягко или жестко:
Linux'овый текстовый редактор leafpad не понимает ничего, кроме UTF-8.
Window'ый текстовый редактор wordpad (из Windows-10) не понимает ничего, кроме UTF-16LE.
*NIX'вая утилита iconv (конвертор сотен разных кодировок, там только Агата нет) понимает всё, но, по умолчанию, "UTF-16" понимает как "UTF-16BE".

Но браузер firefox под любой из систем понимает все три типа UTF.
Подозреваю, что и другие браузеры будут вести себя также.

Microsoft Word (пробовал с 2003 версией) понимает также все три типа UTF, но:
- UTF-16BE он называет "UNICODE (big endian)";
- UTF-16LE - "UNICODE";
- UTF-8 - "UTF-8".

Notepad из состава Windows-10 понимает все три кодироки.
И, вроде бы, даже позволяет сохранять файл тоже в любой из трех кодировок.

"Byte order mark" (BOM)

Это специальный символ, может записыватся в начале текста и указывает на конкретный тип UTF.
Но, как правило, в текстовых файлах он используется, если текст сохраняется как UTF-16 и не используется для текстов в UTF-8.
Notepad, из состава винды, даже явно указывает при сохранении файла, будет ли записываться BOM или нет.
Причина в том, что не все проги правильно понимают этот символ, так что иногда его лучше исключить.

dos33c2 и уникод

Сейчас в dos33c2 работа с уникодом сделана как совершенно отдельная операция.
Она работает только файлами типа T- на стороне Агата.

В случае экспорта необходимо поставить курсор на нужный файл или выделить группу текстовых файлов.
Дальше заходим в главное меню и ищем там "Уникод экспорт и импорт".

В меню выбираем направление и тип кодировки.

Импорт с автоопределением типа кодировки имеет hotkey и является рекомендуемым.
Определение типа выполняется так: если в начале текста найден BOM для UTF-16, то текст считается соответствующим UTF-16 be или le.
Если BOM не найден, то считается, что его тип - UTF-8.
Другие типы UTF dos33c2 не поддерживает.

Импорт с жестко заданным типом UTF не ищет BOM, а сразу начинает декодирование по заданному формату.
Если BOM присутствует в тексте, он станет вопросительным знаком в импортированном тексте.

Экспорт в UTF-8 стоит первым пунктом и имеет hotkey 'u' - как наиболее универсальный формат.
BOM при экспорте записывается по тому же правилу: он есть для UTF-16 и отсутствует для UTF-8.

{ Строго говоря, dos33c2 под UTF-16 подразумевает, скорее, UCS-2. Т.е. в этом режиме она предполагает, что любой
символ представляется двумя и только двумя байтами. Но - с другой стороны - таблица конвертации действительно
не выходит за значения выше кодов символов $CFFF, а в этом случае UCS-2 и UTF-16 совпадают. }

Будет ли отличаться при уникод-экспорте обычный текстовый файл без особо наворочанной псевдографики девятки или чего-то подобного ?

Обратите внимание на то, что символ $ в советских компах был заменён на знак валюты ("солнышко" или "клоп").
Соответственно, если вы экспортируете бейсиковскую программу, то обычный встроенный экспортёр сохраняет код символа и
на PC вы видите знак $ (символ с этим кодом как в агатовских так и в PC-шных бейсиках используется как указатель типа переменной: "строковая").
Но если вы попробуете экспортировать какую нибудь документацию по бейсику, используя уникодовый
экспортер, то в результирующем тексте вы получите знак валюты. В обратную сторону знак $ в агатовский файл импортировать
уникодом невозможно - на Агате нет этого символа. Но это можно сделать обычным импортёром.

Любой цветастый смайлик можно запихнуть в девятку ?

Само собой нет. В уникоде полно символов, визуально похожих, но имеющих разные коды.
Но таблица конвертации в dos33c2 одна.
Поэтому если хочется узнать, что конкретно можно импортировать на девятку,
проще всего экспортировать файл со всеми символами 1..255 и из того, там будет,
выбирать то, что нужно.

В таблице нет символов $80..$9D. При экспорте там будут '?', при импорте - тоже.
Это от того, что этот регион повторяет другой регион, с чуть более высокими кодами.

Тут есть темка:
http://forum.agatcomp.ru//viewtopic.php?id=378
таблица из этой темы ушла уже в два проекта: Аппаратный отладчик для Агата и dos33c2.

Немного про отрисовку графики (часть 1/2)

Агат на RGB-выход выдаёт, фактически, 4 бита цвета: RGB и яркость.
Однако форматы видеопамяти Агат-7 могут подразумевают 1 или 4 бита на пиксель, а Агат-9: 1, 2 или 4 бита на пиксель.
Кроме того, в текстовых режимах, цвет фона в Агат-7 может быть черным или белым, а у Агат-9, кроме того, синим или фиолетовым.
Т.е. 1 или 2 бита, в конечном итоге, по различным правилам, становятся 4 битами.

Также к Агату может подключаться плата палитр, которая преобразует 4 бита в 12 бит по таблице, которая загружается в ОЗУ платы.

Примерно такое же влияние на цвет, какое оказывает плата палитр, может оказать использование монохромного монитора неопределённого оттенка, подключаемого
к разъёму "Видеосигнал". На этот сигнал выдаётся комбинация то ли 3 то ли 4 бит в неожиданных пропорциях.
Абсолютные значения видеосигнала у семёрки зашкаливали, у девятки были более близкими к тому, что ожидал бы обычный телек
(да и моник, поддерживающий более-менее аналоговый сигнал единственного цвета).
Свою семёрку я, в итоге, переделал, чтобы получить чистый ряд оттенков зелёного (у меня монохромный моник был зелёным),
яркость которых линейно возрастала по мере роста номера цвета.

--

К тому, чтобы повторить всю эту логику и вывести агатовские файлы с изображениями на экран современной PC, есть примерно два подхода:

1) Рассматривать систему агатовский ДК + монитор как единое целое и пытаться повторить все детали их совместного поведения.
    - Недостаток подхода: мониторов было много разных, каждый со своими особенностями.
      Да и агатовский ДК имел различные варианты формирователя выходного монохромного сигнала.
    - Достоинство подхода: максимальное приближение изображения к тому, что было на реале при условии комплектации компьютера
      наиболее навороченной конфигурацией (конкретный цветной монитор с поддержкой линии Y по определённым правилам).

2) Рассматривать существенно важным только агатовский ДК, полагая монитор устройством идеальным.
    - Достоинство подхода: это соответствовать некоему абстрактному идеальному варианту:
      агатовский ДК подключен через хороший ЦАП к современному монитору.
    - Недостаток подхода: это будет примерно в равной степени не соответствать
      ни одной конфигурации реального Агата с монитором из 80-90х годов.

Поскольку мнения о том, какой подход использовать, давно и твёрдо разделились, в dos33c2 предыдущих версий (до 2.08 включительно)
был реализован простой, но очень компромиссный, вариант: при просмотре графики, нажатием клавиши Пробел, можно было выбрать одну из трех палитр:

- 1. Монохромную, слегка похожую на реальную картинку Агата с монохромным монитором.
    (Некоторые программы имели дизайн именно под такой монитор, на цветном они будут выглядеть заметно хуже).
    0x000000, 0x333333, 0x222222, 0x666666, 0x111111, 0x555555, 0x444444, 0x777777,
    0x888888, 0xbbbbbb, 0xaaaaaa, 0xeeeeee, 0x999999, 0xdddddd, 0xcccccc, 0xffffff

- 2. Цветную идеализированная: эта палитра строится из предположения, что сигнал Y влияет ровно на 50% яркости:
    0x000000, 0x7f0000, 0x007f00, 0x7f7f00, 0x00007f, 0x7f007f, 0x007f7f, 0x7f7f7f,
    0x404040, 0xff0000, 0x00ff00, 0xffff00, 0x0000ff, 0xff00ff, 0x00ffff, 0xffffff
    Цвет 8 в этой палитре взят вообще с потолка.

- 3. Эпловскую с поправкой на прохождение сигнала через декодер NTSC:
    0x000000, 0x4348C1, 0x157744, 0x43A9EF, 0x656000, 0x929292, 0x65C216, 0x8CEEBA,
    0x933164, 0xC063FF, 0x929292, 0xB9BEFF, 0xE27C36, 0xFFA7DB, 0xDCD75E, 0xFFFFFF

Это переключение было доступно независимо от формата изображения.
Последние изменения по этому вопросу были сделаны около 2018 года.
При этом dos33c2 не поддерживала механизм переключения палитр, который умеет выполнять контроллер ДК Агат-9.

--

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

Также в список палитр были добавлены новые палитры:

- 4. Цветная, соответствующая реальному монитору с поддержкой линии Y (??? какому ???):
    $000000, $d90000, $00d900, $d9d900, $0000d9, $d900d9, $00d9d9, $d9d9d9,
    $262626, $ff2626, $26ff26, $ffff26, $2626ff, $ff26ff, $26ffff, $ffffff

- 5. Монохромная, уточнённая по схемотехнике ДК:
    $000000, $828282, $595959, $dddddd, $414141, $c2c2c2, $979797, $f1f1f1,
    $272727, $b9b9b9, $949494, $f4f4f4, $6c6c6c, $e5e5e5, $c5c5c5, $ffffff

Т.е. теперь dos33c2 может использовать уже 5 встроенных палитр + одну палитру, которая может быть сохранена в VR-блоке файла.
Также в эту версию был добавлен переключатель палитр, который реализован внутри ДК Агат-9.

Таким образом, одно и то же изображение уже может иметь до 24 вариантов отображения.

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

- палитра ДК - всегда 0, но можно переключить на другую;
- палитра платы палитр и монитора: палитры 1 и 2 для изображений в формате контроллера Агат;
палитра 3 для изображений в формате эпловской графики.

Если же VR присутствует, то:

- палитра ДК берётся из данных VR, но можно переключать на другую;
- палитра платы палитр и монитора: палитры 4, 5 и палитра из VR (если она там есть) - для изображений
в формате контроллера Агат, для форматов Apple: палитра 3 и палитра из VR (если она там есть).

Причём для монохромных графических режимов Агата по умолчанию будет включена палитра 1 или 5, а для остальных - 2 или 4.

<продолжение следует>

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

Насчет поддержки png или gif есть некоторые сомнения. Я вот видел, что ivagor с zx-pk сделал поддержку jpeg для Вектор-06Ц. Круто? Да. Но распаковка картинки занимает две минуты. Стал бы я пользоваться просмотрщиком, который 20 минут тратит на 10 картинок? Нет.

Распаковка png и gif конечно попроще, но все равно они тяжеловаты для 6502. Мне кажется, ничего сложнее формата bmp и алгоритма RLE под Агат делать не стоит. С другой стороны, bmp может быть очень здоровым. Например, если там 24-битный цвет.

Так что, по хорошему, Агату нужен свой формат. Ну или какой-то специально оптимизированный вариант bmp или gif. Короче, просто кидать в Агат картинки в известных форматах будет плохо. Обязательно понадобится какая-то утилита, которая будет их конвертировать или во внутренний формат или в известный, но со специальными настройками. Как минимум, чтобы учесть разрешение экрана и неквадратный пиксель.

Но меня вот какой вопрос интересует. Я что-то вообще не видел в коллекции софта каких-то сборников картинок. По отдельности какие-то картинки как части программ - есть. А вот чтобы именно коллекции картинок для "просто посмотреть" - нет. Может, потому и просмотрщиков нет?

Вроде разобрался с палитрами: все эпловские совпадают с теми, что есть на сайте, но они по разному перетасованы (под HiRes, под DHiRes...).

В итоге разрулил ситуацию так:
- Агатовские декодеры работают только с агатовскими палитрами (цветная, монохромная, цветная 50%).
- Эпловский LoRes и DHiRes работают с эпловскими палитрами (независимо от наличия VR).
- Эпловский HiRes, поскольку он обрабатывается "агатовским" декодером, может работать с цветной и монохромной палитрой Агата, а также с палитрой Apple NTSC (под спецназванием "Агат как Apple NTSC").

Пока так. Если, в дальнешем, будет декодер Apple HiRes как NTSC-телек, то тогда можно будет разделить палитры на два декодера: HiRes как Агат (с палитрой Агата) и HiRes как Apple на NTSC.
Но дальше всё упирается в декодеры.

Декодер в dos33c2 выполняет следующее:
он читает буфер видеопамяти (получает указатель на начало блока данных)
и заполняет двумерный массив-растр цветами 0-15.
Также на входе у декодера может быть номер палитры ДК Агат-9 (0-3).
Дальше - не его забота.

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

--

Исправленные ошибки, найденные на неделе и другие изменения:

2.10    После переключения некоторых параметров отображения картинки в графвьювере переставала меняться палитра.                                     
        Некоторые режимы Apple-графики рисовались с агатовской палитрой.                                                                            
            (тут не совсем ошибка: эпловские режимы, которые умеет рисовать Агат, с точки зрения dos33c2 являются агатовскими...)                   
        Перетасованы палитры. Агатовские режимы - с агатовскими палитрами, эпловские - с эпловскими,                                                
             HiRes эпловский с любой на выбор.
        Теперь в окне просмотра графики текущий режим выводится в заголовок окна. И там же теперь информация о палитре.                             

Размер файла, для агата, будет 2 байта?