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

[SMT]

дабы не было "левых" декодеров, если кто поймет, откуда это

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

[Advertiser]

[Alex/AT]

Remap - это "журнал транзакций". В ремап дату записываются сами сектора, которые будут перезаписаны (каталоги, FAT), а затем проставляется отметка транзакции в ремап, которая указывает, какие сектора куда (в ремап дату) переехали.
Фрагменты обрабатываются как в FAT.

Из всего этого очень полезна будет транзакциональность и хеширование имен файлов в каталогах.

[Alex/AT]

лучше бы просто русскими словами

Хммм, давно устоялась привычка делать все описания на английском ж)

[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.

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

[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 и прочему ему на флашку!
Так что АЛКО надеюсь будет писать по спецификациям .

[fk0]

Про ожидание BUSY:

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

Что касается прерываний: ничего из сказанного не понял. Могу
только сказать, что прерываний для создания интерактивных
программ с разумно-минимальным временем реакции не нужно.
Достаточно таймера. Нет, в спектруме я понимаю -- прерывания
исполняют роль таймера. Больше ничего не нужно. И не спорь.
Абсолютно любой алгоритм с циклами разбирается до уровня
конечных автоматов, где есть один единственный цикл на всю
программу. Прерывания нужны только там где время реакции
критично. В данном случае -- не критично.

Что касается "высокоуровневого драйвера" -- вы уже определились,
драйвер чего конкретно вы пишете? У меня вот драйвер
самой платы контроллера, например "Немо-IDE". А у вас никто
не знает что это и каковы его функции. Отсюда и остальной бардак.

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

Микрософт предложил свой вариант: генерацию псевдослучайных
UUID'ов. Лично мне не нравится. Но тоже -- решение.

[SMT]

Больше ничего не нужно. И не спорь.

и не пытаюсь. я на автоматах собаку съел. я же писал "чтобы не вносить кучу кода в программу". мысль была такая: в нормальных ос, где есть прерывания, программа написана в вольном стиле. драйвер висит на прерываниях, а программа может опросить состояние, когда захочет. то есть при добавлении нового устройства или смене драйвера программу сильно трогать не надо. а тут придётся разворачивать главный цикл, часть драйвера придётся вносить в программу, возможно, реорганизовывать вызов долго работающих процедур в плоский цикл, это неудобно

вы уже определились, драйвер чего конкретно вы пишете

я предлагал интерфейс к НЖМД с ATA-интерфейсом. а драйвер nemo-ide, то есть в терминологии ms - bus driver - слишком простая абстракция и ещё одним уровнем выше надо будет много кода, каждый раз повторять его не очень хорошо. можно так же сделать интерфейс для atapi, с байт-ориентированными буферами. вроде на IDE кроме ATA и ATAPI ничего не предвидится

>>тут проблемы с централизованной регистрацией интерфейсов
Микрософт предложил свой вариант: генерацию псевдослучайных
UUID'ов

дело не в uuid'ах, а в том, что нет схемы, как по GUID найти код (оси нет, произвольные программы могут использовать озу полностью и вызывать что-то #3d13 нельзя). также нужен стандарт на то, где будет размещён загруженный код и какими сервисами он может пользоваться

[fk0]

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

Не хочешь -- не вноси. Вынеси только тот цикл на уровень выше.
Кому надо тот внесёт. А надо, практически, всем.

мысль была такая: в нормальных ос, где есть прерывания, программа написана в вольном стиле. драйвер висит на прерываниях,

Покажи, где у немы есть прерывания. Нормальные ос -- это
где-то на ПЦ, а у нас тут жуткий спектрум.

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

Какой главный цикл? Речь лишь о том, чтобы не зацикливать
ничего на НЕОПРЕДЕЛЁННОЕ время в драйвере. И вообще на
большое (больше 30000 тактов) -- ибо музыка, таймер, прерывания,
которые могут быть запрещены и т.п.

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

Либо я не понимаю, либо ты. Вот в данном конкретном случае,
чем не устраивает решение, когда драйвер лишь предоставляет
возможность чтения регистра состояния, без цикла. Зацикливай уровнем выше. Хочешь в это время музыку играй, хочешь BREAK
опрашивай, что хочешь, то и делай. Чем плохо, в сравнении с
вариантом, когда сбой накопителя завешивает всё насмерть,
и весь интерфейс перманентно тормозит. Особенно с компакт-дисками.

я предлагал интерфейс к НЖМД с ATA-интерфейсом.

А как быть с CD-Walk?

а драйвер nemo-ide, то есть в терминологии ms - bus driver - слишком простая абстракция и ещё одним уровнем выше надо будет много кода, каждый раз повторять его не очень хорошо.

А как быть в случае, когда контроллеров, вроде NEMO-IDE разных
много, а КОД ДЛЯ ПОДДЕРЖКИ ATA интерфейса -- ОДИНАКОВЫЙ?
С чем боролись на то и напоролись: "каждый раз повторять его не
очень хорошо".

Что-то мешает иметь отдельно:

1) драйвер собственно контроллера (например, Nemo-IDE).

2а) драйвер ATA-2 для НЖМД.

2б) драйвер ATAPI для CD-ROM.

П. 2 надстраивается над п.1 в виде ещё одного загружаемого
драйвера. Только он всегда один и тот же будет. Загружаемый
он лишь только для возможности обновления версий, а то можно
и просто жёстко компоновать с программами.

можно так же сделать интерфейс для atapi, с байт-ориентированными буферами. вроде на IDE кроме ATA и ATAPI ничего не предвидится

Да, но опять "много одинакового кода", который ещё и поддерживать нужно. В том смысле что оное для Nemo-IDE от
ATA его варианте для NEmo-IDE практически никаких различий,
кроме как в интерфейсе и ряде функций, не содержит. Так почему
бы общую часть не вычленить в (см. выше) п.1, а остальное в п.2?

дело не в uuid'ах, а в том, что нет схемы, как по GUID найти код (оси нет,

А как его вообще можно найти на спектруме? Он или лежит на
одном диске с запускаемой программой или не лежит. Надо будет -- пользователь положит. UUID решает проблему идентификации интерфейсов в даннном случае, т.е. для конкретного драйвера можно точно сказать, что он для винчестера, а не для часов, например.

произвольные программы могут использовать озу полностью и вызывать что-то #3d13 нельзя).

3d13 нужно, для тех же скорпионов. У меня битик предусмотрен.
А в целом для драйвера принимается 64-кбайтовое адресное пространство и восстановление конфигурации памяти и иных устройств (в т.ч. прерываний), если драйвер изменяет, то он восстановление на выходе должен брать на себя. С прерываниями
тут сложности конечно могут быть. Но типично прерываний ни
у кого нет, нужно только ПЗУ иногда переключить. На время
переключения просто запрещаются прерывания. ВСЁ.

также нужен стандарт на то, где будет размещён загруженный код и какими сервисами он может пользоваться

Очевидно, что адрес загрузки фиксированным быть не может.
А как иначе в Vega-Commander скопировать всё со скорповского
винта на немовский? Я понимаю, что Vega-Commander сейчас
такой функции не поддерживает, но не в том-то суть. То-есть и
вопрос-то отпадает -- адрес загрузки какой скажут. Сервисов,
по причине их невостребованности, в данном случае нет никаких.
Если мысль дальше развивать, то сервис достаточен единственный:
поиск модуля кода с таким_то_номером_интерфейс� � и его использование через данный интерфейс.

[SMT]

Покажи, где у немы есть прерывания. Нормальные ос -- это где-то на ПЦ, а у нас тут жуткий спектрум

вот. значит, нужно умерить свои аппетиты. если и делать что-то вместе с чтением (музыка/мышь), то только на прерываниях. никаких разворотов в автоматы. а драйвер сам в те моменты, когда надо, запретит прерывания. в циклах ожидания и чтения их не обязательно запрещать. хотя, проблема может быть в том, что драйвер окажется в другой странице и надо будет это учесть (то есть обработчик im2 тоже надо будет затачивать под такой COM)

Какой главный цикл? Речь лишь о том, чтобы не зацикливать ничего на НЕОПРЕДЕЛЁННОЕ время в драйвере

а если протокол обмена такой, что нельзя заранее определить время чтения? тот же ATAPI: после передачи пакета нужно дождаться BSY=0, проверить DRQ, считать byte count и это самое кол-во байт, опять ждать BSY=0, проверять DRQ, читать byte count. так пока DRQ не сбросится после BSY. получается, всю эту логику нужно тащить в каждую программу, чтобы насувать туда опросов мыши и клавиатуры

Чем плохо, в сравнении с вариантом, когда сбой накопителя завешивает всё насмерть, и весь интерфейс перманентно тормозит

от этого никак не застрахуешься - сбой может вызвать приём блока из FF вместо кода программы и тогда тоже смерть

Что-то мешает иметь отдельно:
1) драйвер собственно контроллера (например, Nemo-IDE).
2а) драйвер ATA-2 для НЖМД.
2б) драйвер ATAPI для CD-ROM

если за каждым байтом идти в драйвер ниже, скорость чтения винта будет ниже скорости дисковода. так даже в windows не делают. хотя в комбинированный драйвер (Nemo+ATA+ATAPI) можно добавить отдельные функции для чтения ATA-регистров, чтобы любители опрашивать клаву в цикле чтения смогли это сделать, жертвуя скоростью обмена

как его вообще можно найти на спектруме? Он или лежит на одном диске с запускаемой программой или не лежит

в принципе, поиск не очень важен. за рабочий вариант можно взять загрузку 1го сектора всех файлов на диске, пока не найдётся с нужным guid'ом. ну или не всех, фильтр по расширению поставить

Если мысль дальше развивать, то сервис достаточен единственный: поиск модуля кода с таким_то_номером_интерфейс� � и его использование через данный интерфейс

использование, как я понимаю, это включение страницы, куда загружен код и вызов этого кода?


нерешаемых проблем не видно. только нужно что-то сделать с im2 и добавить сервисы переключения страниц и распределения памяти. жаль, минимального решения не выходит - ещё немного, и получится ось