Необходимо из защищенки читать файлы довольно большого объема. Вот я и думаю, каким образом реализовать это дело. Чтение можно вести, как я понимаю, посредством 42-й ф-ции прерывания int 13h или через in/out (что, как мне кажется, является наибольшей формой изврата). Для способа int 13h проблема заключается в довольно затратных по времени шагах: 1) Переключится из защищенного в реальный режим. 2) Чтение кластеров через прерывание int 13h. 3) Обратно в PMode. 4) Чтение памяти, куда положило данные прерывание int 13h в другой участок памяти, где собссно находится содержимое файла. 5) Повторять шаги 1-5, пока не прочитаем файл целиком. Учитывая то, что файл может иметь размер около 4-5 МБ, то этот способ кажется, мягко говоря, неэфективным. Если брать in/out, то там нужно иметь ввиду разные интерфейсы подключения диска (хотя я не уверен). Или может есть 3-й вариант? Подскажите, пожалуйста.
hakerkirik Через порты проще всего. Правда придеться писать драйвера для IDE,SATA, RAID, ACHI. Если IDE от SATA почти ничем не отличается. То ACHI это совсем другая песня. А вот RAID он бывает аппортаный и програмый. Взять драйвера от линукса.
Спасибо за ответ. А как обстоят дела с CD/DVD приводами? Там по ходу IDE или SATA интерфейс, или есть что-то еще? По поводу дров. Идея интересная. Может ссылочку на какие-нибудь сорсы подкините?
Решил всё же использовать PIO. Может кто знает, как мне определить тип диска (Master или Slave) и номер канала по номеру диска, который ипользуется в int 13h в регистре DL. У меня есть загрузчик. BIOS, во время передачи управления загрузчику, пишет номер диска, с которого он собственно загрузил этот загрузчик, в регистр DL. Вот только мне надо узнать на каком канале и какой тип имеет этот диск.
А каким чудом вы собираетесь вызывать int 13h из protected mode? t13.org - сайт с документацией по программированию винтов ATA и SATA.
hakerkirik, самый "затратный по времени шаг" - это научиться работать с устройствами напрямую. Помимо всего перечисленного (а этого уже вполне достаточно, чтобы загрузить свой мозг выше крыши) для CD/DVD есть еще вспомогательный интерфейс ATAPI, не говоря уже о том, что существуют такие вещи как SCSI и SAS. Хочешь немного выиграть в скорости при работе с дисками через int 13h, используй V86 и общий буфер с задачей V86. По последнему вопросу: int 13h/48h.
rudik, я имел ввиду другое. Phantom_84, именно через ATAPI PIO я и работаю сейчас. По поводу int 13h/48h. Эта ф-ция возвращает геометрию диска. А мне нужно сопоставить индекс диска, который BIOS передает загрузчику в регистр DL и данными о нахождении диска (номер канала, master/slave). Мне ведь надо каким то образом знать кому посылать in/out запросы.
Там не только геометрия диска в ответе: начиная с версии спецификации EDD 2.0 добавилось ещё поле-указатель на EDD drive parameters - эта таблица содержит данные о физическом общении с устройством.
diamond, теперь вижу, спасибо. Мне в руки попала спецификация Enhanced Disk Drive 1.1, там этого не было.
Пошуршал докой EDD 2.0. Вызываю int 13h/48h. Буфер заполняется нормально. По смещению 26 должен находится адрес буфера Device Parameter Table Extension (DPTE). Т.е. если по смещению 26 находится 0FFFFFFFFh, то DPTE инфы нет, иначе, она присутствует. Так вот, возникла проблема с доступом к этой инфе. Вызываю прерывание, дальше пишу так Код (Text): mov es, word [DriveParams.dpte_info] ; mov ebx, dword [DriveParams.dpte_info] mov ax, word [es:bx+2] DriveParams указывает на буфер для int 13h/48h. dpte_info - на адрес DPTE. В итоге ни по смещению 0,1,2 и т.д. ничего нет... Мож я как-то неправильно понял где смещение а где сегмент?
16-битные far-указатели имеют вид "dw смещение, dw сегмент". То есть правильно писать Код (Text): mov es, word [DriveParams.dpte_info + 2] mov bx, word [DriveParams.dpte_info] Либо одной командой Код (Text): les bx, dword [DriveParams.dpte_info]
Вот с этого места хотелось бы поподробней. Именно такой вариант я реализовывал у себя. Основые функции ФС работают именно через V86, правда пришлось извращаться в плане системного таймера и контроллера прерываний, дабы DOS не развалил установленные мною режимы. Написанные ф-ции более-менее протестены, но не особо обкатаны, пока еще есть некоторое недоверие к ним. На какие траблы я могу наткнуться?
Ну я при реализации работы с дисками через V86 наткнулся на следующие: 1. IRQ от соответствующего жёсткого диска обязательно следует отдавать BIOS'у (иначе BIOS'ы, работающие через DMA, могут не заметить, что данные уже прочитаны). Номер IRQ, к счастью, легко узнать через int 13h/ah=48h. 2. Если для работы с V86 резервируется целиком первый мегабайт и транслируется (в смысле преобразования физического адреса в линейный) тождественно, это сразу избавляет от кучи проблем. Иначе нужно помнить, что помимо собственного кода BIOS использует таблицу прерываний, свой сегмент данных 40h, расширенный сегмент данных (EBDA) в конце основной памяти (его размер можно узнать через int 12h или напрямую через соответствующую ячейку памяти в основном сегменте данных, и этот размер может быть больше страницы). А также, разумеется, буфер для чтения/записи и стек, причём и то, и то должно транслироваться тождественно (для того же DMA; вроде есть такая вещь, как DMA Services или что-то в этом духе, позволяющее указать BIOSу callback-функцию для трансляции V86-адресов в физические, но с ней разбираться надо и я не уверен, что все BIOSы её поддерживают). 3. Если IOPL=3, это тоже избавляет от некоторых проблем; иначе нужно создавать битовую маску для портов ввода/вывода и разрешать в ней нужные порты, а также эмулировать инструкции int/iret, cli/sti, hlt, pushf/popf, pushfd/popfd. 4. О синхронизации также нужно подумать - лучше всего вообще не разрешать повторное вхождение в BIOS, когда кто-то туда уже вошёл. Но если очень хочется, тогда по крайней мере следить за cli/sti (если IOPL<3 и процессор сам этого не делает) и не выполнять другого кода в V86, пока кто-то заблокировал прерывания, а также не забыть о разных стеках для разных потоков.
ну, это вроде трабла всех 9х виндов. Форматишь дискету - все остальное стоит. А вот от битовой маски, если я не ошибаюсь, отделаться не получится. Я даже тему создавал где то в kernel по этому вопросу. В обычных задачах - да, можно. Но не в v86. Да и в чем трудность объявить массив нулей после TSS? IRQ: При работе с винтом без таймера - никак. К тому же он у меня работает с периодом - 10 мс, а не 55. Если DOS вдруг ломанется его вернуть на место, у меня поплывут все счетчики, что равносильно катастрофе. Поэтому тут пришла на помощь битовая маска. Так же, посылка DOSом EOI, не знаю, может ли породить какие то проблемы, но я решил не дрочить судьбу, замаскировал и PIC тоже. Соответственно, пришлось прикрутить к обработчику #GP простенькую эмуляцию по командам In/Out. Единтственный вопрос у меня остался - cli/sti. По идее, теоритически, с IOPL=3 DOS может запретить прерывания и повиснуть. А без IRQ0 я не знаю как можно будет реанимировать систему в такой ситуации. Но, пока работает. Проблему решил оставить на период "вылизывания" кода. Да, есть механизм с вируальными прерываниями, но я его тогда не стал раскуривать, в то время целевым процом был 486.
Получиться, просто исключения на in/out будут всегда возникать, и их придеться эмулить. дык этож 8кб! в то время как код эмуля (на ЯВУ) от силы 1кб, компиленого маш-кода. По моим наблюдениям (как в эмулях так и на реальных желзках), влезания в PIC'и и таймеры при вызове операций чтения/записи вроде как не замечал, как и проблем с CLI и - все пашет довольно таки предсказуемо. Другое дело что довольно таки тормозно, получаеться "работать с диском из Protected Mode".
енто, если разговор идёт про protected mode, то со, скажем, SATA контроллером надо работать через PCI IO space. Исходники в linux ядре.
