Path: utzoo!utgpu!water!watmath!clyde!burl!codas!ufcsv!gatech!udel!mmdf
From: V050KY8G@ubvms.bitnet
Newsgroups: comp.os.minix
Subject: RE: How do you turn on the AT's LEDs?
Message-ID: <1038@louie.udel.EDU>
Date: 24 Jan 88 20:45:19 GMT
Sender: mmdf@udel.EDU
Lines: 75

As you probably know, the PC or AT keyboard is accessed through a couple of
ports, one of which is a "command" port.  Commands to the keyboard include:

Command name			Opcode to send to command port (hex)

reset				FF
resend				FE
NOP				FD to F7 and F2 to EF
Set Default			F6
Default Disable			F5
Enable				F4
Set Typematic Rate/Delay	F3
(this is auto-repeat)
Echo (diagnostic aid)		EE

Finally, the one you are curious about:

Set/Reset Mode Indicators	ED

Basically, the CPU is responsible for keeping track of the states of the 
lights, for you cannot query the keyboard as to what the current states 
are, but merely jam out a new set of LED settings.  This will (no doubt)
involve using the capslock and numlock variables in the tty driver where, 
if the code out of the scan code translate table is a certain code, the 
value of the variable is logically (not bit-wise) inverted.  After any one 
of these inversions take place, all (3 of them, if you wanna include scroll 
lock) values will have to be "assembled" into what IBM calls an "options  
byte" which is the "argument" to the mode LEDs command.  The options byte 
is laid out as follows:

Bit position	LED

7 to 3		(reserved)
2		Caps Lock
1		Numeric Lock
0		Scroll Lock

Handshaking is as follows:

When keyboard command port would be ready to receive a command code, send 
the EDh command
Keyboard sends 'ACK' (stops "everything" waiting for the options byte)
Send options byte (0 in bit to extinguish, 1 in bit to light up)
Keyboard sends 'ACK'

If the keyboard receives another valid command byte instead of the options 
byte, the lights remain "untouched," and that command is processed
(Set/Reset command is aborted).

I haven't looked deep enough in the docs how exacly to do the actual 
keyboard I/O, but I remeber exactly where I saw this, because I wanted to 
add this to MINIX also, but never stuck with the project long enough to get 
it done.  I figure this is enough to get someone (???) started, as long as 
this someone can fill in the details of the port addresses and so on.


As a separate matter, the problem I have been having with MINIX is the hard 
disk routines.  I am running (currently 1.1) on a SAM 3001 (AT compatible) 
with a jumper installed for 10MHz and a Segate 20Mb.  Ocasionally, without 
any warning or apparent cause, the winchester task is waiting for a reply 
from hardware, which it never gets.  I added an additional function key 
(F10) dump to the kernel and determined that this occurs when the disk 
controller's sector buffer is expecting to be serviced (data needs moving).  
Maybe this has been fixed in V1.2, maybe not.  Help?

Incidentally, I saw a message earlier about someone having problems getting 
a hard disk to work with MINIX on partition 2.  MINIX would not access any 
partitions on this system (Samsung) greater than 17 blocks big until the 
hard disk driver was modified in a coupla places in the initialization code 
(the particular mods I did were to change a coupla logical ORs ("||") to 
bit-wise ORs ("|") where the disk controller was being told about the 
number of sectors per track and so on.  This disk has 17 sectors per track, 
so therefore MINIX must have been using track 0 and 1 on any given 
cylinder, and getting errors when the disk controller didn't "think" the same 
way that MINIX "thought").