Применение платы палитр в софте.

Насчет этого "хвоста" я вот чего не понимаю: он включается в длину файла или нет?

Просто у меня сложилось впечатление, что этот хвост добавляется именно в "пустую" с точки зрения DOS область файла типа B.
Вот как-то так:

+----------------------------------+-----+--------------------------+
|             Сектор 0             | ... |     Последний сектор     |
+---------+---------+--------------+-----+--------------+-----------+
| Адрес   | Длина   | Данные файла |     | Данные файла | "Хвост"   |
| 2 байта | 2 байта | 252 байта    |     | 4 байта      | 252 байта |
+---------+---------+--------------+-----+--------------+-----------+

То есть, если у нас ч/б картинка 256x256 (МГВР), то в поле "Длина" будет значение $2000.

Если это так, то последние 252 байта с точки зрения DOS не существуют, и доступ к ним стандартными средствами (командой BLOAD) получить нельзя. Их можно будет вычитать только прямыми вызовами RWTS, что плохо.

Если "хвост" в файл включается, то длина должна быть $20FC. Тогда "хвост" будет грузиться в память сразу после картинки.

Так примерно (выводит комментарий из VR):

3 REM Этот код работает только в ИКП-Бейсике-9
5 REM Для других версий бейсика нужно подбирать смещение буферов ДОС

7 BUF%=$1F00

10 *$30A:
20 ! LDY $C150
30 ! LDX #0
40 ! STA $C15D
50 ! L:LDA $B107,X ! STA BUF%,X ! INX ! BNE L
80 ! STA $C100,Y
90 ! RTS !:

100 HOME
110 ? "Выберите файл-картинку:"
120 ?:?CHR$(4)"BLOAD?,A$2000"
130 CALL $30A

200 ? CHR$(30+128) : ?
210 IF PEEK(BUF% + 4) <> ASC("V") THEN 900
220 IF PEEK(BUF% + 5) <> ASC("R") THEN 900

300 FOR L = 4 TO 15
310   FOR C = 0 TO 15
320     S% = PEEK(BUF% + L * 16 + C)
330     ? CHR$(S%);
340   NEXT C
350   ?
360 NEXT L
370 STOP

900 ? "В этом файле нет VR-расширения"
910 STOP

Я помню, что в dos33 была интересная особенность: сразу после загрузки с Бейсик-60 можно было дать любую ошибочную команду ДОС (например, LOAD с именем несуществующего файла) и ДОС не сообщала о каких-либо ошибках.
Но если дать команду, которая завершится правильно, то на следующие неправильные команды сообщения об ошибках уже появлялись.

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

Так если его можно менять через MaxFiles - это и есть динамическая память.

Я помню ошибку с очисткой таких же буферов под Школьницей.
На форуме писал, несколько лет назад.

В ДОС же можно открыть файл и не закрывать его в одной операции. Сколько таких файлов будет - заранее неизвестно. Во всяком случае текстовых - легко. Другие типы - тоже можно, но посложнее (через FileMan).

Т.е. под один файл выделяется какой-то один кусок, под другой файл будет уже выделятся другой кусок.
Пусть даже формально этот кусок как будто и так зарезервирован ДОСом, но важно то, что некий произвольный по счёту файл может попасть в разные адреса памяти.

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

А, нет. Неправильно проверил :)

Я выбирал для BLOAD один и тот же файл. И похоже, что ДОС видит, что такой файл уже открыт и не пытается выделять ему новый буфер.

Но если попытаться через BLOAD загрузить 3 разных файла типа A, то буфера тоже будут использоваться разные. И после трех ошибок подряд на очередную попытку загрузки ДОС выдает ошибку "МНОГО ОТКРЫТЫХ ФАЙЛОВ".

Так что BLOAD файла типа A просто оставляет незакрытым файл. Независимо от номера буфера.

Надо бы Игоря спросить, какой ему нужен результат.
Есть несколько вариантов что с этой ошибкой делать:
1) с кодом ничего не делать, просто повесить предупреждение, что при попытке загружать вместо картинок какие-то другие файлы программа сломается вдребезги пополам, поэтому лучше и не пытаться. Самый простой вариант.

2) попытаться найти указатель на последний используемый буфер. Мне этот вариант не очень нравится, потому что ошибочно выбранный файл остается открытым. А если пользователь три раза ошибется, то программа все равно сломается.

3) попробовать обработать ошибку и закрыть файл. Как оказалось, команда MAXFILES принудительно закрывает все открытые файлы, поэтому можно добавить такой обработчик ошибок:

96 ONERR GOTO 5000

5000 ER = PEEK(222)
5010 IF ER = 6 THEN STOP
5020 IF ER <> 13 THEN GOTO 5050
5030 PRINT "НЕВЕРНЫЙ ТИП ФАЙЛА": GET A$
5040 PRINT: PRINT CHR$(4)"MAXFILES 3"
5050 RESUME

В ячейке 222 лежит код ошибки ДОС. В строке 5010 сделана проверка на код ошибки "файл не найден". Я сделал тут выход из программы если вместо выбора файла нажали "РЕД". Если такая проверка не нужна, можно эту строку убрать.
В строке 5020 сделана проверка на код ошибки "Неверный тип файла", в строке 5030 вывод текста ошибки, а в строке 5040 - собственно выполнение команды MAXFILES.

Понятно, что костыль, и лучше бы исправить ДОС, но это уж очень тяжелый вариант.

Вообще, пора уже как у Майкрософта базу знаний багов заводить (Knowledge Base). И все ошибки туда под номерами складывать, а то информация растекается по разным темам форума и фиг ее потом найдешь.

Баг, похоже, застарелый :)
Он есть в Apple DOS 3.3, он есть в ДОС, который идет с Бейсик-60, он есть в ALV DOS, ИКП-7, ИКП-9 и ИКП-90 (который с поддержкой сети).

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

К своему стыду обнаружил, что никогда не читал файлы на Агатовском Бейсике :) Пришлось повозиться с написанием тестовой программки, которая открывает 4 файла неправильных типов. Без ONERR GOTO этого не сделать (программа вылетает), но RESUME передает управление в то место, где возникла ошибка, поэтому файл начинает открываться до бесконечности. Плюс, у ONERR GOTO какие-то странные отношения с циклом FOR. Но ничего, выкрутился. Программка тоже отработала корректно - открытые файлы не накапливаются. По крайней мере, у OPEN проблем нет.

Интересный момент - это то, что в тексте кода BLOAD есть комментарий "(CHANGED 11/1/78 FOR TYPE MISMATCH)". Дело в том, что к 1 ноября 1978 разработчик ДОС над ней больше работал - он еще летом передал код Apple. То есть, эту проверку типов добавляли программисты Apple. И, видно, что-то пошло не так :)

И еще два наблюдения навеянные этой багой:
1) Если в современных операционках написать программу на C, которая открывает два раза один и тот же файл, то получится два разных дескриптора. Используя их, можно, например, читать файл из разных точек. Но если попытаться то же самое сделать в ДОС (например, через вызовы файлового менеджера), то в момент второго вызова OPEN ранее открытый файл закроется и первый дескриптор станет недействителен. То есть в ДОС в принципе другой подход (один файл - один дескриптор).

2) Файл-менеджер для ИКП явно переделывали - структуры данных для открытых файлов больше по размеру и устроены иначе. То есть, исходники у разработчиков были достаточно подробные и поправить баг они в теории могли.

А может быть вообще по другому зайти: когда читается файл, последним будет прочитан этот последний сектор. Значит в таблице параметров RWTS будет его адрес (как Т/С так и адрес в ОЗУ). Адрес таблицы параметров RWTS в любом ДОСе из числа DOS3.3 и его наследников можно узнать через вектора в регионе $3Fx.