8042 keyboard controller
ATarpai
The old question again, because I don't find anything on the web and
there is so much confusion on what a real (or emulated) 8042 did: has
anybody any information, assembly listing, document on the executable
code in the ROM of these little microcontrollers? How exactly the AT
or PS/2 implemented it? Is it possible - when I find one of these
chips an a mobo from the 'stoneage' - to take it out and read out the
contents of the rom? It would be really exciting I think...
Cheers,
halicery
Rod Pemberton
news:581c80fe-4075-4c1a...@g25g2000yqn.googlegroups.com...
>
> The old question again, because I don't find anything on the web and
> there is so much confusion on what a real (or emulated) 8042 did:
>
There is? ...
An 8042 is UPI used as a microcontroller. In the IBM AT, it's used as a
keyboard controller. It replaced the 8255 PPI and related logic of the PC
and XT. It also added the A20 enable line.
The AT Model M 101 key keyboard used a Hitachi 6805 microprocessor and it
communicates with an Intel 8042 microcontroller on the AT motherboard.
The PC/XT Model F 83 key keyboard (supposedly) used a 8048 microcontroller
(or a variant of it) and it communicates with an Intel 8255 PPI on the PC or
XT motherboard.
> [...] has
> anybody any information, assembly listing, document on the executable
> code in the ROM of these little microcontrollers?
>
The MESS project may have the ROM for the 8042. (links below)
> How exactly the AT
> or PS/2 implemented it?
>
There is lots on the 8042. There are 8042 datasheets and PC schematics
which show how an the 8042 was connected electrically. The later should be
in the IBM PC, XT, AT, and PS/2 technical reference manuals.
E.g., try here for the 8042 datasheet:
http://www.datasheetarchive.com/pdf/getfile.php?dir=Datasheets-14&file=DSA-277879.pdf&scan=
E.g., you might try here for the PC schematics:
http://www.mcamafia.de/pdf/pdfref.htm
> Is it possible - when I find one of these
> chips an a mobo from the 'stoneage' - to
> take it out and read out the
> contents of the rom?
>
That's called a "dump".
> It would be really exciting I think...
>
The MESS emulator project has a list of acquired and needed dumps for IBM PC
clones. It seems they already dumped the AT's 8042, see "PC AT Model 5170"
in the "IBM Dumps Needed" section:
http://mess.redump.net/dumping:wanted?do=show
I'm not sure if the dumps are included with the MESS project or found
elsewhere... The main MESS project page is here:
http://www.mess.org/
This link shows the inside of an IBM Model F 83 key PC/XT keyboard:
http://geekhack.org/showwiki.php?title=Island:5492
It uses a "8401"... I can only assume it's a custom 8048 or variant.
This link shows the inside of an IBM Model M 101 key AT keyboard:
http://www.pcworld.com/article/147939/inside_the_worlds_greatest_keyboard.html
Although unclear, image 11/15 shows it uses the 6805 Hitachi. On of the
links further below, there is a photograph that shows the 6805 clearly.
Photo's of the internal circuit boards on these page shows IBM used
microntrollers from different manufacturers:
http://ps-2.kev009.com:8081/ohlandl/keyboard/Keyboard.html
http://sandy55.fc2web.com/keyboard/model_m_trivia.html
Rod Pemberton
Maxim S. Shatskih
I'm not sure it has any ROM.
The chip is of 1980ies, and originated in PC/AT.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
James Harris
> Hi all and good evening!
> The old question again, because I don't find anything on the web and
> there is so much confusion on what a real (or emulated) 8042 did: has
I agree about the confusion.
> anybody any information, assembly listing, document on the executable
> code in the ROM of these little microcontrollers? How exactly the AT
> or PS/2 implemented it? Is it possible - when I find one of these
> chips an a mobo from the 'stoneage' - to take it out and read out the
> contents of the rom? It would be really exciting I think...
The data sheet for a particular device should say the rom can be read.
Here's someone doing just that on what is apparently a controller from
the same family.
http://www.youtube.com/watch?v=l0uXiTLOtVM
He might be quite pleased to help if someone contacted him asking for
details of the circuit or microcontroller code. It's just a little bit
difficult to get these from the video!
James
wolfgang kern
"ATarpai" wrote:
My not so old but dusty book from Intel (Oct1987 orderNr: 210393-004)
show that a real 8042 once were an 8-bit Slave Microcontroller with
2K ROM or EPROM, 256 byte RAM, 16 I/O-pins, 90 UPI instructions, ...
and ...
it got a security-bit which disable all external access of the EPROM.
But what you may find in an even 20 year old PC as a 8042-styled
keyboard controller may 'just behave similar', so you may not find
any ROM at all.
PC XT,AT,PS/2 keyboard controllers are well described in RBIL(ports)
and modern chipsets just emulate the bahaviour of this anchient chip.
__
wolfgang
ATarpai
But I think I was not clear to explain my problem, let me throw some
light here by showing you something! I'm aware of the history,
schematics, data sheets and programming, I've spent enough fun time
with it, and the following confused me: (I uploaded an older document,
it's internal so sorry for my language!;) This "dump" is from MS
virtual pc, not real hardware, but the behaviour was there.. can I
excpect this from hardware too?
http://halicery.com/osdev/kbaux.doc
I wrote a ps/2 kb/aux interrupt handler. Everything went well until I
stressed it with key strokes and mouse movements in the same time: the
mouse started to jump around or worse, it hang. Why? To debug this I
had to turn off interrupts, just poll on 0x60 and record the result.
It was confusing/shocking: a 3-byte mouse packet could interrupt a 2-
byte key-break code! It didn't happen vica versa (mouse packets have
never been interrupted by key make/break codes).
I didn't find answer to this 'priority' problem. So, there is
something behind, which is left undocumented, non-standard or just an
expected behaviour? What we know is only the 'programming interface'
of a complex microcomputer (as the 8042 was called that time) through
a few IBM PC-compatible registers, not the internal description of its
operation. MCU, UPI, like the CPU they all have memory to store and
execute the program, a ROM in the case of the 8042, but where is the
assembly program for it? That was my question. This interface is of
course emulated in today's Super I/O chips, but do they result in the
same behaviour as above?
I was just thinking.. "if you were a 8042" and had 2 bi-directional
serial devices connected to you (with clock/data pairs) plus the cpu
bus.. what would your program do? Probably looping and waiting on some
change on some pins, then do the transfer to the 'other side', signal
interrupts, but how exactly? And what if multiple requests happen - as
it does in my example - in the same time, how the firmware/hardware/
emulation handles them in time? Is it the same?
That's why I'd be eager to read some firmware dump! :) I've searched a
bit more and I don't think we can simply dump it when the protection
bit is on.. wolfgang is right. And I've never managed to find a single
dump-file on the net for the 8042 either :(
Thank you for the support, James, I'll check out the youtube link when
I have more time.
Attila
wolfgang kern
ATarpai wrote:
...
> http://halicery.com/osdev/kbaux.doc
the download bounced ..?
> I wrote a ps/2 kb/aux interrupt handler. Everything went well until I
> stressed it with key strokes and mouse movements in the same time: the
> mouse started to jump around or worse, it hang. Why? To debug this I
> had to turn off interrupts, just poll on 0x60 and record the result.
> It was confusing/shocking: a 3-byte mouse packet could interrupt a 2-
> byte key-break code! It didn't happen vica versa (mouse packets have
> never been interrupted by key make/break codes).
...
Your observation is right, except the vice-versa may happen as well,
just rare seen because of difference in speed ...
PS/2-mice may have gone to the museum already yet, but I had no problem
with IRQ-handling and the shared port 60h. It seemed that hardware knew
if it issued an IRQ01 or an IRQ12. So the KBC may transmit keyboard and
mouse bytes interleaved. 'the packets' come in bytewise, and every IRQ
deliver only one byte, so the IRQ-routines shall 'not wait' for a packet
to be complete.
Both of my IRQ-(01,12) routines start with a read of port 60h and
reenable interrupts right after.
__
wolfgang
Maxim S. Shatskih
> something behind, which is left undocumented
Get Windows Driver Kit, it has pnpi8042 sample. Read that source code.
ATarpai
> ATarpai wrote:
>
> ...
>
> >http://halicery.com/osdev/kbaux.doc
>
> the download bounced ..?
I don't know why this happens, but there is nothing more in the
document anyway.
Thank you for the answer! Actually this is how my driver works too (it
should, because of these peripherials are really slow), and that
solved the 'interleaved' problem. But I still had difficulties when
trying to send commands (such as set the leds) in the meantime,
because of the ACK bytes. I'll try to fix this.
Attila
Rod Pemberton
>
> http://halicery.com/osdev/kbaux.doc
>
Apparently, WK helped identify your issue. I'm seeing the same thing as
you. So, apparently that's the fix. Thanks WK! I'm going to have to get
some lessons from him... ;)
Anyway, I was just about to post before your reply came across... I've
replied to some other questions too.
> I wrote a ps/2 kb/aux interrupt handler. Everything went well until I
> stressed it with key strokes and mouse movements in the same time: the
> mouse started to jump around or worse, it hang.
>
Yes, I experienced this too. I'm developing on real hardware. The PC I was
using is now non-functional. I'm not sure if the new machine exhibits that
same behavior.
Now, my mouse and keyboard IRQ routines start by with the same routine which
reads the data and then identifies the data as keyboard or mouse from the
read status. Then, a mouse specific or keyboard specific routine is called
to save the data into the appropriate buffer. I thought I had made an error
when coding because of this behavior, but I never found it. One attempt to
fix this issue was to switch to using specific EOI's instead of generic
EOI's. But, I continued to experience this issue even with specific EOI's.
I haven't worked on my OS in a few years. So, I haven't looked into this
further. It seems, I have a clear EOI for IRQ2 within IRQ2 (master IRQ for
IRQ12), as well a clear EOI for IRQ2 within IRQ12. That could be an
issue... E.g., possibly clearing EOI for IRQ2 twice? Since I haven't run
it in a while and my original test PC is dead, I'm not sure if IRQ2 ever
triggers or not. I know IRQ12 and IRQ1 triggered. IRQ1 should clear master
PIC EOI and IRQ12 should clear master and slave PIC EOIs.
> Why?
>
I suspected this was due to interrupt priority, and/or repeated interrupts.
The keyboard (IRQ1) has higher priority than the mouse (IRQ12 and indirectly
IRQ2). I.e., keyboard should be able to interrupt mouse sequences. But,
IIRC, I too was seeing the mouse interrupt keyboard data. It was worse with
an older slow keyboard and current mouse. IIRC, I suspected an IRQ1 was
being triggered for each piece of keyboard data, instead of just once for
the entire sequence.
> To debug this I
> had to turn off interrupts, just poll on 0x60 and record the result.
I also have a note in some earlier code that I also accidentally enabled
interrupts prior to the mouse and keyboard initialization routines, and the
bad initializations prevented the correct data from being received.
> It was confusing/shocking: a 3-byte mouse packet could interrupt a 2-
> byte key-break code!
>
Yes, I experienced that too. See earlier comments.
> I didn't find answer to this 'priority' problem. So, there is
> something behind, which is left undocumented, non-standard or just an
> expected behaviour? What we know is only the 'programming interface'
> of a complex microcomputer (as the 8042 was called that time) through
> a few IBM PC-compatible registers, not the internal description of its
> operation.
Yes.
> MCU, UPI, like the CPU they all have memory to store and
> execute the program, a ROM in the case of the 8042, but where is the
> assembly program for it? That was my question.
The MESS project may have it. It's probably not publicly available. If it
is, it'd be in the technical reference manuals. In theory, it works much
like the earlier 8255 and related electronic circuitry. I suspect that much
of the code the 8042 contains is probably for AT to XT character set
translation.
> This interface is of
> course emulated in today's Super I/O chips, but do they result in the
> same behaviour as above?
Can you run your OS on another PC? Family? School? Library? Work? (be
careful...)
> This interface is of
> course emulated in today's Super I/O chips, but do they result in the
> same behaviour [...]?
>
They should be compatible with the original AT, but James Harris (and I) has
found some incompatibilites with things like reading the A20 via keyboard
controller on newer machines:
http://aodfaq.wikispaces.com/machine+characteristics
Rod Pemberton
Rod Pemberton
news:afb4ff88-3c99-4575...@e26g2000vbz.googlegroups.com...> > [ATarpai keyboard controller]
>
> http://www.youtube.com/watch?v=l0uXiTLOtVM
>
> He might be quite pleased to help if someone contacted him asking for
> details of the circuit or microcontroller code. It's just a little bit
> difficult to get these from the video!
>
What? ...
The video description has a link to his webpage:
http://www.sbprojects.com/projects/8049spy/8049spy.htm
He provides a schematic and software to read the microcontroller. I don't
see the microcontroller code, but the AT's ROM code would be different from
a Korg synthesizer anyway. I.e., ATarpai needs to build the circuit and
connect a PC, once he's found and desoldered an AT keyboard controller...
"Spy's" schematic has a few simple parts in addition to the mcu:
1 4Mhz crystal - series
2 22pf capacitors
2 100nf capacitors
2 10Kohm resistor
1 1Kohm resistor
1 7805 voltage regulator
1 BC 549 NPN transistor
The resistors are for voltage pull-up. The 100nf capacitors are for voltage
smoothing. The 22pf capacitors are to help the crystal to oscillate. The
BC549 NPN is used in Europe. He could probably use a BC548 instead. A
2N3904 NPN would need to be used in the US. He should be able to get those,
or close enough values at Radio Shack, Digi-Key, Mouser, or Jameco, etc. if
ATarpai is in the US.
"The voltage regulator is needed here, because you also need a 12V supply to
connect to the EA line of the 8049, which places it in programming mode."
Wow, the 8049 works just like an EEPROM...
Rod Pemberton
Rod Pemberton
news:ib5tvd$rma$1...@speranza.aioe.org...
> [snip]
> [circuit parts]
>
> He should be able to get those,
> or close enough values at Radio Shack, Digi-Key, Mouser, or Jameco, etc.
if
> ATarpai is in the US.
>
Actually, if he's picking up parts retail, e.g., Radio Shack, he'll need to
desolder and save the mcu crystal too. You want to desolder it quickly too,
not too much heat, and don't apply any pressure to the crystal's legs when
using it, or it may not resonate.
RP
wolfgang kern
Attila <ATarpai> wrote:
...
|Thank you for the answer! Actually this is how my driver works too (it
|should, because of these peripherials are really slow), and that
|solved the 'interleaved' problem. But I still had difficulties when
|trying to send commands (such as set the leds) in the meantime,
|because of the ACK bytes. I'll try to fix this.
Oh yeah, the damned LEDs need special treatment and may respond
only after several (2..5) milli-seconds delay.
I took the whole LED-control out of the IRQ-routine by just telling
the OS that on of CAPS NUM SCROLL were pressed and have the OS send
the command during next IDLE.
Whatsoever I read about sending commands to the keyboard recommend
to disable the mouse and opposite until the command is acknowledged.
I checked without this advice and figured:
The mouse may come out of sync if an 0xFA is interpreted as part of
a packet, it will resync automatically anyway but have jumped once.
No issues with the keyboard because all packets which start with
a value above 0xE1 shouldn't be interpreted as keystrokes.
I set only ACK/ERR bits in a system variable for debug-purpose.
__
wolfgang
ATarpai
wrote:
> "Rod Pemberton" <do_not_h...@notreplytome.cmm> wrote in message
I'm sitting in Norway btw, and all this sounds very interesting, but
unfortunately I don't have time for such a project.. maybe 10 yrs
ago ;).
But back to the root, although I'm enjoying the topic very much as
usual and learned a lot again from you, all I wanted was 'just' a link
to a 8042 rom dump listing or something to peek into the exact
operation (according to Intel it was both Phoenix and Award who wrote
industry firmware for the first 8042 controllers: "Microprocessor
Peripherals UPI- 41A/41AH/42/42AH User's Manual, Table 1-3").
Anyway, I'll stop here in peace..
Thanks everybody,
Attila
Rod Pemberton
>
> [...] all I wanted was 'just' a link
> to a 8042 rom dump listing or something
> to peek into the exact operation
>
Sigh... (Is he listening to me?)
I suggested checking the MESS rom's. There are MESS rom images for the IBM
PC AT 5170. The 1503033.bin file is the ROM dump of the AT's 8042 keyboard
controller.
http://www.emunews.eu/files/mess/ibm5170.zip
You'll still have to do some work on your own, i.e., locate a disassembler
for the 8042/8049 or whatever...
Rod Pemberton
ATarpai
wrote:
> "ATarpai" <tarpa...@gmail.com> wrote in message
Oh yes, I'm listening, but I was too busy lately to answer - sorry: I
was working on disassembling and understanding this fine piece of code
from 1983...
FYI, anybody who might be interested, here is the commented file at
its present state, http://www.halicery.com/8042/8042_1503033.TXT, read
the 8-bit assembly and take a journey back in time :)
Thanks again for the link!
James Harris
...
> Oh yes, I'm listening, but I was too busy lately to answer - sorry: I
> was working on disassembling and understanding this fine piece of code
> from 1983...
> FYI, anybody who might be interested, here is the commented file at
> its present state,http://www.halicery.com/8042/8042_1503033.TXT, read
> the 8-bit assembly and take a journey back in time :)
I haven't read it in detail but just from the concept it's a great
piece of work. The details are there for anyone who wants to look.
When I look at it in Firefox or IE I have to scroll right some
distance to read some lines. I could copy and paste into a text editor
so it's not a big issue but maybe you could make it easier to read in
a browser?
James
ATarpai
wrote:
Hi,
Thank you for the inspiration and the remarks!
And yes, the word-wrap problem has been overlooked.. I use Chrome,
which wraps line automatically.
Here is a solution for the other browsers I've found by style-ing
<PRE> (Copyright Tero Karvinen www.iki.fi/karvinen):
pre {
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+ */
}
..so I inserted some HTML at the beginning of the text file, saved as,
it's now working fine in IE6 and IE8 (please test it with Firefox).
The new link: http://www.halicery.com/8042/8042_1503033_TXT.htm
atarpai
James Harris
Yes, that works. I'm surprised how complicated it is. Maybe Chrome is
one step ahead!
James
ATarpai
.. or doesn't follow stricly the rules ;) and does what makes sense :)