VESA, Protected mode и LFB.

(Как всё это заставить работать ??? )
Подскожите Pleazz как инициализировать графический режим 640x480x8
в Protected mode с использованием LFB. (А то в Real медленно получается)
И если можно укожите пару адресков с аписанием.

Сообщение отредактировано: Chibis - 24.04.02, 17:28

Не занимайся ерундой! Что в Real, что в Protected mode - скорость почти не  изменится. Попробуй писать процедуры на ассемблере по копированию области памяти с картинкой в видео память SVGA (Я в своё время бился, да так мне это надоело)

Fallex
Спасибо за совет, но ты вобше работал с VESA.
VESA позваляет работать с бальшими разрешениями и количеством цветов.
А меня интересует 640x480x16. В Real mode есть только одно (два но второе не используют)
окно $A000 разметом 64к и это значит, что весь видео буфер нужно
грузить по кускам 640*480*2/65536=9.375 (на одну страницу надо 10
кусков). Из за этих кусков резко усложняются все процедуры вывода
графики на экран и по таму нужно инфо по LFB (Long frame bufer (если не ошибаюсь)).
Все линейно по таму и скорость больше понемаеш?

Информации по LFB более чем достаточно, например, имеется официальное описание стандарта VESA/VBE 3 Core Functions, которое можно скачать с www.vesa.org. Тем не менее, имей в виду, что LFB-приложения не работают под операционными системами Windows NT (NT 3/4, 2000, XP), а это довольно сильное ограничение... :-( Таким образом, использование VESA 1.2 (т.е. работа с банками видео памяти) остается единственным надежным методом программирования SVGA графики в приложениях MS-DOS.

Используй TMT-Pascal !!! Очень удобная работа с графикой !!!

vb
Если LFB под win 2000 не палит то вазможно ли добится приемлимых скоростей используя банки видео памяти?
(скажем закрашивать экран 50 раз на секунду в режиме 640x480x16 на 333 Celeron)

7in
Я бы с удовольствием изучил бы TMT но у меня есть только кампилятор (без редактоа),
что давольно не удобно.

Интересно, куда ж он, редактор, у тебя делся-то???
Он обзывается idew32.exe
Скачивай новую версию 3.90!

Цитата Chibis, 27.04.02, 00:33:38

vb
Если LFB под win 2000 не палит то вазможно ли добится приемлимых скоростей используя банки видео памяти?
(скажем закрашивать экран 50 раз на секунду в режиме 640x480x16 на 333 Celeron)

Это зависит от оптимизации твоего кода и от производительности видеокарты (критическим фактором является пропускная способность VRAM). Думаю, что прокачать 234.5 Mb в секунду ("...закрашивать экран 50 раз на секунду в режиме 640x480x16...") сможет практически любая видеокарта, т.к. даже простенькая Riva Vanta LT имеет пропускную способность памяти 800 Мб/с.

2: Chibis
Я немного ошибся в своем предыдущем письме. В действительности, для выполнения твоей задачи нужно прокачать не 234.5 Мб/с, а всего-навсего 29.3 Мб/с (=640*480*2*50). Такая пропускная способность не является проблемой даже для очень древних карточек.

Правильно люди говорят!
ТМТ паскаль - и проблема решена( ну почти :)
Так чо поищи лучше инфу по модулю GRAPH в ТМТ

Ладно уговорили. Уже качаю TMT.

vb
Незнаю но я лично дабился скорости не больше 40 кадров.
Использовал Pascal 7.0 с Asm.
Перебрасывал по 4 байта используя db 66h.
Все тормоза как я понел из за переключения банков.

TMT С РЕДАКТОРОМ, ПРИБАМБАСАМИ, ПРИМЕРАМИ V3.90 И ГЛАВНОЕ НА ХАЛЯВУ  :D
Уже слюньки потекли.

Сообщение отредактировано: Chibis - 27.04.02, 20:02

Цитата Chibis, 27.04.02, 22:39:51

vb
Незнаю но я лично дабился скорости не больше 40 кадров.
Использовал Pascal 7.0 с Asm.
Перебрасывал по 4 байта используя db 66h.
Все тормоза как я понел из за переключения банков.

Использование 32-битных команд в 16-битном режиме (db 66h) выполняется не особо быстро. Все-таки в native 32-bit protected mode это дело работает гораздо шустрее. Конечно, процедура переключения банков тоже требует достаточно много времени. Тем не менее, она не должна _так_сильно_ тормозить процесс... Ты не мог бы привести полный код своей процедуры закраски экрана?

По поводу переключения банков: лучше переключать их, делая FAR CALL, а не через INT 10h. Шустрее будет....

Особенно медленно прерывания (в т.ч. и INT 10h) работают в 32-битных приложениях защищенного режима, т.к. thunking (переключение режима 32bit->16bit->32bit) очень сильно тормозит приложение. Таким образом, прямой вызов 32-битной процедуры переключения банков, которая доступна в VESA 2.0 и выше (функция 0Ah - Return VBE Protected Mode Interface), действительно очень ускоряет работу с графикой в banked SVGA режимах.

7in
Первый пример VESA который я в дальнейшем разобрал
как раз использавал этот FAR CALL. (см. ниже)

vb
По поводу примера:
Далее приведён почти рабочий пример программы с использованием моей процедуры закраски экрана (VFAP) в Real mode. Следует отметить что она ращитана на работу с разными разрешениями и колличеством цветов, так же предусмотрен просчёт для переключения видео страниц.
Но т.к. тут всё фиксировано то все числа подставлены в ручную. Надеюсь что я подставил верные параметры для работы проги но если она не заработает то прошу меня проинформировать). На моём 333 Cel эта процедура даёт около 47 кадров за секунду. Может есть замечания, предложения по оптимизации, или критика то пишите.

Var wAddPixel:Word; {Заполняется процедурой переключения видео страниц}
    wAddChunk:Word; {-//-//-}
    wEndChunk:Word; {-//-//-}
    wEndPixel:Word; {-//-//-}
 
    BytesPerPixel:Byte;{Заполняется при инициализации}
    pWindowingFunction:Pointer;{-//-//-}
    wDeltaChunk:Word;{-//-//-}
    wWriteSegment:Word;{-//-//-}
    wReadWriteChunk:Word;{Нужно для хранения активного банка.
                          Позволяет избавляться от лишнего переключения банка.
                          Активно используется процедурой прорисовки точки.}
 
    Buf:Array[0..63]of LongInt;
 
Function VESAModeSupport(GrMode:Word):Boolean;
{Нужна для получения информации}
Assembler;
Asm
mov ax,Seg(Buf)
mov es,ax
mov di,Offset(Buf)
mov ax,$4F01
mov cx,GrMode
int $10
End;
 
 
Procedure VFAP(wColor:word);{Вот так она у меня выглядит}
Assembler;
Asm
mov     ax,wAddPixel
mov     bl,BytesPerPixel
xor     bh,bh
mul     bx
add     dx,wAddChunk
mov     di,ax
mov     bx,0
pusha; cli; call pWindowingFunction; sti; popa
mov     cx,wDeltaChunk
add     cx,wEndChunk
mov     ax,wWriteSegment
mov     es,ax
mov     ax,wColor
db      66h
shl     ax,16
add     ax,wColor
 
{Далее сама закраска}
@1: db 66h;stosw
cmp     di,1
jnc     @1
 
inc     dx
pusha; cli; call pWindowingFunction; sti; popa
sub     cx,1
jnz     @1
 
@2:
db      66h
stosw
cmp di,wEndPixel
jnz @2
 
mov dx,wReadWriteChunk
pusha; cli; call pWindowingFunction; sti; popa
End;
 
Begin
VesaModeSupport($101);
{Нужна для получения адреса процедуры переключения строниц}
pWindowingFunction:=Pointer(Buf[3]);{Сам адрес}
 
wWriteSegment:=$A000; {По умолчанию}
BytesPerPixel:=2;
wDeltaChunk:=640*480 div $8000;
wEndPixel:=24576;
 
Asm mov ax,$4f02;mov bx,$111; int 10h; end;
{Грубоя инициализация режима 640x480x16 на самом деле всё делается не так}
 
VFAP($ffff);{Обычно я закрашиваю чёрным цветом}
 
ReadLn;
Asm mov ax,3; int 10h; End;
End.

А для чего ты вызываешь pWindowingFunction в конце процедуры (непосредственно перед “End;”)? IMHO кроме дополнительного торможения программы, это ничего не дает... Кроме того, “rep stosd” будет выполняться быстрее, чем последовательность “@2: stosd; cmp di, wEndPixel; jnz @2”. Еще, вместо pusha/popa можно сохранять только те регистры, которые используются в твоей процедуре (es, ax, di, cx и dx) – так быстрее. Ну и разумеется, если переписать все это дело под 32-bit protected mode, то можно будет избавиться от префикса 66h, что даст дополнительный прирост производительности.

vb
Спасибо за советы, учту.
Было бы интересно посмотреть твои 32-ух битные разработки(если они у тебя есть),
может скинеш что нибудь?

Честно говоря, мне и скинуть то нечего... Давать тебе обобщенные процедуры нет смысла, т.к. они все равно будут достаточно медленными. Писать что-то конкретное для твоего примера тоже не интересно, т.к. ты это прекрасно сделаешь и без меня. Если же надо дать пару-тройку советов по оптимизации конкретного примера - всегда пожалуйста!

Не врубаюсь, зачем нужна 2-ух байтная переменная wWindowGranulity?
(5-ий байт буффера передавймый при вызове VESAModeSupport (AX=4F01))