Часто встречаю это утверждение. Думаю, просто какая-то неудачная реализация в прошлом установила блок на повторное осмысление, надо еще раз попробовать. CP/M 2.2 нормально работает с файловыми системами любого размера в пределах ее математической модели. Конечно, для использования бОльших емкостей приходится размер кластера увеличивать с 2кб (какой он на дисководных распространенных реализациях) до максимальных 16кб. Я не замечал замедления версии дисков с большим кластером которые мы используем для HDD по сравнению с "дисководным" форматированием (BDOS оба раза одинаковый).Сообщение от barsik
Максимальный размер диска для CP/M 2.2 ЕМНИП - 1 гигабайт, а максимальный размер файла - 4Mб. Конечно для 1Гб все ТПА надо отдать под буфер ALV. Но для к примеру 100Мб диска (а это весьма прилично для 8-битки, тот же UZIX имеет предел в 32Мб на одну ФС), надо всего лишь 800 байт для буфера ALV (всего на семь сотен байт больше чем для дисковода) - вполне разумные траты. Учитывая, что ФС можно отмонтировать и менять на другую (как дискетку заменить), все выглядит очень удобно.
- - - Добавлено - - -
И файлов туда можно записать весьма много. Считать лень, но даже на один 16кб-шный кластер пишется 512 файловых дескрипторов (файлы до 128кб размером умещаются в один дескриптор), а кластеров под каталог можно отвести до 16 штук - умножьте сами.Но конечно когда диск большой (что достижимо). Для маленьких (и не очень) носителей очень часто употреблялись библиотеки LBR как подкаталоги (если не хватало штатных Юзеров) - это давало уплотнение и позволяло писать на небольшой диск большее количество файлов чем есть есть файловых дескрипторов. Многие пробвинутые CCP от CPM 3.х работали c LBR как с каталогами (по крайней мере на чтение).
Другое дело, что надо наверное брать продвинутые реализации CP/M - c датами файлов и т.п., такие тоже были (даже в исходниках встречал).
Ответить с цитированием