По имени *.trd, да? =)Цитата:
Сообщение от jtn
Шучу, шучу... Хоть фат и крив, однако он - стандарт, уже оторвавшийся от некросовта даже. Недавно вон суд мериканьский постановил, чтто некрофовту низзя патент на фат получить и брать бабло за это =)
Вид для печати
По имени *.trd, да? =)Цитата:
Сообщение от jtn
Шучу, шучу... Хоть фат и крив, однако он - стандарт, уже оторвавшийся от некросовта даже. Недавно вон суд мериканьский постановил, чтто некрофовту низзя патент на фат получить и брать бабло за это =)
Я покупал в Ижевске, в м-не "Радио"; 10р.70к. за 1 дискету. Купил себе только одну коробку из интереса, т.к. у нас в Глазове, те-же Verbatim, но только 3'5" HD стоят порядка 7...9 рублей. Уж лучше их юзать...Цитата:
Сообщение от Максагор
По качеству дискеты действительно классные, отсюда видать и такая цена - типа экслюзив ;) (В Удмуртии, сеть м-нов "Радио", единственные где еще продают 5'25" DD).
Verbatim эти дискеты делает, судя по-всему, для азиатского и южно-американского рынков. Изготавливаются в Мексике (на коробке есть лейбл Made in Mexico, но все остальные копирайты (с) Verbatim Corporation & (R) DuPont).
Из разговора с продавацами выяснил, что поставки этих дискет бывают крайне нерегулярно, и когда будет следующий завоз - неизвестно :(
Какая фирма завозит дискеты в Россию выяснить не удалось, т.к. в магазины они попадают через несколько оптовых посредников...
на самом деле я тоже против всяких новых форматов, но мне кажется болеее простой совсем не помешал бы. вот например буржуи используют образы iso9660 пишут их на CompactFlash и втыкают вместо IDE HDD, поддержка на уровне:Цитата:
Сообщение от lvd
LOAD "blabla" SAVE "12131" никакой фрагментации.
я про то, что нафига спеку лопатить мнгогигабайтный винт, в котором кластер - десятки килобайт, когда можно создать нефрагментированный файл размером с сотню дргую мегабайт, с кластером=256 байт, компактной структурой каталогов и дополнительно тулзу для пц. trd/fdi кстати можно рассмотреть как частные случаи...
А еще FAT -> ZXFAT.Цитата:
когда можно создать нефрагментированный файл
Блин, нафига так извращаться. Таблицу разделов не зря придумали. Создаем ZX-раздел со своим типом, а для него пишем плагины к ОСам и менеджерам файлов (можно даже IFS ;) )
P.S. Банально-идиотская поддержка FAT12/16/32 для спека делается за день-два ;)
P.P.S. Пока и не просите, руки не доходят - диплом+многочегоеще.
Вообще-то на компакт-флэш, воткнутый в ИДЕ никакие образы и уж тем-более iso9660 писать не надо. :) Достаточно просто разбить этот самый флэш на раздел(ы) и форматнуть в любом удобном виде. :p А вообще-то можно посмотреть в сторону minix, ну или еще каких ФС попроще.
Sony MFD2DD - выпускаются и продаются, предназначены для всяких ЧПУ у которых дискеты на 720 используются.Цитата:
Сообщение от lvd
Вот-вот рекомендую не трепать пока не сделаешь! Трепаловых и так достаточно! Точно знаю что и за неделю не сделаешь, особено FAT32 и особено на машинах с 128кб - угадай почему :)Цитата:
Сообщение от Alex/AT
ООООоооооо. А читать фат по одному сектору кто запретил? ;)Цитата:
Трепаловых и так достаточно! Точно знаю что и за неделю не сделаешь, особено FAT32 и особено на машинах с 128кб
Мужики, а почему обязательно FAT ?
Оно конечно просто, но я всеж предпочел бы ext2 или ext3.
Чисто теоретически (из книг по ОС) - системы типа FAT - самые жрущие память, но самые отказоустойчивые.
Однако ext3- память жрет гораздо меньше, хоть и менее отказоустойчивая. Зато с помощью небольшой довески проблемы с отказоустойчивостью устраняются. К тому же ext3 - изначально рассчитана на то, чтобы в именах файлов использовались практически любые символы и длина имен - неограничена (огромный плюс).
Вообще - если системно подойти, то должны быть отдельно драйверы HDD (функции - чтени-запись сектора), а поверх такого драйвера - драйвер любой ФС, какой хочешь.
Плюсы очевидны - разработчикам аппаратуры не надо будет парится с проблемами ФС (чтение и запись сектора - гораздо более простые вещи). В то же время разработчики драйверов ФС не буду заморачиваться с драйверами блочных устройств. А если валить все в одну кучу - то драйвера будут большими и кривыми.
Это все естественно требует некоего стандарта взаимодействия драйверов.
Ты книгу вверх ногами держал. Прочитай еще раз, там все строго наоборот.Цитата:
Сообщение от SfS
Ну да а запись файла займет ...цать минут в лучшем случае. Ну и нафига такой фат.Цитата:
Сообщение от Alex/AT
Дело в том, что не стоит безумно копировать чужие идеи - это ущербный путь "развития"... Наверняка можно придумать чтото более достойное и простое для работы с HDD - заточенное именно для 8битной машины!
Вверх ногами ? Вот цитата:Цитата:
Сообщение от kgbplus
В ext3 же хранится карта свободных блоков, плюс очень правильно организовано кэширование - потому производительность больше.Цитата:
Сообщение от book
Хотя насчет пожирания памяти - все зависит от размера кэша. Тут можно спорить долго и бессмысленно.Цитата:
Сообщение от book
А тут битность машины никакой роли не играет. Подходов к созданию ФС - масса и они все были обкатаны в доль и поперек. Я предлагаю сделать драйвер винта и драйвер ФС - отдельными. Тогда каждый будет юзать ФС по вкусу и спор отпадет сам собой.Цитата:
Сообщение от CHRV
Битность играет роль! НАпример кешировать ФАТ32 (а это нужно для нормальной-быстрой работы) на 8-битке не получится принципиально. А драйвер не винта а устройства хранения, это может быть и не винт, согласен? :wink:Цитата:
Сообщение от SfS
Открою секрет... даже винда никогда не держит весь FAT в памяти.
Что подразумевается под словами весь ФАТ(32)?Цитата:
Сообщение от Alex/AT
Естественно не держит, если например под ФАТ подразмевается весь раздел жесткого диска :)
Извините за сарказм, вы в майкрософт случаем не работаете?
Под FAT подразумевается именно то, что это слово обозначает. File Allocation Table.
подозреваю, что с реализацией фат32 главная проблема былв бы именно та, что все кластеры , в том числе самого фат, имеют размер от 32К (и больше) :) Разве что найдется способ читать кластер частями, - все рано это неудобно реализовывается. (DMA при наличии на машине большой памяти? Не в курсе).
Вот наконец то разумные идеи!Цитата:
Сообщение от Vladimir Kladov
Именно на 128К скорость работы будет просто безумно низкая, тем более если частями читать! Я работал в проекте по поддержке ФАТ32 для одной экзотики поэтому четко представляю проблемы....
Товарищ Алекс обещал сделать на 128 за один день - ну/ну!
Поспорить чтоли, но просто не хочется обижать человека , все так наш - спектрумист :).
Во вторых обьективно ФАТ32, не устану повторять, НАФИГ НЕ НУЖНА на спеке...
И поймите пожалста копировать все с другой платформы - лучше купите себе эту платформу. Спек всегда отличался тем что избегал тяжеловесных и ненужных для него решений. В том то и вся прелесть что придумать можно удачную фат избежав всю это тяжеловесность, поэтому дерзайте и не надо из спека делать жалкую подобию ПЦ.
Рома, почему нельзя на 8битке кэшировать 32битный фат ? Я не понимаю! Какая разница - хранить в участке памяти 8 или 32х битиные числа ? Другое дело, что 32битная арифметика медленне считаться будет - но это уже абсолютно другой вопрос! Поэтому ПРИНЦИПИАЛЬНОЙ невозможности тут нет.Цитата:
Сообщение от CHRV
Абсолютно согласен - именно это я и имел ввиду (просто тут речь о винтах шла - вот "винт" к языку и прицепился). Именно "драйвер устройства хранения".Цитата:
Сообщение от CHRV
То есть проблема не в кэшировании FAT, а в кэшировании кластера ? Но ведь кластер можно сделать и не 32К, а скажем 1К. 32К он только на больших винтах нужен.Цитата:
Сообщение от CHRV
Удачная FAT - это уже не FAT)))Цитата:
Сообщение от CHRV
Я ж предлагал - ext3.(конечно ее можно еще упростить - для спека, скажем полное журналирование-ни к чему). Там размер блока ВСЕГДА 512 байт. Никаких кластеров по 32К. А 512 байтные блоки - вполне по силам кэшировать спеку...
Товарищи... еще ни в одной нормальной системе кеширование на уровне кластеров не выполнялось. Оно всегда выполняется на уровне физических секторов. А кластер, между делом, можно и по частям читать ;) Я вообще предполагал читать FAT посекторно, а не покластерно. И файлы тоже.Цитата:
То есть проблема не в кэшировании FAT, а в кэшировании кластера ? Но ведь кластер можно сделать и не 32К, а скажем 1К. 32К он только на больших винтах нужен.
Да нет, достаточно просто. Сначала рассчитывается кластер, потом стартовый сектор, длина чтения относительно стартового сектора - а дальше как обычно...Цитата:
Разве что найдется способ читать кластер частями, - все рано это неудобно реализовывается.
P.S. Мне как-то доводилось разбирать (реверсить, без никакого описания)... нет, не FAT - Transactional FAT с ARM-платформы. Вот это геморрой, я вам скажу. Реальный. Авторы - сумасшедшие. Хотя реализовано достаточно удобно (если не обращать внимания на непонятный кольцевой ремаппинг секторов и области журналирования). Если хочется - могу дать описание формата, но без тамошних заморочек...
P.P.S. А реализация FAT12/16/32 правда за день делается (если засесть). Если сегодня вечером свободное время будет - попробую накидать хотя бы чтение каталогов.
Реализовать такое можно. Но не шибко это удобно. ИМХО.Цитата:
Сообщение от Alex/AT
Ладно я спорить не буду, предлагаю ради прикола кому нить сделать. А тогда посмотрим :-).Цитата:
Сообщение от SfS
Обещаю что скорость записи файла будет дай бог минут пять-десять. Тем более я не понимаю где в 128к вы собираетесь все это разместить, там программе то лежать негде тогда будет... подумайте об алгоритме поиска свободного кластера :)
Что касается меня - я изначально против FATа. )Цитата:
Сообщение от CHRV
Ну я не против ФАТ если он будет называться ZX-FAT :)Цитата:
Сообщение от SfS
А вот писюканским ФАТам на спеке делать нечего, вместо того чтобы спорить голословно, я предлагал подумать как можно минимизировать и реализовать поддержку больших дисков на ZX... И уместить это в минимальное количество памяти при сохранении большой скорости.
ПРоблема будет не в чтении а в ЗАПИСИ. Я тебе об этом намекал, намекал :)Цитата:
Сообщение от Alex/AT
Имеешь в виду нахождение свободных кластеров? Если поля Current_Free_Sector и Free_Sectors_Number выставлены корректно, то не будет. А иначе - не медленнее, чем в DOS без Smartdrive (ну, медленнее за счет 8-бит платформы, но не намного).Цитата:
ПРоблема будет не в чтении а в ЗАПИСИ. Я тебе об этом намекал, намекал
Рекомендую начать делать, а потом спорить :wink: .Цитата:
Сообщение от Alex/AT
я кстати именно на это и намекал. Если нет отдельной таблички "занятости" (кластеров), то поиск становится очень медленной операцией. Насколько мне известно, ни fat16, ни fat32 такой отдельной таблички не содержат.Цитата:
Сообщение от CHRV
Не поможет даже 1-битная табличка. Могу предложить только вариант с деревом высокого порядка (несбалансированным, балансировка в рамках диска + 8-битной платформы - это убийство), причем дерево лишнего места на диске занимать не будет.Цитата:
Сообщение от Vladimir Kladov
интересно будет посмотретьЦитата:
Сообщение от Alex/AT
Даю чуток обрезанное (дабы не было "левых" декодеров, если кто поймет, откуда это) описание (кое-что там под вопросом, но суть реализации 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
да не надо в точности до отдельных смещений, лучше бы просто русскими словами... из этого не понятно, зачем нужен remap - это против битых секторов? как система обрабатывает фрагменты?Цитата:
Сообщение от Alex/AT
Remap - это "журнал транзакций". В ремап дату записываются сами сектора, которые будут перезаписаны (каталоги, FAT), а затем проставляется отметка транзакции в ремап, которая указывает, какие сектора куда (в ремап дату) переехали.
Фрагменты обрабатываются как в FAT.
Из всего этого очень полезна будет транзакциональность и хеширование имен файлов в каталогах.
Хммм, давно устоялась привычка делать все описания на английском ж)Цитата:
лучше бы просто русскими словами
Правильно!!! =) тем более, что ник твой smart file system на амиге =)Цитата:
Сообщение от SfS
Неа) Ник от SfinxSoftware) Я так на взломанных прогах подписывался )Цитата:
Сообщение от acidrain
А если серьезно - то для дискеток и флешек FAT - самое то. А вот для винта - однозначно лучше чтото ext-подобное.
Всем сюда :) =)
http://sourceforge.net/projects/smartfilesystem/
Может будет интересно ;)
Или сюда: http://www.amiga.org.ru/