Совсем не понял этот абзац. И терминология тоже неясная. Кластер это терминология из MSDOS и это совсем не то, что CP/M-группы. CP/M-группа это англоязычный термин, в отечественой литературе обычно это заменяют словом CP/M-блок. Иными словами, это минимально расходуемый фрагмент диска, и его используют для того, чтобы сократить число записей в каталоге.Сообщение от Sayman
Под блоком понимается минимальный размер участка диска, который можно занять, т.е отметить занятым. Размер блока может быть 1, 2, 4, 8 или 16 килобайт. И так это было даже в самой первой CP/M версии 1.3. Таким образом, даже, если CP/M-файл имеет размер всего один логический сектор в 128 байт, то на диске всё-равно занимается целый блок.
Физический сектор может быть увеличен или уменьшен до любого размера. Именно это и есть свойство CP/M, что позволило ей победить. CP/M вообще наплевать, как физически устроен диск и на размер физического сектора, тем более. BDOS работает через всего 2 подпрограммы - считать 128 байт и записать 128 байт. 128 байт называют логическим сектором, чтобы говорить, что CP/M имеет обмен логическими секторами. А BDOS занимает пространство диска с кратностью в блок, т.е в минимальном случае - это 8 логических секторов (1 кб).
Исторически первым форматом дисков был формат дисковода ЭВМ MDS-800, что также применён в СМ-1800. Этот дисковод называется ЕС-5074 и имеет формат 77 треков, 26 физических секторов по 256 байт в каждом. Чем больше размер сектора, тем меньше пространства диска впустую тратится на межсекторные гапы. Поэтому у СИНКЛЕРА с секторами в 256 байт на диске всего 640 кб, в MSDOS с секторами 512 на диск влезает 720К, а у КОРВЕТА с секторами в 1024 байта размер диска 800 кб (а у MAC - 880 кб, т.к там 1 сектор на весь трек). ВГ93 не может иметь сектора большего размера, а вот РК-КНГМД может иметь 1 сектор на весь трек. За счет чего ёмкость увеличивается на 20%).
Это обычный формат. Он у всех компьютеров с контроллером от КОРВЕТА. Гораздо сложнее найти компьютер, у которого был бы иной формат.
В CP/M нет корня диска. А если есть, то это не CP/M.
FAT это не файловая система, хотя иногда ошибочно так говорят. FAT это область на диске.
Если есть FAT, то это файловая система MSDOS. И она "полностью совместима с CP/M" никак быть не может. Только частичная совместимость, хотя для многих программ этого хватает. Если есть FAT, то значит не строится Allocation Table и часть функций BDOS не работают. Такая ДОС по работе дисководных функций близка к MSX-DOS. В MSX-DOS 1.0 (1984), как и в MSDOS 1.0, не было подкаталогов, хотя уверен, что изначально они были задуманы, т.к без подкаталогов формат MSDOS с FAT даёт лишь небольшой выигрыш (за счёт того, что не надо строить в ОЗУ Allocation Table).
А вот введение подкаталогов, отчего каталоги нижнего уровня размещены в файлах, для винта даёт существенный выигрыш, т.к для поиска файла, не надо сканировать общий каталог размером в 200 кб. Но FAT, т.к он один для всего диска, при больших дисках имеет очень большой объём (обычно сколько мегабайтов, столько килобайтов FAT) и тем самым, или TPA для 8-ми разрядки становится маленьким или надо сканировать FAT по кусочкам, что также тормозит.
Речи о гигабайтных дисках для 8-ми разрядки - это просто сказки для дураков. Такого в природе не бывает.
Смысла абзаца не понял. Возможно Вы пытались сказать, что, т.к CP/M работает только с юзерами, то какими-то средствами чтение/запись секторов каталога, заменялось на чтение/запись файла подкаталога, отчего CP/M работала с файлами подкаталога, как с юзером CP/M. Так и должна работать MSX-DOS 2.0.
Не для базовой CP/M 2.2. Это другая ДОС на основе BDOS CP/M. Понятно, что основная часть кода ДОС в другой банке. Но больший размер TPA оплачивается быстродействием, т.к считанные данные приходится пересылать из банки в банку.
Это не CP/M. ОЗУ в других банках, это не TPA, это просто какое-то ОЗУ. Если так считать, то в ОРИОНЕ с 256К, TPA в CP/M - тоже большое, но это же не так. TPA это только то, что в адресном пространстве DOS. Незачем грузить COM-файл в другие банки. Для больших файлов в CP/M грузят оверлеи или организуют "сокеты" для динамической подкачки кусков кода. И если есть RAM-диск и оверлеи подгружаются оттуда, то это ничуть не тормозит. Если бы был компилятор ЯВУ, что поддерживает банки ОЗУ, тогда это имело бы смысл, т.к для кода созданного ЯВУ как раз не хватает объёма TPA. Без этого от излишнего ОЗУ польза только для организации эл.диска.
Естественно, когда начинаешь искать что-то по MSX, то находишь кучу сайтов про MSX-компьютер. Но где исходники? Чтобы писать, что где-то есть - дайте ссылку на скачивание исходника.
Естественно. Её писал тот же Тим Паттерсон, что написал MSDOS. Он написал её по заказу Microsoft за 3 месяца 1984-го за 200.000 USD. Но он написал только MSX-DOS 1.0, где нет подкаталогов. Подкаталоги ввела уже сама фирма Microsoft 4 года спустя (видимо тогда на 8-ми разрядках появились винты и стали актуальны подкаталоги).
Все функции MSX-DOS для КР580 реализовал в 1997 С.Коровкин. Он сначала хотел написать полноценную ДОС с форматом MSDOS. Но в итоге сделал только программу обмена файлами между MSDOS и ОЗУ (под ОЗУ имею ввиду ORDOS, т.к по сути это тоже самое). Но он говорил мне, что он реализовал все функции нужные для MSDOS. Так что желающие могут дизассемблировать и получить нечто подобное MSX-DOS.
Я писал о маленьких каталогах безотносительно к их размеру, а чтобы сказать что есть не один общий каталог винта в 200 кб, а он разделен на много частей, со средним размером в 4 кб и числом экстентов до 256 (или даже 128). Поэтому поиск в подкаталоге занимает не 10 секунд, а 1 секунду.
Так сделано в моей TURBO-DOS. Там на части разбивается не только общий каталог, но и само пространство диска. При организации подкаталога, для него сразу выделяется сплошной кусок диска. В начале этого куска есть свой каталог. Для корневого каталога (корневого диска) все блоки входящие в подкаталог заняты. Но программе, находясь в подкаталоге не приходится работать с огромным каталогом. Она работает с маленьким каталогом. А с учётом того, что работа идёт не логическими секторами, а физическими и нет ненужных копирований, то скорость с винтом получается в 20 раз больше, чем в CP/M. Однако, если выделенное при создании подкаталога место закончилось, то для увеличения размера области для файлов в подкаталоге нужна специальная программа (освобождающая блоки за концом области выделенной подкаталогу). Но даже такая структура диска намного лучше, чем жёсткое разбиение винта на кучу мелких партиций, т.к такие подкаталоги можно оперативно создавать и удалять. В этой ДОС для больших файлов в каталоге не создаётся моря экстентов, как в CP/M, причём при сохранениии дефрагментации файлов, а размер блока - разный для разных файлов. Не знаю, поняли ли идею, но не важно.
При ускорении CP/M надо решить 3 задачи (но почти всё это полностью или частично лишает совместимости с CP/M)
- замена работы логическими секторами на физические
- устранение построения Alloccation Table (хранение её в готовом виде)
- разбиение общего гигантского каталога на много маленьких подкаталогов
Вариант использования структуры диска MSDOS я не рассматривал, т.к мне интересно было сделать что-то своё. К тому же я не уверен, что из-за низкой скорости CPU и малости ОЗУ, эта идеология лучшая для 8-ми разрядки. Совместимость с CP/M меня не волновала, т.к я давно убедился что от ЯВУ пользы нет.
Желательно попробовать, но я сомневаюсь, что можно что-то ускорить без ПДП.
Посмотрел свои старые листинги CP/M-BIOS винчестера и хотя ничего уже не понял, но всё-же увидел, что приняты меры ускорения (линейные участки для чтения-записи в одной итерации цикла сразу 16 байтов). Цикл чтения из флоповода существенно проще и короче. Поэтому так и должно было получиться, что скорость обмена вдвое ниже, чем с контроллером НГМД на ВГ93.
Во вложении привожу include-файл c подпрограммами для винта (петли чтения-записи это метки: 're_loo' и 'wrs_loo'). В 1990 я видел американский CP/M компьютер с винчестером и он тоже был тормозной.
Максимальный размер диска определяется максимальным размером блока (16 кб) умноженным на 65536 (номер блока двухбайтовый). Т.о это 1 Гб, т.е тут память не подвела. Максимальный размер файла определяется максимальным числом байтов описываемый одним экстентом умноженным на максимально допустимое число экстентов. В одном экстенте описывается 8 блоков по 16 кб. Указатель номера экстента (RC) может быть до 128. Итого максимальный размер файла: 8 * 16 кб * 128 = 16 мб.
16 блоков по 16 кб каждый, дают размер каталога в 256 кб. Такой каталог при реальных скоростях CPU будет сканироваться до минуты. При построении Allocation Table сканируется весь каталог в 256 кбайт, что займёт 1 минуту. То же самое произойдёт, если дать DIR. При запуске файлов, если файлов мало, то поиск будет быстрый. Но если ошибиться и задать имя файла, которого нет, то тоже будет сканироваться весь каталог целиком, и система будет читать каталог целую минуту. Будет ли такая система приемлемой?
Раз у Вас есть CP/M для винта и есть мнение, что она сохранится быстрой и при больших дисках, давайте узнаем, сколько будет читаться каталог в 256 кб. Для этого скопируйте файл размером в 256 кб и засеките время копирования. Результат не надо делить пополам, т.к CPU тратит время не только на само считывание, но и на просмотр экстентов. А при копировании просматривается весь каталог целевого диска в поиске есть ли файл с таким же именем. А затем строится Allocation Table целевого диска. В итоге копирование одного файла займёт ~3 минуты.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
