Реализация и поддержка FAT16/32 на Спектруме с HDD

[jtn]

baze уже написал поддержку fat16 для divIDE (readonly пока), скоро будет оболочка для этого и nmi menu. говорить .sna грузятся. еще хоят сделать сделать загрузку tap/tzx с помощью перехвата in a,(#fe) на rst #xx. у меня ничего не спрашивайте, лучше зайдите на ircnet #z80 и спросите Zilog'a (он по-русски понимает кстати)

[Advertiser]

[fk0]

На сколько я знаю, это не реализовано потому как под таблицы FAT требуется слишком много памяти...

Нет. Тривиальная реализация кэша как, например, было сделано в iS-DOS,
или как описывается в любой книге по устройству unix, кардинально решает данную проблему.

[fk0]

Hi Многоуважаемый All! Недавно заимел IDE-контроллер (Nemo), и у меня возникло огромное желание реализовать поддержку файловых систем FAT16/32 и возможно, NTFS, а также ext2/ext3/reiserfs на Спектруме.

Желание быстро иссякнет. Особенно если цель не имеет
практически никакого смысла. ПЦ-ориентированные ФС для
спектрума не эффективны и чрезвычайно ресурсоёмки.
Может быть, минимальный смысл имеет FAT12 и FAT16 --
исключительно с целью совместимости. Не только с ПЦ,
но и, например, с MSX.

Для спектрума считаю целесообразным поддержку ISO9660.
Причины разные:

* это международный стандарт, следовательно можно
расчитывать на поддержку данной ФС на разнообразном
оборудовании и в разных ОС;

* минимальная поддержка для копирования файлов уже
реализована в CD-Walk (см. http://spbzxnet.org.ru/cdwalk);
Я думаю, несложно будет его доработать для работы с
разделом HDD.

* В ФС ISO 9660 заложена возможность расширения
под конкретные нужды, чем активно пользуются. Так
Windows использует т.н. Jouliet расширение, а Unix --
Rockridge. Mac имеет своё. Спектрум может ввести собственное
расширение с целью поддержки специфических для него
атрибутов файлов (порядковый номер в каталоге, адрес
загрузки и т.п.);

* ISO9660 позволяет организовывать более сложную структуру
каталогов, чем ациклический граф с обязательно единственным
путём от каждого узла к вершине и наоборот (имеется ввиду FAT)
-- считаю, это важное свойство.

Из недостатков можно отметить опять необходимость дефрагментации диска (как в TR-DOS), что, впрочем, не особенно
актуально для современных носителей: объём типично ~640МБайт,
размер файла <64Кб. Итого имеем дробление диска на >=10000
независимых частей (файлов).

Имея справочный материал по командам HDD из газеты Абзац, я получил примерное представление о реализации чтения/записи на винт,

Написать грамотный драйвер без фирменных спецификаций
НЕВОЗМОЖНО. И не спорь. На сайте CDWALK (выше ссылка)
есть ссылка на источники информации. Абзац -- это вводная
статья, но ни в коем случае не справочный материал!

но сейчас мне не хватает именно информации о структуре и программировании FAT, серфинг в поисковиках дал только общее представление по сабджу.

Значит ты просто не умеешь пользоваться интернетом. FAT --
изобретение микрософта. И микрософт свободно публикует
всю необходимую информацию. Я почему-то её нахожу в
первых ссылках на гугле по запросу "FAT filesystem specification".

Может быть кто-то задавался подобным вопросом, и может поделиться своими исследованиями или документациенй ? Буду очень благодарен. В моих планах написание коммандера, работающего со всеми файловыми системами на zx, (tr-dos, is-dos(tr-dos, is-dos, msdos), в том числе и FAT. Согласитесь, было бы очень неплохо использовать весь обьем HDD ( а не 16 mb only как в ISDOS) исключительно для хранения спековского вареза, и любых других файлов неограниченного количества и размера, как это делают эмуляторщики.

Не соглашусь. Хрен ли толку с такого командера? Файлы туда-сюда
копировать? У меня и другие дела есть. А тот же ZXASM с винта
не запустишь. Или просто игрушки, демки. RAM-диск? Так говорят
те, кто практически так не пробовал: запись должна быть
надёжной -- когда я в ZASM нажимаю "Save" должно записываться.

С возможностью редактирования и копирования с/на tr-dos, isdos. IMHO, для ZX с HDD нужна не ось, а именно навороченный командер.

Я это слышу 7-й год.

В данный момент, испытывая дефицит информации, я пробую реализовать подобие FAT12 на винте. Если вам интересен данный subj, его востребованность на ZX, а также если вы желаете принять

Интересно -- см. выше. Драйвера любых контроллеров. Любых накопителей (из ширпотреба: ATAPI CD-ROM, ATA-2 HDD,
compact flash). Поддержка файловой системы ISO9660 на чтение
и на запись (по крайней мере на HDD, если на запись). Поддержка
виртуального TR-DOS диска, формируемого из каталогов ФС ISO9660.
Поддержка напрямую: запись это запись, а чтение это чтение.
Никаких доработок спектрума. Аппаратный минимум: Pentagon-128
и NEMO-IDE. Разрешается своп на диск (IDE), своп в 8-ю банку
памяти (скорпион и аналоги), своп в 2-ю банку кеша.
Всё (минимальный загрузчик и поддержка свопа) должно размещаться
в ПЗУ TR-DOS, остальное загружаться с диска, вариант: дополнительного ПЗУ (для чтения CD-ROM без наличия HDD) или
compact-flash -- это позволит обновление ПО.
Далее -- реализация псевдомногозадачного режима с высвопливанием памяти на НЖМД. Прерывание в обработчкие
клавиатуры ПЗУ Basic-48 и, параллельно, на кнопке Magic.

Это -- интересно. Реализовывать -- некому. Кто хочет тот
не знает как и не может. Кто может, тому нафиг не нужно.

[fk0]

В общем, всем интересующимся данной тематикой советую сходить по этой ссылочке и заиметь себе эту книжку,

Порвать её и спустить в сортир. Нельзя писать софт по книжкам.
Особенно работающий с дисками. Есть оригиналы, свободно доступны,
с формальным изложением всех тонкостей. Проблемы изучения английского
языка в режиме read-only -- смешны.

[fk0]

Кстати параллельно стоит вопрос написания универсального набора процедур для работы с винтом (а точнее с контроллером винта). Если это дело застандартизировать. И запихать например в свободныем места ТРДОС или в свободные странички ПЗУ, то это было бы какоето развитие и серьезное подспорие программисту (ибо не надо изучать весь десяток разных контроллеров). Ну и

Я принципиально против ПЗУ. Software -- это не законченное
изделие. У него нет финальной версии. ОНО ЖИВЁТ!.
Финальную версию имеет только мёртвый, бесполезный и давно
никому не нужный софт. ПЗУ же оно по-определению ПОСТОЯННОЕ,
НЕИЗМЕННОЕ. В ПЗУ может размещаться только то, что ни у кого
не возникнет желания менять. Загрузчик.

хардварщикам проще - написал свои процедуры и весь софт будущий будет совместим.

Я предлагал -- динамически загружаемый драйвер. Я могу даже пример привести: CD-Walk можно, теоретически, использовать с
ATM-Turbo-2+. Вега такую возможность в свою замороженную
версию CD-WALK не закладывал. Мысль, надеюсь понятна. Она
может стать ещё более понятна если выяснится, что ATM таки
не работает. Достаточно будет исправить и выпустить новую
версию модуля драйвера.

[fk0]

решить проблему... оптимальный вариант и по памяти и в плане скорости - B-Tree , как пример можно рассматреть HPFS (OS/2), да и в плане отказоустойчивости - NTFS отдыхает

При проектировании ОС UNIX о таком решении уже знали. И отказались.
И смогли обосновать почему -- затраты на поддержку B-tree изначально
достаточно высокие и далее растут линейно. Линейный же каталог
изначально не требует практически никаких затрат, но обгоняет B-tree
по экспоненте. Проблема в том, что прямая с экспонентой пересекаются
достаточно далеко от нуля. Ну не бывает, типично, многих тысяч
файлов в каталоге. Сотни -- бывают. Тысячи -- редко.

[fk0]

гы гы! нееее! не в одном каталоге а хотя бы на диске!!!! поскольку ты один фиг будешь перебирать всё подряд!

ЗАЧЕМ?

Посмотри как сделано в iso9660.

В том же unix это сделано на уровне пользовательских программ -- locate.

Простота -- залог успеха.

[fk0]

видел предложения сделать чтение/запись сектора. но есть же ещё
несколько десятков ATA-команд. не будет же драйвер таким объемным. сами команды стандартизированы и выносить в драйвер их коды и протокол работы с каждой нет никакого смысла, на разных контроллерах они одинаковы. пускай уже программа разбирается.

Прежде стоит задать вопрос. ДРАЙВЕР ЧЕГО? Контроллера?
Накопителя вообще? Именно НЖМД с ATA-2 интерфейсом?

предлагаю команды разбить на более мелкие операции. всего я насчитал 5 необходимых:

1. ожидание нужного состояния (BUSY/DRQ) регистра статуса, например

Я даже про реалтайм не буду (музыка и т.п.). Но есть же просто
ИНТЕРАКТИВНЫЕ ПРОГРАММЫ. Тот же CD-WALK. Курсор должен
бегать по экрану, часы переобновляться, кнопка отмены срабатывать
немедленно и т.п.

4. передача сектора (512 байт) из контроллера в память (HL).
5. аналогично передача сектора из памяти в контроллер

А ничего, что для ЛЮБОГО данные передаются не секторами,
а словами (16 бит)? Для CD-ROM, например, запись пакета
требует передачи 6 слов...

разместить точки входа лучше последовательно как 5 jr xxxx, 128 байт должно хватить на весь драйвер (или если моместить jr в середину, то адресуем и 256 байт). обязательно нужно стандартизировать, какие регистры драйвер может использовать для своих нужд, а какие не меняет

Я уже высказывал кажется, я принципиально против каких-то
там точек входа. Не надо мешать в общую кучу мух с котлетами.
Есть ФУНКЦИИ, есть ПРОГРАММНЫЙ ИНТЕРФЕЙС, обеспечивающий
возможность их использования. Это разные вещи.

Что касается драйвера, уже 3 года прошло как всё давно
хорошо продумано и опубликовано (см. http://spbzxnet.org.ru/cdwalk/ide-driver.html).
Существует 12 "точек входа". Ряд из них обеспечивает
работу с собственно накопителем: чтение и запись
регистров поштучно и блоком (только запись -- для команд),
чтение и запись данных. Контроллер накопителя программно
доступен как 9/10 регистров и данный интерфейс полностью
достаточен. Остальные функции требуются для поддержки
собствнно "контроллера интерфейса ATA" (например, Nemo-IDE).
Они нужны. Так, например, в цитируемом выше варианте не
предполагалось наличие более одного канала (разъёма на плате)
для подключения шлейфов. В действительности спринтер же
имеет два. Как ваш драйвер будет работать на спринтере?
12 функций -- это именно что минимум. Работа с прерываниями
причём не проработана. Занимает... 512 байт минимум, лучше
до килобайта. Это практический опыт 8 контроллеров. Там же
циклы развёрнутые (в меру) нужны кое-где, иначе совсем по
скорости печально выходит.

Что касается модулей (там же, на сайте cdwalk), в настоящий момент первая версия признана крайне неудобной и неэффективной. Положительно оценивается возможность реализации на ZX COM-подобного (Component Object Model) интерфейса, но этим
никто не занимается и, наверное, не будет.

[SMT]

Написать грамотный драйвер без фирменных спецификаций
НЕВОЗМОЖНО

вот тут абсолютно согласен. тот же AlCo вместо того, чтобы скачать SFF-8020i: ATA Packet Interface for CD-ROMs, начинает танцы с бубном в своих программах. то у него HDD-Doctor не видит CD-ROM без "инициализации в HDST" (не удосужился прочитать насчёт DRDY в ATAPI), то частенько злоупотребляют (началось, наверное, с Веги) пакетом с кодом команды #00 перед основной командой (AlCo так и думает, что это nop). а почему она иногда избавляет от глюков и как сделать правильно, можно понять, почитав стандарт

всё-таки сейчас не 96 год, когда информация добывалась из драйверов и сплетен

>>ожидание нужного состояния (BUSY/DRQ) регистра статуса"
Я даже про реалтайм не буду (музыка и т.п.). Но есть же просто
ИНТЕРАКТИВНЫЕ ПРОГРАММЫ

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

Положительно оценивается возможность реализации на ZX COM-подобного

тут проблемы с централизованной регистрацией интерфейсов (реестро-то нету)

[CHRV]

вот тут абсолютно согласен. тот же AlCo вместо того, чтобы скачать SFF-8020i: ATA Packet Interface for CD-ROMs, начинает танцы с бубном в своих программах. то у него HDD-Doctor не видит CD-ROM без "инициализации в HDST" (не удосужился прочитать насчёт DRDY в ATAPI), то частенько злоупотребляют (началось, наверное, с Веги) пакетом с кодом команды #00 перед основной командой (AlCo так и думает, что это nop). а почему она иногда избавляет от глюков и как сделать правильно, можно понять, почитав стандарт

Заявляю что сбросил АЛКО все стандарты по ATAPI и прочему ему на флашку!
Так что АЛКО надеюсь будет писать по спецификациям .