Помогите с видеобуфером
я начал учить асм, но что-то не пойму как отображать данные напрямую в видеобуфер.по калашниковской рассылке прога отжирает 100% у проца и все!объясните пожалуйста как все это сделать.
В текстовом режиме адаптера (это в реальном режиме процессора - адресация через сегмент:смещение) видеопамять проецируется на адресную область ОЗУ с 0B800:0000. На символ - 2 байта: ASCII-код и маска (цвет символа и фона). В графическом режиме - весь сегмент 0A000, вроде бы. В зависимости от режима - разное кол-во байт под один пиксел (в память записывается его цвет).
Описывается в Зубкове (что-то вроде "Программирование на языке Assembler под DOS, Windows и Unix"). + Здесь (именно здесь - на codenet`е) положил исходничек прожки, к-рая работает в графическом режиме.
P.S.: Ничего лучше Калашникова и Зубкова я не видел (хотя есть несколько книжек подходящих под роль справочников)
P.P.S.: прикрепляю прекрасный справочник по ASM`у для реального режима и не только...
я начал учить асм, но что-то не пойму как отображать данные напрямую в видеобуфер.по калашниковской рассылке прога отжирает 100% у проца и все!объясните пожалуйста как все это сделать.
Научись вопросы задавать.
а вот почему такой код проц из калашникова на 100%
загружает проц и вообще ни чего не выводит:
CSEG segment
org 100h
Begin:
mov ax,0B800h
mov es,ax
mov di,0
mov al,1
mov ah,31
mov cx,2000
Next_face:
mov es:[di],ax
add di,2
loop Next_face
mov ah,10h
int 16h
int 20h
CSEG ends
end Begin
Скажи пожайлуста и если не трудно напиши какой нибудь пример простой типа то-же вывода 1 символа на экран(тока простой а то я асм тока начал учить).Сзаранее спасибо
а вот почему такой код проц из калашникова на 100%
А откуда ты знаешь про загрузку процессора? Из Windows? Ничего странного в этом нет - NTVDM обычно забирает все неиспользованное время процессора.
В чистом DOS то же самое. Реальный режим поэтому и называется реальным, потому что всегда использует процессор полностью, даже если гоняет пустые циклы.
Скажи пожайлуста и если не трудно напиши какой нибудь пример простой типа то-же вывода 1 символа на экран
Вуаля:
.model tiny
.code
org 100h
Begin:
mov ax,0B800h
mov es,ax
mov di,0
mov al,1
mov ah,1
mov cx,2000 ;80*25
;
Next_face:
mov es:di,ax
add di,2
dec cx
jnz Next_face
ret
end begin
Собственно говоря, я мало что изменил:
1) loop у меня работал как-то странно: сразу занулял CX. Это дело я AFD смотрел (многие считаю его лучшим 16-разрядным отладчиком, и я целиком присоединяюсь к их мнению). Т.о. loop заменил на dec и jnz, хотя это бред какой-то;
2) пример Калашникова с неточностью. Надо так:
CSEG segment
assume CS:CSEG,DS:CSEG,SS:CSEG
org 100h
Begin:
;...
CSEG ends
end Begin
Директива assume связывает для ассемблера сегментные регистры с определённым директивой segment сегментом. Assume не изменяет значений сегментных регистров (они выставляются при передаче управления программе), но позволяет ассемблеру отслеживать правильность ссылок.
Я же использовал упрощённый способ определения сегментов (.code);
3) Директива .model определяет используемую модель памяти. Самая простая - tiny: код, данные и стек располагаются в одном сегменте до 64K;
4) Вместо int 20h использую ret. Там есть несколько нюансов, но ret спокойно можно использовать, если ты не извращаешься с CS, к чему со временем ты обязательно придёшь :) (хотя бы в резидентах);
5) САМОЕ ВАЖНОЕ: в XP это нифига не пашет. Для проверки DOS с дискетки грузил :), т.к. на харде как месяц убил за ненадобностью. В WinЭх работать, наверно, будет. НО интересная особенность: если это написать на встроенном асме в BP (Borland Pascal), то всё работает! Был ещё ряд подобных прецедентов. Т.е. эмуляция реального режима для Паскаля происходит как-то по-другому. Может что martsoft что подскажет? Хотя я не понимаю, как это NTVDM забирает все ресурсы проца: во-первых это Виртуальная машина => не такая тупая и, вообще, сама работает в защищённом режиме; во-вторых у меня никаких 100% taskmanager не показывает, если я правильно понимаю ситуацию.
Кстати, в реальном режиме режиме прога проц не полностью использует: он ещё аппаратные прерывания отслеживает; :):):)
P.S.: часть того, что я написал есть в HELPASM`е, но ВСЁ есть в Зубкове. Намёк очевиден. :) Если жалко денег (а на такое, имхо, жалеть не стоит) или сложно купить (тираж действительно маленький), то можно в сети найти (сам скачивал chm`ку). Но там лажа: жутко урезанный он. :(
Собственно говоря, я мало что изменил:
1) loop у меня работал как-то странно: сразу занулял CX.
Что интересно, я тоже пробовал изменил цикл, т. к. он мне не понравился. Пробовал repe stosw и repe stosw - наобум лазаря, так сказать, т. к. совершенно забыл, которая из команд что делает. На практике же никаких изменений.
Я же использовал упрощённый способ определения сегментов (.code);
По большому счету один хер, как задавать регистры. Но приведенные примеры без труда линкуются в .com.
У меня аналогично - в XP не работает. Правда, перезагружаться было влом. Есть идея попробовать создать не com-файл, а exe и покэспериментировать с ним. Ведь BP создает именно exe.
Ситуацию понимаешь правильно. Однако, на практике так выходит, что приложения вроде самого BP или DOS Navigator заставляют систему жрать все свободное процессорное время.
Сам подумай - NTVDM, какой бы умной она не была, не может определить, что делается в недрах DOS-программы, даже если та гоняет пустой цикл. А программы его гоняют - цивилизованные средства ожидания событий появились в DOS только с введением DPMI. Да и не все программы поддерживают последние нововведения... Поэтому в 100%-й загрузке процессора при выполнении хотя бы одной DOS-задачи нет ничего странного.
Что интересно, я тоже пробовал изменил цикл, т. к. он мне не понравился. Пробовал repe stosw и repe stosw - наобум лазаря, так сказать, т. к. совершенно забыл, которая из команд что делает. На практике же никаких изменений.
По большому счету один хер, как задавать регистры. Но приведенные примеры без труда линкуются в .com.
У меня аналогично - в XP не работает. Правда, перезагружаться было влом. Есть идея попробовать создать не com-файл, а exe и покэспериментировать с ним. Ведь BP создает именно exe.
Ситуацию понимаешь правильно. Однако, на практике так выходит, что приложения вроде самого BP или DOS Navigator заставляют систему жрать все свободное процессорное время.
Сам подумай - NTVDM, какой бы умной она не была, не может определить, что делается в недрах DOS-программы, даже если та гоняет пустой цикл. А программы его гоняют - цивилизованные средства ожидания событий появились в DOS только с введением DPMI. Да и не все программы поддерживают последние нововведения... Поэтому в 100%-й загрузке процессора при выполнении хотя бы одной DOS-задачи нет ничего странного.
Ну, дожили. Теперь add cx,2 не то же самое, что inc cx inc cx! Что вы программите на ассемблере, еще используя прямой доступ к видеопамяти в среде Windows XP??? Я не уверен, что она обрабатывает обращения к этим адресам. Используйте VMWare или какой-нибудь dosbox. На худой конец - в чистый DOS с дискетки:-)
Теперь add cx,2 не то же самое, что inc cx inc cx!
Замечание ко мне? Я вроде ничего про CX не говорил. stosw сама уменьшает CX при каждой итерации.
Скажите пожалуйста, а как тогда работает программа вроде DOS Navigator? Она пишет напрямую в память - это точно.
Насколько я знаю, несмотря на то, что во всех учебниках по программированию было написано, что прямой вывод в видеопамять - дурной тон, многие программы пользовались именно этим способом вывода, т. к. работа через BIOS была безнадежно медленна.
Замечание ко мне? Я вроде ничего про CX не говорил. stosw сама уменьшает CX при каждой итерации.
Скажите пожалуйста, а как тогда работает программа вроде DOS Navigator? Она пишет напрямую в память - это точно.
Насколько я знаю, несмотря на то, что во всех учебниках по программированию было написано, что прямой вывод в видеопамять - дурной тон, многие программы пользовались именно этим способом вывода, т. к. работа через BIOS была безнадежно медленна.
1. это к тем, кто loop на dec cx jnz заменяет
2. Windows XP обрабатывает обращение к памяти, но перерисовывает это все только через определенные интервалы времени. Разверни окно своего приложения на весь экран, увидишь, что вывод через средства BIOS гораздо быстрее, чем прямой вывод в видеопамять. Необходимо, чтобы программа не завершалась через 3 мс, тогда и увидишь результат своей работы. Или запускай все это из command.com. А вывод через BIOS потому быстрее, потому что эти операции может выполнять видеодрайвер в XP.(Конечно же, в чистом real mode все не так)
А вывод через BIOS потому быстрее, потому что эти операции может выполнять видеодрайвер в XP.(Конечно же, в чистом real mode все не так)
В real mode все с точностью до наоборот.
Кстати, только сейчас, в Windows, начинаешь понимать старые учебники по программированию, где написано о возможной совместимости с будущими ОС. ;)
Это касается и ввода с клавиатуры. Программы, использующие чтение символов через BIOS, останавливаются во время ввода с клавиатуры, и не забирают 100% времени процессора. Только вот если приходится еще отрабатывать и мышку, то...
В real mode все с точностью до наоборот.
Кстати, только сейчас, в Windows, начинаешь понимать старые учебники по программированию, где написано о возможной совместимости с будущими ОС. ;)
Это касается и ввода с клавиатуры. Программы, использующие чтение символов через BIOS, останавливаются во время ввода с клавиатуры, и не забирают 100% времени процессора. Только вот если приходится еще отрабатывать и мышку, то...
В BIOS есть функция, проверяющая, есть ли в буфере клавиатуры что-нибудь. В C вариант: bioskey;
Она возвращается незамедлительно. Я писал целый GUI для DOS, все работало одновременно, и мышь, и клавиатура. Если знаний недостаточно - обратитесь к help'ам, man'aм, google и прочим вещам.
Ну, дожили. Теперь add cx,2 не то же самое, что inc cx inc cx! Что вы программите на ассемблере, еще используя прямой доступ к видеопамяти в среде Windows XP??? Я не уверен, что она обрабатывает обращения к этим адресам. Используйте VMWare или какой-нибудь dosbox. На худой конец - в чистый DOS с дискетки:-)
1)По поводу эмуляции реального режима в WinXP: если из BP запустить ‘Dos Shell’, то всё прекрасно работает, как в чистом DOS`е.
2)Тогда уж и занулять только xor`ом! :) (на тему add)
В BIOS есть функция, проверяющая, есть ли в буфере клавиатуры что-нибудь. В C вариант: bioskey;
Она возвращается незамедлительно.
Так я не про то. С чтением клавиатуры проблем нет. А вот для мыши нельзя выставить системную фунцию "ждать событий от мыши".
Я писал целый GUI для DOS, все работало одновременно, и мышь, и клавиатура.
Ну, вот. Значит, на практике приходилось сталкиваться... Не уверен, что опрос устройств делается одновременно, скорее, попеременно. Вспомни, как выглядит цикл определения новых событий... Уверен, что именно он и забирает все время процессора.
Хотя, в DOS наверняка есть цивилизованный способ передачи неиспользуемых тактов процессора системе. Например, NC 5.0 (для DOS) вроде как не вызывает 100% загрузки процессора, хотя поддерживает и мышь, и клавиатуру...
1)По поводу эмуляции реального режима в WinXP: если из BP запустить ‘Dos Shell’, то всё прекрасно работает, как в чистом DOS`е.
Проблема наверняка в том, что программа завершается быстрее, чем Windows успевает обновить содержимое ее окна, как указал Envel. Вроде как похоже на правду. Сам не проверял - на работе приходится работать ;)
Проблема наверняка в том, что программа завершается быстрее, чем Windows успевает обновить содержимое ее окна, как указал Envel. Вроде как похоже на правду. Сам не проверял - на работе приходится работать ;)
Все так и есть.
А на счет "ждать события от мыши" - это в DOS легко реализовать, установив свой обработчик для мыши (см. функции прерывания 33h), по крайней мере я делал так. Так же можно установить обработчик прерывания от клавиатуры. И никаких циклов не будет, не придется ждать. А на счет цикла получения новых событий - он не возвращается, пока не получит событие:-) То время, пока система ждет появление событий, отдается другим процессам:-) Так в многозадачной среде, иначе бы первая запущенная программа зависла на этом цикле.
А на счет "ждать события от мыши" - это в DOS легко реализовать, установив свой обработчик для мыши (см. функции прерывания 33h), по крайней мере я делал так. Так же можно установить обработчик прерывания от клавиатуры. И никаких циклов не будет, не придется ждать. А на счет цикла получения новых событий - он не возвращается, пока не получит событие:-)
Мне в свое время приходилось программировать на Turbo Vision (BP), а также очень сильно копаться в его исходниках. Там тоже вроде устанавливались обработчики прерываний, только вот цикл опроса устройств все равно присутствовал. По твоим же словам, разработчики Turbo Vision поступили неверно. Это вполне может быть, Borland часто грешит простотой в жертву всему остальному, но мне все-таки стало интересно.
Не мог бы ты привести пример кода, получающий события от мыши и клавы? Я же попробую раскопать, как это было реализовано в TV...
В многозадачной среде все намного проще, т. к. это уже запрограммировано системой (если только не приходится собственную ОС писать).
Да и вообще, событийная модель управления программами намного проще укладывается в многозадачную, нежели однозадачную среду.
И еще... Наш флуд возник из-за вопроса, почему DOS-приложения в NTVDM забирают все свободное время процессора... Где-то (уже не помню где) проскальзывало сообщение, что в реализации NTVDM есть баг, в результате которого приложения DOS не отдают неиспользованные кванты процессора системе. Даже вроде был патч, исправляющий неисправность. Никто не в курсе, что и как?
Это давно достаточно было, я даже вроде скачивал что-то, но у меня не заработало... Уже не помню, короче.
Хочется просто найти научное объяснение имеющегося феномена. ;)
Мне в свое время приходилось программировать на Turbo Vision (BP), а также очень сильно копаться в его исходниках. Там тоже вроде устанавливались обработчики прерываний, только вот цикл опроса устройств все равно присутствовал. По твоим же словам, разработчики Turbo Vision поступили неверно. Это вполне может быть, Borland часто грешит простотой в жертву всему остальному, но мне все-таки стало интересно.
Не мог бы ты привести пример кода, получающий события от мыши и клавы? Я же попробую раскопать, как это было реализовано в TV...
В многозадачной среде все намного проще, т. к. это уже запрограммировано системой (если только не приходится собственную ОС писать).
Да и вообще, событийная модель управления программами намного проще укладывается в многозадачную, нежели однозадачную среду.
И еще... Наш флуд возник из-за вопроса, почему DOS-приложения в NTVDM забирают все свободное время процессора... Где-то (уже не помню где) проскальзывало сообщение, что в реализации NTVDM есть баг, в результате которого приложения DOS не отдают неиспользованные кванты процессора системе. Даже вроде был патч, исправляющий неисправность. Никто не в курсе, что и как?
Это давно достаточно было, я даже вроде скачивал что-то, но у меня не заработало... Уже не помню, короче.
Хочется просто найти научное объяснение имеющегося феномена. ;)
Про баг тоже слышал, может это и правда.
Пример кода выложу, если будет время. Суть в том, чтоб обработчики прерываний сами вызывают обработчики соответствующих событий, а также определяют, кого вызывать.
Суть в том, чтоб обработчики прерываний сами вызывают обработчики соответствующих событий, а также определяют, кого вызывать.
Это для DOS??
Это для DOS??
Ну, а для чего же еще ты станешь обработчик прерывания свой устанавливать??? Там, правда, свои тонкости.
Ну, а для чего же еще ты станешь обработчик прерывания свой устанавливать???
А, ну да. Чушь спорол.
Там, правда, свои тонкости.
Хм, вот и было бы интересно взглянуть, что в TV было сделано не так.