Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
Damien

16.03.2013, 13:55
 

Inhibition of Cap lock key and Num lock key (Developers)

Hi,

According to you, what is the best way to ignore entirely these 3 specific keyboard entries, which light up a led : caps lock, num lock, screenPause ?

I know that these keys are specific as their treatment takes some CPU time, which is precisely my problem. So is it possible for MSDOS to ignore this ?


Thanks.

bretjohn

Homepage E-mail

Rio Rancho, NM,
16.03.2013, 16:41

@ Damien
 

Inhibition of Cap lock key and Num lock key

> According to you, what is the best way to ignore entirely these 3 specific
> keyboard entries, which light up a led : caps lock, num lock, screenPause?
>
> I know that these keys are specific as their treatment takes some CPU time,
> which is precisely my problem. So is it possible for MSDOS to ignore this?

DOS doesn't normally handle the keyboard, it lets the BIOS do it instead. The keys you specifically mentioned are not normally processed by DOS at all, and I've never seen a BIOS that would let you "ignore" them. But, DOS will let you redefine key(s) to do something other than what the BIOS normally does.

If you're unwilling to write a custom program yourself, there are a couple of options you can try. The first is the FreeDOS KEYB program:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/2.01/

I'm not sure if it will let you redefine a key to do nothing at all, but it should let you redefine a key to do something innocuous (like a <Shift> key or <Escape> key or something).

You could also try my SCANCODE program:

http://bretjohnson.us

SCANCODE is sort of like a programmable macro facility, that let's you "type" keys into other programs in response to different input parameters (timing, text {dis}appearing on screen, time of day, other keystrokes, etc.). One of the things it can do is effectively change one key into another, so it could be used to change your special keys into something innocuous as well, such as beeping the speaker. It can also be used to effectively disable the entire keyboard for a period of time, though I'm not sure that's what you're after.

Since timing is your main concern, your best option is probably to write a custom program.

Damien

16.03.2013, 21:34

@ bretjohn
 

Inhibition of Cap lock key and Num lock key

Thank you for your answer bretjohn,

Your webpage and programs seem interesting and I will look at it.

At the present time I don't know how to write my program as I don't know the nature of the job that the computer does when I press "Pause" for example. Is it running an interrupt routine ?(I havent seen it in the usual interrupts) ? in this case I guess I have to change the IVT. Is it another kind of handling ? then where to modify/cancel the information ?

I will do some reading or test and tell you if I still have my problem :)

bretjohn

Homepage E-mail

Rio Rancho, NM,
17.03.2013, 08:47

@ Damien
 

Inhibition of Cap lock key and Num lock key

What <Pause> does is is issue the End-of-Interrupt for IRQ 1 (INT 9) in the hardware, which lets another keystroke be issued. But, it does not actually exit the INT 9 software interrupt handler. The computer stays "stuck" in an INT 9 software loop, but hardware interrupts are reenabled. When another keystroke is entered (any keystroke other than another <Pause>), it exits the software loop and things act normally again.

The timing issues you have with the Lock keys (Caps, Num, & Scroll) are probably just related to delays with the keyboard hardware turning the LED's on and off. The software handling part of the Lock keys just sets a flag in memory, and you wouldn't even notice it from a timing perspective.

To create a program to trap these keys so they don't do anything, or do something else, you will either need to trap INT 9 or INT 15.4F.

Damien

17.03.2013, 13:42

@ bretjohn
 

Inhibition of Cap lock key and Num lock key

> The timing issues you have with the Lock keys (Caps, Num, & Scroll) are
> probably just related to delays with the keyboard hardware turning the
> LED's on and off. The software handling part of the Lock keys just sets a
> flag in memory, and you wouldn't even notice it from a timing perspective.

You are right !
Actually I program under djgpp / allegro. I hadn't checked yet all the keyboard function, but I looked at the manual and I found a simple flag : "key_led_flag"
So, after reading your post, I tried this... and indeed, the lock keys no longer take enourmous cpu time when pressed! (and of course the led doesn't change anymore).


(And in Allegro context the <Pause> key doesn't seem to create problems.)

Thanks.

Back to index page
Thread view  Board view
22049 Postings in 2034 Threads, 396 registered users, 239 users online (1 registered, 238 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum