Path: utzoo!utgpu!water!watmath!clyde!ima!bbn!bbn.com!cosell
From: cosell@bbn.com (Bernie Cosell)
Newsgroups: comp.sys.amiga.tech
Subject: Keymap description files
Message-ID: <25646@bbn.COM>
Date: 11 Jun 88 20:24:53 GMT
Sender: news@bbn.COM
Reply-To: cosell@BBN.COM (Bernie Cosell)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 48

I need some help understanding the format of the keymap files.  This is the
result of a bit of a difference of opinion about software engineering between
me and William Hawes: I think conman should be tailorable in spirit like the
"stty intr <this> susp <that>" on UNIX, he thinks that the tailoring should
be done in the keymap (in essence, bending what you type to fit his
assignments, instead of bending his assignments to fit what you type).
Anyhow... I find myself in the position of having to figure out how to do
some tweaking of my keymap.  I poked around some and read through the RKM
section on the keymap stuff, but no hint of what disk format the "setmap"
command expects to eat.  Is that documented somewhere?

I've spent most of this afternoon puzzling through a binary dump of a keymap
file and I've figured out some stuff.  One of the most interesting is that
there is a qualifier that is not documented in my edition of the RKM: 0x80
seems to mean "this is a dead key, ignore it".  Also, the RKM has not a peep
about what "KCF_DOWNUP" might mean. [NB: this from Vol1, my copy of Vol2
where I could try to check out console.doc or some such is, unfortunately,
misplaced, and (again!  Weep!!) Mortimore has let me down].

Another cute thing I've discovered is that the disk file "high" maps
all cover the keys 0x40 to -->0x77<-- (NOT 0x67 -- _that_ threw me for
a while until I figured out why the lengths of things weren't working
out! -- is that an artifact of the setmap command, or do the actual
GetKeyMap() arrays actually go for an extra sixteen keys?)

Anyhow, if someone knows the full format of the disk file, I'd be
appreciative.  Thanks!

What I've figured out so far:

the file begins with 0x2a bytes which I haven't the foggiest about.
then the combined length of the following struct keymap, together with the 8
pointed-to arrays and the strings.  The struct+arrays+strings is followed by
what seems to be 8 bytes of the "name" of the keymap.  And then what looks
like a bunch of 4byte numbers to the end of the file.

The keymap+array has its pointers relocated in an interesting way:
You set up the pointers so that the chunk of storage with the arrays in it
begins with zero (so the "address" of the struct-keymap, itself, would be
-0x20), then you offset the whole mess by the position in the file (which is
to shift the struct+array+strings by 0x2E).  So, the actual address of the
first byte of the first array is 2E.  The arrays come in the order Lo
capsable, high capsable, low repeat, high repeat, low keytypes, high
keytypes, low keymaps, highkeymaps.
   __
  /  )                              Bernie Cosell
 /--<  _  __  __   o _              BBN Labs, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_             cosell@bbn.com