Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!gem.mps.ohio-state.edu!ctrsol!lll-winken!brutus.cs.uiuc.edu!psuvax1!rutgers!aramis.rutgers.edu!porthos.rutgers.edu!csirmaz From: csirmaz@porthos.rutgers.edu (Laszlo Csirmaz) Newsgroups: comp.sys.ibm.pc Subject: Re: Turning off NumLock through softwar Message-ID: Date: 15 Nov 89 19:22:28 GMT References: <3932@ur-cc.UUCP> <110200029@uxe.cso.uiuc.edu> <1758@tellab5.TELLABS.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 27 In article <1758@tellab5.TELLABS.COM> fayne@tellab5.TELLABS.COM (Jeffrey Fayne) writes: > In article <110200029@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > > > > > >The interesting question is, why does it work? How does the light > >bulb know that I changed a single bit in memory? > >Doug MCDonald > > The BIOS updates the keyboard (at least the AT keyboards) based > on the 0040:0017 status byte contents. > > Jeff > In fact, the BIOS has all the right to do what it wants. Anyway, MOST of the BIOS I know of uses the 0040:0017 status word to decide whether the NUMLOCK button is toggled or not. The keyboard handling procedure in certain BIOS packages updates the lights every time it gets the control; others do it only when the NUMLOCK button is hit. (This is true for AT only, on XT the keyboard itself switches the lights.) Thus the light for NUMLOCK will surely not go off by running any of the recommended programs, but MIGHT go off after hitting any button (fortunate case) or by hitting the NUMLOCK button (less fortunate case). Or it can do anything it wishes (unfortunate case). Laci