Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : AMD:News, Press Releases and Information Only! -- Ignore unavailable to you. Want to Upgrade?

To: Paul Engel who wrote (1632)	10/22/1997 8:40:00 PM
From: Ali Chen	Read Replies (1) \| Respond to of 6843

Paul, That's basically how the Keyboard Works,. No, it is not how it works TODAY. I did not realize that a MIT PhD could be so lazy and/or dumb. What you have described here is the 8088 XT keyboard, about 20 years old, not even PCjr or AT. That is exactly I am telling to everyone - you are outdated, and judge modern trends from ancient prospective. Which rotten guide did you use to compile your essay? Needless to say, you failed miserably. Let me walk you through many of your mistakes. 1. You "forgot" to mention that the very essential function of contemporary keyboards (so-called MF-II type, not even AT) is to send defferent MAKE and BREAK codes for each key, with so-called "precodes", and much more complex code sequences. This allows to recognize several simultaneously depressed keys, left and right control keys, etc. - very useful feature for games... 2. You forgot that the keyboard-to-host protocol is bi-directional, so the keyboard can be reprogrammed to certain extent. At least, the host can use RESEND and about 16 other commands to keyboard, to provide no-loss protocol... I am not even talking here about debouncing firmware, N-key rollover, and watch-dog techniques. 3. The Keyboard Clock/Keyboard Data lines are fed into some logic circuitry in the chip set that, when Data is present... You apparently are not aware that this "circuitry" is comprised of one more microcontroller of 8742 type on motherboards (as a separate chip or integrated), with rather complex duties including full-duplex support for serial keyboard protocol, as well as PS/2 mouse port. 4. The data comes in serially, clocked into the I/O port by the Keyboard Clock line. The CPU reads each bit, then stores it in an internal register until 16 bits are read - two bytes. "Little" mistake again, Dr. Endel. The keyboard data format is still 8-bit (+parity, start, and stop). CPU reads nothing yet, all transfers and serial-to-parallel conversions are done by that microcontroller. The 16-bit will appear much later.. 5. This Hardware Interrupt causes the main processor (CPU) to stop (after completing its current instruction) and branch to a software routine in the BIOS chip (software Interrupt 16Hex). This routine, the Keyboard Routine, is then executed by the main CPU. You recompile your old book with many mistakes here. Hardware interrupt routine and INT16h routine are completely different and serve different functions. Using the hardware IRQ1 (INT09), one BIOS routine reads data from the 8742 controller, analyses them, converts into ASCII, and put into a special ring buffer, now in that legacy 16-bit format you mentioned before. Completely different and asynchronous routine, the DOS INT16 service, is called from old DOS software and provides these 16-bit words from that ring buffer until empty. And remember, the CPU never stops when receiving an interrupt... 6. Application programs receive their keyboard input by simply reading the value in the AL (or AL & AH) registers following a Keyboard-generated Interrupt. Actually, I expected next to see now those characters appear on your screen and combine into your dirty posts. You stopped in half a way. I suppose you do not use the outdated DOS applications anymore but mostly use the power of M$ Windows95, do you? However, at the times when you studied XT computers, there was no Windows yet. Therefore I am afraid to ask about your "vision" of keyboard virtual drivers, DPC (deferred procedure calls), scallable fonts, and other Microsoft Windows goodies that happen before a character appears on your screen. I assume you are taking a beginning class in PCs and need this information to help pass a homework problem or exam. No, I am taking practical exercises. As you see, there is not too much you can help me with. Now, "expert", do you feel to hit the road, off AMD threads?

To: Paul Engel who wrote (1632)	10/22/1997 11:17:00 PM
From: greenspirit	Read Replies (1) \| Respond to of 6843

WOW PAUL! Can you do my homework too :-)

To: Paul Engel who wrote (1632)	10/24/1997 1:25:00 PM
From: Aaron Cooperband	Read Replies (2) \| Respond to of 6843

Paul - Re: keyboard Wow! Very impressive. If anyone was still in doubt as to your knowledge, this posting should have put that to rest. Aaron

To: Paul Engel who wrote (1632)	10/25/1997 7:30:00 PM
From: Scott D.	Read Replies (3) \| Respond to of 6843

Your keyboard description is pretty close, but when you say, "The CPU reads each bit", you need to clarify that it is the 8042 CPU logic in the chipset that handles this function. The x86 CPU only gets one interrupt per byte of keyboard data. Also, the shift key state is handled by the keyboard driver (or rom code for dos). The keyboard does not give special treatment the shift/control keys. For example, if your keyboard repeat rate is set to max and you hold down a shift key, you get 30 interrupts per second. Cap locks led turns on only because the keyboard driver sends the proper command in response to detecting the cap locks closure. Given that the keyboard/mouse is the least documented legacy pc hardware device, your description is impressive. I wonder if Ali realized this when picking the keyboard? Ali can now explain to us how the mouse works.