Index
> OS Construction > OS Development?Goto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
baldr 30 May 2010, 19:16
MeshNix wrote: What is the table? Is it the keymap? Code: db 0, 27, "1234567890-=", 9, 8; 00…0F db "qwertyuiop[]", 13, 0, "as"; 10…1F db "dfghjkl;'`", 0, "\zxcv" ; 20…2F db "bnm,./" ; 30…35 Probably you may try to correctly ignore (it's not so easy, several keys send quite long sequences, notably Pause) all keys except NumLock and toggle LED properly?  MeshNix wrote: With polling, don't I only wait for the device if it is busy? |
|||
30 May 2010, 19:16 |
|
|
cod3b453 30 May 2010, 21:00
As baldr hinted, a single key will produce between 1 and 8 bytes to read from buffer depending on the sequence as you read. You can find tables of these values here: http://www.computer-engineering.org/ps2keyboard/scancodes2.html . So you check for special 0xE0/0xE1 codes then the break (key up) code 0xF0 then you do lookup on the rest [this changes with layout].
|
|||
|
30 May 2010, 21:00 |
|
|
adroit 31 May 2010, 01:19
Thanks, cod3b453. These are for extended scan codes I believe.
Keys like "Q","W","E", ... "\" can be ignored but special keys like Caps Lock and NumLock, etc. have to be handled specially. Is that what your saying? -------------- Would the lookup be something like this? Code: ... jmp start: keymap_table: db 0, 27, "1234567890-=", 9, 8; 00…0F db "qwertyuiop[]", 13, 0, "as"; 10…1F db "dfghjkl;'`", 0, "\zxcv" ; 20…2F db "bnm,./" ; 30…35 char db ? ; store lookup char start: in al,60h mov bx,keymap_table ; mov al,al ; just to simplify xlatb mov [char],al ... I just realise that the keymap is arranged according to the key press hex value. cod3b453 wrote: [this changes with layout] |
|||
|
31 May 2010, 01:19 |
|
|
cod3b453 31 May 2010, 12:49
Well, you need to handle all cases correctly so that you read exactly the right number of bytes for the scan code - reading allows another byte to be put on the keyboard buffer for other key events; if you read too many/too few you will get unpredictable results.
The scan codes are the same for physical keys but the keys and therefore the keymap will alter with language layout e.g. english use "qwerty", german use "qwertz"; simply load different tables for different layouts without any more code. |
|||
|
31 May 2010, 12:49 |
|
|
ManOfSteel 31 May 2010, 15:46
The keyboard driver is basically a very boring long routine full of comparisons and jumps.
Start by checking a few status bytes such as the acknowledge code, then test if you have a make code or a break code. If it's a make code, check for locks, shift, controls, etc. and switch on "status variables" (for later use). Check for 0xe0 and 0xe1 extended keys. The rest should now be normal keys. Just check your "status variables" and xlat the keys accordingly using different tables if for example caps lock is on or shift is pressed. If it's a break code, check for shift, alt, etc. and switch off the "status variables". That's more or less it. |
|||
|
31 May 2010, 15:46 |
|
|
adroit 01 Jun 2010, 17:29
Okay (thanks )
 . Do I HAVE TO set the driver so that if an extended key is pressed it is has to handle that key, or can I leave for later  ? |
|||
|
01 Jun 2010, 17:29 |
|
|
edfed 01 Jun 2010, 18:59
for exetended keys, you should remember special scan code, quit interrupt and wait for next scan code.
instead of threading the key as a single byte, you should thread it as multiple bytes. that's all. |
|||
|
01 Jun 2010, 18:59 |
|
|
adroit 02 Jun 2010, 00:50
Thanks edfed. I think I will ignore keys like print, insert until I get a full grasp on the whole keyboard driver thing. But I am still confused with the interrupt setup. I have done it.
Code: mov word [es:09h*4],KbdHandler mov [es:09h*4+2],cs Does this mean that when ever a key is pressed, the handler will be invoke, or do I have to use: Code: int 09h |
|||
|
02 Jun 2010, 00:50 |
|
|
baldr 02 Jun 2010, 07:12
MeshNix,
That code is good for RM (if cs:KbdHandler is a valid 16:16 pointer to handler). Whenever keyboard sends something, IRQ1 will be fired and if it isn't masked, processor will perform the same routine as for int 09h (which, as you've said, corresponds to IRQ1). |
|||
|
02 Jun 2010, 07:12 |
|
|
ManOfSteel 02 Jun 2010, 12:34
MeshNix, you should never call an IRQ manually. It's called automatically by the hardware. Instead, within the IRQ routine, you should store the key in a known memory location and setup a software interrupt that will read that memory location for keys. Do you remember BIOS interrupt 0x16? Well, you should have a similar thing for your OS.
|
|||
|
02 Jun 2010, 12:34 |
|
|
baldr 02 Jun 2010, 16:56
ManOfSteel,
He can't call IRQ, unless special hardware involved. He can call IRQ handler, though. Under circumstances that makes perfect sense. |
|||
|
02 Jun 2010, 16:56 |
|
|
ManOfSteel 02 Jun 2010, 17:06
baldr wrote: He can't call IRQ, unless special hardware involved. He can call IRQ handler, though. What I meant. baldr wrote: Under circumstances that makes perfect sense. What circumstances are we talking about? I can't see any use for that. The IRQ handler is called after a hardware event, and a software interrupt retrieves the data, whether it's a keyboard keycode, mouse coordinates, sector read, etc. |
|||
|
02 Jun 2010, 17:06 |
|
|
baldr 02 Jun 2010, 18:15
ManOfSteel wrote: What circumstances are we talking about? |
|||
|
02 Jun 2010, 18:15 |
|
|
ManOfSteel 02 Jun 2010, 19:15
Yes I did. But I thought we were talking about constructing modern OS, not emulating ones that belong right here along with the Morris worm.
 |
|||
|
02 Jun 2010, 19:15 |
|
|
adroit 02 Jun 2010, 23:25
 MOS
(Sorry I am a bit interrogative when getting information on a technical subject) 
baldr wrote: Whenever keyboard sends something, IRQ1 will be fired and if it isn't masked What do you mean by if it isn't masked? ManOfSteel wrote: MeshNix, you should never call an IRQ manually. It's called automatically by the hardware. Instead, within the IRQ routine, you should store the key in a known memory location and setup a software interrupt that will read that memory location for keys. Do you remember BIOS interrupt 0x16? Well, you should have a similar thing for your OS. Great, so as long as I have the handler code for the keyboard in offset 09h*4, when IRQ1 is generated it will read the code from that offset? _________________ meshnix |
|||
|
02 Jun 2010, 23:25 |
|
|
Tyler 02 Jun 2010, 23:55
MeshNix wrote:
To mask the IRQs is to tell the PIC not to call your ISR. To mask an IRQ, you set the IRQ's corresponding bit in port 21h for the first 8 and a1h for the second 8. (Note: int 9==IRQ 1) Here's more on IRQs. MeshNix wrote:
No, you put a pointer to the handler code there. I think(NOT sure) that the first word holds the segment and the second holds the offset. |
|||
|
02 Jun 2010, 23:55 |
|
|
adroit 03 Jun 2010, 01:52
Tyler wrote: To mask the IRQs is to tell the PIC not to call your ISR. To mask an IRQ, you set the IRQ's corresponding bit in port 21h for the first 8 and a1h for the second 8. (Note: int 9==IRQ 1) Here's more on IRQs.  complicated stuff!
Tyler wrote: No, you put a pointer to the handler code there. I think(NOT sure) that the first word holds the segment and the second holds the offset. Huh? Doesn't es:0x09*4 store the offset of the label for the handler Then, es:0x09*4+2, store the segment for that offset. So: Code: seg = es:0x09*4+2 off = es:0x09*4 ; when int 09h is invoke, wouldn't it be similar to this: call seg:off |
|||
|
03 Jun 2010, 01:52 |
|
|
Tyler 03 Jun 2010, 02:02
I assume you're using real mode since it looks like you're patching the IVT. If, say you're int 9 handler is at 500h:0, then you would patch the word at 9*4 with 500h(segment) and patch the word at 9*4+2 with 0(offset). When interrupt 9 is called, the processor reads the segment and offset from 9*4(which you just patched) and executes a "jmp 500h:0".
|
|||
|
03 Jun 2010, 02:02 |
|
|
adroit 03 Jun 2010, 02:11
Okay. So 500h:0 is a pointer to the handler code itself.
|
|||
|
03 Jun 2010, 02:11 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|