Разбираюсь сейчас с рамдиском. Очень много непонятного прежде всего в исходниках,
что ставит меня в тупик. Итак:
По идее, рамдиск должен полностью повторять флопик по размеру, файловой структуре
и т.д. Исключение - FAT рамдиска, который вынесен и переконвертирован, но о нем
отдельный разговор.
Емкость флопика - 1457664 байта или 2847 кластера по 512 байт. FAT должен состоять
из 2848 элементов (+1 свободный). Вынесенный FAT рамдиска занимает 2 байта на элемент.
А теперь смотрим в исходники ядра:
Вынесенный FAT располагается в памяти по адресам 0x280000-0x281000, это 4096 байт или
2048 элементов. Где остальные 800 ?
Посмотрим, как определяется размер рамдиска:
ramdisk_free_space:
;---------------------------------------------
; returns free space in edi
;---------------------------------------------
push eax ebx ecx
mov eax,0x280000
xor edi,edi
mov ecx,1448000/512 ; ОГО-го !!!!!
rdfs1:
mov ebx,[eax]
and ebx,4095
cmp ebx,0
jne rdfs2
add edi,512
rdfs2:
add eax,2
loop rdfs1
pop ecx ebx eax
ret
Почему-то размер рамдиска определяется исходя из 1448000 байт деленных на 512 байт в
кластере (кстати, 1448000 на 512 нацело не делится). Так какой же размер рамдиска?
А теперь посмотрим, как обсчитывается FAT рамдиска:
; calculate fat chain
calculatefatchain:
pushad
mov esi,0x100000+512 ;указатель на "настоящий" FAT в образе дискеты
mov edi,0x280000 ;это указатель на вынесенный FAT
fcnew:
.............................
cmp edi,0x280000+4100*4 ;cколько-сколько????
jnz fcnew
popad
ret
Итак, при конвертации обрабатывается 4100*4 байт или 8200 элементов. Учтите, копия FAT
на рамдиске не создается, она искуственно дублируется при обратном процессе (реконвертации
в "нормальный" FAT12 на образе диска перед его записью на диск.
Так сколько же элементов в FAT??????????????
Рамдиск - дурдом какой-то
Михаил
Ты неправильно насчитал.
Размер образа 1440*1024.
Получается 2880 секторов на диске, но так как отсчет начинается не с начала диска, а с расположения директории ROOT, то в результате имеем 2847 кластеров. Сам FAT себя не содержит. Потому и сбой на нулевой дорожке часто оказывается фатальным.
На дискете и в образе для FAT12 используется 12 битное представление секторов (кластеров), отсюда и название. Но так как работать с 12 битными значениями не удобно (хотя возможно), то в драйвере они перекодируются в 16 битный вид. Соответственно на каждый кластер теперь используется WORD.
Теперь считаем 2847*2 (так как 2 байта) = 5694*2 (так как 2 копии FAT) = 11388.
Но это частный случай.
А так как FAT12 позволяет использовать большее количество кластеров. То в драйвере расчет идет на максимальное значение. 4100*4 =16400.
Потому данные расположенные mem.inc неверны. Это я понял тогда когда начал работать над поддержкой флопика.
0x280000+4100*4(десятичные числа)=0x284010.
На всякий случай для флопика я еще отодвинул буфер распакованного FAT, и он начинается c 0x285000. Хотя можно уменьшить адрес для экономии памяти.
Ты неправильно насчитал.
Размер образа 1440*1024.
Получается 2880 секторов на диске, но так как отсчет начинается не с начала диска, а с расположения директории ROOT, то в результате имеем 2847 кластеров. Сам FAT себя не содержит. Потому и сбой на нулевой дорожке часто оказывается фатальным.
На дискете и в образе для FAT12 используется 12 битное представление секторов (кластеров), отсюда и название. Но так как работать с 12 битными значениями не удобно (хотя возможно), то в драйвере они перекодируются в 16 битный вид. Соответственно на каждый кластер теперь используется WORD.
Теперь считаем 2847*2 (так как 2 байта) = 5694*2 (так как 2 копии FAT) = 11388.
Но это частный случай.
А так как FAT12 позволяет использовать большее количество кластеров. То в драйвере расчет идет на максимальное значение. 4100*4 =16400.
Потому данные расположенные mem.inc неверны. Это я понял тогда когда начал работать над поддержкой флопика.
0x280000+4100*4(десятичные числа)=0x284010.
На всякий случай для флопика я еще отодвинул буфер распакованного FAT, и он начинается c 0x285000. Хотя можно уменьшить адрес для экономии памяти.
Марат!
А какой смысл использовать FAT12 на всю катушку, если получившийся образ на дискету назад не впихнешь
И еще. Про конвертацию я уже мало того что все понял, но уже переписал процедуры конвертации и реконвертации FAT12 в FAT рамдиска. Теперь они работают быстрее и при этом занимают меньше времени. Но этого мало, буду работать дальше. Так что как еще наработаю, лови исходники. И все-таки: зачем конвертировать больше элементов FAT чем реально используется? Учти, второй копией FAT драйвер рамдиска не пользуется. Про нее вспоминают только тогда, когда необходима обратная конвертация - после нее искусственно создают вторую копию в образе. И правильно - вероятность сбоя в памяти все же меньше чем на дискете.
Насчет размера диска. Все-таки непонятно, почему они исходят из размера 1448000 байт?
Так что, теперь распакованный FAT будет начинаться с 0x285000? Уф блин опять все переписывать.
Делаем вывод: делается очень много ненужных движений. Для рамдиска создается FAT, часть элементов которой вообще никогда не будет использоваться (полученные кластеры не залезут на дискету). При этом создается вторая копия, о которой в дальнейшем вообще не вспоминают. Определение размера диска идет через пень колоду, но слава богу, этот глюк почти не заметен (но по идее, сильно заполненный рамдиск определяется как заполненный полностью, а последние 9664 байта использовать просто невозможно - система будет возвращать "диск полон".
Я по любому перепишу драйвера рамдиска. Ну не нравятся они мне.
А какой смысл использовать FAT12 на всю катушку, если получившийся образ на дискету назад не впихнешь
И еще. Про конвертацию я уже мало того что все понял, но уже переписал процедуры конвертации и реконвертации FAT12 в FAT рамдиска. Теперь они работают быстрее и при этом занимают меньше времени. Но этого мало, буду работать дальше. Так что как еще наработаю, лови исходники. И все-таки: зачем конвертировать больше элементов FAT чем реально используется? Учти, второй копией FAT драйвер рамдиска не пользуется. Про нее вспоминают только тогда, когда необходима обратная конвертация - после нее искусственно создают вторую копию в образе. И правильно - вероятность сбоя в памяти все же меньше чем на дискете.
Насчет размера диска. Все-таки непонятно, почему они исходят из размера 1448000 байт?
Так что, теперь распакованный FAT будет начинаться с 0x285000? Уф блин опять все переписывать.
Делаем вывод: делается очень много ненужных движений. Для рамдиска создается FAT, часть элементов которой вообще никогда не будет использоваться (полученные кластеры не залезут на дискету). При этом создается вторая копия, о которой в дальнейшем вообще не вспоминают. Определение размера диска идет через пень колоду, но слава богу, этот глюк почти не заметен (но по идее, сильно заполненный рамдиск определяется как заполненный полностью, а последние 9664 байта использовать просто невозможно - система будет возвращать "диск полон".
Я по любому перепишу драйвера рамдиска. Ну не нравятся они мне.
Это для флопика, а не для рам-диска.Так что, теперь распакованный FAT будет начинаться с 0x285000?
Надеюсь они станут логичнее и в них будет больше комментариев . Скоро уже часть за частью мы все ядро перепишем - mike.dld переписал gui, Mario79+ты - файловая подсистема, я - управление процессами и памятью. В целом это уже значительная часть ядра.Я по любому перепишу драйвера рамдиска. Ну не нравятся они мне.
А зачем флопику распакованный FAT? Хотя логика есть в том, что с ним легче работать чем с FAT12 - 12 бит гемор еще тот. И соответствующие процедуры конвертации/деконвертации уже есть, я постарался чтоб они побыстрее работали, оказалось не зря - при работе с флопиком они будут использоваться куда чаще - при каждой модификации (а то и чтении) FATa. Только тогда надо предусмотреть в них передачу указателя на FAT как параметра, а то они пока жестко содержат указатели.halyavin wrote:Это для флопика, а не для рам-диска.Так что, теперь распакованный FAT будет начинаться с 0x285000?
На самом деле нет. Если метка диска и его серийный номер не изменились, значит у нас все та же дискета и заново читать и распаковывать FAT не нужно.использоваться куда чаще - при каждой модификации (а то и чтении) FATa.
А если она изменилась, а у нас все записано только в образ? Тогда уже заново упаковывать FAT просто не имеет смысла - дискеты-то уже тю-тю. Я имею в виду не только распаковку, но и последующую упаковку.halyavin wrote:На самом деле нет. Если метка диска и его серийный номер не изменились, значит у нас все та же дискета и заново читать и распаковывать FAT не нужно.использоваться куда чаще - при каждой модификации (а то и чтении) FATa.
На сколько я понимаю, изменения сбрасываются немедленно, а если юзверь выдернул дискету во время записи на нее, то что произойдет одному богу (Mario79) известно .А если она изменилась, а у нас все записано только в образ?
Конвертация в 12-бит будет использоваться, действительно, гораздо чаще - при каждой записи на дискету , но с 12 битами работать еще хуже.
Михаил
Ты просто не понял немного. Halyavin знает чуть больше тебя, так как кое-что видел, чего еще кроме него никто (и разумеется меня) не видел.
Запутался ты потому, что решил, что запись на флопик и РАМ диск связаны между собой. Так вот заверяю тебя это абсолютно независимые друг от друга драйверы. Конечно, драйвер флопика повторяет некоторые элементы драйвера РАМ диска. Но они пользуются разными процедурами, их коды нигде не пересекаются. Конечно, это занимает немного больше места в коде, но зато параллельный доступ к флопику и РАМ диску не мешают друг другу.
Процедуру записи РАМ диска на флопик я вообще не трогал, она осталась такой, какой была.
Мой драйвер флопика работает с дискетой также, как в системе работается с винтом. То есть если надо записать или считать файл, то считывается FAT+ROOT+ищется путь к файлу во вложенных папках и затем производится работа с файлом. Нет необходимости работать с образом. Все как в других ОС. Нормальный драйвер флопика.
Если выдернуть дискету из флопика во время записи произойдет фатальный сбой, впрочем, это случится и в любой другой ОС.
Ты просто не понял немного. Halyavin знает чуть больше тебя, так как кое-что видел, чего еще кроме него никто (и разумеется меня) не видел.
Запутался ты потому, что решил, что запись на флопик и РАМ диск связаны между собой. Так вот заверяю тебя это абсолютно независимые друг от друга драйверы. Конечно, драйвер флопика повторяет некоторые элементы драйвера РАМ диска. Но они пользуются разными процедурами, их коды нигде не пересекаются. Конечно, это занимает немного больше места в коде, но зато параллельный доступ к флопику и РАМ диску не мешают друг другу.
Процедуру записи РАМ диска на флопик я вообще не трогал, она осталась такой, какой была.
Мой драйвер флопика работает с дискетой также, как в системе работается с винтом. То есть если надо записать или считать файл, то считывается FAT+ROOT+ищется путь к файлу во вложенных папках и затем производится работа с файлом. Нет необходимости работать с образом. Все как в других ОС. Нормальный драйвер флопика.
Если выдернуть дискету из флопика во время записи произойдет фатальный сбой, впрочем, это случится и в любой другой ОС.
Марат
Копаюсь тут в исходниках и с удивлением обнаруживаю, что удаление файла с рамдиска через 58-ю функцию так и не реализовано. Правда ли это или я что-нить недопонимаю?
Кстати, драйвера рамдиска я уже переделал насколько смог. Теперь кстати нормально заработал мой LC. Пофиксены некоторые баги и частями переписан частями оптимизирован кривой код. Изменения в основном коснулись FC.INC кстати, код оптимизирован по скорости. Теперь по ходу прийдется копаться в FC.INC Еще у меня создалось впечатление, что этот буржуйский товарищ не реатизовал все, что заявлено в 58 функции. И еще: он явно копался в драйвере рамдиска, но не до конца. Будем работать.
Копаюсь тут в исходниках и с удивлением обнаруживаю, что удаление файла с рамдиска через 58-ю функцию так и не реализовано. Правда ли это или я что-нить недопонимаю?
Кстати, драйвера рамдиска я уже переделал насколько смог. Теперь кстати нормально заработал мой LC. Пофиксены некоторые баги и частями переписан частями оптимизирован кривой код. Изменения в основном коснулись FC.INC кстати, код оптимизирован по скорости. Теперь по ходу прийдется копаться в FC.INC Еще у меня создалось впечатление, что этот буржуйский товарищ не реатизовал все, что заявлено в 58 функции. И еще: он явно копался в драйвере рамдиска, но не до конца. Будем работать.
Who is online
Users browsing this forum: No registered users and 10 guests