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

Вид для печати

Показывать 40 сообщений этой темы на одной странице

10.02.2005, 16:35
CHRV

Цитата:

Сообщение от Vega

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

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

ZX+HDD+FAT

Thanks all за сылки!!!
13.02.2005, 00:58
breeze

Цитата:

Сообщение от CityAceE

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

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

Цитата:

Сообщение от breeze

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

10000 файлов в одном каталоге - изврат!
13.02.2005, 03:30
breeze

Цитата:

Сообщение от SMT

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

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

Цитата:

Сообщение от breeze

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

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

дополнения к формату драйвера HDD

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

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

Цитата:

Сообщение от SMT

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

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

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

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

Цитата:

Сообщение от breeze

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

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

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

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

Показывать 40 сообщений этой темы на одной странице