Subject: Re: Apollo keyboard driver for hp9000/4xx series - feedback
To: mike smith <miff@spam.frisbee.net.au>
From: Michael Joosten <joost@c-lab.de>
List: port-hp300
Date: 04/06/1997 04:30:30
> No, I was seeing this regularly almost right up until Jason
> released the latest snapshot.  Make sure you have pmap.c version
> 1.28 and locore.s 1.67.  There may be other files that are relevant,
> but I'm fairly sure they're where it was at.  (No CVS access *mumble*)

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?

OK, I get keys from the Apollo keyboard - really fine. So I went out and made a
mess with a soldering iron, some spare stuff and an old DN3000 keyboard. And
finally, this worked - Even more finally, I convinced a Sparc to use both its
ttys and dump me the stuff with a hexdump program. But it took tiimmmeee... I
absolutely hate serial stuff, whoever invents new sockets for this belongs into
the deepest hell !!!!! I attached the poor victim to an DN3500 of our trash
rooms and ...

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:

Controls from box to keyboard:
0xff 0x00: Reset to cooked mode
0xff 0x01: set to raw mode, key up/down events
0xff 0x12 0x21: query keyboard for status/version/model, whatever
Returns: <ff 12 21> then in ASCII:
	3-@<CR>
	2-0<CR>
	SD-03980-MS<CR>
	0xff 0x00   <-- current status of keyboard, cooked or raw

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

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.

Further stuff:
ff 21 81   beep on
ff 21 82   beep off

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

Buttons:
last button up is always f0 00 00
left down:   e0 00 00
middle down  b0 00 00
right down   d0 00 00
left+ middle a0 00 00
middle+right 90 00 00
left+right   c0 00 00

That is, first byte > 0x80 is mouse event, where the first byte contains the
button code and the next two singned byes encode the motion.

According to Apollo docs,  they have had three different keyboards. So I'd
guess the cooked mode is rather an emulation of their first one. Note that the
function keys in 'cooked' mode also have up/down, as opposed to the rest. Note
that RETURN is mapped to 0xcb.

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....
Stopped at      _Debugger+0x6:  unlk    a6

I hit 'c':db> c
syncing disks... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 

Of course, it did not sync the disk, and when doing its fsck during the next
reboot, everything seemed to be munged:
Automatic boot in progress: starting file system checks.
/dev/rsd0a: INCORRECT BLOCK COUNT I=641 (2 should be 0) (CORRECTED)
/dev/rsd0a: INCORRECT BLOCK COUNT I=647 (0 should be 2) (CORRECTED)
PARTIALLY ALLOCATED INODE I=660
/dev/rsd0a: UNEXPECTED INCONSISTENCY; RUN ffs MANUALLY.
Automatic file system check failed; help!
Enter pathname of shell or RETURN for sh: 
# fsck /dev/rsd0a
** /dev/rsd0a
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=1289 (96 should be 32)
CORRECT? [yn] y
<and so on....>
PARTIALLY ALLOCATED INODE I=3879
CLEAR? [yn] y

PARTIALLY ALLOCATED INODE I=3889
CLEAR? [yn] y

<and so on>

Next attempt:
root on sd0a swap on sd0b
root file system type: ffs
init: not found
panic: no init
Stopped at      _Debugger+0x6:  unlk    a6
db> 

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