Помогите с загрузочным сектором

А всё-таки какая программа самая быстрая, маленькая и удобная для записи файла(BOOTSECT.BIN(512 байт)) на BOOT-сектор диска Floppy или CD или DVD(мне нужно на DVD).

 

Зачем тебе самая быстрая? Лучше самая надежная и многофункциональная. Лично я для записи на CD/DVD использую Nero, которая умудряется на двухядерном проце и 4 гигах памяти загружаться с небольшой задержкой. Только учти, что bootsect.bin для флоппика не подойдет для CD/DVD, да и находиться загрузочный блок там должен в другом месте. Можешь использовать возможность эмуляции флоппика при загрузке с CD/DVD.

 

Извеняюсь, долго старался, менял, но у меня так и не получилось перевести код в 32-битный режим, что не так:

Код (Text):

1. org     100h
2.         use32                          
3.  
4.     mov ax,3
5.     int 10h
6.  
7.     push cs
8.     pop  ds
9.     mov  esi,hello
10.     mov  edi,550
11.     mov  ax,0B800h
12.     mov  es,ax
13.     mov  ah,7
14. @@:
15.     lodsb
16.     or  al,al
17.     je  @F
18.     stosw
19.     jmp @B
20. @@:
21.     mov ah, 10h
22.     int 16h
23.     ret    
24.  
25. hello db 'Hello world!',0h

 

Zhelezka
use32 скажем прямо не переводит процессор в защищенный режим . Это всего лишь директива ассемблеру, какой код генерировать -- 16/32/64 бита, а не инструкция процессора. Чтобы перевести процессор в защищенный режим необходимо провести некоторую подготовку. Например, так:

Код (Text):

1. use16
2. org ;подставить свой org.
3.  
4. xor ax, ax
5. mov ds, ax
6. mov es, ax
7. mov ss, ax
8. mov sp, 0x7C00 ;подставить свое значение стека.
9.  
10. cli
11. lgdt [gdtr]
12. mov eax, cr0
13. or eax, 0x1
14. mov cr0, eax ;включили защищенный режим.
15. db 0x66
16. jmp 0x8:pm
17.  
18. use32
19. ;Мы в защищенном режиме:
20. pm:
21.  mov ax, 0x10
22.  mov ds, ax
23.  mov es, ax
24.  mov ss, ax
25.  mov esp, 0x1000 ;подставить свое значение стека.
26.  mov ecx, MSG_SIZE
27.  mov esi, msg
28.  mov edi, 0xB8000
29.  rep movsb
30.  jmp $
31.  
32. gdtr:
33. dw 0xF
34. dd gdt
35.  
36. gdt:
37. dq 0x0 ;null descriptor
38. ;code segment:
39. dw 0xFFFF      ;dw_limit
40. dw  0x0          ;dw_base1
41. db  0x0         ;db_base2
42. db 10011010b   ;db_ar: P=1,DPL=0,S=1,TYPE=e/r,A=0
43. db 11001111b   ;db_: G=1,D=1,L=0,U=0,LIMIT=1111b
44. db 0x0         ;db_base3
45. ;data segment:
46. dw 0xFFFF      ;dw_limit
47. dw  0x0          ;dw_base1
48. db  0x0         ;db_base2
49. db 10010010b   ;db_ar: P=1,DPL=0,S=1,TYPE=drw,A=0
50. db 11001111b   ;db_: G=1,D=1,L=0,U=0,LIMIT=1111b
51. db 0x0         ;db_base3
52.  
53. msg: db 'H', 0x7, 'e', 0x7, 'l', 0x7, 'l', 0x7, 'o', 0x7, ' ', 0x7, 'P', 0x7, 'M', 0x7
54. MSG_SIZE = $ - msg

Написано навскидку, но, вроде, не ошибся.

Но в любом случае тебе надо почитать о защищенном режиме.

 

Mika0x65, допущена довольно простая ошибка: ты выставил префикс 0x66, но сам-то код у тебя 16-разрядный (use16) - проц. будет пытаться выполнить команду с 4-байтным смещением, а у тебя смещение в опкоде будет занимать только два байта. Чтобы добиться нужного результата, в fasm'е можно написать jmp pword 8:pm или по старинке db 0x66/db 0xEA/dd pm/dw 8. Можно ограничиться и 16-разрядной командой, т.к. смещение точки назначения не превосходит 0xFFFF.

 

Лимит GDT не захватывает последний дескриптор.

 

Я только вот не согласна с заявлением в 512 байт!
BOOT сектор на самом деле имеет 512 байт, но никто таких ограничений на загрузчик не накладывает...
Если не ошибаюсь, то по смещению +0h находится near jmp на пред выборочный загрузчик. Сам загрузчик должен лежать после BOOT данных файловой системы (не забывайте про совместимость). Так как сам BIOS грузит только первый сектор нулевой стороны нулевой дорожки в 512 байт (и на моей машине кстати не любит отсутствия 0x55AAh в конце и просит подтверждения загрузки!), то я бы советовала этот метод:

1) поставить near jmp <pre_loader> по смещению +00h (pre_loader должен быть помещён ПОСЛЕ таблицы, но до 0x55AAh) ну вы в курсе ;
2) по метке pre_loader поместить код, который используя INT13 (02/03 в ah) загрузит нормальный полнофункциональный загрузчик который я, к примеру, закинула в hidden sectors для того, чтоб не скрыть его от ОС;
3) нормально заполнить FAT12 таблицу!!! - это поможет избежать проблем в будущем.


насчет самой быстрой программы:
1) на оптических носителях BOOT находится не там, где он есть на дискетах, НО... (внимательно читаем) бут сектор на CD/DVD это как бы эмуляция BOOT дискеты, потому, что все программы просто переписывают копию дискеты (сектор в сектор) на область BOOT CD/DVD. (можно расслабится). Так что все тривиально и проверено: используемый BOOT должен быть корректно размещен на дискете и тогда проблем с CD/DVD не будет.
2) Лично я использовала scdwriter: бесплатно и всего 300KB. А с nero лучше не связываться. У меня были с ним проблемы, так как он некорректно обрабатывал FAT12 дискеты.

Any questions?

 

Хотя я уже ответила на этот вопрос в предыдущем посте, но: какой резон использовать nero для таких вещей. Я понимаю, что для P4 два ядра это смешной и простой процесс

"bootsect.bin для флоппика не подойдет для CD/DVD" - не согласна! Подойдет, проверено!!!

 

ovejto, предлагаете использовать FAT12 - неплохо, только не нужно никуда закидывать "нормальный полнофункциональный" загрузчик. Нужно его разместить в файле и считать во время загрузки с помощью кода загрузчика. Ну и собственно, с чем вы не согласны... Я говорил про чистый CD-загрузчик без эмуляции флоппика или жесткого диска. Хотя на этот счет и сделал небольшую оговорку:

Nero отлично обрабатывает образы дискет, причем ему все равно, какая там файловая система. Главное, указать в настройках, что это образ дискеты, и указать тип дискеты, потому что загрузочной спецификацией поддерживаются три вида дискет: 1,2 Мб, 1,44 Мб и 2,88 Мб - размер образа должен соответствовать типу дискеты. Nero использовать необязательно, просто это самая распространенная программа такого класса под Windows.

 

Да, можно, но так придётся либо использовать DOS прерывания (которых ещё нет и не будет), либо ручками разбирать FAT12(иль другую) таблицу с помощью int13 или портов, что, согласитесь, трудоемко да и не нужно. Так что с hidden sectors будет просто чуть легче, хотя, соглашусь, тоже не очень рационально.

насчёт nero: если это правда, то c nero можно и подружиться. Так, как вы и сказали, это самая распростроненная прожигалка. Согласна

P.S.: А про самое оптимальное размещение "нормального полнофункционального" загрузчика надо ещё будет мне подумать на досуге. На данный момент использую hidden sector'а ну и тулзу, которая формирует образ дискеты и скармливает ее scdwriter'у. Оптимизация рулит.

 

Что за скрытые секторы? В FAT так обычно называются секторы, предшествующие разделу жесткого диска, т.е. для флоппика число таких секторов должно быть равно 0. Есть еще резервные секторы, которые начинаются как раз с загрузочного сектора, но для FAT12 число таких секторов должно быть равно 1 (только загрузочный сектор), потому что практически все драйверы при работе с FAT12 подразумевают именно такое значение. Остается только один нормальный вариант - это секторы "в конце" флоппика, "отобранные" у области файловых данных FAT. Я прав?

 

как правило это сектора не используемые файловой системой. К примеру сектора 1-62 сначала жесткого диска либо это последние 8 Мб в конце диска если диск был побрит и формован стандартными утилами винды.

 

В них очень удобно хранить либо код собственного загрузчика, либо код или данные виря/тря. Так я поступал ещё в прошлом веке. Хранил данные вирей в первых секторах винта.

 

k3internal, речь идет об образе флоппика на CD, а не об образе жесткого диска. Дополнительные 31 Кб в начале жесткого диска используются многими бут-менеджерами и т.п. программами. Хотя в моем mbr-загрузчике эта область сейчас и не используется, вполне возможно я ее задействую в будущем.

 

Почему же если драйвера подразумевают что так должно быть, то так и должно быть?? Кстати, кто именно так "подразумевает"? Есть в конце концов какие-то стандарты. Не нравится hidden sectors, используйте reserved sectors! Кто мешает.

Ваш вариант, насколько я понимаю, это взять попросту и обрезать FAT (покрыть FAT не 1.44 а, например, 1.10 Mb) и в конце приаттачить свой код, правильно? Можно и так. А можно и количество FAT уменьшить до 1 вместо 2.
Вариантов много..

 

Можно и так, но это редкость(не у винды). И если разбивать ручками (или сторонними прогами) то такого не будет. Кстати, первые сектора от 2 до 62, если я не ошибаюсь, лучше не трогать. Linux загрузчик их может потереть при первой же возможности.

Но мы про дискеты

P.S: Вспомню про такую программку fformat для DOS, которая делала из 1.44 MB 1.72 (точно не помню сколько). Автору респект!

 

Угу, есть стандарт от Microsoft, русский перевод лежит на Васме в разделе "Документы". Он прямо говорит и про hidden sectors (что там должен быть 0 для unpartitioned devices типа дискеты), и про reserved sectors (что там для совместимости в FAT12/16 обязана стоять единица). Другой вопрос, что даже сама Microsoft вовсе не во всём придерживается этого стандарта А прямой ответ на первый вопрос звучит так: если созданный том FAT расходится с драйверами, то драйвера такой том не смогут загрузить, а виноватым будет, естественно, тот, кто такой том создал (а вовсе не драйвера, которые нормально примонтируют нормальные разделы).

 

Без загрузки OC, под Bios
нужно-ли для работы Vesa какие-то драйвера?

 

Zhelezka
Для VESA(Video Electronics Standards Association) драйверы не нужны. VESA а вернее VBE - VESA BIOS EXTENSION должна быть доступна сразу после загрузки и иниациализации компьютера.

 

Почему программа не работает:
(почти тоже самое что и сообщение #44):

Код (Text):

1. format PE
2. entry start
3.  
4. use16
5. start:
6.  
7. xor ax, ax
8. mov ds, ax
9. mov es, ax
10. mov ss, ax
11. mov sp, 0x7C00
12.  
13. cli
14. lgdt [gdtr]
15. mov eax, cr0
16. or eax, 0x1
17. mov cr0, eax
18. db 0x66
19. jmp pword 8:pm
20. ;db 0x66
21. ;db 0xEA
22. ;dd pm
23. ;dw 8
24.  
25. use32
26. pm:
27.  mov ax, 0x10
28.  mov ds, ax
29.  mov es, ax
30.  mov ss, ax
31.  mov esp, 0x1000
32.  mov ecx, MSG_SIZE
33.  mov esi, msg
34.  mov edi, 0xB8000
35.  rep movsb
36.  jmp $
37.  
38. gdtr:
39. dw 0xF
40. dd gdt
41.  
42. gdt:
43. dq 0x0 ;null descriptor
44. ;code segment:
45. dw 0xFFFF      ;dw_limit
46. dw  0x0          ;dw_base1
47. db  0x0         ;db_base2
48. db 10011010b   ;db_ar: P=1,DPL=0,S=1,TYPE=e/r,A=0
49. db 11001111b   ;db_: G=1,D=1,L=0,U=0,LIMIT=1111b
50. db 0x0         ;db_base3
51. ;data segment:
52. dw 0xFFFF      ;dw_limit
53. dw  0x0          ;dw_base1
54. db  0x0         ;db_base2
55. db 10010010b   ;db_ar: P=1,DPL=0,S=1,TYPE=drw,A=0
56. db 11001111b   ;db_: G=1,D=1,L=0,U=0,LIMIT=1111b
57. db 0x0         ;db_base3
58.  
59. msg: db 'H', 0x7, 'e', 0x7, 'l', 0x7, 'l', 0x7, 'o', 0x7, ' ', 0x7, 'P', 0x7, 'M', 0x7
60. MSG_SIZE = $ - msg

В откладчике(Visual C++) вижу это: