Michael Joosten wrote:
> 
> Funny, the GENERIC one worked, even when I added your stuff to it. I recompiled
> TEST, and got a panic in ffs_statfs. Very wierd. So I enabled some stuff from
> GENERIC in TEST, and it worked. Huh?

Likewise, huh?
 
> Well, after I found out that stty 1200 raw works, but I also need cs8  (here
> Herb is wrong: the keyboards use 8 bits !). And so I got some results:

I just sucked out what the bootprom stuffs in and concluded that
they use 1200bps, even parity and 8 databits, with a divisor slightly
off what one would expect for an 8MHz clock.  (Using a 'correct'
divisor for an 8MHz clock results in framing errors.  I think their
UART implementation is a hair simplistic.)
 
> Controls from box to keyboard:
> 0xff 0x00: Reset to cooked mode
> 0xff 0x01: set to raw mode, key up/down events

Cool.

> 0xff 0x12 0x21: query keyboard for status/version/model, whatever

That's three bytes?  Damn, here I was thinking they used a single-
byte command/response set.  Now I have to rework my command handling
to deal with that.  Great. Looks like there must be quite a bit
to their protocol if they need that much talking.

> these commands are echoed by the keyboard, so one can easily check its
> existence...(send ff00 -> listen for ff00 back)

It's worth noting that it doesn't echo the command back until it's
got the whole thing, ie. if I send 0xff then wait, I hear nothing. 
Then I send 0x01, and I get 0xff 0x01 back together.  The UART FIFO's
true size still eludes me, but I think it's actually fairly deep (maybe
as much as 8 bytes, certainly at least two).
 
> key up/down events are as follows: the keys are simply numbered form 01 to
> whatever, from left to right, line-wise. But there are some holes, I think.
> key down is <key-up-code> | 0x80. The keyboard does autorepeat by inserting
> 0x7f after the key up code, and fast ! Perhaps at 10Hz, I think.

Can you see if there are any Aegis commands to change the keyboard
repeat rate?  That'd be handy.  I was initally going to use
cooked mode for "normal" console mode and 'scancode' mode for
direct device access.  Not so sure now.

> Mouse:
> left : f0 ff 00   where the second byte is signed, is lower if moved with
>                   higher speed
> right: f0 01 00   ditto, 01-06 for hight speeds
> 
> up:    f0 00 ff   ditto for the third byte
> down:  f0 00 01   ditto

That's almost it; you didn't mention the escape sequence.  My 
notes on the mouse data read :

 * - Mouse activity shows up inline in 4-byte packets introduced with
0xdf.
 *   Byte 1 is   1MRL0000    where M, R, L are the mouse buttons, and 0
is
 *                           down, 1 is up.
 *   Byte 2 is 2's complement X movement, +ve to the right.
 *   Byte 3 is 2's complement Y movement, +ve is up.

If you see anything in the lower half of the button-byte, I'd
like to know about it (some protocols like this put extra mickey
bits in there for finer resolution).  This looks _lots_ like the
Mouse Systems mouse protocol 8)
 
> So far about the good news. Bad is, that I left the box with TEST kernel
> running and, when I came back:
>
> Apr  6 00:52:15 hp400 /netbsd: apkbd0: cfcr 1b div 81a0
> Apr  6 00:52:22 hp400 /netbsd: apkbd0:  rxrdy 6d
> apkbd0:  rxrdy 6d
> Apr  6 00:52:22 hp400 /netbsd: apkbd0:  rxrdy 6d
> Apr  6 00:52:22 hp400 /netbsd: apkbd0:  rxrdy 6d
> panic: dmago: count > MAXPHYS                       <------ very mystic....

Erk, that looks like memory corruption/hardware conflict
somewhere.  I hope it's not my fault 8(

> Halleluja! And now I've to dig out the SLC with netbsd on it to boot and
> reinstall..... @%$^%@$#^%

Shit. Sorree.  I've left mine up overnight without any
problems.

--
Mike Smith  *BSD hack  Unix hardware collector
The question "why are the fundamental laws of nature mathematical"
invites the trivial response "because we define as fundamental those
laws which are mathematical".  Paul Davies, _The_Mind_of_God_