Команда имеет побочный эффект - она закрывает все файлы, которые открыты в момент ее вызова. Это происходит, даже если фактическое количество файлов не изменяется.

В Apple DOS 3.3 максимальное число одновременно открытых файлов - 16.

ДОС, которая идет с Бейсик-60 имеет такое же ограничение, но по факту значения от 14 до 16 приводят к появлению мусора на экране. Значение 13 сразу визуальных эффектов не дает, но зато они появляются на экране при последующей загрузке программы на Бейсике.
Возможно, это вызвано тем, что MAXFILES сдвигает вниз верхнюю границу программы в Бейсике и либо сами буфера открытых файлов, либо область переменных Бейсика наползает на область экрана, которая в семерке находится довольно высоко ($7800). Но это не точно, значения адресов я не проверял.

В ИКП (как ИКП-7, так и ИКП-9) поведение команды изменили. Проверка, что аргумент меньше или равен 16 осталась, но по факту команда с аргументами от 4 до 16 выдает ошибку "ОШ.ДИРЕКТИВА". Использовать можно только значения от 1 до 3. Что довольно странно, поскольку область буферов открытых файлов находится в другой странице ДопОЗУ и дефицита памяти вроде как нет.

Суть ошибки: при попытке загрузить командой BLOAD файл другого типа (проверялись файлы типа A и T), ДОС сообщает об ошибке, но не закрывает файл.
Число одновременно открытых файлов в ДОС ограничено (по умолчанию 3 штуки), поэтому при попытке загрузить несколько разных файлов неправильного типа это ограничение срабатывает, и ДОС теряет возможность загружать файлы вообще, даже правильного типа.
Чтобы закрыть все открытые файлы принудительно, нужно использовать команду MAXFILES.

Ошибка присутствует в Apple DOS 3.3, в ДОС, который идет с Бейсик-60, в ALV DOS, ИКП-7, ИКП-9 и ИКП-90 (с поддержкой сети).

Вот мы же видели как например "Алиса" устраивает эмулятор 140кб диска на поверхности 840. При этом используя только 16 секторов на треке. Знаем про 4-х томную систему. Видели что в девятке эпловские игрушки занимающие целый диск 140 кучами переносят на 840.

Какие есть варианты? Поделитесь мыслями и идеями.

Тут вопрос интересный вылез в процессе изучения одной программульки:
программулька была для эпла, а затем перенесена на агат.
В этой программульке на эпле есть такая штука:

412A -   A9 37 ..   ")."    LDA   #37
412C -   8D F9 03   ".Ы."   STA   03F9
412F -   A9 41 ..   ")a"    LDA   #41
4131 -   8D FA 03   ".З."   STA   03FA
4134 -   4C 59 FF   "lyЪ"   JMP   FF59

Т.е. тут настраивается некий вектор (как выяснилось - это адрес для команды JMP, опкод $4C которой лежит по адресу $3F8), а затем управление уходит прямиком на ПЗУшный сисмон.

Перед тем как это сделать, прога пишет что-то вроде "Нажмите ^Y чтобы вернуться".

И вот оказывается, что эпловский сисмон, действительно, на ^Y в качестве возврата делает переход на заданный вектор, т.е. управление возвращается в программу.

Этому предшествует такая последовательность операций в сисмоне:

FF7D-  D9 CC FF    "YLЪ"    CMP   FFCC, Y
FF80-  D0 F8 ..    "PЬ"     BNE   FF7A
FF82-  20 BE FF    ".>Ъ"    JSR   FFBE   
FFBE-  A9 FE ..    ")Ч"     LDA   #FE 
FFC0-  48 .. ..    "h"      PHA       
FFC1-  B9 E3 FF    "9ЦЪ"    LDA   FFE3, Y
FFC4-  48 .. ..    "h"      PHA      
FFC5-  A5 31 ..    "%."     LDA   31  
FFC7-  A0 00 ..    " ."     LDY   #00
FFC9-  84 31 ..    ".."     STY   31  
FFCB-  60 .. ..    "ю"      RTS       
FEC5-  EA .. ..    "Й"      NOP   
FEC6-  EA .. ..    "Й"      NOP   
FEC7-  EA .. ..    "Й"      NOP   
FEC8-  EA .. ..    "Й"      NOP   
FEC9-  EA .. ..    "Й"      NOP   
FECA-  4C F8 03    "lЬ."    JMP   03F8
03F8-  4C 65 41    "lеa"    JMP   4165
4137-  D8 .. ..    "X"      CLD   

Т.е. тут есть ссылка на некую таблицу операций ($FFCC) и если в таблице находится какой-то код (но это не коды кнопок, а что-то немного видоизменённое), то управление передаётся по таблице $FFE3.

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

И ещё я помню, что в девятке эта логика слегка испорчена тем, что некоторые обработчики вышли за пределы страницы $FExx, а она тут забита как константа (что-то с магнитофоном там не работает из-за этого). Это во время разработки ЛинкN1 вскрылось.

Так вот в агате, точнее в сисмоне Бейсика-60, тоже есть этот переход:

FEBB -   4C F8 03   "lЬ."   JMP   03F8

Только вот ^Y в агате - это стрелка вверх. Так что либо этой операции вообще нет, а JMP висит как рудимент, то ли есть, но на какой-то другой комбинации клавиш.
Есть подозрение, что это именно рудимент, так как по адресу 3F8 лежит значение AA, то есть или тут ошибка или кто-то точно знал, что этот вектор в агатовском сисмоне не актуален.

К чему я всё это пишу: если у нас есть герой, желающий поковыряться в сисмоне и выяснить всё же, какие операции были забиты в этих таблицах в эпле и агате  - это было бы полезно.
Сисмон сидит в ПЗУ, т.е. его всегда можно использовать - чем он и полезен. Причём сисмоны бейсиков и те, что лежат в ПЗУ, скорее всего мало отличаются (но отличия небольшие всё таки есть), так что достаточно будет поковырять сисмоны ПЗУ, дальше при необходимости провести аналогии до загружаемых сисмонов будет легко.

Адреса этих двух таблиц сисмона в агате и эпле совпадают. Но вход в сисмон в агате - FF69. Но это во всех инструкциях к агату указано.

{ похоже, что автор переноса проги на агат не знал об этой особенности агатовского сисмона и сперва пытался сделать такой вызов (есть фразы переведённые в диалогах), но потом понял, что возврат из сисмона не прокатывает и залочил сам вызов сисмона (а фраза осталась) }

(Обратите внимание, "2" - это не ИКП, "4" -  похоже у 4-х томки есть название по имени автора контроллера, "10" - заинтриговало).

1 ДОС 3.3 (а также ее доработка , т.н. "быстрая ДОС")
Стандартная , адаптированная на ПЭВМ "Агат-7" AppleSoft DOS 3.3
Система занимает на диске с 0-го по 2-ой трек .
Поддерживается работа с накопителями :
 - типа "Shugart" - ЕС 5088 .
Существует версия для ПЭВМ "Агат-7" .
Оценка: 5
Автор: ЛЭМЗ,г.Москва
1986 г.

2 BASIC + ДОС 3.3
Стандартный BASIC с улучшеной версией ДОС 3.3 (быстрый обмен с НГМД , драйвер принтера и др.) , обладающей всеми стандартными функциями и командами AppleDOS 3.3 . После разметки диска автоматически записывается ДОС и BASIC-интерпретатор . Существует также доработка этой системы графическим интерфейсом .
На диске занимает с 0-го по 5(7)-ый трек . Поддерживается работа с накопителями :
 - типа "Teac" - ЕС 5323 , ЕС 5311 или FD-55F (может использоваться как загрузочный) ;
 - типа "Shugart" - ЕС 5088 (может использоваться как загрузочный) .
Существует версия для ПЭВМ "Агат-7" и "Агат-9" .
Оценка : 4
Автор: Кривцов,г.Москва
1987 г.
Для данной программы имеется описание и исходные тексты .

3 AppleSoft - (DOS 3.3 + AppleSoft BASIC) для контроллера ФГ3.089.121
Данная программа предназначена для поддержки работы ДК-121 (другое название контроллера ФГ3.089.121) , а также для эмуляции на ПЭВМ "Агат-7" системного монитора , AppleSoft BASIC-интерпретатора и ОС DOS 3.3 , которые , вкупе с ДК-121 , создают среду программирования , идентичную стандартной среде на ПЭВМ "Apple ][" фирмы Apple Computer Inc.
В результате использования данной програмы , а также ДК-121 , можно практически полностью создать на базе ПЭВМ "Агат-7" компьютер западного образца , с программным обеспечением свыше 20-ти тысяч различных программ , ПЭВМ "Apple ][" (к примеру в США в сфере образования почти на 60% используются компьютеры этого и совместимого с ним типов) .
На диске занимает с 0-го по 4(5)-ый трек .
Поддерживается работа с накопителями :
 - типа "Shugart" - ЕС 5088 (может использоваться как загрузочный) ;
 - типа "Teac" - ЕС 5323 , ЕС 5311 или FD-55F (может использоваться как загрузочный) .
Существует версия для ПЭВМ "Агат-7" и "Агат-9" .
Оценка: 5
Автор: неизвестен
1987 г.
Для данной программы имеется описание и исходные тексты , а также описание работы и применения ДК-121 .

4 FVS DOS 3.3
Данная ОС построена по принципу стандартной ДОС 3.3 с некоторыми отличиями , так-то :
 - разбиение дискового пространства данных на 4-ре тома , т.е. один физический накопитель разбивается на четыре логических ,
 - присваивание различным логическим томам на диске в поле данных различным физическим номерам томов в служебном поле адреса ,
 - при разметке инициализируется только текущий каталог и стартовый файл с ОС или языком программирования на диск не записывается ,
 - различия в системных векторах ОС при ее работе со стандартными BASIC-интерпретаторами .
С помощью данной ОС возможно использование практически всего программного обеспечения для "старого" BASICа и ДОС 3.3 для FM-накопителей ЕС 5088 , так как тело самой ДОС расположено в памяти практически по тем же адресам . Данную систему поддерживает стандартный ИКП .
На диске занимает с 0-го по 1-ый трек .
Поддерживается работа с накопителями :
 - типа "Teac" - ЕС 5323 , ЕС 5311 или FD-55F .
Существует версия для ПЭВМ "Агат-7" и "Агат-9" .
Оценка: 5
Автор: неизвестен
???? г.

5 FD55FV DOS
Симбиоз стандартной ДОС 3.3 и FVS DOS 3.3 , в результате которого получилась очень неудобная и некачественная ОС , основными недостатками которой являются плохая организация (вернее весьма отличная от ДОС 3.3 , тем и неудобная) записи данных и каталога , а также расположение одного каталога на $14-$38-$64-$8C треках .
Используется в основном в AppleSoft системах и в некоторых системах с нечастым обращением к ДОС .
На диске занимает с 0-го по 1-ый трек .
Поддерживается работа с накопителями :
 - типа "Teac" - ЕС 5323 , ЕС 5311 или FD-55F .
Существует версия для ПЭВМ "Агат-7" .
Оценка: 2
Автор: неизвестен
???? г.

6 Lotos-DOS 3.2
Наиболее удачная доработка стандартной ДОС 3.3 для FM-накопителей .
В данной системе предусмотрены новый команды , операции и свойства , так-то :
 - команды работы с текстовым представлением файлов ;
 - верификация ОС ;
 - защита от вирусов ;
 - перезапуск системы ;
 - расширеные операции по работе с файлами данных и их восстановлением ;
 - работа с принтером типа СМ 6337 в графическом режиме ;
 - т.н. "быстрая ДОС" ;
 - расширеные возможности по форматированию и инициализации дисков ;
 - оглавление (метка) диска .
Система занимает на диске с 0-го по 2-ой трек .
Поддерживается работа с накопителями :
 - типа "Teac" - ЕС 5323 , ЕС 5311 или FD-55F ;
 - типа "Shugart" - ЕС 5088 .
Существует версия для ПЭВМ "Агат-7" .
Оценка: 5
Автор: Антипов,г.Волжский
1991 г.
Для данной программы имеется описание и исходные тексты в формате BASIC-программ .


10 Ў-BASIC & superDOS 3.3
Попытка эмулировать AppleSoft BASIC только на программном уровне без привлечения упомянутого выше ДК-121 .
Данная система обладает очень развитым графическим и звуковым интерфейсом .
Единственные неудобства - 128-символьный знакогенератор (нет кириллицы , только строчные и прописные латинские литеры) и отличные вектора BASIC-интерпретатора .
Система занимает на диске с 0-го по 2-ой трек , а также 68 секторов файла данных BASIC-интерпретатора или же просто с 0-го по 7-ой трек .
Поддерживается работа с накопителями :
 - типа "Shugart" - ЕС 5088 .
Существует версия для ПЭВМ "Агат-7" .
Оценка: 5
Автор(доработка): Живодров,г.Волгоград
1992 г.

Ещё этому ДОСу косточки пока не мыли. Бейсику ИКП-шному мыли, но ведь с ним вместе живёт и ДОС.

Про мороку с драйвером файловой системы я писал и писать буду в соседней ветке.

А вот неожиданность: ошибка в драйвере RWTS.
Не частая, не редкая.
Суть в обработке очереди команд.

Логика различных агатовских драйверов с отложенным исполнением, обычно, похожа. Очередной запрос проверяется на следующее:
1) Есть ли задания в очереди ?
2) Касается ли этот запрос текущего трека (того, над которым сейчас висит головка) ?
3) Является ли запрос отложенным ?
4) Был ли уже отложенный запрос на данный сектор ?
Если запрос касается трека очереди либо очередь пуста, запрос ставится в очередь.
Если нет - то очередь уходит на исполнение, очищается и запрос добавляется к пустой очереди.

Косяк в пункте 4: он проверяется тут:

0FA9 -   A0 05 ..   " ."    LDY   #05
0FAB -   B1 48 ..   "1h"    LDA   (48), Y
0FAD -   AA .. ..   "*"     TAX   
0FAE -   BD 00 07   "=.."   LDA   0700, X
0FB1 -   F0 05 ..   "ð."    BEQ   0FB8
0FB3 -   20 82 0C   "..."   JSR   0C82

по адресу (48),5 задаётся номер сектора, а в таблице по адресу 700 лежит массив операций, которые нужно выполнить для каждого сектора. Если для запрошенного сектора не было отложенных запросов - всё хорошо. Иначе запускается процедура 0C82. А косяк в том, что она в регистре X ожидает номер слоты, умноженный на $10. А вовсе не номер сектора. Дальше залип и завис.

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

Проверить просто: постройте файл, у которого в TSL будет указан несколько раз один и тот же сектор. BLOAD/LOAD в ИКП зависнет либо будут какие-нибудь непредсказуемости. Учтите, что число секторов в каталоге должно быть больше или соответствовать числу секторов в TSL.

-=-

А как на неё вышел я?
Тут дело в логике работы стандартного процессора комстроки и моего врапера:
- стандартный процессор на операции чтения файла LOAD/BLOAD выполняет такую последовательность вызовов (для B-типа, например):
  1) fopen, fclose. Здесь проверяется тип файла (соответствие запрошенному B).
  2) fopen, fread(2 байта) - смещение, fread(2 байта) - размер, fread(размер), fclose.
Т.е. процессор знает размер файла и запрашивает только нужное число байт.
- у меня враппер действует по другому:
  fopen, fread($FF00 байт), fclose.
fread даёт ошибку "чтение после конца данных", но меня это не колышет, я могу узнать фактическое число прочитанных байт из возвращаемого file control block.
Проблема в том, что в file driver есть некоторый косячок: он все запросы к RWTS на чтение блоков данных файла посылает с флагом "отложенный". Кроме последнего запроса, который считается последним исходя из _запрошенного_ объёма данных. И не учитывает, что TSL-то уже закончился, т.е. достигнут EOF. Ну а в fclose никто и не подумал вызвать закрытие очереди (а зачем ?).

Хотел объехать это, просто вызвав сброс очереди перед fclose, но, похоже, явной команды для этого RWTS не предусматривает и, в любом случае, проверяет поле номера сектора. А дальше срабатывает ошибка в RWTS и он зависает. Можно попробовать менять номер сектора на любой другой или вообще запрашивать другой трек, но костыль-то получается знатный...

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

Сегодня  попробовал копнуть самую тёмный и страшный подвал dos3.3: файловый менеджер или, говоря более современным языком, драйвер файловой системы.

Тут есть одна хитрая загогулина: если вызов RWTS - то есть драйвера дисковода - вполне описывался во всей агатовской документации, причем даже без ошибок, то про драйвер файловой системы как-то замалчивали. Вроде есть chr$(4) и нефиг тут сопеть.

Но chr$(4) открывает не все доступные операции. Он, в общем-то, позволяет только читать/писать B и A файлы, причем только целиком, а T-файлы - только побайтово.

А изюминка прямого доступа к драйверу ФС в том, что читать и писать можно любые типы файлов, причем блоками произвольного размера !
Этого нет даже в Школьнице.

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

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

Сегодняшние ковыряния привели к любопытной находке: оказывается, в ИКП-ДОС тоже есть API файлового менеджера и, похоже, он почти точно соответствует менеджеру DOS3.3. Но, конечно, не всё так просто: перед обращением ко входным точкам в ИКП нужно сперва перенастроить контроллер памяти. Тут авторы ИКП как-то пропустили всю суть API, как стандарта, не требующего лишних движений и обеспечивающего переносимость программ.
Входных точек всего две: процедура получения вектора на дескриптор запроса и процедура вызова драйвера. Всё точно также как и при вызове RWTS (я думаю, все помнят мировую константу $3D9 ? Это несмещаемая процедура вызова RWTS).

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