Господа, помогите разобраться. Имеется Plop Boot Manager установленный на жесткий диск. Все работает отлично. MBR сектор в аттаче. Смысла в 90% кода откровенно не понял, но суть не в этом. Главное, что код из MBR Plop'a загружает 0x23 сектора в память 0x2000:0x0100 начиная с CHS:0/0/3 сектора. И делает туда длинный JMP. Я пишу свой код в MBR, который считывает 0x23 сектора в память 0x2000:0x0100 начиная с LBA:2 сектора. И делает туда длинный RET. Но Plop не стартует под моим загрузчиком. Посмотрите, плиз, что я упустил? PS: Устанавливаю Dl=0x80h, ES=0x2000, Стек на 0x0000:0x7C00h результат 0й. Проверку на наличие своего кода в MBR Plop не делает, проверенно. Мой загрузчик работает правильно, и делает все выше описанное, проверено. Но чего не хватает plop'y не понимаю.
Наличие длинного JMP наводит на мысль, что там может быть переход в нереальный или защищенный режим. Положи MBR от plop. В чем смысл использования именно plop. Grub4dos менее глючный и позволяет грузить plop из своего меню. ++++++++++++++++ Посмотрел я HW0_PLP.BS Там все прозрачно. JMP без всяких фокусов. Теперь желательно увидеть ваш загрузчик. Особенно длинный ret
Возможно, plop'у не хватает родного кода в определенном месте. То что MBR загрузчик не делает каких-либо дополнительных проверок, еще не означает, что этого не делает загружаемый код. Возможно, он даже использует код MBR-загрузчика в памяти. Попробуй в своем MBR-загрузчике оставлять в памяти код MBR plop'а в таком виде, как будто он работал (с учетом копирования и самомодификации).
Phantom_84 Там нет ничего подозрительного. Чтение секторов и прога для вывода сообщения "ошибка загрузки". Есть еще одно подозрение. Возможно MisHel64 забыл сохранить в MBR таблицу разделов.
Cуть не в том. Именно он лежит в аттаче к первому посту. Использование Grub4Dos для загрузки plop считаю избыточным способом. Можно конечно пойти по такому пути, но использовать адекватный boot менеджер, а не Grub4Dos, но это сравнимо с удалением гланд через анальное отверстие. Код (Text): Push DWord ptr Ds:[Di+4] Ret DSI указывает на пакет для Int 0x13/0x42 Ret внутри FAR процедуры разворачивается RetF (0xCB) Прежде чем писать суда, я проверял свой код. Чтение и переход действительно происходит в указанное место.
Такая мысль мне то же приходила, и казалась единственно правильной. Но проверка показала, что это не так. Хотя на проверку этой мысли я убил почти сутки. Немного посмотрев код самого PLOP, ошибка стала очевидной, и допущенной автором PLOP. В своем коде он делает Код (Text): Xor Al, Al .. LodsB .. Mov Cx, Ax ... LOOP XXXX И использует CX, для формирования некой структуры. В реальной жизни, эта ошибка никогда не всплывет. Потому, что после вызова INT 0x13 в MBR, Ah будет равен НУЛЮ. Пропатил код PLOP, заменив Xor Al, Al на Xor Ax, Ax И добавил XOR Ax, Ax в свой загрузчик. И проблема решилась. Всем спасибо.
Тему закрыли... На BIOS в таких вопросах лучше вообще не полагаться, хотя данная функция возвращает в ah нулевое значение (если не произошло ошибки). Кстати по поводу возможной ошибки здесь можно подискутировать. Самомодифицирующийся код тоже весьма мутный.
стандартные функции описаны в спецификациях edd. и я обычно им доверяю. инче зачем ими пользоваться если не веришь в результат который они вернут?
Лично, я считаю, что правилом хорошего тона, было бы обработать код возврата. И проверить, не только код возврата, но и посмотреть, что же именно было прочитано. К edd используемая функция не имеет никакого отношения.
Это было в общем: А это в частности: Лучше скажи, каким идиотом нужно быть, чтобы сделать xor al,al вместо xor ax,ax, учитывая то, что функция BIOS, вызываемая, вообще-то говоря, не в данном исполняемом модуле, вернет ah=0. В EDD 4 собираются впихнуть в том числе и описание старых функций. Давайте не будем на пустом месте... повышать активность общения в форуме. Два реальных вопроса, касающихся в общем-то не очень примечательного кода, я обозначил: 1) не понятно, как обрабатывается возникновение возможной ошибки, и обрабатывается ли вообще; 2) зачем здесь нужен самомодифицирующийся код, тем более такой мутный - умные люди меня учили никогда не модифицировать близлежащие инструкции без дальнего перехода - может, в неочевидности его работы и заключена вся фишка, хотя навряд ли. Короче предлагаю поразмышлять над этим самостоятельно.
Phantom_84 1) Никак. Вообще ни как. 2) Мое мнение об аффторе, как о программисте, после просмотра только кода в MBR было не высоким. А после просмотра кода программы упало ниже плинтуса.
