Hi,
vbbrett wrote:
Thanks alot Brendan! Very Informative post, if I can say so myself. As to my plight: I wish to write a driver for a PS/2 mouse. Correct me if I'm wrong, but serial mice are hardly in date except for old PCs. Would you consider it worth while to include support for and almost outdated device? Though, I suppose that I must implement a serial driver somewhere along the way.....
Serial mice are still in use, but I guess it can depend on which computers your OS supports. On newer computers my OS will allow 2 seperate users per computer, with 2 PS/2 keyboards and 2 serial mice. Most PS/2 mice are designed so that they can be plugged into a serial port (they automatically detect what they are plugged into and behave accordingly).
Because the PS/2 mouse is controlled by the same chip/IO ports as the keyboard it can be difficult to write a device driver for mouse only. If your OS protects IO ports, so that a device driver needs to allocate an IO port before using it then you only one device driver will be able to access the keyboard controller chip IO ports at a time. Also because the keyboard controller chip uses the same input and output buffers for both keyboard and mouse (channel A and channel B) it would be difficult to prevent a keyboard driver from interfering with the mouse driver. To avoid all of this I'd write a single PS/2 driver that handles keyboards and mice.
Initializing the keyboard controller chip:
- allocate resources for both channels (IO ports 0x60 and 0x64, IRQ's 1 and 12)
- set keyboard controller command byte (disable IRQ's and disable both channels)
- perform controller chip self test
- set keyboard controller command byte (enable both channels)
- perform interface tests
- send reset command to channel A
- determine channel A device type from status returned from reset
- send reset command to channel B
- determine channel B device type from status returned from reset
- set keyboard controller command byte (enable IRQ's for used channels, disable unused channels)
Once all this is done you can initialize each device. For keyboards this means setting typematic delay, repeat rate and LED's. Mice will start out as a standard mouse, but by setting the sample rate several times with special values you can change the protocol it uses to enable the scroll wheel, and then (if scroll wheel worked) use another sample rate sequence to enable the 5 button with scroll wheel protocol.
The best PS/2 mouse page I've found so far is:
http://panda.cs.ndsu.nodak.edu/%7Eachap ... mouse.html
vbbrett wrote:
As to the time, and such... I would prefer to get this RTC-whatever-you-call-it time. Also, would you care being more precise about this BIOS ticker? I just get the info direct from the port you mentioned? Is it in any specific format? Does it count? ect,ect. Thanks again for the info.
The BIOS tick timer uses IRQ 0 to increase a counter (at 0x0000046c in memory) 18.2065 times per second (by default). It's not much use in protected mode, but you can re-program the timer chip and write your own IRQ 0 handler.
The RTC (Real Time Chip) keeps track of the current second, minute, hour, day, month, year in hardware. There's a few problems with it though, as some OS's set it to local time (windows) and some set it to UTC (Linux). IMHO it's best to use UTC as it's the same everywhere (which avoids inconsistancies over networks). Unfortunately if a computer is set up to run your OS and windows (dual boot) you'll need to use local time, and there's no way to tell when windows has changed the RTC for daylight savings so your OS's time can be messed up easily.
I've attached code that reads the current time values from the RTC, but I'd recommend downloading this excellent document that covers all PC timing:
http://www.contactor.se/~daniel/links/Pctim003.txt
Cheers,
Brendan
)