[comp.std.misc] User Interface Standards -- *Keyboards!*

jcb@frisbee.Sun.COM (Jim Becker) (07/14/89)

	There is much clamoring over standardization of just about
everything in the computer industry. People want to have "plug and
play" hardware and consistent software for levels from kernels to
graphical user interfaces. Current efforts appear to have missed a
main difference for a user utilizing different brands of hardware.

	The _Keyboard_ is the main interface mechanism that *all*
computer users utilize to harness their machines, yet the user is
subject to the whims of the manufacturer or the particular hardware
vendor. Each different system potentially has a different keyboard
layout and feel than all others. Manufacturers make decisions (because
of limited resources) of what the keyboard for their products should
be and all subsequent users are stuck with the decisions. [I believe
manufacturers are trying to make the best choice for the user, but
their choice is none-the-less different from the choice of another
manufacturer.]

	In the IBM PC world there are any number of different
keyboards that can be plugged into the box and used. There are lots of
different models from many manufacturers, I believe that they are all
pretty much compatible (I'm not a PC user). But why do I have a
different layout that I have to stumble over with each workstation
level system, as well as (X) terminals and other personal systems
(Amiga, Atari, Mac). [and where did DEC put ESC anyway?]

	My hands are very large, and using something like the Mac is a
nightmare for me, it makes me feel like I'm standing on top of a fence
on one foot trying to type. I am very comfortable typing with an
Amiga, but other keyboards are more difficult. Why can't I use my
Amiga keyboard whereever I want to type. In the past fifteen years of
programming I have had to adjust to numerous different styles, which
has done nothing for my ability to type comfortably.

	In addition to the size of the keyboard is the layout of the
keys, which for a programmer go a lot further than the alpha-numerics.
Each time I have a different keyboard I am subject to different
locations for all those funny keys that make up C and Unix...

	Carpal Tunnel Syndrome, and other maladies, are starting to
affect more and more people that need to use their hands for their
livelihood. Providing a standard interface for all keyboards opens the
option of having a radically different keyboard, one that CTS affected or
otherwise disabled people can use. 

	The original keyboard was designed to slow down typing, not
make it more efficient. The designers had hardware constraints that
are no longer with us.  If we are going to continue to progress in our
interface to the computer the door must be available for change. To
break from the mold of the manufacturer-specific qwerty keyboard there
should be standardization of keyboard hardware/software interfaces so
users can pick and choose the keyboard interface of personal choice.

	I believe this would be one standard all users would embrace!


-Jim Becker	jcb@sun.com


+		These are my own comments, and do not reflect 		+
+		the views of Sun in any way, shape or form.		+

pardo@june.cs.washington.edu (David Keppel) (07/14/89)

jcb@frisbee.Sun.COM (Jim Becker) writes:
>[Standardize *keyboards*!]

There are at least two issues.  One is where the physical keys sit,
and one is the binding of a physical key to a logical character.

In most respects, a lot of keyboards are similar but not *quite* the
same in their placement of the keys.  Examples of major screw-ups
include the `Shift' key on the original IBM-PC keyboard, which was
simply shaped wrong.  It was hard to hit, whether you were using it as
a `Shift' key or as anything else.

The other consideration is key binding.  Note that the (in)famous DEC
keyboard has screwy bindings but pretty normal placement.  The default
key bindings for X have the seqence [Shift .] produce the "<" token,
rather than the default `.'.  With sufficient rebinding capabilities,
any kind of rebinding is possible, in software, to suit the user's
taste.  The only problem is that the key caps may not agree with the
keys being struck.  Somebody has built a prototype of a keyboard that
has LCDs in each keycap, but it is probably expensive and/or
unavailable.  The Xerox solution is to have keymaps that can be
displayed in the corner of your screen.  Cheaper and almost as
effective.

BTW, the DEC keyboard is the result of an effort by DEC to produce an
internationally standardized keyboard.  They had to try to unify
several DOZEN keyboard standards (U.S., English, French, German, and
so on) to give a keyboard that had the minimum change from country to
country. Unfortunately, the ESC and "<" and ">" keys got lost.  After
using the DEC keyboards for a while, the things that bother me are the
placement of the relational operators and the lack of a right-hand
Meta key.  I am not bothered by the ESC key.

Steven Roberts (author of ``Computing Across America'') has a keyboard
built in to the handlebar of his bicycle.  Now *that* is an
alternative keyboard!  He types articles as he cruises the desolate
highways of Kansas...

	;-D on  ( Oh dear, where's the door key? )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo

bob@giza.cis.ohio-state.edu (Bob Sutterfield) (07/14/89)

In article <115518@sun.Eng.Sun.COM> jcb@frisbee.Sun.COM (Jim Becker) writes:
   [... a reasonable discussion of the need to standardize on a good
   keyboard, and to provide plug compatibility so that favorite
   keyboards could be moved to new machines ...]

I find Jim's commentary especially ironic, in light of the Sun type-4
keyboard.  Check recent discussion on comp.sys.sun/sun-spots regarding
this beastie!

   +		These are my own comments, and do not reflect 		+
   +		the views of Sun in any way, shape or form.		+

Apparently they don't!  Why not talk to others at Sun - perhaps you
can persuade them from the inside of the need to provide options to
the widely-beloved (:-) type-4 buttonbox.

dsill@ark1.nswc.navy.mil (Dave Sill) (07/14/89)

The best keyboard proposal I've heard consists of defining a standard
hardware/software interface between the terminal or computer and the
"keyboard".  Of course, there'd have to be codes for all the printable
characters, control characters, meta-characters, cursor movement,
function keys, etc.  It should also include provisions for
non-character-based input, i.e., graphic pointer movement
(mouse/trackball/joystick), and button clicks.

Most equipment would come with a "standard" qwerty keyboard, but third
party vendors would supply various alternatives including smart
keyboards, keyboards with built-in trackballs, digitizing tablets,
voice recognition boxes, handicap input devices (like the one Stephen
Hawking uses), etc.

Serious hacks would carry their keyboards around with them from
machine to machine replacing whatever keyboard was provided.  They'd
never have to worry about adjusting to a different keyboard.

I don't know much about Apple's Desktop Bus, but it may be something
like what I'm talking about.  If so, it sure seems like some third
party vendors are missing an opportunity.  Can anyone familiar with
ADB comment on this?
-- 
-Dave (dsill@relay.nswc.navy.mil)

steve@arc.UUCP (Steve Savitzky) (07/14/89)

In article <13@ark1.nswc.navy.mil> dsill@relay.nswc.navy.mil (David Sill) writes:
>The best keyboard proposal I've heard consists of defining a standard
>hardware/software interface between the terminal or computer and the
>"keyboard".

The two keyboard interfaces I'm acquainted with are PC and ADB, both
of which are serial, but with different protocols.  Both expect the
keyboard to generate different codes for key-down and key-up, which
allows any key to be a shift (a feature which is not very well
supported in the PC or Mac software).

ADB handles arbitrary devices (e.g. mice); the PC can be made to do
the same by mapping them into keystrokes or modifying the keyboard
driver to handle more scancodes.

>Most equipment would come with a "standard" qwerty keyboard, but third
>party vendors would supply various alternatives including smart
>keyboards, keyboards with built-in trackballs, digitizing tablets,
>voice recognition boxes, handicap input devices (like the one Stephen
>Hawking uses), etc.

This is done more with ADB than PC, but there are plenty of alternate
PC keyboards, some of which DO have things like trackballs on them.

>Serious hacks would carry their keyboards around with them from
>machine to machine replacing whatever keyboard was provided.  They'd
>never have to worry about adjusting to a different keyboard.

What I'd like to see is a little box I can carry around with either a
keyboard or a portable PC that lets it emulate arbitrary keyboards and
do arbitrary remapping on the keys.  To be really general you'd have
to be able to program it to handle the oddballs, like Apollo and Sun,
as well as PC's and Macs.

For things like PC's you'd want the ability to map mouse motion and
buttons into different keystrokes for different programs; this would
require some smarts on the PC side.

>I don't know much about Apple's Desktop Bus, but it may be something
>like what I'm talking about.  If so, it sure seems like some third
>party vendors are missing an opportunity.  Can anyone familiar with
>ADB comment on this?

ADB is sort of in the right direction, but because it's Apple it has
all the usual problems:  small market, high price, and weird problems
(e.g. if you unplug your keyboard you risk blowing up your Mac,
because the ADB also includes the "on" button!)  Also the CPU has to
poll it--no interrupts.

>-- 
>-Dave (dsill@relay.nswc.navy.mil)


-- 
  Steve Savitzky     | steve@arc.uucp | apple.com!arc!steve 
  ADVANsoft Research Corp.    |  (408) 727-3357(w) / 294-6492(h)
  4301 Great America Parkway  |  #include<disclaimer.h>
  Santa Clara, CA  95054      |  May the Source be with you!

dsill@ark1.nswc.navy.mil (Dave Sill) (07/15/89)

Newsgroups: comp.std.misc
Subject: Re: User Interface Standards -- *Keyboards!*
Summary: 
Expires: 
References: <115518@sun.Eng.Sun.COM> <13@ark1.nswc.navy.mil> <440@arc.UUCP>
Sender: 
Reply-To: dsill@relay.nswc.navy.mil (Dave Sill)
Followup-To: 
Distribution: 
Organization: Naval Surface Warfare Center, Dahlgren, VA
Keywords: keyboards,standardize,plug-n-play,freedom,ADB

In article <440@arc.UUCP> steve@arc.UUCP (Steve Savitzky) writes:
>ADB handles arbitrary devices (e.g. mice); the PC can be made to do
>the same by mapping them into keystrokes or modifying the keyboard
>driver to handle more scancodes.

Ugh.  I'd rather have no pointer support than kludgey support.

There are (at least) two ways you could go about improving the input
interface.  You could try to provide an intelligent front-end that
would plug into the required existing systems and act like the
original equipment.  That would require a bunch of smarts on the part
of the "keyboard": it would have to be taught how to interface with
each new system.  It would also require a bunch of hardware: logic,
jacks, and cables to allow it to hook up to each system.  After all
this work you still wouldn't achieve a very high level of consistency.
The trackball attached to your keyboard wouldn't be able to act like a
Microsoft Mouse on a PC.  The sole advantage of this approach is that
it doesn't require the development and adoption of Yet Another
Standard.

The other way *does* require a standard, but the payoff is much
greater.  You get a single hardware/software interface that supports a
much wider range of input devices *well*, as well as much more
consistency of operation between systems.

>This is done more with ADB than PC, but there are plenty of alternate
>PC keyboards, some of which DO have things like trackballs on them.

Which unfortunately can't behave like a "normal" PC mouse/pointer.

>What I'd like to see is a little box I can carry around with either a
>keyboard or a portable PC that lets it emulate arbitrary keyboards and
>do arbitrary remapping on the keys.  To be really general you'd have
>to be able to program it to handle the oddballs, like Apollo and Sun,
>as well as PC's and Macs.

Which is what I mentioned above: complex, expensive, unlikely to work
with the next system NeXT or Sun or IBM puts out, and only buys you a
common keyboard layout.

>For things like PC's you'd want the ability to map mouse motion and
>buttons into different keystrokes for different programs; this would
>require some smarts on the PC side.

*That's* another problem altogether: the lack of a single standard
pointer on the PC, and the lack of applications that even support a
pointer.

>ADB is sort of in the right direction, but because it's Apple it has
>all the usual problems:  small market, high price, and weird problems
>(e.g. if you unplug your keyboard you risk blowing up your Mac,
>because the ADB also includes the "on" button!)  Also the CPU has to
>poll it--no interrupts.

Well, at least it's proof-of-concept and a place for those designing
the next generation to look.  I don't see any problem with putting the
"on" button on the ADB, the problem is that it's too easy to
accidentally send garbage when plugs are moved.
-- 
Dave Sill (dsill@relay.nswc.navy.mil)

news@ism780c.isc.com (News system) (07/15/89)

In article <115518@sun.Eng.Sun.COM> jcb@frisbee.Sun.COM (Jim Becker) writes:
>
>
>	The _Keyboard_ is the main interface mechanism that *all*
>computer users utilize to harness their machines, yet the user is
>subject to the whims of the manufacturer or the particular hardware
>vendor.

The Feb. 1868 issue of CACM, page 126, has an article titled "Proposed USA
Standard, General Purpose Alphanumeric Keyboard Arrangement for Information
Interchange".  An editor's note says "The proposed American standard has been
accepted for final letter ballot and concurrent publication by a Subcommittee
of the USA Standards Institute".  I don't know the outcome of that ballot.

However, even if it was approved, it would not help C programers because
the locationsof the characters [ ] \ | { } ^ were not prescribed.

    Marv Rubinstein

steve@arc.UUCP (Steve Savitzky) (07/15/89)

In article <14@ark1.nswc.navy.mil> dsill@ark1.UUCP (Dave Sill) writes:
>In article <440@arc.UUCP> steve@arc.UUCP (Steve Savitzky) writes:
...
>>ADB handles arbitrary devices (e.g. mice); the PC can be made to do
>>the same by mapping them into keystrokes or modifying the keyboard
>>driver to handle more scancodes.
>
>Ugh.  I'd rather have no pointer support than kludgey support.

Obviously, we differ.  I have a PC and a mouse, and the combination
can be made to work well enough for me to prefer it to a PC and no
mouse.  Would it make you feel better if I say "user interface events"
instead of "keystrokes" or "scancodes"?

>There are (at least) two ways you could go about improving the input
>interface.  You could try to provide an intelligent front-end that
>would plug into the required existing systems and act like the
>original equipment.  That would require a bunch of smarts on the part
>of the "keyboard":
...
>                            The sole advantage of this approach is that
>it doesn't require the development and adoption of Yet Another
>Standard.
>
>The other way *does* require a standard, but the payoff is much
>greater.  You get a single hardware/software interface that supports a
>much wider range of input devices *well*, as well as much more
>consistency of operation between systems.

I think you've missed the point.  There is unlikely EVER to be a
standard for keyboard arrangements and keybindings, because the "best"
such arrangement is a matter of preference (i.e. a religious issue).
I would rather have the ability to customize my interface than have
somebody else's idea of the "correct" interface shoved down my throat.

Similarly, keyboard/mouse/etc. interfaces are improbable in the next
ten years or so, because manufacturers work on the (usually correct)
assumption that their customers are using only THEIR OWN (the mfr's)
equipment.  

What I want is something I can use *now* (not thirty years from now
when keyboards are obsolete enough to have a standard interface) to be
able to carry my own personal user interface around in my briefcase.

>>This is done more with ADB than PC, but there are plenty of alternate
>>PC keyboards, some of which DO have things like trackballs on them.
>
>Which unfortunately can't behave like a "normal" PC mouse/pointer.

No reason why not.  You just have to make the keyboard interrupt
handler in the PC service both the keyboard and mouse device drivers.

[stuff omitted]

>*That's* another problem altogether: the lack of a single standard
>pointer on the PC, and the lack of applications that even support a
>pointer.

Which is EXACTLY *my* point.

>>ADB is sort of in the right direction, but...
>>        if you unplug your keyboard you risk blowing up your Mac,
>>because the ADB also includes the "on" button!)...

>                     I don't see any problem with putting the
>"on" button on the ADB, the problem is that it's too easy to
>accidentally send garbage when plugs are moved.

No, the problem is that you blow a fuse which Apple cleverly *solders*
to the motherboard!

>Dave Sill (dsill@relay.nswc.navy.mil)


-- 
  Steve Savitzky     | steve@arc.uucp | apple.com!arc!steve 
  ADVANsoft Research Corp.    |  (408) 727-3357(w) / 294-6492(h)
  4301 Great America Parkway  |  #include<disclaimer.h>
  Santa Clara, CA  95054      |  May the Source be with you!

lars@salt.acc.com (Lars J Poulsen) (07/15/89)

In article <29607@ism780c.isc.com> marv@ism780.UUCP (Marvin Rubenstein) writes:
>The Feb. 1868 issue of CACM, page 126, has an article titled "Proposed USA
>Standard, General Purpose Alphanumeric Keyboard Arrangement for Information
>Interchange".  An editor's note says "The proposed American standard has been
>accepted for final letter ballot and concurrent publication by a Subcommittee
>of the USA Standards Institute".  I don't know the outcome of that ballot.
>
>However, even if it was approved, it would not help C programers because
>the locationsof the characters [ ] \ | { } ^ were not prescribed.

It looks like the above date is wrong. I don't think CACM has been
published for over a hundred years.

If the date is 1968, the end result was that TWO layouts were
standardized, (a) one known as "typewriter-pairing", which blessed the
IBM typewriter keyboard,  and (b) one called "bit-pairing" which was
laid out to make the shift key always toggle just one bit.

Subsequently, US manufacturers of terminal equipment went for the
"typewriter-pairing" layout; this caused all sorts of problems for
European resellers (where the local language needed additional letters).
The bit-pairing keyboard would have allowed this with virtually no
modification, but the typewriter-pairing keyboards did not allow
national adaptation until technology advanced far enough to send all
keystrokes through a lookup table in an EPROM.

A typewriter pairing keyboard has <> above comma and period; a
bit-pairing keyboard has ";" over "," and ":" over ".".
I prefer bitpairing keyboards, but can never find them, and I hate even
more to always run with patched software, so I type six-finger: All of
left hand, but only one finger on the right hand.

In the late 1970-es I was a National tech support person for the Danish
distributor of Wang Office Systems, and spent a LOT of time bickering
with the marketing people in Lowell, Mass about requirements for
nationally acceptable keyboards.

/ Lars Poulsen <lars@salt.acc.com>   (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service              Affiliation stated for identification only
                My employer probably would not agree if he knew what I said !!

quiroz@cs.rochester.edu (Cesar Quiroz) (07/15/89)

In <29607@ism780c.isc.com>, marv@ism780.UUCP (Marvin Rubenstein) wrote:
| The Feb. 1868 issue of CACM, page 126, has an article titled "Proposed USA
           ????
| Standard, General Purpose Alphanumeric Keyboard Arrangement for Information
| Interchange".  An editor's note says "The proposed American standard has been
| accepted for final letter ballot and concurrent publication by a Subcommittee
| of the USA Standards Institute".  I don't know the outcome of that ballot.

If true as quoted (doubt it:-), I assume the standard in question is
now obsolete anyway.  Mind rechecking the year?

-- 
                                      Cesar Augusto Quiroz Gonzalez
                                      Department of Computer Science
                                      University of Rochester
                                      Rochester,  NY 14627

dsill@ark1.nswc.navy.mil (Dave Sill) (07/15/89)

In article <442@arc.UUCP> steve@arc.UUCP (Steve Savitzky) writes:
>Obviously, we differ.

Yeah, but at least we agree there's a problem.

>I have a PC and a mouse, and the combination
>can be made to work well enough for me to prefer it to a PC and no
>mouse.  Would it make you feel better if I say "user interface events"
>instead of "keystrokes" or "scancodes"?

I don't care what you call it.  I don't see how you can run a mouse
over a PC keyboard connection and have it work like one of the common
PC mice such as Microsoft or Logitech.  Am I missing something?

>>The other way *does* require a standard, but the payoff is much
>>greater.  You get a single hardware/software interface that supports a
>>much wider range of input devices *well*, as well as much more
>>consistency of operation between systems.
>
>I think you've missed the point.  There is unlikely EVER to be a
>standard for keyboard arrangements and keybindings, because the "best"
>such arrangement is a matter of preference (i.e. a religious issue).
>I would rather have the ability to customize my interface than have
>somebody else's idea of the "correct" interface shoved down my throat.

I couldn't agree more.  Any effort to standardize keyboards would be a
waste of time.

>Similarly, keyboard/mouse/etc. interfaces are improbable in the next
>ten years or so, because manufacturers work on the (usually correct)
>assumption that their customers are using only THEIR OWN (the mfr's)
>equipment.

Hey, I never said it was likely to happen anytime soon.  The biggest
obstacle is, of course, hardware vendors.  They're perfectly happy
with the status quo: they sell a keyboard/mouse/tablet with every
system.  They have no competion.  The PC world is close to an
exception; there are many after-market PC keyboards available.  But,
as far as I know, that hasn't significantly impacted the number of PCs
sold without keyboards.

For such a standard to happen, users have to be made aware of the
benefits.  Once vendors hear users clamoring for something they
usually provide it.

>What I want is something I can use *now* (not thirty years from now
>when keyboards are obsolete enough to have a standard interface) to be
>able to carry my own personal user interface around in my briefcase.

We're not just talking about a *keyboard* interface, we're talking about
an *input* interface.  Imagine a sightless user with a Braille (or
whatever) keyboard that could be attached to PC compatibles,
workstations, Macs, Amigas, etc.  Even though it's unlikely there
would be many people who would switch between so many systems, think
of how this would leverage the specialty input device market.  Rather
than having to market N versions of their enhanced keyboard or
handicap interface they'd only have to make one.  These days, only the
most-used systems have a large enough base to support a third-party
keyboard market.

>>Which unfortunately can't behave like a "normal" PC mouse/pointer.
>
>No reason why not.  You just have to make the keyboard interrupt
>handler in the PC service both the keyboard and mouse device drivers.

Okay, that's what I was missing.  Could that be done?  Are there any
free scan codes?  Would it require hardware mods?  What about the
physical complexity of the device required to enable it to attach to
different systems?

>>>        if you unplug your keyboard you risk blowing up your Mac,
>>>because the ADB also includes the "on" button!)...
>
>>                     I don't see any problem with putting the
>>"on" button on the ADB, the problem is that it's too easy to
>>accidentally send garbage when plugs are moved.
>
>No, the problem is that you blow a fuse which Apple cleverly *solders*
>to the motherboard!

Do we agree that that's a quality-of-implementation issue and not a
flaw in the concept?
-- 
Dave Sill (dsill@relay.nswc.navy.mil)

campbell@redsox.bsw.com (Larry Campbell) (07/16/89)

I think there's no need to standardize on the key placement, labelling,
or any other mechanical aspect of the keyboard.  What needs standardization
is the interface between the keyboard and the outside world.  That way I can
bring my favorite (Dvorak, DEC, whatever) funky keyboard with me, plug it in,
and feel right at home.  The dead hand of the market will cause a standard,
or at least an equilibrium, to be reached for the physical key placement.
But until keyboards are interchangeable, there's no free choice and thus
no way for the market to operate.
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@bsw.com                        120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02146

hrs1@cbnewsi.ATT.COM (herman.r.silbiger) (07/16/89)

Actually, a large number of ANSI keyboard layout standards exist in the X3 
series.  There are also some that specify keytop symbols and designations.
Many of these are being updated, and new ones written, by the X3V1 standards
committee.

X3V1 is the Text, Office, and Publishing Systems Standards Committee.
The Chair is Millard Collins, phone him at 1 817 962 4392 for information.

Herman Silbiger hrs@batavier.ATT.COM

peter@ficc.uu.net (Peter da Silva) (07/17/89)

In article <17@ark1.nswc.navy.mil>, dsill@ark1.nswc.navy.mil (Dave Sill) writes:
> I don't care what you call it.  I don't see how you can run a mouse
> over a PC keyboard connection and have it work like one of the common
> PC mice such as Microsoft or Logitech.  Am I missing something?

I don't see why not... the standard PC mice generate a set of 5-byte serial
packets: [buttons] [delta x] [delta y] [delta x] [delta y]. What's wrong
with including these packets in the input stream?

The [buttons] only uses codes 0xF8 through 0xFF. That leaves 0x00 through
0xF7 for scancodes. If you want button-up/button-down you can always use
0xF7 followed by a scancode byte, and use the rest of the codes for other
devices. We're not talking super-high baud rates here.

Or even send the keyboard's idea of the (7-bit) ascii code followed by the
scancode, with 0xF7 for non-ascii data. That way a stupid device (like a
cheap terminal) can ignore every other byte (either way) and still work.

Am I missing something?
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: peter@ficc.uu.net, +1 713 274 5180. | Multiprocessors are just a
Personal: peter@sugar.hackercorp.com.   `-_-' | way of using up excess memory
Quote: Have you hugged your wolf today?  'U`  | bandwidth. - mark@mips.com

steve@arc.UUCP (Steve Savitzky) (07/18/89)

In article <17@ark1.nswc.navy.mil> dsill@relay.nswc.navy.mil (Dave
Sill) writes:
>                               I don't see how you can run a mouse
>over a PC keyboard connection and have it work like one of the common
>PC mice such as Microsoft or Logitech.  Am I missing something?

Actually, Logitech used to sell one.  It requires modifying the
keyboard driver.  (I think you realized this later.)

[about the ADB]

>Do we agree that that's a quality-of-implementation issue and not a
>flaw in the concept?

Yes, though "implementation" may include the spec itself (i.e. it may
well be specified in such a way as to make the fuse-blowing problem
unfixable--I'd have to check). 

...

Me, I'd love to see an I/O interface spec.  Something along the lines
of Ethernet + TCP-IP + X11 (since we seem to agree that it won't
happen anytime soon).  Ethernet bandwidth (or the equivalent in
wireless IR link) would make it bidirectional, which is important for
things like position-of-head-sensing stereo-view helmets (which I
want).  You need to be able to send high-quality audio both ways, too.

Hey, maybe we should just say "That's the new standard" and stand
back :-).  At least one company (Agilis?) has announced a laptop
workstation with the pieces tied together with Ethernet, so it's not
impossibly farfetched.  And X has always seemed like the right way to
talk to a display controller...

-- 
  Steve Savitzky     | steve@arc.uucp | apple.com!arc!steve 
  ADVANsoft Research Corp.    |  (408) 727-3357(w) / 294-6492(h)
  4301 Great America Parkway  |  #include<disclaimer.h>
  Santa Clara, CA  95054      |  May the Source be with you!

news@ism780c.isc.com (News system) (07/18/89)

In article <1989Jul15.034605.28654@cs.rochester.edu> quiroz@cs.rochester.edu (Cesar Quiroz) writes:
>
>In <29607@ism780c.isc.com>, marv@ism780.UUCP (Marvin Rubenstein) wrote:
>| The Feb. 1868 issue of CACM, page 126, has an article titled "Proposed USA
>           ????
>| Standard, General Purpose Alphanumeric Keyboard Arrangement for Information
[the rest of my original posting deleted]

>
>If true as quoted (doubt it:-), I assume the standard in question is
>now obsolete anyway.  Mind rechecking the year?

Why do you doubt it?  I had the issue of CACM in front of me when I wrote
the original note.  The the date is correct.  1968, 21 years ago!  It seems
I have an unusual memory for this kind of computer related trivia.  As
I said in my original note, I don't know if the standard was adopted.  If
it was, I also don't now if it is still in effect.  But it doesn't matter,
no one followed it.

If any one is interested, I can give you the reference to the proposed
standard for hand written programs.  The standard was proposed so that
readers could tell the difference between the letter, oh, and the numeral,
zero. (No, this is not a joke)

    Marv Rubinstein

spage@cup.portal.com (S spage Page) (07/19/89)

The de facto standard is the IBM 101-key keyboard on the PC AT.  You can buy
a Mac keyboard with the same layout, the NeXT keyboard is similar, there are
a zillion clone vendors selling all kinds of versions of this from spongey
to tappy to clickly, I believe you can plug one right into the DG Aviion
system, etc., etc.

As to whether it's a GOOD standard,...  It duplicates the cursor control and
PageUp/PageDown/Home/End/Insert/Delete keys, first on the number pad and then
in two blocks.  This is somewhat redundant and the NeXT keyboard uses the
PageUp/PageDown/... block for ?? Brightness, Volume, and other weirdness.

The problem with any standard keyboard layout is that software programs
always end up using every key, so that to implement window system shortcuts
like Front/Back/Close, you have to either fight with applications or add
extra keys.  Sun grabbed the left 10 keys from the original PC layout.
However, the Microsoft Windows use of <Alt-> is much easier to remember and
faster to type.  I walked up to a PC once and ran Windows for 30 minutes
before I noticed it didn't have a mouse!  If OSF/Motif can implement the same
keyboard U.I. it would be a big win.

Another advantage of the PC AT hardware standard is the number of plug-
compatible special designs available for it.  I have bad arthritis and
have tried several different keyboards.  I've seen ads for dished keyboards,
keyboards with touch pads, keyboards with separately adjustable left and
right keys.  The most amazing product I've heard of is one which splits the
keyboard into two "pucks", one for each hand.  You rest your hands on 
heavily contured surfaces studded with microswitches, so the effort to strike
keys is minimized.  And... each one rolls around independently, so either
hand can drive a mouse.  If anyone has more information about this keyboard,
please send me email.

=S Page		spage@cup.Portal.COM

jimc@iscuva.ISCS.COM (Jim Cathey) (07/20/89)

In article <20581@cup.portal.com> spage@cup.portal.com (S spage Page) writes:
>The de facto standard is the IBM 101-key keyboard on the PC AT.  You can buy
>...
>As to whether it's a GOOD standard,...  It duplicates the cursor control and
>...
>Another advantage of the PC AT hardware standard is the number of plug-
>compatible special designs available for it.  I have bad arthritis and
>...

And a monstrously big _disadvantage_ of the PC keyboard series is its TTL
signal interface.  Probably the most noise-sensitive interface they could
have chosen.  You are extremely limited in how far you can extend the cable
before you start getting unreliable keystrokes, especially if you package
video into the same cable.  Plus it expects 5V regulated power, another
no-no for longer cables.

Our keyboards use RS-422 and we routinely get 3000 feet of cable on these
signals with no problems.  It's also a low-speed LAN in that we get 8 
keyboards and 8 printers all on the same wire, with only one serial 
controller.  Very handy for installing low-cost multi-user stations.

Unfortunately us designers are besieged by legions of marketing types dancing
in a circle around us and chanting "Off the SHELF, Industry STANDard..." 
They expect the same sort of thing that we do with our custom keyboards to
be done with AT keyboards, only "cheaper".  After all, a keyboard's a 
keyboard, right?  

Grumble.

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com)
! II      CCCCCC !  (509) 927-5757
+----------------+
			"With excitement like this, who is needing enemas?"