Реализация и поддержка FAT16/32 на Спектруме с HDD [Архив] - Speccy

^m00h^

09.02.2005, 06:40

Hi Многоуважаемый All! Недавно заимел IDE-контроллер (Nemo), и у меня возникло огромное желание реализовать поддержку файловых систем FAT16/32 и возможно, NTFS, а также ext2/ext3/reiserfs на Спектруме. Имея справочный материал по командам HDD из газеты Абзац, я получил примерное представление о реализации чтения/записи на винт, но сейчас мне не хватает именно информации о структуре и программировании FAT, серфинг в поисковиках дал только общее представление по сабджу. Может быть кто-то задавался подобным вопросом, и может поделиться своими исследованиями или документациенй ? Буду очень благодарен. В моих планах написание коммандера, работающего со всеми файловыми системами на zx, (tr-dos, is-dos(tr-dos, is-dos, msdos), в том числе и FAT. Согласитесь, было бы очень неплохо использовать весь обьем HDD ( а не 16 mb only как в ISDOS) исключительно для хранения спековского вареза, и любых других файлов неограниченного количества и размера, как это делают эмуляторщики.
С возможностью редактирования и копирования с/на tr-dos, isdos. IMHO, для ZX с HDD нужна не ось, а именно навороченный командер. В данный момент, испытывая дефицит информации, я пробую реализовать подобие FAT12 на винте. Если вам интересен данный subj, его востребованность на ZX, а также если вы желаете принять участие в его разработке, то попрошу развить данную тему в форуме, либо пишите на мэйл andy_petroff(at)mail.ru, с пометкой для Макса. (Я юзаю инет у ^m00h^'a, поэтому логин в форуме и мыло - его).

CityAceE

09.02.2005, 07:06

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

jtn

09.02.2005, 07:09

скачай пцшную прогу WINHEX, в документации к ней есть интересующая тебя инфа, плюс сама прога пригодится для изучения таблиц.
Что касается размеров таблиц, то никто ведь не заставляет целиком держать их в памяти.

Vega

09.02.2005, 16:26

В общем, всем интересующимся данной тематикой советую сходить по этой ссылочке и заиметь себе эту книжку, учитывая её цену. http://www.piter.com/display.phtml?pattern=%EA%F3%EB%E0%EA%EE%E2&searchField=alls&rezim=web_yes&submit=%ED%E0%E9%F2%E8

Кулаков В. Программирование дисковых подсистем.

Здесь можно найти не только описание FAT, но и ISO 9660, и формат хранения данных на DVD, и вообще более подробное и расширенное описание команд винчестера, чем в моей статье в Абзаце.

CHRV

09.02.2005, 16:34

Приветствую Влада ;)

Львиная часть док по CDROM и DVD есть на http://www.ecma-international.org

CHRV

09.02.2005, 16:44

Максагор

09.02.2005, 18:17

SMT

09.02.2005, 19:22

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

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

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

wait:
in a,(рег-р статуса)
ld c,a
and h
cp l
jr nz,wait
in a,(рег-р ошибок)
ld b,a
retрегистр ошибок тоже читаем заодно, чтобы второй раз не обращаться к драйверу. эту же процедуру можно использовать просто для чтения статуса при HL=0

2. запись блока регистров. HL - указатель на 7 байт значений регистров 1-7.
можно и такой формат:
<рег.1><знач.1><рег.2><знач.2>...<00>, но по времени экономия небольшая и больше потратим тактов на заполнение номеров регистров в передаваемом блоке. плюс бонус - при записи в последний (7-й) регистр валидного кода команды начинается выполнение команды.

3. чтение блока регистров. аналогично. читаем блок из 7 регистров в (HL)

4. передача сектора (512 байт) из контроллера в память (HL). считается, что DRQ=1,BUSY=0 (хотя, можно сюда же поставить вызов 1-й процедуры, но лучше вызвать её из программы, так как такие команды, как read multiple не требуют ожидания DRQ) для ATM и доработанного Nemo (защелка на A8) очень короткая программа

ld b,#00
ld c,<порт данных>
inir
inir
ret

5. аналогично передача сектора из памяти в контроллер

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

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

Vega

10.02.2005, 02:03

Максагор

10.02.2005, 05:36

Почитал предложения SMT, и это сподвигло меня на написание полноценного драйвера для работы с винтом, который может претендовать на стандарт. В фактически законченном на 80% виде улетел к CHRV - Роману Чунину. Буду ждать его рецензии.

Теперь за тобой, как за первопроходцем в этой сфере - аналогичный драйвер для работы с CD как с IDE-устройством (плюс можно и как со звуковым)!

CHRV

10.02.2005, 16:35

Почитал предложения SMT, и это сподвигло меня на написание полноценного драйвера для работы с винтом, который может претендовать на стандарт. В фактически законченном на 80% виде улетел к CHRV - Роману Чунину. Буду ждать его рецензии.
ОК уже посмотрел пока невнимательно твой драйвер, претендующий на low level API. Надо еще наладить както быструю связь с АЛКО, и так же метну Максу а через него Юре УКМЗ и Корсунину.
Свое соображения добавляю другим цветом в документ, чего и другим заинтересованным людям советую. Публикации пока не предусматривается - щаз проведем первичные "внутренние разборки". А там видно будет.
Влад спасибо, действительно серьезная и главная нужная работа, а то "разброд и шатания" порядком достали, особенно в реализации например мамеда.

^m00h^

11.02.2005, 09:42

Thanks all за сылки!!!

breeze

13.02.2005, 00:58

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

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

SMT

13.02.2005, 02:00

оно еще и долго филе на диске искать будет, может конечно быстрее чем с ленты :D , но уж точно утухнуть можно когда у тебя будет более 10000 файлов10000 файлов в одном каталоге - изврат!

breeze

13.02.2005, 03:30

10000 файлов в одном каталоге - изврат!

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

SMT

13.02.2005, 07:57

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

кто эт вас так дезинформировал :) а каталог на что?

SMT

13.02.2005, 08:20

неплохо бы для функций чтения/записи сектора передавать номер страницы, куда читать данные (и номер страницы, куда возвращаться). иначе, если ось сидит в странице, придётся дополнительно в нижней памяти размещать переключалку страниц, как резидент в STS, то есть отнимать память у прикладных программ. неплохо бы предусмотреть какой-то код страницы (например, #FF), для которого не происходит переключения (используется текущий банк).

если драйвер зашит в ПЗУ, то всё нормально - он привязан к памяти и модели контроллера машины. а если на диске, придётся собирать один драйвер из двух. можно выкладывать драйвер в исходниках с определенными соглашениями и воспользоваться оптом AlCo в автосборке (окончательный драйвер собирается запуском alasm-a).

breeze

13.02.2005, 23:33

кто эт вас так дезинформировал а каталог на что?

ладно! не буду спорить, вперёд ребята на мины, а я уже наелся, поэтому буду копать в свою сторону, как говориться время покажет... :rolleyes:

кста, не помню тут вот кто-то писал про то что всю таблицу FAT32 в раму грузить якобы не надо, возможно, но вот интересно что будет когда начнется фрагментация ? :(

зы. хотя конечно я может и описючился уже, и на zx всё будет не так и страшно, просто хотелось бы всё делать с запасом... :sleep:

fk0

18.02.2005, 13:30

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

Ну прежде чем строить странные предположения что мешает посмотреть как это сделано
в любом же юниксе? Метод кеширования широко описывается в литературе. И там же пишется почему двоичные деревья неэффективны: да действительно, сложность алгоритма линейного поиска выше, но НА БОЛЬШИХ ЧИСЛАХ. А на малых числах, а реально это могут быть до сотен записей, выигрывает линейный алгоритм ввиду своей простоты. И кроме того ничего, не мешает в памяти строить индексы записей каталога.
Аналогично с поиском свободного места: никто не мешает держать список свободных
блоков в памяти, и пополнять его по мере надобности, а не елозить по всему FAT в поисках каждого кластера, как когда-то сделали в спринтере.

Ещё раз -- что мешает, прежде чем бросаться в бой с ассемблером наперевес, почитать хотя бы, как это делается у других? Информация доступна, и вникать в дебри HPFS
и NTFS (на самом деле это одно и то же, ранние версии между собой просто были совместимы, частично...) не то что не обязательно, вредно.

CityAceE

18.02.2005, 16:16

Ух ты, сам Кирилл Фролов отбросив свои принципы решил навестить нас :) Ну теперь-то уж точно полный комплект :) Или здесь кого-то ещё нет?

elf/2

18.02.2005, 16:52

Или здесь кого-то ещё нет?
мне удалось RomanRom'а затащить, а вот Lazy пока лениться :) хотя может он незримо присутсвует...

CityAceE

18.02.2005, 16:53

Эх, ещё AlCo здесь не хватает :( Но он по каким-то непонятным причинам сидит без Интернета.

elf/2

18.02.2005, 16:59

Эх, ещё AlCo здесь не хватает :( Но он по каким-то непонятным причинам сидит без Интернета.
надо скинуться на инет для AlCo :)

breeze

20.02.2005, 02:31

Ну прежде чем строить странные предположения что мешает посмотреть как это сделано
в любом же юниксе? Метод кеширования широко описывается в литературе.

Вообще-то это и не предположения, а моё IMHO просто не хотелось разводить флейм! однако скажите мне plz! каким боком здесь кеширование ?

И там же пишется почему двоичные деревья неэффективны: да действительно, сложность алгоритма линейного поиска выше, но НА БОЛЬШИХ ЧИСЛАХ. А на малых числах, а реально это могут быть до сотен записей, выигрывает линейный алгоритм ввиду своей простоты.

Блин! ну и сколько у вас файлов на диске будет ? 1 - 100 ? или более ? что-то я не догоню :( на пэцэте файлы большие по объему и то их очень много, на спектруме же размер файла очень мал и соотвентвенно на винчестере такого же объема их будет гораздо больше, так а каких малых числах идет речь ? о дискетах что ли ?

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

памяти много ? :)

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

ну не знаю как сделали в спринтере, не смотрел, но вот со свободным местом это отдельная песня :)

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

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

Информация доступна, и вникать в дебри HPFS и NTFS (на самом деле это одно и то же, ранние версии между собой просто были совместимы, частично...) не то что не обязательно, вредно.

Полный бред! любая информация способствует саморазвитию, а вот вредна ли она тебе ты решаешь сам в процессе постижения!

что же касается NTFS и HPFS это _РАЗНЫЕ_ !!! и очень разные вещи! и я могу поспорить как человек разобравшийся с HPFS и человек который с HPFS на ZX читал филе!

по поводу всего остального, лучше чем переливать из пустого в порожний , пусть каждый попробуеть хоть что-то написать! и не важно что это будет, FAT, HPFS или BPFS :) народ сам разберется что и с чем есть!

fk0

21.02.2005, 17:43

[ В очередной раз убеждаюсь, какой ужас эти форумы -- квотинга не видно,
цветового кодирования буковок -- тоже, текст нужно писать малюсенькими
буковками в малюсеньком окошечке, ни черта не разглядеть. :-( ]

> Вообще-то это и не предположения, а моё IMHO просто не хотелось разводить
> флейм! однако скажите мне plz! каким боком здесь кеширование?

Кеширование позволяет не держать все необходимые данные в памяти, а извлекать
туда наиболее часто запрашиваемые части файлов, управляющие структуры, списки
каталогов и т.п., включая саму таблицу FAT. Поэтому слова, дескать дла поддержки
FAT нужно вагон памяти мне не понятны -- это чушь. Следуя вашей логике на том
же ПЦ с тем же FAT32, в досе, невозможно было бы работать. Он ж в 640КБ не умещается никак, чаще всего. Однако MSDOS умудряется довольствоваться
парой-тройкой килобайт, ну сколько BUFFERS будет стоять.

> Блин! ну и сколько у вас файлов на диске будет ? 1 - 100 ? или более ? что-то я не
> догоню :( на пэцэте файлы большие по объему и то их очень много, на спектруме
> же размер файла очень мал и соотвентвенно на винчестере такого же объема их
> будет гораздо больше, так а каких малых числах идет речь ? о дискетах что ли ?

"Или ты гонишь, или я не догоняю"... (Ц)

Что имеется ввиду? Общее число файлов? Оно не имеет значения. Число файлов
в каталоге? В среднем, *несколько десятков*. Не надо здесь про \Windows\System32
рассказывать... Винду пока на спек не портировали.

Далее, о чём я пишу ниже: ничто не мешает построить индексы каталога в памяти.
Если есть такая потребность.

> памяти много ? :)

Смотря как отмерять.

> ну не знаю как сделали в спринтере, не смотрел, но вот со свободным
> местом это отдельная песня :)

У спектрумистов всегда проблемы со свободным местом на ровном месте.
Начинается это со простого статического распределения памяти. А не с
замороченных алгоритмов балансировки деревьев... Оборотная сторона
HPFS, может больно бить по производительности.

> что же касается NTFS и HPFS это _РАЗНЫЕ_ !!! и очень разные вещи! и я могу
> поспорить как человек разобравшийся с HPFS и человек который с HPFS на
> ZX читал филе!

Спорь, не спорь, а у NT и NTFS ноги растут из OS/2 тех версий, когда там
копирайт микрософта наполовину с ибм-ом стоял.

CHRV

22.02.2005, 00:24

lvd

22.02.2005, 15:04

Господа!
А какого хрена Вам сдались всякие FAT32 и NTFSы.
СПек всегда отличался своими МИНИМАЛИСТКИМИ стандартами, неужели надо обязательно городить поддержку NTFS, вместо того чтобы придумать какую-нить ZX-FAT, и убрать от туда тормоза "взрослых" систем.
ДАвайте накидаем ТЗ каким требованиям должна отвечать FAT для ZX и на этой основе придумать реализацию.
А копирование тупых здоровых систем - это ущербный путь! :wink:

Ну хз... фат16 раскопирована во всех мп3 плеерах, во всех фотиках... почему бы и не на спеке? С разделами по 10 гигов конечно могут быть траблы, но... Вдобавок эту ФС понимает любой комп.

moroz1999

22.02.2005, 18:30

Господа!
А какого хрена Вам сдались всякие FAT32 и NTFSы.
основная причина, по которой у меня нету сейчас реала - отсутствие у меня 5.25 дискет и дисковертов, пользуя которые я мог бы легко запускать софт на реале. здесь фат - самое универсальное решение.

CHRV

22.02.2005, 21:32

основная причина, по которой у меня нету сейчас реала - отсутствие у меня 5.25 дискет и дисковертов, пользуя которые я мог бы легко запускать софт на реале. здесь фат - самое универсальное решение.
ВОт бред, у меня тоже нет!
Я отлично использую обычные ПИСЮКАНСКИЕ трехсполовиной дюймовые дисководы и БЕЗ ВСЯКОЙ ПЕРЕДЕЛКИ.
Открою огромный секрет:
Чтобы дисковод от ПЦ виделся как A переверни на шлейфе провода с 10 по 12 при запаковке в разьем и усе :smile: .
А для работы у обычных дискет достаточно залепить окошечко чтобы они виделись как 720мб. А лучше набрать родных 720мб дискет.
ВОт и все, и юзай реал, а убогие 5.25 дискеты я с 1995 года не использую. У меня два реала и замечательно работают.

lvd

22.02.2005, 22:07

moroz1999

22.02.2005, 22:52

^m00h^

23.02.2005, 00:52

ВОт бред, у меня тоже нет!
Я отлично использую обычные ПИСЮКАНСКИЕ трехсполовиной дюймовые дисководы и БЕЗ ВСЯКОЙ ПЕРЕДЕЛКИ.
Открою огромный секрет:
Чтобы дисковод от ПЦ виделся как A переверни на шлейфе провода с 10 по 12 при запаковке в разьем и усе :smile: .
А для работы у обычных дискет достаточно залепить окошечко чтобы они виделись как 720мб. А лучше набрать родных 720мб дискет.
ВОт и все, и юзай реал, а убогие 5.25 дискеты я с 1995 года не использую. У меня два реала и замечательно работают.

Очень приятно рыться в дискетах если у тебя их несколько сотен!!! а чтобы новый софт записать? покупать новые дискеты?. И старые не потрёшь. На них итак всё необходимое. Другое дело держишь ВЕСЬ спековский софт на винте. Взял что надо, скопировал на дискету и юзай на здоровье. Читать доку, слушать музыку прямо с винта в командоре. А именно FAT, для того чтобы иметь совместимость с другими платформами т.е. взял хард, пошёл к корешу и записал что надо и сколько надо. А не бегать с десятком дискет, потом копировать-распаковывать-конвертировать-сортировать-подписовать. Кстате "убогие 5.25 дискеты" в десять раз живучее чем 3.5дюймовки.

SMT

23.02.2005, 02:20

Кстате "убогие 5.25 дискеты" в десять раз живучее чем 3.5дюймовки.
у меня наоборот - на 3,5 ни одного файла не пропало. а на 5,25... тем более, хорошие новые 5,25 невозможно найти

lvd

23.02.2005, 09:26

у меня наоборот - на 3,5 ни одного файла не пропало. а на 5,25... тем более, хорошие новые 5,25 невозможно найти

Вот именно - хорошие дискеты живучие всегда, но сейчас уже и 3.5' мегаотстойные.

Всё ещё интересуемся у CHRV названием 3.5 рулеза, который сейчас реально найти... =)

CHRV

23.02.2005, 14:43

Вот именно - хорошие дискеты живучие всегда, но сейчас уже и 3.5' мегаотстойные.

Всё ещё интересуемся у CHRV названием 3.5 рулеза, который сейчас реально найти... =)
Дисководы которые я использовал в эксперименте по переворачиванию шлейфа следующих марок (извините модели не могу точно сказать,кроме NECa): Matsushita, Panasonic, Samsung и NEC FD1231H.
Дискеты на 720 доставались следующим образом, пошел на местный ВЦ у нас на работе и попросил полазить по ящикам, нашлось около 20 дискет именно на 720.
HD дискеты использующиеся с таким же успехом называются Imation. Просто других у меня нет дома :smile:
Ходить с винтом - увольте.
МОе мнение на ZX должна быть быстрая и удобная именно для ZX фат, а не писюканские тормоза.

jtn

23.02.2005, 17:38

а мне кажется так. на низком уровне fat32/16, а потом в виде нефрагментированного файла некий образ, внутри которого некий zx-fat

Stingrey

24.02.2005, 00:30

... хорошие новые 5,25 невозможно найти...

Verbatim до сих пор выпускает 5'25" MD 2D (DS/DD) "Data Life Plus" с тефлоновым покрытием (!!!) - вечные, как сковородки от TEFAL :)

Максагор

24.02.2005, 01:19

Verbatim до сих пор выпускает 5'25" MD 2D (DS/DD) "Data Life Plus" с тефлоновым покрытием (!!!) - вечные, как сковородки от TEFAL :)

То есть, даже на HD-диски на 1.2Мб, а саые классические DD на 720Кб??? Wow!!! :eek:
И где их можно приобрести?

kgbplus

24.02.2005, 17:12

То есть, даже на HD-диски на 1.2Мб, а саые классические DD на 720Кб??? Wow!!! :eek:
И где их можно приобрести?
Кстати, судя по данным интернета действительно есть такие.
В трех видах: DataLifePlus, DataLife и DataLife для Mac
Продаются в USA... Стоят у них $4.42 за коробку 10 дискет.

CHRV

24.02.2005, 17:30

Кстати, судя по данным интернета действительно есть такие.
В трех видах: DataLifePlus, DataLife и DataLife для Mac
Продаются в USA... Стоят у них $4.42 за коробку 10 дискет.Мужики, все это конечно прекрасно!
Но уж больно офтопично!
Давайте продолжим быть FAT or not to be....

lvd

24.02.2005, 17:59

а мне кажется так. на низком уровне fat32/16, а потом в виде нефрагментированного файла некий образ, внутри которого некий zx-fat

По имени *.trd, да? =)

Шучу, шучу... Хоть фат и крив, однако он - стандарт, уже оторвавшийся от некросовта даже. Недавно вон суд мериканьский постановил, чтто некрофовту низзя патент на фат получить и брать бабло за это =)

Stingrey

26.02.2005, 00:04

То есть, даже на HD-диски на 1.2Мб, а саые классические DD на 720Кб??? Wow!!! :eek:
И где их можно приобрести?
Я покупал в Ижевске, в м-не "Радио"; 10р.70к. за 1 дискету. Купил себе только одну коробку из интереса, т.к. у нас в Глазове, те-же Verbatim, но только 3'5" HD стоят порядка 7...9 рублей. Уж лучше их юзать...

По качеству дискеты действительно классные, отсюда видать и такая цена - типа экслюзив ;) (В Удмуртии, сеть м-нов "Радио", единственные где еще продают 5'25" DD).

Verbatim эти дискеты делает, судя по-всему, для азиатского и южно-американского рынков. Изготавливаются в Мексике (на коробке есть лейбл Made in Mexico, но все остальные копирайты (с) Verbatim Corporation & (R) DuPont).

Из разговора с продавацами выяснил, что поставки этих дискет бывают крайне нерегулярно, и когда будет следующий завоз - неизвестно :(
Какая фирма завозит дискеты в Россию выяснить не удалось, т.к. в магазины они попадают через несколько оптовых посредников...

jtn

26.02.2005, 00:30

По имени *.trd, да? =)

Шучу, шучу... Хоть фат и крив, однако он - стандарт, уже оторвавшийся от некросовта даже.
на самом деле я тоже против всяких новых форматов, но мне кажется болеее простой совсем не помешал бы. вот например буржуи используют образы iso9660 пишут их на CompactFlash и втыкают вместо IDE HDD, поддержка на уровне:
LOAD "blabla" SAVE "12131" никакой фрагментации.
я про то, что нафига спеку лопатить мнгогигабайтный винт, в котором кластер - десятки килобайт, когда можно создать нефрагментированный файл размером с сотню дргую мегабайт, с кластером=256 байт, компактной структурой каталогов и дополнительно тулзу для пц. trd/fdi кстати можно рассмотреть как частные случаи...

Alex/AT

05.04.2005, 22:55

когда можно создать нефрагментированный файл
А еще FAT -> ZXFAT.

Блин, нафига так извращаться. Таблицу разделов не зря придумали. Создаем ZX-раздел со своим типом, а для него пишем плагины к ОСам и менеджерам файлов (можно даже IFS ;) )

P.S. Банально-идиотская поддержка FAT12/16/32 для спека делается за день-два ;)
P.P.S. Пока и не просите, руки не доходят - диплом+многочегоеще.

Q-Master

06.04.2005, 09:51

Вообще-то на компакт-флэш, воткнутый в ИДЕ никакие образы и уж тем-более iso9660 писать не надо. :) Достаточно просто разбить этот самый флэш на раздел(ы) и форматнуть в любом удобном виде. :p А вообще-то можно посмотреть в сторону minix, ну или еще каких ФС попроще.

CHRV

06.04.2005, 11:26

CHRV, 1000% ты прав! =) Кстати, не подскажешь, где набрать этих самых родных 720kb дискет? %) Последний 720kb рулез, который я помню - некие konica, некоторым уже лет по 6 - полёт идеальный.
Sony MFD2DD - выпускаются и продаются, предназначены для всяких ЧПУ у которых дискеты на 720 используются.

CHRV

06.04.2005, 11:29

P.S. Банально-идиотская поддержка FAT12/16/32 для спека делается за день-два ;)
P.P.S. Пока и не просите, руки не доходят - диплом+многочегоеще.
Вот-вот рекомендую не трепать пока не сделаешь! Трепаловых и так достаточно! Точно знаю что и за неделю не сделаешь, особено FAT32 и особено на машинах с 128кб - угадай почему :)

Alex/AT

06.04.2005, 22:32

Трепаловых и так достаточно! Точно знаю что и за неделю не сделаешь, особено FAT32 и особено на машинах с 128кб
ООООоооооо. А читать фат по одному сектору кто запретил? ;)

SfS

07.04.2005, 05:51

Мужики, а почему обязательно FAT ?
Оно конечно просто, но я всеж предпочел бы ext2 или ext3.

Чисто теоретически (из книг по ОС) - системы типа FAT - самые жрущие память, но самые отказоустойчивые.
Однако ext3- память жрет гораздо меньше, хоть и менее отказоустойчивая. Зато с помощью небольшой довески проблемы с отказоустойчивостью устраняются. К тому же ext3 - изначально рассчитана на то, чтобы в именах файлов использовались практически любые символы и длина имен - неограничена (огромный плюс).

Вообще - если системно подойти, то должны быть отдельно драйверы HDD (функции - чтени-запись сектора), а поверх такого драйвера - драйвер любой ФС, какой хочешь.
Плюсы очевидны - разработчикам аппаратуры не надо будет парится с проблемами ФС (чтение и запись сектора - гораздо более простые вещи). В то же время разработчики драйверов ФС не буду заморачиваться с драйверами блочных устройств. А если валить все в одну кучу - то драйвера будут большими и кривыми.
Это все естественно требует некоего стандарта взаимодействия драйверов.

kgbplus

07.04.2005, 10:25

Чисто теоретически (из книг по ОС) - системы типа FAT - самые жрущие память, но самые отказоустойчивые.
Однако ext3- память жрет гораздо меньше, хоть и менее отказоустойчивая.
Ты книгу вверх ногами держал. Прочитай еще раз, там все строго наоборот.

CHRV

07.04.2005, 10:56

ООООоооооо. А читать фат по одному сектору кто запретил? ;)
Ну да а запись файла займет ...цать минут в лучшем случае. Ну и нафига такой фат.
Дело в том, что не стоит безумно копировать чужие идеи - это ущербный путь "развития"... Наверняка можно придумать чтото более достойное и простое для работы с HDD - заточенное именно для 8битной машины!

SfS

07.04.2005, 11:06

Ты книгу вверх ногами держал. Прочитай еще раз, там все строго наоборот.

Вверх ногами ? Вот цитата:

На таких устройствах DOS использует FAT с 16-битовыми элементами. На совсем уж больших (более 32 мегабайт) дисках DOS выделяет пространство не блоками, а кластерами из нескольких блоков. Эта файловая система так и называется - FAT.
Такая файловая система очень проста и имеет одно серьезное достоинство: врожденную устойчивость к сбоям (fault tolerance), но об этом ниже.
...
Но здесь мы сталкиваемся со специфической проблемой: чем больше диск, тем больше у него FAT, соответственно, тем больше нужно памяти: у тома Novell Netware 3.12размером 1.115 Гбайт с размером кластера 4 кбайта размер FAT достигает мегабайта.

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

Экстенты открытых файлов и карта свободных блоков во время работы размещаются в ОЗУ, поэтому производительность такой ФС в большинстве ситуаций намного (в 1.5 - 2 раза и более) выше, чем у FAT без кэша, при вполне приемлемых требованиях к памяти и размере кластера 512 байт.
...
Но за эти преимущества приходится платить неустойчивостью к сбоям

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

SfS

07.04.2005, 11:10

Ну да а запись файла займет ...цать минут в лучшем случае. Ну и нафига такой фат.
Дело в том, что не стоит безумно копировать чужие идеи - это ущербный путь "развития"... Наверняка можно придумать чтото более достойное и простое для работы с HDD - заточенное именно для 8битной машины!

А тут битность машины никакой роли не играет. Подходов к созданию ФС - масса и они все были обкатаны в доль и поперек. Я предлагаю сделать драйвер винта и драйвер ФС - отдельными. Тогда каждый будет юзать ФС по вкусу и спор отпадет сам собой.

CHRV

07.04.2005, 11:49

А тут битность машины никакой роли не играет. Подходов к созданию ФС - масса и они все были обкатаны в доль и поперек. Я предлагаю сделать драйвер винта и драйвер ФС - отдельными. Тогда каждый будет юзать ФС по вкусу и спор отпадет сам собой.
Битность играет роль! НАпример кешировать ФАТ32 (а это нужно для нормальной-быстрой работы) на 8-битке не получится принципиально. А драйвер не винта а устройства хранения, это может быть и не винт, согласен? :wink:

Alex/AT

07.04.2005, 15:11

Открою секрет... даже винда никогда не держит весь FAT в памяти.

CHRV

07.04.2005, 16:26

Открою секрет... даже винда никогда не держит весь FAT в памяти.
Что подразумевается под словами весь ФАТ(32)?
Естественно не держит, если например под ФАТ подразмевается весь раздел жесткого диска :)
Извините за сарказм, вы в майкрософт случаем не работаете?

Alex/AT

07.04.2005, 21:36

Под FAT подразумевается именно то, что это слово обозначает. File Allocation Table.

Vladimir Kladov

07.04.2005, 22:31

CHRV

07.04.2005, 23:32

подозреваю, что с реализацией фат32 главная проблема былв бы именно та, что все кластеры , в том числе самого фат, имеют размер от 32К (и больше) :) Разве что найдется способ читать кластер частями, - все рано это неудобно реализовывается. (DMA при наличии на машине большой памяти? Не в курсе).
Вот наконец то разумные идеи!
Именно на 128К скорость работы будет просто безумно низкая, тем более если частями читать! Я работал в проекте по поддержке ФАТ32 для одной экзотики поэтому четко представляю проблемы....
Товарищ Алекс обещал сделать на 128 за один день - ну/ну!
Поспорить чтоли, но просто не хочется обижать человека , все так наш - спектрумист :).
Во вторых обьективно ФАТ32, не устану повторять, НАФИГ НЕ НУЖНА на спеке...
И поймите пожалста копировать все с другой платформы - лучше купите себе эту платформу. Спек всегда отличался тем что избегал тяжеловесных и ненужных для него решений. В том то и вся прелесть что придумать можно удачную фат избежав всю это тяжеловесность, поэтому дерзайте и не надо из спека делать жалкую подобию ПЦ.

SfS

08.04.2005, 07:23

Битность играет роль! НАпример кешировать ФАТ32 (а это нужно для нормальной-быстрой работы) на 8-битке не получится принципиально.

Рома, почему нельзя на 8битке кэшировать 32битный фат ? Я не понимаю! Какая разница - хранить в участке памяти 8 или 32х битиные числа ? Другое дело, что 32битная арифметика медленне считаться будет - но это уже абсолютно другой вопрос! Поэтому ПРИНЦИПИАЛЬНОЙ невозможности тут нет.

А драйвер не винта а устройства хранения, это может быть и не винт, согласен? :wink:

Абсолютно согласен - именно это я и имел ввиду (просто тут речь о винтах шла - вот "винт" к языку и прицепился). Именно "драйвер устройства хранения".

SfS

08.04.2005, 07:46

Вот наконец то разумные идеи!

То есть проблема не в кэшировании FAT, а в кэшировании кластера ? Но ведь кластер можно сделать и не 32К, а скажем 1К. 32К он только на больших винтах нужен.

В том то и вся прелесть что придумать можно удачную фат избежав всю это тяжеловесность, поэтому дерзайте и не надо из спека делать жалкую подобию ПЦ.

Удачная FAT - это уже не FAT)))
Я ж предлагал - ext3.(конечно ее можно еще упростить - для спека, скажем полное журналирование-ни к чему). Там размер блока ВСЕГДА 512 байт. Никаких кластеров по 32К. А 512 байтные блоки - вполне по силам кэшировать спеку...

Alex/AT

08.04.2005, 09:27

То есть проблема не в кэшировании FAT, а в кэшировании кластера ? Но ведь кластер можно сделать и не 32К, а скажем 1К. 32К он только на больших винтах нужен.
Товарищи... еще ни в одной нормальной системе кеширование на уровне кластеров не выполнялось. Оно всегда выполняется на уровне физических секторов. А кластер, между делом, можно и по частям читать ;) Я вообще предполагал читать FAT посекторно, а не покластерно. И файлы тоже.

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

P.S. Мне как-то доводилось разбирать (реверсить, без никакого описания)... нет, не FAT - Transactional FAT с ARM-платформы. Вот это геморрой, я вам скажу. Реальный. Авторы - сумасшедшие. Хотя реализовано достаточно удобно (если не обращать внимания на непонятный кольцевой ремаппинг секторов и области журналирования). Если хочется - могу дать описание формата, но без тамошних заморочек...

P.P.S. А реализация FAT12/16/32 правда за день делается (если засесть). Если сегодня вечером свободное время будет - попробую накидать хотя бы чтение каталогов.

SfS

08.04.2005, 09:30

Товарищи... еще ни в одной нормальной системе кеширование на уровне кластеров не выполнялось. Оно всегда выполняется на уровне физических секторов. А кластер, между делом, можно и по частям читать ;) Я вообще предполагал читать FAT посекторно, а не покластерно. И файлы тоже.

Реализовать такое можно. Но не шибко это удобно. ИМХО.

CHRV

08.04.2005, 09:38

Рома, почему нельзя на 8битке кэшировать 32битный фат ? Я не понимаю! Какая разница - хранить в участке памяти 8 или 32х битиные числа ? Другое дело, что 32битная арифметика медленне считаться будет - но это уже абсолютно другой вопрос! Поэтому ПРИНЦИПИАЛЬНОЙ невозможности тут нет.
Ладно я спорить не буду, предлагаю ради прикола кому нить сделать. А тогда посмотрим :-).
Обещаю что скорость записи файла будет дай бог минут пять-десять. Тем более я не понимаю где в 128к вы собираетесь все это разместить, там программе то лежать негде тогда будет... подумайте об алгоритме поиска свободного кластера :)

SfS

08.04.2005, 10:35

Ладно я спорить не буду, предлагаю ради прикола кому нить сделать. А тогда посмотрим :-).
Обещаю что скорость записи файла будет дай бог минут пять-десять. Тем более я не понимаю где в 128к вы собираетесь все это разместить, там программе то лежать негде тогда будет... подумайте об алгоритме поиска свободного кластера :)

Что касается меня - я изначально против FATа. )

CHRV

08.04.2005, 10:45

Что касается меня - я изначально против FATа. )
Ну я не против ФАТ если он будет называться ZX-FAT :)
А вот писюканским ФАТам на спеке делать нечего, вместо того чтобы спорить голословно, я предлагал подумать как можно минимизировать и реализовать поддержку больших дисков на ZX... И уместить это в минимальное количество памяти при сохранении большой скорости.

CHRV

08.04.2005, 10:47

P.P.S. А реализация FAT12/16/32 правда за день делается (если засесть). Если сегодня вечером свободное время будет - попробую накидать хотя бы чтение каталогов.
ПРоблема будет не в чтении а в ЗАПИСИ. Я тебе об этом намекал, намекал :)

Alex/AT

08.04.2005, 12:51

ПРоблема будет не в чтении а в ЗАПИСИ. Я тебе об этом намекал, намекал
Имеешь в виду нахождение свободных кластеров? Если поля Current_Free_Sector и Free_Sectors_Number выставлены корректно, то не будет. А иначе - не медленнее, чем в DOS без Smartdrive (ну, медленнее за счет 8-бит платформы, но не намного).

CHRV

08.04.2005, 13:12

Имеешь в виду нахождение свободных кластеров? Если поля Current_Free_Sector и Free_Sectors_Number выставлены корректно, то не будет. А иначе - не медленнее, чем в DOS без Smartdrive (ну, медленнее за счет 8-бит платформы, но не намного).
Рекомендую начать делать, а потом спорить :wink: .

Vladimir Kladov

08.04.2005, 14:30

подумайте об алгоритме поиска свободного кластера
я кстати именно на это и намекал. Если нет отдельной таблички "занятости" (кластеров), то поиск становится очень медленной операцией. Насколько мне известно, ни fat16, ни fat32 такой отдельной таблички не содержат.

Alex/AT

08.04.2005, 16:54

я кстати именно на это и намекал. Если нет отдельной таблички "занятости" (кластеров), то поиск становится очень медленной операцией. Насколько мне известно, ни fat16, ни fat32 такой отдельной таблички не содержат.
Не поможет даже 1-битная табличка. Могу предложить только вариант с деревом высокого порядка (несбалансированным, балансировка в рамках диска + 8-битной платформы - это убийство), причем дерево лишнего места на диске занимать не будет.

SMT

08.04.2005, 20:19

Transactional FAT с ARM-платформы... Если хочется - могу дать описание формата, но без тамошних заморочекинтересно будет посмотреть

Alex/AT

08.04.2005, 23:18

интересно будет посмотреть

Даю чуток обрезанное (дабы не было "левых" декодеров, если кто поймет, откуда это) описание (кое-что там под вопросом, но суть реализации FS будет ясна).

Sector 0 is superblock (block 0, block 1 is copy):

0000 0004 ID1 [3FFFFFFF]
0004 0001 ID2 (???) [20]
0005 0002 Version (???) ([0102] for 1.02)
0007 0001 Superblock length - 1 (???)
0008 0004 Block size (bytes) [00004000]
000C 0002 System area start (???) [03EC]
000E 0002 System area length (???) [0020]
0010 0004 File area length in sectors [000074A0]
0014 0002 Superblock block [0000]
0016 0002 Superblock copy block [0001]
0018 0002 Remap area block [0002]
001A 0002 Remap area length [0005]
001C 0002 File data area start block [0007]
001E 0002 File data area length [03A5]
0020 0002 Remap data area start block [03AC]
0022 0002 Remap data area length [0040]
0024 0002 System area start (???) [03EC]
0026 0002 Filler (???) [0000]

Remap area:

Basically filled with FFs. Non-FF parts begin with [3FFFFFFF] ID and
structured as follows:

0000 0004 ID [3FFFFFFF]
0050 xxxx Remap table (2 byte logical block numbers for corresponding
remap area block, FFFF = not used)

Data blocks 1-2: FAT16 (each sector begins with [0000] [FFFF] where [0000] is corresponding FAT part number, there are 4 FATs, FE blocks each, totalling 3F8 blocks max, [0000] in FAT means stop, [FFFF] means unused).

Data block 3: root directory

Directory structure:

0000 0080 Filename hashes (sums)
0080 xxxx Entries

Directory entry:

0000 0001 Type (2 - directory, 1 - file)
0001 0001 Filename hash
0002 0002 [FFFF]
0004 0004 Block pointer
0008 0004 Some kind of attributes
000C 0004 [00000000]
0010 0004 For '.' record - length (in records) + 1,
[00000000] for other directories,
length in bytes for files
0014 006C Filename (ASCIIZ)

Vladimir Kladov

09.04.2005, 13:18

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

SMT

09.04.2005, 19:01

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

Alex/AT

09.04.2005, 19:25

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

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

Alex/AT

09.04.2005, 19:26

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

acidrain

15.04.2005, 00:08

Что касается меня - я изначально против FATа. )

Правильно!!! =) тем более, что ник твой smart file system на амиге =)

SfS

15.04.2005, 10:20

Правильно!!! =) тем более, что ник твой smart file system на амиге =)

Неа) Ник от SfinxSoftware) Я так на взломанных прогах подписывался )

А если серьезно - то для дискеток и флешек FAT - самое то. А вот для винта - однозначно лучше чтото ext-подобное.

acidrain

05.05.2005, 11:24

Всем сюда :) =)

http://sourceforge.net/projects/smartfilesystem/
Может будет интересно ;)
Или сюда: http://www.amiga.org.ru/

Corpsegrinder

06.05.2005, 08:41

В общем проблемы не вижу: Для постоянного использования на zx нужна своя простая файловая система - это ясно, как божий день, однако тема затевалась, с той целью, что человек не хотел придумывать ничего нового, а хотел написать командер, который бы работал с винтом/CD/fdd.

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

Так что спор - бесполезный - и то и другое нужно.

random

06.05.2005, 09:49

Всем сюда =)

http://sourceforge.net/projects/smartfilesystem/
Может будет интересно

совершенно дохлый проэкт, нафига туда ходить? только ради CVS сорцов сомнительной полезности на спектруме?

acidrain

06.05.2005, 22:27

совершенно дохлый проэкт

почему этот проект дохлый? суперская файловая система, которой многие пользуются на амиге. Еще есть pfs. А проект только стал gpl и opensource, посему не вижу повода утверждать обратное. Надо разобраться в вопросе, а потом утверждать что либо, не так ли?

Alex/AT

07.05.2005, 07:57

Честно говоря, разбираться в чужом исходном коде для анализа и возможного переноса C -> ASM - глючно. Вот если бы там описание было, можно бы было подумать.

Alex/AT

07.05.2005, 07:59

Да... еще некоторые размышления на тему... Если делать FDD-файловую систему, то надо делать ее по возможности совместимой с TR-DOS. Т.е., допустим, объявляем, какие нефрагментированные файлы мы хотим разместить в заголовке TRDOS, и система делает это (при возможности).

Для HDD, естессно, такое не нужно.

P.S. Я могу "накидать" приблизительное (но детальное) описание FS для дальнейшего обсуждения и возможной реализации. Давайте по пунктам переберем для начала, чего мы хотим от новой FS. Мое мнение:

1) Носители любого размера (от 600 кб до 120 Гб).
2) Небольшой размер реализации и требуемой памяти.
3) Транзакциональность. Чтобы не было глюков при сбоях диска на запись и пропаданиях питания.
4) Отсутствие FAT в каких бы то ни было проявлениях. Дабы не было единой точки сбоя.

ukms[z]

12.05.2005, 23:47

немного не по теме.
Alex/AT, флешер для самсунгов - твоих рук дело ?

Alex/AT

14.05.2005, 11:04

немного не по теме.
Alex/AT, флешер для самсунгов - твоих рук дело ?
Ага ;)

Знахарь

14.05.2005, 12:10

После прочитанного я тоже усомнился в необходимости полноценной работы с FAT16/32. Может просто чтение реализовать? Причем необязательно из 20й по вложенности папки. А из, скажем, второй. Мне всегда хватало записать на дискету в корень, прочитать и всё. Поддерживаю идею с самомстоятельной ZX файловой системой. Как и с осью выходит попыткапостроить небоскреб на фундаменте... эээ... сарая :) Зачем ? Может каждому свое ? Разумеется, если кто-то напишет фат драйвер компактный, маленький и тп. - то можно и фат. Но переговоры говорят об обратном. Так я понял ?

Paul_ls

14.05.2005, 12:23

Поддержать FAT16/32 проблем нет, хоть до 20-й вложенности, хоть на 5000 файлов, весь вопрос в другом. Это будет работать _очень_ медленно, всвязи с огромным (по меркам спека) количеством обрабатываемых данных. Размер памяти значения особого не имеет, потому что ее всё равно не хватит, особенно на FAT32.

Знахарь

14.05.2005, 15:50

Про это речь и идет. Оно написать можно и кваку 3ю. Да только сколько будет ФПСов ? Именнно в этом и дело.

А кто там писал, что накидал чтение фата32 ? Расскажите народу, что в итоге вышло. Интересно ведь.

jtn

14.05.2005, 16:35

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

fk0

23.08.2005, 17:12

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

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

fk0

23.08.2005, 17:38

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

23.08.2005, 17:40

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

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

fk0

23.08.2005, 17:45

fk0

23.08.2005, 17:49

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

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

fk0

23.08.2005, 17:51

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

ЗАЧЕМ?

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

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

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

fk0

23.08.2005, 18:11

видел предложения сделать чтение/запись сектора. но есть же ещё
несколько десятков 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

24.08.2005, 10:05

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

вот тут абсолютно согласен. тот же 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

24.08.2005, 20:29

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

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

fk0

25.08.2005, 16:36

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

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

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

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

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

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

SMT

25.08.2005, 17:34

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

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

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

fk0

26.08.2005, 13:47

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

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

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

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

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

Какой главный цикл? Речь лишь о том, чтобы не зацикливать
ничего на НЕОПРЕДЕЛЁННОЕ время в драйвере. И вообще на
большое (больше 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

26.08.2005, 16:09

Покажи, где у немы есть прерывания. Нормальные ос -- это где-то на ПЦ, а у нас тут жуткий спектрумвот. значит, нужно умерить свои аппетиты. если и делать что-то вместе с чтением (музыка/мышь), то только на прерываниях. никаких разворотов в автоматы. а драйвер сам в те моменты, когда надо, запретит прерывания. в циклах ожидания и чтения их не обязательно запрещать. хотя, проблема может быть в том, что драйвер окажется в другой странице и надо будет это учесть (то есть обработчик 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 и добавить сервисы переключения страниц и распределения памяти. жаль, минимального решения не выходит - ещё немного, и получится ось ;)

fk0

05.09.2005, 18:46

вот. значит, нужно умерить свои аппетиты. если и делать что-то вместе с чтением (музыка/мышь), то только на прерываниях.

Оставь это на усмотрение авторов программ. Вот лично я хочу
всё разворачивать в автоматы. А ты меня стало быть ограничиваешь
своим недофункциональным драйвером.

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

Опять двадцатьпять, пошли по кругу -- ЗАЧЕМ ЦИКЛ?
Нет цикла, нет проблем. Кому очень позарез как надо мёртвый,
потенциально опасный (зависнуть может) цикл -- пусть сам себе
его напишет. Мне цикл не нужен.

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

Мне уже кажется, с автоматами было проще...

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

С тем, что вся эта логика в том или ином месте должна наличествовать, надеюсь, спорить никто не будет. Так?
Я повторяю ещё раз:

А ЧТО МЕШАЕТ ИМЕТЬ *ДВА* РАЗДЕЛЬНЫХ ДРАЙВЕРА.

зачем, спрашивается, всё пытаться втиснуть в "bus driver"?
Вот логика будет размещаться, тем более, что для ATA/ATAPI
она разная, во втором драйвере. ЛОГИКА ТАМ БУДЕТ РАЗМЕЩАТЬСЯ,
я ничего не говорю при циклы. Цикл может опять же организован
быть по-разному. Кому надо тот зациклит двума командами.
Кому надо будет иметь отношения с автоматами. Для лентяев
можно написать библиотеку-обёртку /АППАРАТНО НЕЗАВИСИМУЮ/,
которая "обернёт" все функции в их зацикленные версии.
Это чем-то плохо?

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

Я уже писал: за каждым блоком.

комбинированный драйвер (Nemo+ATA+ATAPI) можно добавить

Это вообще не имеет смысла, по очевидным причинам.
Достаточно опубликовать номера портов. Но как прав был
Немо... :-(

отдельные функции для чтения ATA-регистров, чтобы любители опрашивать клаву в цикле чтения смогли это сделать, жертвуя скоростью обменав принципе,

НЕТ. Абсолютный. Там жертв скорости никаких практически
нет. Блоки передаются целиком. Суть только в избегании
блокировки при отсутствии/неисправности/неготовности
накопителя. В момент передачи блока никаких тормозов нет,
в данном случае цикл именно в дравере, НО ОН НЕ ВЫЗЫВАЕТ
БЛОКИРОВОК НА НЕОПРЕДЕЛЁННЫЙ ПЕРИОД ВРЕМЕНИ, он
всегда исполняется за конечное и предсказуемое время.

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

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

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

Я про страницы не думал вообще -- это проблема уровня приложения. Если загрузит в страницу -- пусть её переключает.
Требуется чтение-запись из страницы -- изволь загружать
драйвер в основную память и сам переключай страницы.

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

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

:-(

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

Нет, ты лучше скажи, предложенный вариант (с сайта cdwalk) --
он чем плох? Именно по функциям. По-моему -- оптимален.
Хотелось бы иметь аналогичный вариант уровня ATA и ATAPI,
а также более общий к ним драйвер "блочного устройства".

breeze

18.02.2006, 02:30

Ну как я понял, пролистав 11 страниц :eek: что воз и ныне там... :mad:

А так хотелось праздника :confused:

Господа, дыкть может придём к решению какому-нибудь ? или zx.pk.ru место где только хорошо языками чесать ? :mad:

James DiGreze

18.02.2006, 06:37

Воз пока на месте. Работа над поддержкой FAT16 ведется, но, в данный момент, по остаточному принципу. Если с чтением файлов все более или менее понятно, то запись файлов - задачка довольно нетривиальная...
Есть задумка сделать нечто, похожее на CD-WALK, но обнадеживать пока не буду, ибо со свободным временем напряг...

breeze

18.02.2006, 16:02

Если с чтением файлов все более или менее понятно, то запись файлов - задачка довольно нетривиальная...

жаль конечно :o а что-нибудь более менее рабочее или хоть наработки какие-нибудь есть ? :rolleyes:

James DiGreze

18.02.2006, 20:36

К превеликому сожалению, пока ничего, что можно показать, нет.

Speccyfan

29.03.2006, 17:44

Эх. году этак в 2000-м я пробывал работать с IDE устройствами (сейчас даже схему не помню, там набор портов, просто АП6-х кажысь) написал audio player CD и читал/писал по секторам на винт. А вот fat16 так и не раскрутил, заткнулся на умножении/делении 4-х байтных чисел, не помню для чего но надо это. Жалкто что дискеты в свое время не все конвертнул, исходники наверное в большинстве своем пропали :(

James DiGreze

29.03.2006, 17:49

Деления там почти нет, а умножения идут "статические" на константы 0x20, 0x200... Зато сложений выше крыши.
С записью, кажется, разобрался. Нужно более детальное тестирование.
Пока что есть разрозненные процедуры, которые еще предстоит собрать "в кучу" ;)

alone

17.06.2006, 23:49

breeze

18.06.2006, 02:06

Юзай DNA OS, там поддержаны системы TR-DOS, FAT12, FAT16 и CDFS. Исходники свободные.

спасибо :) но суть не в этом :D кстати какая последняя версия и где взять ?

OlegarX

05.04.2007, 23:48

Дело в том, что не стоит безумно копировать чужие идеи - это ущербный путь "развития"... Наверняка можно придумать чтото более достойное и простое для работы с HDD - заточенное именно для 8битной машины!
эт точно, не помню где, но видел схему подключения IDE винта по 8ми битному интерфейсу, там даже адаптированный BASIC был, как найду, покажу...

budder

08.04.2007, 14:04

Ладно я спорить не буду, предлагаю ради прикола кому нить сделать. А тогда посмотрим :-).
Обещаю что скорость записи файла будет дай бог минут пять-десять. Тем более я не понимаю где в 128к вы собираетесь все это разместить, там программе то лежать негде тогда будет... подумайте об алгоритме поиска свободного кластера :)

Запись файла в FAT32 на Спеке секундное дело! ;) Дискета менее чем за минуту на HDD загоняется.

OlegarX

09.04.2007, 12:47

видел схему подключения IDE винта по 8ми битному интерфейсу
http://members.tripod.com/~piters/simpif.htm

Error404

09.04.2007, 17:46

http://members.tripod.com/~piters/simpif.htm

8-битный интерфейс не катит. Зачем оно, если по нему даже identify диска не прочитаешь?
Тем более, что 16-битный уже давно реализован в куче несложных контроллеров разных видов.

А что касается FAT12/16/32, то это реализовано в openSource - например, тут:
http://elm-chan.org/fsw/ff/00index_e.html

берешь, компилируешь - и всё. У меня на Орионе работает. Не вижу причин, чтобы оно не заработало и на ZX.

alone

10.04.2007, 14:12

Цитата:
Сообщение от alone
Юзай DNA OS, там поддержаны системы TR-DOS, FAT12, FAT16 и CDFS. Исходники свободные.
спасибо но суть не в этом кстати какая последняя версия и где взять ?
dnaos.nm.ru
Автор сейчас в процессе добавления FAT32.

Error404

23.04.2007, 18:30

А вот кстати. Кто-нибудь реализовывал FatFS ( http://elm-chan.org/fsw/ff/00index_e.html ) на ZX или чем-то еще 8-битном? Интересует вот что: если реализовывал, то наверное и какие-нибудь утилиты писали для работы с ней? А поскольку сама библиотека FatFS у меня запущена и отлажена, то если кто-то заОпенСоурсит утилиты для нее, то я легко их портирую к себе. ;) А то лениво как-то то все писать с нуля. Сам я пока осилил только примитивный консольный утилит типа dir/copy/del/ren/mkdir.

Zet9

14.09.2007, 12:51

Цитата:
Сообщение от Error404 Посмотреть сообщение

Цитата:
Сообщение от alone
Юзай DNA OS, там поддержаны системы TR-DOS, FAT12, FAT16 и CDFS. Исходники свободные.
спасибо но суть не в этом кстати какая последняя версия и где взять ?
dnaos.nm.ru
Автор сейчас в процессе добавления FAT32.

Уже есть некоторые результаты :v2_smile:

transman

06.01.2008, 18:49

А поддержка UDF будет?

Zet9

06.01.2008, 22:12

А поддержка UDF будет?

UDF совместима с iso9660 снизу вверх, т.е. драйвер iso9660 читает DVD-диски с файловой системой UDF. Соответственно DVD-диски, которые записаны в программе NERO с типом UDF/ISO9660 (без расширения Juliet) в системе DNA читаются на ура.

transman

10.01.2008, 15:45

Меня больше интересуют -rw диски, форматированыые в udf (типа большая дискета)

Zet9

27.01.2008, 11:02

Меня больше интересуют -rw диски, форматированыые в udf (типа большая дискета)

Имеется ввиду DVD-RW диски?
Как их создавать/форматировать?

Если в программе NERO просто записать файлы на DVD-RW,
то система DNA их читает - попробовал на двух двд-рвишках

backa

19.11.2010, 01:07

идея умерла - судя по тишине в ветке
жаль что смогли портировать чановскую библиотеку FATFS под ZX - а ведь в АВР всего 1Кбайт памяти и всё работает ...

Zet9

20.11.2010, 17:43

идея умерла - судя по тишине в ветке
Не умерла,а дошла до своего логического завершения, после того,как участники,активно доказывающие НЕВОЗМОЖНОСТЬ сабжа, с удивлением узнали, что сабж не только возможен,а УЖЕ РЕАЛИЗОВАН, и успешно используется в системе DNA начиная с далекого 2003 года - сначала чтение и запись существующих файлов с/на FAT16,с 2004 года - создание и удаление файлов,с 2005 года создание и удаления подкаталогов,с осени 2007 - создание/удаление/чтение/запись файлов и подкаталогов на разделах с FAT32.
И еще в программе WDC начиная с конца 2006 года появилась возможность чтения файлов и подкаталогов с FAT32,а с 2007 года ещё и создание и запись на FAT32 (удаления не появилось).
В 2008 году появилась программа FATall с похожими функциями, только ориентированная на работу с SD-картами, в прошедшем году в ней появилась поддержка IDE-винчестеров.

Так что все ОК - обсуждения перенеслись в соседние ветки:
http://zx.pk.ru/showthread.php?t=1519&page=20
http://zx.pk.ru/showthread.php?t=11349
http://zx.pk.ru/showthread.php?t=4777
http://zx.pk.ru/showthread.php?t=7238

жаль что смогли портировать чановскую библиотеку FATFS под ZX
на Орион портировали - но медленно работает(там проц тоже Z80)

а ведь в АВР всего 1Кбайт памяти и всё работает ...
ну например,в системе DNA код объединенного драйвера FAT16/32 со всеми функциями примерно 4,5 Кб занимает, работает быстро - примерно 160 Килобайт в секунду чтение с винчестера и 110 Кб/с запись на винчестер

Error404

23.11.2010, 12:16

идея умерла - судя по тишине в ветке
жаль что смогли портировать чановскую библиотеку FATFS под ZX - а ведь в АВР всего 1Кбайт памяти и всё работает ...

на Орион портировали - но медленно работает(там проц тоже Z80)

Слежу за развитием FatFS, очень симпатичный проект.

В АРВ сильно лучше компиляторы, на знаю за счет чего - возможно, типы более емкие нативно поддерживаются, или регистров больше, или способы адресации. Х.З. Тем не менее, 1к недостижимо и там. Вот тут есть данные по размеру кода FatFS на разных платформах :
http://elm-chan.org/fsw/ff/en/appnote.html

У меня для Z80 используется версия 6 FatFS (последняя до внедрения LFN, т.к. не вижу никакого смысла в LFN применительно к обмену с CP/M, где имена как раз 8.3). При этом размер кода библиотеки (в варианте функционала близкого к максимальному) 29кб (компилятор - HiTech C 3.9, версия для CP/M 198x года). На AVR тоже самое занимает 12,5 кб.

Итого минимальная утилита будет порядка 30к. В-принципе, приемлимо, но для ассемблерного кода конечно не конкурент - как по размеру, так и по быстродействию (хотя скорость работы на чтение меня вполне устраивает, вот запись файла подтормаживает на ковыряниях в FAT-е). Зато на портирование собственно библиотеки Чена у меня ушло порядка двух недель (да и те в-основном на "освоение" компилятора - он небезглючен, как оказалось). Скорость портирования - основное из-за чего и был выбран вариант реализации FAT на С.

Кому интересно, вариант FatFS адаптированной для z80 (HiTech C 3.9) я выкладывал тут в составе некой утилиты:
http://zx.pk.ru/showpost.php?p=322368&postcount=52

Все что относится к FatFS компилируется (командником чегототам.sub) в библиотеку libff.lib.