Господа! Я в ауте! Если выставлять бит исользования LFB при включении режима, то всё прекрасно! Если не выставлять, то отваливаются прерывания . В принципе, ну его нафиг . Всё равно без LFB никакого кайфа нет . Так что, кажися, проблема решена .

Итак, подытожим: из защищённого режима можно спокойно вызывать функции 0x4f00, 0x4f01, 0x4f02 прерывания 0×10. Но не рекомендуется указывать режимы без использования LFB, иначе может случиться нечто, что приведёт к системному сбою.

UPD:
1. Обязательно надо включить обработчики прерываний в реальном режиме перед вызовом int 10h.
2. Если перепрограммирован контроллер — скопировать векторы прерываний реального режима на новые.
3. Использовать только LFB-режимы.

Продолжаю колдовство с VESA.

Поменял модель организации вызова 16-разрядного кода. Теперь Код располагается в специальном сегменте, который начинается с адреса 0×90000. В этом же сегменте создаётся аллокатор страниц и аллокатор блоков. Их можно использовать для выделения памяти в пределах этого сегмента (что весьма удобно). Например, можно выделить 512 байт под общую информацию VBE или под буфер для получения информации о режиме.

Проблема в другом: после вызова 10h почему-то отваливаются IRQ-прерывания, хотя процессор возвращается обратно в защищённый режим и продолжает цикл. Возможно, надо будет попробовать переинициализировать контроллер.

VESA

Всё-таки, упирался-не упирался, а прикрутил к ядру возможность вызывать int 10h. При чём, параметры можно передавать вот в такой вот структурке:

#pragma pack(push, 1)

typedef struct TRealmodeRegState
{
    WORD    FLAGS;
    WORD    DI;
    WORD    SI;
    WORD    DX;
    WORD    CX;
    WORD    BX;
    WORD    AX;
} TRealmodeRegState;

#pragma pack(pop)

Теперь оська умеет вваливаться в графический режим по f11 и вываливаться из него (тоже по f11). В качестве тестового режима было решено взять 0×114 (800x600x16).

Пора писать драйвер VBE (/dev/vbe).

Multiprocessing

Процессоры научились входить в main. Мало того, в качестве аргумента в main теперь передаётся номер процессора, который определяется специальным атомарным семафором. Теперь надо задуматься о шедулере, ибо тот шедулер, что имеется на данный момент, совсем не годится для мультипроцессорных систем. Уже есть идеи по организации шедулинга, но их надо воплотить в жизнь.
Ещё хотелось бы, чтобы на время иницализации /dev каждый процессор прописал себя в /dev/cpuid. Для этого надо как-то придумать, чтобы нужные нити запускались на нужных процессорах. Будем думать.
Known bugs
На AMD Athlon x2 упорно не хотят читаться секторы FDD. Скорее, проблема в том, что надо дёргать MTRR. Но надо проверить.
Опять же, на двухъядернике при нажатии нескольких клавиш одновременно виснет клава. Очень неприятно. Скорее, виноват второй CPU, который, возможно, отлавливает прерывание от клавиатуры. Наверное, проблема решится отрубанием APIC или программированием его в Virtual Wire Mode.