Доброе время суток =) не сказать что очень компетентен в данном вопросе, так что если есть ошибки и не точности прошу поправить =) Собственно вопрос : если до того как стандартный код прерывания от клавиатуры обработает значения регистров контроллера клавиатуры, это значение считает посторонний код (именно считает и никаких изменений) то после возврата управления коду прерывания, он сможет так же получить эти значения и корректно обработать прерывание, или они (значения регистров контроллера) обновляются ??? т.е что обновляются это конечно понятно =)) только вот если действия произойдут в указанном порядке стандартное прерывание выполниться как и без постороннего кода??
Я не пробовал, но судя по тому, что в ДОСе на прерывание клавы вешали дофигища цепочечных обработчиков, которым тоже был интересен скан-код клавишы, то, скорее всего, его можно считывать вплоть до EOI. Если я не прав, поправьте)
Думаю, врядли. Если что то и получится, то не будет корректным решением. Установленный 0-й бит в порту 64h, свидетельствует о том, что порт данных содержит данные. Как я думаю, ты можешь считать данные из порта данных (60h) без какого либо вредительства, но котроллер может заготовить в своем буфере для передачи несколько байт данных, например, сканкоды правого шифта, стрелки и т.д. два байта и более. Что бы контроллер клавы выложил следующий байт в порт, необходимо передернуть блокировку, 7-й бит в управляющем порту (61h). После передергивания - снова анализ бита 0 в порту 64h. Т.е. передергивание бита блокировки своего рода квитирование приема данных от контр. клавы обработчиком прерывания. Да, в DOSе много чего вешалось на 9-й вектор. Но работать совместно с обработчиком прерываний не получится. В частности, я когда то делал резидент, который "корректировал" ASCI-коды. Но делал он это уже непосредственно в буфере клавы, что в сегменте данных BIOS. Т.е. управление по int 09h передавалось на мой обработчик, который тут же передавал упраление на стандартный обработчик, а после того как он обработает - управление снова попадало ко мне, тогда я лез в буфер и проверял его содержимое. Но это в DOSе. Под другими осями так низко спускаться не приходилось.
Barbos, заглянешь на форум вечером, есть вопросы по написанному но сначала хочу еще разок прочесть инф-ю в книге? (чтобы по возможности не спрашивать глупостей=)
Barbos Для продвинутых контролеров была команда "Fetch" - она считывала код, оставляя все нетронутым для "других". Я так понимаю речь именно про это. Она для этого и была сделана, чтобы делать цепочку обработчиков - логгеры например.
В 60-м порту содержится код последней нажатой клавиши и насколько я помню, его значение не меняется до следующего вызова IRQ1. Многие резиденты, например русификаторы, садятся перед оригинальным обработчиком и ничего, всё работает. Необходимо только помнить, что постоянно действующие обработчики прерываний не должны выполняться слишком долго чтобы не было проблем.
я кодил под стандартный. код последней нажатой клавиши может быть несколько байт. Щас все в деталях не помню, но например, нажатие на стрелочку - 8042 выдает префикс расширения, код Shift, еще что то, причем что - зависит от состояния NumLock. Там набирается как минимум 4 байта. Вобщем, считав один байт из 60h - рановато делать какие либо выводы. см. архив выше, резидент тоже садится перед стандартным обработчиком, но прежде чем что то делать вызывает стандартный. "руссификация" происходит именно в буфере BIOS. Еще могу поделиться собственным обработчиком клавы. Код для защищенного режима, 32 бита, компиляция MASM 6.1a, глюков пока не замечал. Код (Text): Align256 macro ;выравнивание на границу 256 байт if (($ - @CurSeg) mod 256) ne 0 org (($ - @CurSeg) and (not 255))+256 endif endm KbrdData segment ;буфер клавиатуры ;каждый код символа в буфере представлен в виде двух байт, первый - сканкод, второй - ASCII Align256 KbrdBuff db 256 dup (?) ;непосредственно буфер BegKB db 0 ;голова (указатели внутри буфера) EndKB db 0 ;хвост KbrdData ends KbrdCode segment KbrdHandler proc far push EAX in AL,64h test AL,1 ;есть ли в выходном буфере 8042 данные jz short @@popEAX ;переход, если в буфере пусто push DS ;сохраняем используемые регистры push EBX push EDX mov AX,selDataKrn ;загрузить селектор сегмента данных mov DS,AX ;получаем смещение байта, начиная с которого будем складывать коды movzx EBX,byte ptr EndKB add EBX,offset KbrdBuff @@ReadKB: in AL,60h ;читаем скан код call KbrdInterpreter ;получение ASCII-кода по сканкоду ;вход: AL - сканкод ;выход: carry, тогда AH - ASCII, AL - сканкод ; not carry - сканкоду соответствующего ASCII нет jnc @@RSBK mov word ptr [EBX],AX ;кладем в буфер add EndKB,2 ;подвигаем "хвост" @@RSBK: ;передернуть блокировку клавы in AL,61h mov AH,AL or AL,80h out 61h,AL mov AL,AH out 61h,AL ;если в буфере есть еще что то, то повторяем чтение in AL,64h test AL,1 jz short @@BufEmpt add BL,2 jmp short @@ReadKB @@BufEmpt: pop EDX pop EBX pop DS @@popEAX: mov AL,20h ;неспецифическое окончание прерывания out 20h,AL pop EAX iretd KbrdHandler endp KbrdCode ends И, на закуску, пару манов, которых мне хватило.
файлик прикрепляться не захотел. Вот версия в инете http://www.csd.uoc.gr/~hy325/spring-2006/docs/8042.pdf
