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

http://www.lowlevel.ru/osdev/sources.htm

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

 

Огромное спасибо, супер чтиво.

 

Вопрос. Зачем такие извращенства?

 

Не знаю, я masm не использую

 

Loginanton, куда выйти-то? ))

 

Ура работает! Огромное спасибо всем кто мне помог ЭТО сделать! Теперь хотелось бы понять собственно как это работает Кстати вот код:

Код (Text):

1. [org 0x7c00]
2.  
3. start:
4.  
5. cli
6. mov ax, cs
7. mov ds, ax
8. mov ss, ax
9. mov sp, start
10.  
11. sti
12.  
13. mov si, msg
14. call kputs
15.  
16. cli
17. hlt
18. jmp short $
19.  
20. kputs:
21.  
22. .loop:
23. lodsb
24. test al, al
25. jz .quit
26. mov ah, 0x0e
27. int 0x10
28. jmp short .loop
29. .quit:
30. ret
31.  
32. msg: db "Hello World!!!",0x0a,0x0d,0
33. times 510-($-$$) db 0
34. db 0xaa, 0x55

Подскажите что означают следующие строки:
cli
sti
short в jmp short $ и знак $
lodsb
times 510-($-$$) db 0

 

а я ещё не встречал биоса который просил бы 55АА. Кто встречал?

 

Я встречал и не раз. Вот чего я не встречал, так это нормального загрузочного сектора, где бы 0x55, 0xAA не было.

 

http://www.xakep.ru/post/24239/default.asp
Тоже на эту тему.
(Случайно в поисковке нашёл)

 

CLI—Запретить прерывания
STI—Разрешить прерывания

Когда вы создали программу и запустили ее на выполнение, то работает не только она одна. Простейший пример - таймер, который вызывается примерно 18 раз в секунду для обновления. Компьютер всегда что-то делает! Даже тогда, когда ждет от вас нажатия клавиши. Что происходит, когда вызывается прерывание от таймера? Примерно тоже, что и при вызове процедуры. Компьютер запоминает в стеке адрес текущей команды, а также все регистры и переходит на адрес прерывания, по которому находится процедура обработки этого прерывания (например, таймера, которая обновит показания часов/минут/секунд). Затем, как процедура отработала, компьютер восстановит из стека адрес возврата и все регистры, и наша программа пойдет работать дальше.

Вот пример, в котором мы изменим регистры SS:SP, не запрещая прерывания:
(1) mov ax,100h
(2) mov ss,ax
(3) mov sp,200h

Допустим, прерывание таймера сработало после строки (2). Что у нас получилось? SS равен 100h, а SP еще не успел измениться. Получается, что сегмент стека верный, а смещение - осталось прежним (допустим, SP=0FFFEh). В итоге, SS=100h, а SP=0FFFEh. Компьютер и сохранит по этому адресу данные. Какой при этом код программы затрется - не известно. Мы ведь хотели сделать SS=100h, а SP=200h! Хорошо, если две строки успели выполниться перед вызовом прерывания. Хорошо также, если по адресу 100h:0FFFEh ничего нет (память свободна). А если есть? Тогда компьютер, скорее всего, "зависнет".

Отсюда вытекает два правила:
1) Прежде чем менять регистры SS:SP, необходимо запретить все прерывания командой cli, а затем разрешить командой sti.
2) SS:SP нужно устанавливать на свободную область памяти. При этом следует убедиться, что код не утратил работоспособности.

ссылка на статью-оригинал: http://www.kalashnikoff.ru/Assembler/issues/006.htm

 

Я по традиции во всех своих загрузчиках использую cli/sti. Но это всего лишь дань традиции (совместимости), потому что уже ой как давно процессор не реагирует на маскируемые прерывания, пока не выполнит еще одну инструкцию после инструкции, модифицирующей регистр ss. Если бы не этот факт, ваши рассуждения были бы вполне логичны

 

Согласно документации: "Any move into SS will inhibit all interrupts, including NMI, until after the execution of the next instruction." То есть изменение регистра SS задерживает все прерывания до завершения выполнения следующей инструкции. Поэтому после инструкции изменения регистра SS должна непосредственно следовать инструкция изменения SP. В приведенном примере достаточно указанной последовательности и больше ничего делать не надо.
(1) mov ax,100h
(2) mov ss,ax
(3) mov sp,200h

В документации так же сказано, что отмена прерываний действует только при выполнении первой инструкции изменения значения SS, поэтому следующая последовательность инструкций небезопасна.
pop ss
pop ss
pop sp

Обязательно надо читать документацию.

 

В защищенном режиме есть еще одна "лазейка" для процессора, позволяющая поработать с не до конца инициализированной парой ss:esp. Когда происходит изменение ss, запрещаются только аппаратные прерывания, но не исключения или ловушки. Процессор производит выборку кода не только по eip. Если включено страничное преобразование, то может произойти #PF, если страница помечена как выгруженная, а #PF -- исключение, а не аппаратное прерывание. Поэтому его обработчик будет вызван несмотря на запрет. Если смена указателя стека не произойдет, (обработчик и прерванный код имеют одинаковые привелегии), то будет плохо . Поэтому Intel завещает использовать команду lss для изменения ss:esp.

 

Извеняюсь, но я так и не понял зачем в коде lodsb и stosw:
Сообщение #8:

Код (Text):

1. org 100h           
2.     use16              
3.  
4.     mov ax,3 ; устанавливаем режим
5.     int 10h
6.  
7.     push cs
8.     pop  ds
9.     mov  si,hello
10.     mov  di,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.     ret    
22.  
23. hello db 'Hello world!',0h

Что они делают нашёл, но для чего они в тексте?
И для чего этот блок между @@ и @@
(Видел пример вывода текста без этого)

 

Zhelezka
Это вывод текста. Есть множество способов вывести текст.

Код (Text):

1. @@:
2.     lodsb       ;// Загружаем в al байт из строки по смещению ds:si прибовляет к регистру Si еденицу. Тое читаем в регистр байты из hello.  Ah лежит атрибут символа 07
3.     or  al,al    ;// Проверка на ноль в конце строки
4.     je  @F     ;
5.     stosw      ; Выводим ax в es:di к di прибовляем двойку
6.     jmp @B
7. @@:

Другими словами мы привратили 'Hello world!' в 'H',7,'e',7,'l',7,'l',7'o',7,' ',7,'w',7,'o',7,'r',7,'l',7,'d',7,'!',7

 

Читайте:

 

О, даже так

 

Mika0x65, прикладной указатель стека нас не должен интересовать. В режиме ядра исключений в процессе модификации указателя системного стека по идее быть не должно.

 

Phantom_84
Это при условии, что любой код, выполняющийся в ядре всегда и полностью загружен в память.