программирование fdd

народ, нужна помощь.
с самим программированием fdc я разобрался.
меня интересует:
1. самый главный вопрос. это как посчитать GAP для дискет.
можно конечно воспользоваться таблицей из linux или драйвера 800. но там gap только для разного количества секторов на дорожке, а про изменения gap при разном размере сектора нечего негде нет.
вот мне и интересно есть ли какая-нибудь формула или еще что.
2. как автамотически определить gap при первом обращении к диску.
то есть как понять что он правильный. например если у меня есть таблица gap, то как понять какой тип диска передомной. ведь для определения мне надо прочитать первый сектор, но как узнать что я его правильно прочел.
3. влияет ли скорость врашения в современных дисководах на результат.
4. как работать с 288 дискетами. я не понимаю команду perpendicular mode надо слать перед каждой командой или только один раз. и существуюл ли вообще такие дисководы. насчет дискет я читал что из обычнои 144 можно сделать 288. но вот про дисководы я не слышал ничего.

просьба не писать зачем тебе это надо и тп.
мне это очень интересно и нужно. в нете нечего не нашол. а в исходниках линукса сложно разобраться полностью, они слишком большие.

 

abcd008
gap нужно брать из таблицы, каких-то формул для его расчета нет, есть стандартные параметры для разных типов дискет. В принципе эта табличка параметров дискеты есть в области данных БИОС вот здесь написано подробно http://www.lib.csu.ru/DL/bases/prg/frolov/books/bsp/v01b/ch1.htm, правдо сразу предупрежу она не всегда храниться по фиксированному адресу как в этой статье, чисто когда драйвер тестил, обнаружил, что на award'е находится по этому адресу, а на ami нет, по-нормальному определить этот адрес можно из какого-то вектора прерывания (не помню точно, почитай). А так стандартный способ определить тип дисковода через CMOS.

Нету современных дисководов их уже давно не выпускают, ну на моем все работало как-правило и без задержки после запуска мотора, но лучше всетаки ее сделать, ну для чтения можно "долбить" дисковод пока он не наберет нужные обороты и CRC код совпадется, а вот для записи нужно обязательно делать задержку при после включения мотора.

Не знаю, а таких приводов и дискет не видел никогда, не знаю выпускались ли они вообще, а то может были только экспериментальные образцы. Я в своем драйвере поддержку дискет такого формата не делал, да вообще достаточно только 1.44 сделать, других просто не найдешь (ну только на рынке раритетов может быть ), да и вообще филиппиками системные блоки давно не комплектуют.

Да ну знающие люди поймут, первый драйвер дискового устройства для моей ОС был конечно флопик, т.к. на первый взгляд с ним работать проще. Но я сразу скажу что написать драйвер FDD далеко не самая простая задача т. к. все приходится делать вручную вплоть до запуска мотора, в отличии например от ATA c более высокоуровневым интерфейсом, ну там правда свои проблемы, которые решить сложней...

 

1. а gap, по-моему, ни на что не влияет. Он там для красоты. Ну, при форматировании можно заморочиться, ради скорости последовательного чтения/записи но как, я честно говоря не знаю, думаю надо экспериментировать. Я, когда развлекался, эти значения где-то нашёл. Сейчас я бы их искал в fdutils. В ядре linux тоже можно, но ядро меньшее количество форматов поддерживает.
2. см. 1. Контроллер флоповода сам ищет сектор в пределах дорожки, надо лишь указать номер этого сектора. Если же сектор не прочитается, то контроллер вернёт ошибку.
3. Наверное нет. А может и влияет: скорость чтения/записи меняется.
4. Для начала надо купить привод, который умеет работать в перпендикулярном режиме. Сам я таких в глаза не видел, но говорят бывают. Или бывали когда-то. Насчёт того, имеет ли смысл втыкать в него 1440Kb дискеты -- я честно говоря не знаю.

 

Рынок раритетов... Спросил у гугла, такой раритет как 2.88Mb привод стоит 130EUR: http://abcresellers.com/store/product64.html
Но я не согласен что имеет смысл ограничиваться форматом 1.44Mb. Более того, поскольку флопов больше нигде нету, то имеет смысл забыть про совместимость, и ограничиться каким-нибудь другим форматом, скажем в 1640Kb или 1860Kb.

 

gap таблица у меня есть, но там нет значений gap для секторов больше 512.
как его посчитать самому?

я тоже не встречал 288 дисководов, но если бы их не было то линух бы их не поддерживал.

еще есть вопрос: как отределить тип работы XT AT PS2. или они все AT.
но PS2 вроде тоже совместимы

 

abcd008

Экспериментально. В идеале на многих-многих приводах, на дискетах разных производителей. В реальности, скорее всего придётся обойтись одним-двумя приводами, и парой типов дискет. Пробуешь разные значения, если форматируется/читается/пишется то уменьшаешь значение, иначе увеличиваешь. Задача найти минимальные значения, которые достаточно надёжны.

 

abcd008

Сейчас все поголовно АТ-совместимые, других не найдёшь. Была ли какая-то возможность определить -- не помню (хотя, если процессор 8088, то это точно не АТ -- в них процы, начиная с 80286, стояли). Были ещё PCjr, кстати...

А вообще, о совместимости надо заботиться только с современным железом, а со старьём лучше даже не заморачиваться -- пустая потеря сил и времени.

 

просто если я их сам отбалды придумаю, то не факт что они на другом компе прочитаются.

 

Где-то под первым мегом есть байтовая ячейка, значение которой указывает на тип машины. У меня до сих пор вроде бы выполняется проверка на наличие АТ-сигнатуры. Если не ошибаюсь, это 0xFC.

 

интересен тот факт что линукс определяет тип дисковода в cmos(10h).
но ведь в биос можно установить разный тип и даже выключить. а fdc всеревно останетца преждним.
его можно буждет найти через порты.


еще один вопрос в книгах которые я читал ни слова про порт 3f3h. а в документации от интел
написано что через него можно определить тип дискеты и дисковода.

вот отрывок из статьи которую вы мне скинули:
The TDR register is the Tape Drive Register and the floppy disk controller media and drive type register. Only what has been called the "enhanced" mode of operation is supported and documented here.


Table 61. Media ID Bit Functions
======================================
Bit 7, 6,5 |Media Type
===========|==========================
X X 1 |Invalid Data
-----------|--------------------------
0 0 0 |5.25 in
-----------|--------------------------
0 1 0 |2.88 Megabyte (formatted)
-----------|--------------------------
1 0 0 |1.44 Megabyte (formatted)
-----------|--------------------------
1 1 0 |720 Kilobyte (formatted)
|
======================================

 

есть в самом конце bios, там и название и дата и тд. но не факт что в том же uefi этот байт будет.

 

Зачем? наверняка abcd008 нужно сделать только поддержку, ну может грузить свою ось, все рано для бльшего проще потом написать драйвер юсб флешки например. И приятно когда твой драйвер читает любые дискеты.

Сделай пока драйвер драйвер для нормального размера сектора, а потом можешь и 1024 (если привод такой найдешь ).

Ой какое ошибочное мнение, просто некоторые последние модели дисководов могут сами вычислить это значения в случае невозможности использовать запрошенного, но рассчитывать на это я бы не стал.

Опять же только некоторые последние модели и то может потребоваться подать специальные команды перевода в этот режим.

CMOS

Экспериментально можно конечно все определить.... но вот надежность такой записи меня почему-то смущает, есть готовые табличные значения для <= 1.44 они стандартизированы, для 2.88 для каждого дисковода могут быть свои, однако есть стандартные значения, найди книгу Михаила Гука "Дисковая подсистема ПК" там есть примечания к полям gap в которых указаны стандартные значения.

Абсолютно согласен с этими высказываниями.

 

>Сделай пока драйвер драйвер для нормального размера сектора, а потом можешь и 1024 (если привод такой найдешь ).

любой дисковод может поддерживать 512, 1024 и тд. сектор. это стандарт и от диска не зависит.
диск это просто магнитная "лента". а разметку делаешь сам, как хочешь.

если использовать команды сдвига головки, вместо seek. то можно даже номера дорожек в любом порядке записывать
(13748). для шифрования хорошо подходит.

а gap нужен просто для того чтоб привод мог определить где кончается сектор.
и на современных приводах он может быть меньше чем на старых моделях. но тогда не смогут прочитаться на старых приводах.

 

shm

=)
Последние -- это выпущенные после 1990 года?
abcd008

Угу. Но если ты планируешь изобретать свои собственные форматы, то насколько я понимаю других путей у тебя не будет, кроме экспериментальной проверки. Если же ты готов ограничится уже проверенными на практике форматами, то возьми fdutils и посмотри там. Кстати там же есть программка superformat, которая измеряет параметры дисковода/дискеты, в частности raw-ёмкость дорожки. Уж не знаю, уточняет ли она секторный gap (никогда в сорцы не заглядывал), но чего-то она там измеряет.

 

а вообще формула для gap должна быть. ведь не зря же в книгах и в доках пишут фотмат дорожки.
где сколько байт и тд. а еще я где-то читал что при скорости вращения 300 на дорожку помещается 36,62Кб(вместе со служебной информацией). исходя из этого как-то должно считаться.

 

Точную дату не назову, но вот ты не внимательно меня читал. Я написал, что некоторые последние модели дисководов могут сами вычислить эти значения, т. е. и сейчас могут в системных блоках выпуска где-то в районе 2000х годов, могут быть приводы не "переваривающие" некорректный gap.

 

r90
я почитал доки к fdutils и не понимаю откуда они взяли 12450 байт на дорожку. для какой скорости это посчитано?

 

abcd008

Это, если я правильно тебя понял, raw-плотность. Сектор ведь пишется в на дорожку в виде эдакой структуры данных, которая помимо прочего содержит и данные которые записываем мы. Вот если обойтись без всех этих структур (что вряд ли возможно на практике), просто писать на дорожку наши данные без разметки, то поместится 12450 байт. Но это не точная цифра. Она меняется в зависимости от привода и дискеты. Она, я думаю, меняется в зависимости от того, на какую дорожку мы пишем.

Не знаю. Открой сорцы superformat, она выполняет эти расчёты.

 

вопрос не по теме:
почему все пишут что сейчас архитектура AT а не PS/2.
ведь байт в области биос 40Eh помечен как LPT4, а в PS/2 как начало области EBDA. коем он и является уже давно.
и в спецификации acpi про него неписано что это адрес сегмента ebda.

отсюда и вопрос?

 

abcd008,

Насчёт дискет: есть же стандарты, про 3.5" HD (ECMA-125, ISO/IEC 9529:1989) чётко написано — плотность записи 15916 ftprad (изменений полярности на радиан; т.е. на круг выходит чуть больше 100000 ячеек, или 12500 байт; это неплохо согласуется с частотой вращения носителя 300 об./мин и скоростью обмена данными 500 кбит/с). Там же подробно расписана структура дорожки и прочие ограничения.

Архитектура уже давно не AT (если под этим иметь в виду 8/16-бит ISA), да и в старших моделях PS/2 использовалась шина MCA. Связь этого со структурой BDA и наличием EBDA довольно туманна.