Спасибо за разъяснение. К сожалению, CP/M работает секторами по 128 байт, из-за чего читает не сразу на место загрузки (DMA), как это делает RK-DOS, а сначала читает в дисковый буфер, равный, в минимуме, размеру физ.сектора, а в оптимуме, равный размеру CP/M-блока в 2 кб. А затем выполняет море пересылок лог.секторов по 128 байт, что дико тормозит.Сообщение от uart
Поэтому первая версия CP/M что я странслировал на базе подпрограмм Е.Седова (в 1994) работала примерно в 50 раз медленнее, чем RK-DOS. Т.е потребительная ценность была нулевой. Спустя год усовершенствований удалось довести скорость обмена в CP/M до скорости примерно в 10 раз медленнее, чем RK-DOS. Это довольно быстро, с учётом того, что в RK-DOS дискетная загрузка происходит мгновенно, что никаким версиям CP/M для 8-ми разрядок и не снилась. Скорость обмена такая же как при SD-формате (400К) с КНГМД на базе ВГ93.
Однако, чтобы выиграть скорость использовались сектора не 512 байт, как у Е.Седова, а сектора с размером CP/M-блока (отпадают лишние поиски секторов, а также расчёты позиций в буфере). Сектора размером в блок не позволяют максимально использовать полезный объём трека, хотя существенно ускоряют. Максимально выгодны сектора размером целиком во весь трек. Формат - один сектор на трек. Что не только даёт максимальную ёмкость диска (отпадают межсекторные гапы, куча служебной информации, а кратность размера сектора допустима в 128 байт, - т.е всё пространство трека используется максимально, т.е на форматную ёмкость), но и существенно ускоряет.
Недостаток такого формата в том, что если есть дохлота в треке, то дохлым помечается не только один CP/M-блок, а сразу несколько, т.е при плохих дисках быстро растут потери полезного объёма. Кстати формат один сектор на весь трек применяется в первом Apple MAC (880К на DD-диск). Второй, более существенный недостаток, - это большой размер дискового буфера, что сокращает TPA, поэтому, когда я стал использовать DOS ОРИОНА в банке 0 (где свободного ОЗУ совсем мало), то вынужден был вновь вернуться к формату с секторами по 512 байт и найти другие способы повышения скорости обмена.
Кроме того, при использовании даже самОй RK-DOS на хорошем дисководе приходится менять размер сектора, т.к во VTOC на информацию о занятых секторах трека отведён только один байт, тем самым число секторов в треке не может превышать 8 (для сравнения в DOS Агата на это отведено 4 байта, отчего макс.число секторов 32). Таким образом при 8 секторах на трек мы имеем только 8*512= 4 кб на трек, т.е лишь 640 кб на диск. Поэтому приходится размер сектора в RK-DOS увеличивать до 1 кб, что позволяет иметь диски размером до 1280К. Обычно я использовал RK-DOS в формате 800К (с секторами в 1 кб), а CP/M в формате 880 и 960 кб. Для обоих случаев предложенная оптимизация - не вариант.
Это я пояснил, почему данный трюк для CP/M не очень-то удачен. Если надо читать блок в 1 кб или в 3 кб, как это поможет? Кстати, в RK-DOS имеется возможность поднять скорость обмена, используя формат с интерливингом. Впрочем, RK-DOS и без того самая быстрая ДОС для 8-ми разрядок. Хотя для винчестера, где важна скорость, толку от этого мало, т.к концепция изначально не поддерживает большие диски.
Мне времени не всегда хватало. В ранних вариантах CP/M на базе РК-КНГМД, где я ещё не модифицировал константы (в процедурах Е.Седова для РК-КНГМД, почти всё на задержках, привязано к скорости CPU) приходилось работать на низких скоростях CPU в формате 880 кб и выше. И скоростей не хватало (при отказе от извращений Е.Седова, что пригодны только для КР580, времена петель увеличись в 1.5 раза) и хотя аппаратно увеличить скорость прогона можно, но код не позволяет. Вот тут и нужен был дополнительный ресурс ускорения процедур.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
