.
Вид для печати
.
Никак не получится - только полным сканом
можетЦитата:
- может ли быть на дискете нестандартный формат в котором бы было: кол-во секторов на треке и размер этих самых секторов разное ? (например на первом треке - 16 секторов по 256 байт, на втором треке 8 секторов по 512 байт, на третьем треке 4 сектора по 512 и 8 секторов по 256 итд...
1024 байтаЦитата:
- какой максимальный размер сектора может быть ? и есть ли какие-нибудь ограничения у TR-DOS на этот счёт ??
Стандартными средствами получается только минимум информации - это количество файлов (для системы файлов TR-DOS) и свободное место (в последнем даже не уверен). Насколько знаю, почти все существующие программы получают эту информацию напрямую из 9 сектора.
Второе, чисто физически диск отформатировать можно хоть как - даже, скажем, на первой дорожке всё стандартное (16x256) на второй первый сектор 256, второй 1024, третий вообще 128 и т.д. Логически же необхидимо эту информацию о размерах и порядках секторов каким-то образом структурировать. Классический Тырдос это делать к сожалению не позволяет. Насколько я знаю это относится в т.ч. к is-dos'у. Т.е. на спектруме нет готовых процедур чтобы обслуживать такие диски - всё писать придётся самому. И естественно, так как нет автоматической фиксации физического формата диска, то все примочки с размерами секторов и их последовательностями придётся тупо запоминать/записывать на бумажке и в конечном итоге фиксировать в управляющем коде.
В-третьих, существует 4 типа секторов - 128,256, 512 и 1025 байта. Выбирай любой.
Закономерный вопрос, зачем это нужно?
Добавлено через 6 минут
И ещё, насчёт "выщемить". В контроллере 1818ВГ93 есть замечательная команда "читать индекс". Последовательно используя эту команду можно получить полностью карту дорожки, и соответственно применяя к каждой дорожке - карту диска целиком.
Я сам её использовал и работает она достаточно хорошо. Единственное, она не позволит получить данные о хитро-форматированных секторах (например, сектор с отсутствующим концом, или с икажённой CRC и т.п.), потому что команда будет завершаться ошибкой. В этом случае если хоть что-то и может помочь, то только команда чтения дорожки.
Если есть время и желание иметь жестокие извращения с тр-досом, можно получить карту дорожки следующим образом:
- читать каждый сектор по одному (#3d13, c=5,b=1)
- читать его в буфер до 1к, заполненный заранее известными данными. Для пущей надежности два раза (чтоб определить длину)
- перебирать все сектора на дорожке (в особо тяжелых случаях до 255, ибо они могут иметь практически произвольную нумерацию, если я не ошибаюсь) и учитывать только прочитанные
Итого- долго, длинно, нудно, но стандартными средствами (разве что надо перехват ошибок сделать и ничего не печатать через пзу, ибо большие сектора будут налазить на системные переменные).
Не совсем так. Она читает заголовок единственного, первого попавшегося сектора на дорожке. Никто не даст тебе гарантии что последовательно выдавая ее ты получишь все сектора. Ты можешь получить одно и то же несколько раз, а на какой-то сектор не попасть вообще.
Добавлено через 1 минуту
При использовании функций 5 и 6 - не будут, ибо чтение/запись производится в указанный пользователем буфер, а не в системный.
По поводу флоппи-драйвера для дверей... Я тут однажды фантазировал, что будет, если я захочу дальше развивать trackdisk.device для MorphOS и буду учить его понимать форматы, отличные от 18 секторов по 512 байтов. Задача абсолютно та же самая, что и у тебя. Аппаратура схожая. Вот мои соображения.
Для начала несколько допущений. Без них зарываемся сразу.
Допущение N1: файловая система знает, какие форматы могут быть у носителя.
Допущение N2: все сектора на диске одинакового размера.
Теперь реальные условия.
Условие N1: сектора на дорожке не обязательно пронумерованы по порядку (см. IS-DOS).
Условие N2: существует несколько способов трансляции номер блока ->CHS. Первый - традиционный, один цилиндр - две дорожки. Назовем его interleaved (чередующий). Второй - сначала проходим все дорожки на одной стороне, затем на второй (это используют например PlusD и Opus). Назовем его sequental (последовательный). Третий - разные стороны рассматриваются как разные диски (+3DOS).
Проблему с номерами секторов можно решить, введя таблицу трансляции логических номеров в физические (как это и сделано в IS-DOS). Драйвер дисковода должен иметь вызов, позволяющий задать такую таблицу. А также количество секторов, их длину, и способ трансляции номеров сторон (только верхняя, только нижняя, interleaved, sequental).
Еще предусмотри указание плотности записи (DD/HD) - на будущее, ибо дисковод об этом не отчитывается. Автоматически определить плотность записи легко методом тыка, но только при том условии, что вставлена форматированная дискета. Если же мы хотим отформатировать абсолютно пустой диск, то плотность нужно указывать насильно, иначе контроллер будет работать не в том режиме который надо и ничего не получится.
Ну конечно можно и "чтением дорожки" прочитать первую дорожку, проанализировать ее и считать что все дороги такие же. В принципе идеологически это более правильно. Я даже пока сам тебе писал, стал склоняться к такому варианту.
Но сделать команду для явного указания геометрии тоже надо - на случай переформатирования дискеты из одной в другую.
Не вижу такой ситуации чтобы такое произошло. Я уже указал области ограничения этой команды - только нарочно испорченные сектора (или кривые руки программера, но это ... другая история). Анализировал так и защищённые диски и простые - всё отлично работает.
Эта команда в отличие от "чтение дорожки" не требует дополнительных рассчётов - готовая Plain-таблица на выходе. Насколько я знаю теневой сервис-монитор Скорпиона использует эту же команду для чтения формата дорожки, вовзращая данные о дорожки в почти таком же формате, котором возвращает ВГ93 при "Чтении индекса".
2 Griv: а как это делается? Быстро-быстро выдаем друг за другом пачку команд "чтение индекса", пока повторы не пойдут?
А кто спорит то??? Я прочитаю 15 индексов секторов и будут они одинаковые! От этого эффективность команды не снизится ни на йоту! с точностью до наоборот - я буду точно знать что есть 15 секторов и они имеют одинаковые номера!
P.S. (сорри за оффтоп)Кстати... недавно прочитал новейшие тенденции... производители жёстких дисков жалуются что размер физического сектора в 512 байт слишком мал, что значительно уменьшает эффективность использования пластин жёстких дисков... Для ТыРдосистов же всё просто - у нас УЖЕ есть диски по килобайту на сектор!!!
Добавлено через 11 минут
Нет. Там же есть регистр состояния %) и есть бит индексного отверстия... В чём вопрос???
Фишка вся в том что ты никогда не узнаешь, прочел ты 15 раз один и тот же индекс, или все 15 раз разные. Для того чтобы точно попадать даже в стандартный формат диска нужно калибровать дисковод сделав точный хронометраж скорости вращения. Но если на дорожке будут сектора разного размера то это опять получится мимо тазика.
Поэтому кроме как прочесть дорожку целиком - способа нет.
Кстати чтение дорожки целиком в общем случае не поможет тоже. Диск может быть с физическим дефектом, или в каком-то из gap-ов может быть записан индексный маркер, или вводная последовательность, что вызовет дальнейший сбой синхронизации.
То есть "сырые данные" с дорожки получить можно, но вот в пригодном для какой-то логической обработки виде - в общем случае нет.
Если бы все было так просто, то никто нигде бы вручную геометрию диска не задавал.
Ну как %) Пришёл - и всё! баста! заканчиваем чтение!
Добавлено через 9 минут
Если диск защищённый - то достаточно высокая вероятность того, что из прочитанной дорожки ничего восстановить не получится (те же плавающие биты вообще невозможно восстановить на домашнем оборудовании). Если же диск нормально отформатированный просто имеет нестандартные размеры/последовательности секторов (или даже номера), то это всё легко автоматически может быть восстановлено из содержимого дорожки. Кстати эта команда примечательна ещё тем, что позволяет определить истинную длину дорожки - у меня она колебалась от 7 до 8 килобайт. Теоретически можно было бы на диске разместить 6 секторов по 1024 байта, что даст ёмкость (огого!) по 960 кб на диск. Практически же, так не получается по разным причинам - укороченный индексные области не читаются на всех дисководах (они нужны вообще то для синхронизации); при записи диска обновление происходит не только данных сектора но и контрольной суммы сектора, что может (если слишком короткие зоны синхронизации) затереть начало следующего сектора и прочая прочая...
Кстати, что интересно. Кажется в спектрофоне или где то ещё я видел указание длины дорожки - около 6 килобайт - приводилась точная цифра. В общем то очевидно, что эта цифра будет колебаться, так как зависит от ширины индексного отверстия, от скорости вращения диска (она тоже варьируется!!!) и т.д., мне непонятно как могла получиться конкретная цифра %)
И ещё, я не фанат команды "чтения индекса", не вешайте на меня собак, я просто сказал что это было бы элегантно, и потом я сам использовал её где то... хотел сделать чтото вроде Disk Formatter который восстанавливает формат диска.
я писал анализатор диска
читаешь дорожку (2 раза) а потом тупо сканируешь данные на предмет соответствий
так я писал копировщие для ZX Power 4
а там неслабая защита стояла