1) Да станичная адресация будет.
2) Пока не вижу такой необходимости, нет приложений, требующих настолько значительных ресурсов. К тому же реализация свопа возможна лишь после 100% уверенности в драйвере файловой системы.
3) Вопрос к Халявину Андрею.
Зачем? Код ядра должен сам определять такие вещи, иначе это будет не ядро, а решето.

Приложения и сейчас могут, зарезервировав порты, использовать их напрямую за счет битовой карты ввода-вывода.
На счет шлюза прерывания - сделать это возможно, но достаточно трудно - нужно изменить код ядра в большом количестве различных мест, и причем правильно, поскольку малейшая ошибка приведет к зависанию . В отдаленной перспективе это можно сделать.

1) по-моему, не так уж это и сложно...просто тогда не надо включать страничную поддержку...кстати, хотел у тебя спросить (Халявин) - при работе с включенной страничной поддержкой намного сильнее греются процы? может, имеет смысл для ноутов использовать старые дистры или выпускать новые с альтернативными ядрами?
2) а почему до сих пор фигурирует режим 1280x1024???? ведь Vesa 2.0 на картах Nvidia выделяет по 4 Мб - что явно не хватит...а как другие карты в режимах vesa 2.0???? кто знает?

kiwi_mani_snova
Ну, не знаю у меня на старом компе видюха AtI RageXL 8 метров памяти и работает на как раз только в Vesa2 никак не выше, однако 1280*1024 держит нормально.

Незнаю где оставить свое сообщение,но раз уж тут народ говорит о видео,то наверное здесь.
Я долго думал - как увелить скорость PutImage для слабых компьютеров.Полез в исходники ядра,изучил файл vesa20.inc.Удалил несколько команд из тела цикла 32 и 24 битного PutImage(сравнение с esp и все с ним связанное).Врезультате тело цикла стало на 3 такта короче.После долгого тестирования никаких глюков или отклонений от нормальной работы я необнаружил.Увеличение FPS я ненаблюдал,потомучто при моем мощном копьютере скорость ограничивается пропусканием шины(больше чем 150 кадров в режиме 640*480 получить неудается).Но думаю на слабом компьютере увеличение скорости будет наблюдаться.Что вы об этом думаете ?( Я НЕ ПРЕТЕНДУЮ НЕ НА ЧЬИ АВТОРСКИЕ ПРАВА!)

ИЗМЕНЕННАЯ ЧАСТЬ:
mov edi, [putimg.real_sy]
align 4
.new_line:
mov esi, [putimg.real_sx]
align 4
.new_x:
mov eax, [ecx] ; ecx = RRBBGGRR
mov [edx], ax
shr eax, 16
mov [edx+2], al

add ecx, 3 ;[putimg.source_bpp]
add edx, 3

dec esi
jnz .new_x

add ecx, [putimg.line_increment]
add edx, [putimg.screen_newline]

dec edi
jnz .new_line
.finish:
add esp, putimg.stack_data
popad
xor eax, eax
ret

put_image_end_32:
mov edi, [putimg.real_sy]
align 4
.new_line:
mov esi, [putimg.real_sx]

align 4
.new_x:
mov eax, [ecx] ; ecx = RRBBGGRR
mov [edx], eax
add ecx,3; [putimg.source_bpp]
add edx, 4
dec esi
jnz .new_x

add ecx, [putimg.line_increment]
add edx, [putimg.screen_newline] ;[BytesPerScanLine]
dec edi
jnz .new_line
.finish:
add esp, putimg.stack_data
popad
xor eax, eax

andrew_programmer
Надо будет попробовать на моем Duron950(шина 100, память DDR), а потом попробую на Cyrix233(шина 75, память - SDRAM). Кто его знает, может, выжмем еще 5-10%.

Я посчитал и получилось,что на Duron950 fps не увеличиться ,а на cyrix233 должно.

kiwi_mani_snova
Я понял, почему у меня видюха держит 1280*1024 при Vesa2.
Дело в том, что MeOS для Vesa2 использует 24 бита, а не 32. Соответственно 1280*1024*24=3.75 Мб.

andrew_programmer
Обидно, но есть таки глюк в твоем коде на обоих моих компах. Если таскать окно приложения, то все иконки оказываются поверх него.
А результаты следующие, проверял в MGB.
Первая цифра до твоей доработки, вторая после:

Duron950
800*600*32-Vesa3
window 143/142
bar 2261/2260
line 37683/37825
text1 18352/18280
text2 14416/14346
number 55878/55783
pixel 392120/392715

Cyrix233MX(M2)
800*600*24-Vesa2
window 31/30
bar 276/277
line 5320/5325
text1 2477/2500
text2 1595/1602
number 8494/8600
pixel 120445/121069

Поскольку +/- 0.5% точно можно отнести на погрешность измерения, то выводы такие. Duron никакого ускорения, Cyrix прирост в text1 +0.93%, прирост в number +1.25%, прирост в pixel +0.52% и это все прирост без учета погрешности измерения. Но, к сожалению, весь прирост обламывает глюк с иконками.

Ускорение рассчитано исключительно на PutImage - именно там(даже с глюком) должен быть значительный прирост скорости.Если 3 такта сэкономлено и раньше FPS было 50 кадров в секунду,то получаем: 3*(640*480)*50=46 МГц cэкономленой тактовой частоты процессора или прирост на 7-10 кадров.

MGB совершенно не измеряет скорость PutImage!!!

Чтобы измерять FPS я написал специальную программу.Она пишет (в левом верхнем углу окна)сколько кадров было выведено за секунду.Просто для стопроцентной однозначности попробуй измерить спомощью нее.Вот код программы:


use32
org 0x0

db 'MENUET01'
dd 0x1
dd START
dd I_END
dd 0x1000+640*480*3+0x1000
dd 0x1000
dd 0x0
dd 0x0
;ќв  Їа®Ја ¬¬  ®ЇаҐ¤Ґ«пҐв FPS ¤«п PutImage а §¬Ґа®¬ 640*480 ЇЁЄбҐ«Ґ©
;-----------------------------------------------------------
;----------¤«п вҐбвЁа®ў ­Ёп ­ ¦¬ЁвҐ Їа®ЎҐ«------------------
;-----------------------------------------------------------
; ўв®а Їа®Ја ¬¬л Andrew_programmer ®­ ¦Ґ Ђ­¤аҐ© €Ј­ в쥢
;б Ё¤Ґп¬Ё Ё«Ё ў®Їа®б ¬Ё Є® ¬­Ґ ЇЁиЁвҐ ­  e-mail polynki@mail.ru
START:
mov eax,40
mov ebx,111b
int 0x40
;use only keybord of scan-codes
mov eax,66
mov ebx,1
mov ecx,1
int 0x40
pm:
mov eax,47
mov ebx,5*65536
mov ecx,[frame]
mov edx,100*65536+5
mov esi,0xffffff
int 0x40
;
still: mov eax,23
mov ebx,1
int 0x40
cmp eax,1
je drawwin
cmp eax,2
je key
cmp eax,3
je button
jmp still
;-------------------------------------------
key:

mov eax,2
int 0x40
cmp ah,57
je fpst
cmp ah,1
je close
jmp still
;close program and exit
close: mov eax,-1
int 0x40
;main cycle(fps)

fpst:
call clock
mov eax,[time]
mov [time1],eax
mov [frame],0
cycle:
mov eax,7
mov ebx,0x1000
mov ecx,640*65536+480
mov edx,3*65536+20
int 0x40
add [frame],1
call clock
mov eax,[time]
sub eax,[time1]
cmp eax,100
jl cycle
jmp pm
;-------------------------------------------
button:mov eax,17
int 0x40
cmp ah,1
jne still
mov eax,-1
int 0x40
;--------------------------------------------
drawwin:mov eax,12
mov ebx,1
int 0x40
;аЁб㥬 ®Є­® § ¤ ў п ўбҐ ­Ґ®Ўе®¤Ё¬лҐ 梥в 
mov eax,0
mov ebx,50*65536+650
mov ecx,50*65536+500
mov edx,0x02AABBCC
mov esi,0x805080d0
mov edi,0x005080d0
int 0x40
;ЇЁиҐ¬ § Ј®«®ў®Є ®Є­ 
mov eax,4
mov ebx,5*65536+5
mov ecx,0x10ddeeff
mov edx,name
mov esi,7
int 0x40
;аЁб㥬 Є­®ЇЄг § ЄалвЁп ®Є­ 
mov eax,8
mov ebx,(650-19)*65536+12
mov ecx,5*65536+12
mov edx,1
mov esi,0x6688dd
int 0x40
jmp still
;---------------------------------------------------------------------------
;get time in 1/100 sec
clock: mov eax,26
mov ebx,9
int 0x40
mov [time],eax
ret
;------------------------------------------------------------------
time dd 0
time1 dd 0
frame dd 0
name db 'testfps'
I_END:

andrew_programmer
ты плохо читаешь перечитай мои слова - глюк на обоих комперах!

Извини,если обидел.
Про глюк я знаю(после твоих слов я его проверял и исследовал),но что-то отношусь к нему пренебрежительно(в 50% перетаскиваний эконки не рисуются поверх окна).
А MGB действительно не измеряет скорость обновления экрана(FPS).

тестировал MGB...под ядром 0.72 грандиозный отрыв от Колибри 3, Колибри 4 уже начало подтягиваться...надо возвращаться к схеме шлюзов прерываний, а не к шлюзам задач...Халявин, может, напишем вариант 65 или 72 ядра, только с 3-м кольцом для приложений? просто при каждом прерывании сейчас 104 байта как минимум в TSS копируется туда -сюда....тормознуто...Вилле изучал шлюзы задач, а мы отдуваемся(((

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

Я читал IRC лог (больше 13 тысяч строчек ) и статьи о MeOS в "Мой компьютер" и здесь суммирую пожелания Вилле и украинского автора:
- перейти от GDT к LDT для каждого процесса
- увеличить лимит количества процессов (сейчас в MeOS он равен 255, а например в Syllable - больше 16 миллионов).
Поскольку Андрей занимается переделыванием ядра, то возможно он сможет это сделать.