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

[CHRV]

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

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

[^m00h^]

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

[breeze]

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

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

[SMT]

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

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

[breeze]

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

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

[SMT]

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

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

[Advertiser]

[SMT]

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

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

[breeze]

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

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

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

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

[fk0]

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

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

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

[CityAceE]

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