.
TR-Dos Diskette
.
Последний раз редактировалось breeze; 11.10.2013 в 19:25.
(๑•̀ㅂ•́)و✧ Doors UI → https://t.me/doorsui | https://t.me/atari_xl_xe ← Atari XL/XE (●´ω｀●)ゞ
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Никак не получится - только полным сканомСообщение от breeze
Интересует, возможно ли стандартными средствами получить информацию о дискете?
сколько на дискете треков, сколько секторов в треке, и каков размер одного сектора в байтах ?
конечно всё это можно выщемить методом перебора и сканирования соответствующих частей дискеты, но вдруг есть счастье в этой жизни и можно как-то без доп процедур
может- может ли быть на дискете нестандартный формат в котором бы было: кол-во секторов на треке и размер этих самых секторов разное ? (например на первом треке - 16 секторов по 256 байт, на втором треке 8 секторов по 512 байт, на третьем треке 4 сектора по 512 и 8 секторов по 256 итд...
1024 байта- какой максимальный размер сектора может быть ? и есть ли какие-нибудь ограничения у TR-DOS на этот счёт ??
Стандартными средствами получается только минимум информации - это количество файлов (для системы файлов TR-DOS) и свободное место (в последнем даже не уверен). Насколько знаю, почти все существующие программы получают эту информацию напрямую из 9 сектора.Интересует, возможно ли стандартными средствами получить информацию о дискете?
сколько на дискете треков, сколько секторов в треке, и каков размер одного сектора в байтах ?
конечно всё это можно выщемить методом перебора и сканирования соответствующих частей дискеты, но вдруг есть счастье в этой жизни и можно как-то без доп процедур
ps. попутно 2 вопроса:
- может ли быть на дискете нестандартный формат в котором бы было: кол-во секторов на треке и размер этих самых секторов разное ? (например на первом треке - 16 секторов по 256 байт, на втором треке 8 секторов по 512 байт, на третьем треке 4 сектора по 512 и 8 секторов по 256 итд...
- какой максимальный размер сектора может быть ? и есть ли какие-нибудь ограничения у TR-DOS на этот счёт ??
заранее биг snx!
Второе, чисто физически диск отформатировать можно хоть как - даже, скажем, на первой дорожке всё стандартное (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 - не будут, ибо чтение/запись производится в указанный пользователем буфер, а не в системный.
Последний раз редактировалось Sonic; 28.08.2007 в 09:57. Причина: Добавлено сообщение
По поводу флоппи-драйвера для дверей... Я тут однажды фантазировал, что будет, если я захочу дальше развивать trackdisk.device для MorphOS и буду учить его понимать форматы, отличные от 18 секторов по 512 байтов. Задача абсолютно та же самая, что и у тебя. Аппаратура схожая. Вот мои соображения.
Для начала несколько допущений. Без них зарываемся сразу.
Допущение N1: файловая система знает, какие форматы могут быть у носителя.
Допущение N2: все сектора на диске одинакового размера.
Теперь реальные условия.
Условие N1: сектора на дорожке не обязательно пронумерованы по порядку (см. IS-DOS).
Условие N2: существует несколько способов трансляции номер блока ->CHS. Первый - традиционный, один цилиндр - две дорожки. Назовем его interleaved (чередующий). Второй - сначала проходим все дорожки на одной стороне, затем на второй (это используют например PlusD и Opus). Назовем его sequental (последовательный). Третий - разные стороны рассматриваются как разные диски (+3DOS).
Проблему с номерами секторов можно решить, введя таблицу трансляции логических номеров в физические (как это и сделано в IS-DOS). Драйвер дисковода должен иметь вызов, позволяющий задать такую таблицу. А также количество секторов, их длину, и способ трансляции номеров сторон (только верхняя, только нижняя, interleaved, sequental).
Еще предусмотри указание плотности записи (DD/HD) - на будущее, ибо дисковод об этом не отчитывается. Автоматически определить плотность записи легко методом тыка, но только при том условии, что вставлена форматированная дискета. Если же мы хотим отформатировать абсолютно пустой диск, то плотность нужно указывать насильно, иначе контроллер будет работать не в том режиме который надо и ничего не получится.
А у меня что, разве не так?
Я тебе говорю о том, что драйвер FS должен выдать драйверу флопика сведения о реальной геометрии накопителя. Тогда драйвер флопика сможет давать тебе данные.
Ну конечно можно и "чтением дорожки" прочитать первую дорожку, проанализировать ее и считать что все дороги такие же. В принципе идеологически это более правильно. Я даже пока сам тебе писал, стал склоняться к такому варианту.
Но сделать команду для явного указания геометрии тоже надо - на случай переформатирования дискеты из одной в другую.
Не вижу такой ситуации чтобы такое произошло. Я уже указал области ограничения этой команды - только нарочно испорченные сектора (или кривые руки программера, но это ... другая история). Анализировал так и защищённые диски и простые - всё отлично работает.
Эта команда в отличие от "чтение дорожки" не требует дополнительных рассчётов - готовая Plain-таблица на выходе. Насколько я знаю теневой сервис-монитор Скорпиона использует эту же команду для чтения формата дорожки, вовзращая данные о дорожки в почти таком же формате, котором возвращает ВГ93 при "Чтении индекса".
2 Griv: а как это делается? Быстро-быстро выдаем друг за другом пачку команд "чтение индекса", пока повторы не пойдут?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
