[comp.sys.atari.8bit] Alternate keypads

gdtltr@vax1.acs.udel.EDU (Gary D Duzan) (04/13/88)

   I've had an idea rolling around in my head for a
while & I thought I'd post it up here & see what people 
think of it. A number of programs these days are
starting to use shift-control sequences (I know of
PaperClip and the Express! terminal programs). I think
it would be neat to have an alternate keyboard that has
these keys as seperate function keys. For example, S-C
1-0 could be F1-F10, S-C P could be print screen, etc.
Making standards like this would help in software 
development since users wouldn't have to learn a whole
new set of keys for each program. Opinions?

			   Gary Duzan
			   Time  Lord
                       Third Regeneration
                    Atari Enthusiast Extreme

cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (04/14/88)

In article <1017@udccvax1.acs.udel.EDU>, gdtltr@vax1.acs.udel.EDU (Gary D Duzan) writes:
> 
> ... A number of programs these days are
> starting to use shift-control sequences (I know of
> PaperClip and the Express! terminal programs).

... add Kermit65 to the list...   :-)
 
> it would be neat to have an alternate keyboard that has
> these keys as seperate function keys. ...

[details omitted for brevity]

This is indeed a good, and in fact somewhat workable, idea.  The only 
limitation I see is that NOT ALL shift-control key combinations actually
seem to generate hardware codes.  (I may be mistaken.  I know that not
all SH-CTL combinations result in a character code reaching RAM shadow
location 764 (decimal; hex 2FC), but it may be present in the hardware
register whose location escapes me just now...)

Anyway, within that limitation, you should be able to do whatever you
want with these key combinations, but some keyboard patterns may get
bollixed if there's a "dead" key in the middle of it.  Just be aware 
of this, and you should be "golden!".
 
-- 
UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa 
cfchiesa@bsu-cs.UUCP                                           

gdtltr@vax1.acs.udel.EDU (Gary D Duzan) (04/14/88)

In article <2620@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher Chiesa) writes:
>In article <1017@udccvax1.acs.udel.EDU>, gdtltr@vax1.acs.udel.EDU (Gary D Duzan) writes:
> 
>> it would be neat to have an alternate keyboard that has
>> these keys as seperate function keys. ...
>
>[details omitted for brevity]
>
>This is indeed a good, and in fact somewhat workable, idea.  The only 
>limitation I see is that NOT ALL shift-control key combinations actually
>seem to generate hardware codes.  (I may be mistaken.  I know that not
>all SH-CTL combinations result in a character code reaching RAM shadow
>location 764 (decimal; hex 2FC), but it may be present in the hardware
>register whose location escapes me just now...)

   True. Some S-C keys don't register anything in 764. Those would have
to be omitted. I am more worried, however, about the hardware side. First
of all, I would have to get details on how the current keyboard is 
connected. Then I would have to find time to put it together. I don't know
if I could handle that. Therefore, if someone wants to develop & market this
idea, it is fine with me. Just be sure to send me a copy.

					    Gary Duzan
					    Time  Lord
                                        Third Regeneration
                                     Atari Enthusiast Extreme
                                Lots of ideas, but no time for them

jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (04/18/88)

    Date: 13 Apr 88 23:45:40 GMT
    From: bsu-cs!cfchiesa@iuvax.cs.indiana.edu  (Christopher Chiesa)

    In article <1017@udccvax1.acs.udel.EDU>, gdtltr@vax1.acs.udel.EDU (Gary D Duzan)
     writes:
    >
    > ... A number of programs these days are
    > starting to use shift-control sequences (I know of
    > PaperClip and the Express! terminal programs).

    ... add Kermit65 to the list...   :-)

Also the X-Lent word processor pgm.

    > it would be neat to have an alternate keyboard that has
    > these keys as seperate function keys. ...

    [details omitted for brevity]

    This is indeed a good, and in fact somewhat workable, idea.  The only
    limitation I see is that NOT ALL shift-control key combinations actually
    seem to generate hardware codes.  (I may be mistaken.  I know that not
    all SH-CTL combinations result in a character code reaching RAM shadow
    location 764 (decimal; hex 2FC), but it may be present in the hardware
    register whose location escapes me just now...)

No, you're not mistaken, at least about the symptom.  I've never gotten
to the bottom of the root cause, either, but my guess is that the real
low-level key-scanning logic gets confused by some combinations of c-sh-
things, and concludes that there was really no keypress.  Esp given that
the the nonfunctional keys are in sort of a regular pattern, that seems
more likely than that somebody actually filtered them out in the
interrupt-level software.

    Anyway, within that limitation, you should be able to do whatever you
    want with these key combinations, but some keyboard patterns may get
    bollixed if there's a "dead" key in the middle of it.  

True, but it's worse than just holes.  As I recall, you lose Tab thru
'R', and 'H' thru '|', ie there are two substantial horizontal chunks
taken out of the keyboard.  That makes it real tough to do, say, a fake
VT100 keypad.  I know, as I tried real hard to get that to work when I
did the last version of Kermit65.
							   Just be aware
    of this, and you should be "golden!".

I sent mail last summer about the problem, but didn't get any feedback
about any workarounds.  Anybody got any better ideas these days?

njd@ihlpm.ATT.COM (DiMasi) (04/19/88)

In article <19880417184118.1.JRD@MOA.SCRC.Symbolics.COM>, jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes:
> 
> ....
> True, but it's worse than just holes.  As I recall, you lose Tab thru
> 'R', and 'H' thru '|', ie there are two substantial horizontal chunks
> ....
Hmmm... "Tab thru 'R'" implies that W and R don't work with <CTRL><SHIFT>.
Yet, the ACTION! editor uses these along with other <CTRL><SHIFT> combinations.
(It has used such combinations since ACTION! first appeared, as far as I know.)
How does it work, if the key combo's don't generate any codes?

Nick DiMasi
Uni'q Digital Technologies (Fox Valley Software subsidiary;
   ^          working as a contractor at AT&T Bell Labs in Naperville, IL)
(  | this is an accent mark, supposed to replace the dot over the 'i')

jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (04/20/88)

    Date: 18 Apr 88 22:55:07 GMT
    From: ihnp4!ihlpm!njd@ucbvax.Berkeley.EDU  (DiMasi)

    In article <19880417184118.1.JRD@MOA.SCRC.Symbolics.COM>, jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes:
    > 
    > ....
    > True, but it's worse than just holes.  As I recall, you lose Tab thru
    > 'R', and 'H' thru '|', ie there are two substantial horizontal chunks
    > ....
    Hmmm... "Tab thru 'R'" implies that W and R don't work with <CTRL><SHIFT>.
    Yet, the ACTION! editor uses these along with other <CTRL><SHIFT> combinations.
    (It has used such combinations since ACTION! first appeared, as far as I know.)
    How does it work, if the key combo's don't generate any codes?

Well, probably I got the details wrong.  I don't have my notes from
doing Kermit in front of me, so I probably misremembered exactly which
sections are busted.  I do clearly remember that there are two sections
of the keyboard, one approximately on the left half, one on the right,
and separated by one row, that don't generate anything with c-sh-.