EKEY in gforth in DOS 
Author Message
 EKEY in gforth in DOS

On Tue, 18 Sep 2001 15:54:24 +0200, Robert Epprecht

Quote:

>A side note:
>IIRC a Debian update (without changing Gforth in any way) changed once
>the values returned by Gforth EKEY on my Debian Linux system.
>Please note the 'IIRC', my memory *might* fool me on this behalf.

>I had to change my ekey mapping to get the same result as before.
>i.e.   '$4012D690 CONSTANT <left>' before the update
>became '$4012E690 CONSTANT <left>' after.
>             ^
>Same $xxxxDxxx to $xxxxExxx pattern for all the other cursor and function
>keys, as far as I remember.

Another side note:
Industrial control systems often offer process control keyboards.
Their key events cannot be treated in a standardized way. And Forth is
not restricted to the PC and workstation world.

Andreas



Sat, 06 Mar 2004 23:44:18 GMT  
 EKEY in gforth in DOS

Quote:

>Another side note:
>Industrial control systems often offer process control keyboards.
>Their key events cannot be treated in a standardized way. And Forth is
>not restricted to the PC and workstation world.

Indeed, I am not asking the all key events be handled in a
standardised way: that is, I am not insisting that every system should
have EKEY and that it should work as the standard describes, rather
that EKEY should be omitted if it cannot be made to work as the
standard describes.

But it turns out that all that is missing in gforth is the handler for
dos.  I've got that in hand, based on experiments I was doing on the
train going home last night.



Sun, 07 Mar 2004 08:04:02 GMT  
 EKEY in gforth in DOS

Quote:

>Another side note:
>Industrial control systems often offer process control keyboards.
>Their key events cannot be treated in a standardized way. And Forth is
>not restricted to the PC and workstation world.

How do you mean "cannot be treated in a standardised way"?

(1)  Do you mean: "cannot be expected to deliver PC keyboard codes or
VT100 escape sequences",

(2) or do you mean, "it will be impossible to define an EKEY that
delivers an atomic ( -- u ) onto the stack"?

(1) is fine by me.  Indeed, (2) is Ok too, as long as there is not an
EKEY present that pretends to do so.

Note that this is a critique of gforth in DOS as opposed to a
complaint ... after all, its not even been designated 1.0.0 yet, and
it does *try* to do the right thing.



Sun, 07 Mar 2004 10:24:59 GMT  
 EKEY in gforth in DOS

Quote:



>>Another side note:
>>Industrial control systems often offer process control keyboards.
>>Their key events cannot be treated in a standardized way. And Forth is
>>not restricted to the PC and workstation world.

>Indeed, I am not asking the all key events be handled in a
>standardised way: that is, I am not insisting that every system should
>have EKEY and that it should work as the standard describes, rather
>that EKEY should be omitted if it cannot be made to work as the
>standard describes.

>But it turns out that all that is missing in gforth is the handler for
>dos.  I've got that in hand, based on experiments I was doing on the
>train going home last night.

For the curious ones here is a code snippet from my own little Forth
system. It compiles under DOS/Win and Linux. It may not be perfect but
it works.

The primitive rawkey gets one single control char from the terminal
input stream. The Linux terminal events are translated as if they were
DOS terminal events. DOS special keys are just mapped to above 256.

\ ------ ANSI-Terminal Keyboard Control
--------------------------------------

MARKER DONE

\ code GETENV  _getenv    \ ( adr u buf -- flag ) read environment
variable

: ISLINUX?  ( -- flag / true if running on Linux )
  s" OSTYPE" here 20 getenv dup
  if drop here count 2dup upper s" LINUX" compare 0= then
  done ;

ISLINUX? [IF]

BEGIN-PRIVATE

: KC:  \ enter item in kcodes table
  get-word >double not -24 ?throw drop dup 0= if drop exit then ,
  bl word count tuck here splace 2 + aligned allot ;

CREATE KCODES  \ as per linux (tested with SuSE 6.3)
kc: 331 D    \ left
kc: 328 A    \ up
kc: 333 C    \ right
kc: 336 B    \ down
kc: 338 2~   \ ins
kc: 339 3~   \ del
kc: 327 1~   \ home
kc: 335 4~   \ end
kc: 329 5~   \ pgup
kc: 337 6~   \ pgdn
kc: 315 [A   \ F1
kc: 316 [B   \ F2
kc: 317 [C   \ F3
kc: 318 [D   \ F4
kc: 319 [E   \ F5
kc: 320 17~  \ F6
kc: 321 18~  \ F7
kc: 322 19~  \ F8
kc: 323 20~  \ F9
kc: 324 21~  \ F10
kc: 389 23~  \ F11
kc: 390 24~  \ F12
kc: 340 25~  \ Sh-F1
kc: 341 26~  \ Sh-F2
kc: 342 28~  \ Sh-F3
kc: 343 29~  \ Sh-F4
kc: 344 31~  \ Sh-F5
kc: 345 32~  \ Sh-F6
kc: 346 33~  \ Sh-F7
kc: 347 34~  \ Sh-F8
kc: 0

CREATE KQUEUE \ raw keys are queued up as counted string
3 CELLS ALLOT KQUEUE 3 CELLS ERASE

0 VALUE KC  \ holds address after successful kc-scan

: KC-SCAN  \ ( -- flag ) scan for extended key codes

  kqueue 3 + kcodes

  while  dup cell+ count 3 pick over compare 0=
         if to kc drop true exit then

  repeat 2drop false ;

\  code RAWKEY? _rawkeyq    \ ( -- flag ) true if keyboard event is
waiting
\ _code RAWKEY  _rawkey     \ ( -- code ) receive one raw keyboard
event

: REFILL-KQUEUE  \ ( -- ) refill queue as much as possible

        rawkey?

  repeat ;

: FETCH-RAWKEY  \ ( -- rawkey ) fetch first queue char


  then ;

: FETCH-KCKEY  \ ( -- cookedkey ) fetch control key and empty raw queue chars


  kqueue 1+ dup pluck + swap 10 3 pick - move
  kqueue 12 + over - swap erase

: GET-EKEY
  kc-scan if fetch-kckey else fetch-rawkey then ;

\ EKEY and EKEY? are defered

:NONAME  \ ( -- flag )

  refill-kqueue

IS EKEY?

:NONAME  \ ( -- key )
  begin ekey? until get-ekey ;
IS EKEY

END-PRIVATE MAKE-PRIVATE  \ discard headers

[ELSE]  \ DOS or Win32

\ 'defered ekey' compiles current execution vector of defered EKEY

:NONAME  \ ( -- keycode ) this works for DOS and Windows NT
  defered ekey dup 0= over -32 = or if drop rawkey 256 + then ;
IS EKEY

[THEN]

Andreas



Sun, 07 Mar 2004 15:13:33 GMT  
 EKEY in gforth in DOS

Quote:

> I had to change my ekey mapping to get the same result as before.
> i.e.   '$4012D690 CONSTANT <left>' before the update
> became '$4012E690 CONSTANT <left>' after.

The key mapping are not *constants*, they are symbols (really
addresses). You can't rely on the numbers, they'll change again and
again. You can rely only on the symbols, e.g.

k-left Constant <left>

would always work.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/



Sun, 07 Mar 2004 16:32:13 GMT  
 EKEY in gforth in DOS

Quote:


> > I had to change my ekey mapping to get the same result as before.
>> i.e.   '$4012D690 CONSTANT <left>' before the update
>> became '$4012E690 CONSTANT <left>' after.

> The key mapping are not *constants*, they are symbols (really
> addresses). You can't rely on the numbers, they'll change again and
> again. You can rely only on the symbols, e.g.

> k-left Constant <left>

> would always work.

Thank you for clarifying this.

Robert Epprecht



Sun, 07 Mar 2004 22:25:52 GMT  
 EKEY in gforth in DOS
0 [IF]


Quote:

>> Do I understand correctly that the gforth for Linux reconstructs a
>> single keyboard event out of VT-102 escape sequences?

>Yes. EKEY maps those sequences to symbolic constants like k-left or k5
>(cursor-left, function key 5). If you want to port it to DOS, you'd
>catch 0 instead of #esc, and check only the next key, not a pattern, but
>you should convert that key to the same symbolic constants. Check for
>the "os-class" environment query, it will return the string "dos" for
>DOS.

>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://www.jwdt.com/~paysan/

I have the following.  I obtained the values for the dos k-"name"
constants by writing a function like

: ek? ( -- ) ." Press an extended key: " KEY . KEY . " ;

and using the ` function in BMW to run the function while editing the
file.
[THEN]

\ dosekey, based on:
\ ekey etc.

\ Copyright (C) 2001 Free Software Foundation, Inc.

\ This file is part of Gforth.

\ Gforth is free software; you can redistribute it and/or
\ modify it under the terms of the GNU General Public License
\ as published by the Free Software Foundation; either version 2
\ of the License, or (at your option) any later version.

\ This program is distributed in the hope that it will be useful,
\ but WITHOUT ANY WARRANTY; without even the implied warranty of
\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
\ GNU General Public License for more details.

\ You should have received a copy of the GNU General Public License
\ along with this program; if not, write to the Free Software
\ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, USA.

\ this implementation of EKEY just translates the KEY values
\ received following a null to values between 256 and 511

\ Caveats: It also translates a sequence of two codes beginning with
\ 0 if they were not generated by pressing the key.  It does not wait
\ for the second value in the sequence to arrive.

\ In a Forth implementation on DOS in which special keys are not
\ available by a second call to KEY following a null value, this
\ code will not work.  It has only been used on Gforth 0.5

\ The dos-keycode names are compatible with pfe-0.9.14

: dos-keycode ( c "name" -- ; name execution: -- u ) 256 + constant ;

75 dos-keycode k-left
77 dos-keycode k-right
72 dos-keycode k-up
80 dos-keycode k-down
71 dos-keycode k-home
79 dos-keycode k-end
115 keycode k-prior \ note: captured by xterm
116 keycode k-next \ note: captured by xterm
82 dos-keycode k-insert \ not in pfe
\ function/keypad keys
59 dos-keycode k1
60 dos-keycode k2
61 dos-keycode k3
62 dos-keycode k4
63 dos-keycode k5
64 dos-keycode k6
65 dos-keycode k7
66 dos-keycode k8
67 dos-keycode k9
68 dos-keycode k10
133 dos-keycode k11 \ not in pfe
134 dos-keycode k12 \ not in pfe

\ shifted function/keypad keys have the same key sequences (in
\ xterm) and pfe gives the same keycodes; so use of these is
\ not portable to gforth outside of DOS
84 dos-keycode s-k1
85 dos-keycode s-k2
86 dos-keycode s-k3
87 dos-keycode s-k4
88 dos-keycode s-k5
89 dos-keycode s-k6
90 dos-keycode s-k7
91 dos-keycode s-k8
92 dos-keycode s-k9
93 dos-keycode s-k10
135 dos-keycode s-k11 \ not in pfe
136 dos-keycode s-k12 \ not in pfe

: ekey ( -- u ) \ facility-ext e-key
    key ?dup 0= if key 256 + then
;

: ekey>char ( u -- u false | c true ) \ facility-ext e-key-to-char
    dup 256 u<
;

: ekey? ( -- flag ) \ facility-ext e-key-question


    key?
;

FALSE [IF]
   : test-ekey?
      begin
         begin
            begin key? until
         ekey? until
         .s ekey .s drop
      again
   ;
   test-ekey?
[THEN]



Mon, 08 Mar 2004 15:32:08 GMT  
 EKEY in gforth in DOS
Quote:

  ...

> \ this implementation of EKEY just translates the KEY values
> \ received following a null to values between 256 and 511

  ...

How? Where? I don't see that in the code. (It's 6:30 AM.)

Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------



Mon, 08 Mar 2004 18:29:30 GMT  
 EKEY in gforth in DOS


Quote:

>> The question is whether EKEY should be expected to comply with its
>> definition, in which a "Raw Keyboard Event" is returned, according to
>> the definition and stack comment, as a single cell on the stack.

I would interpret it this way: pressing a function key on a vt100
is one event, although the vt100 sends an escape char followed by more
characters over the 9600 baud line. A decent implementation reconstructs
what happened and passes a single event to the application.
Although I think we share the same insight, I would prefer the terminology
raw event for the single keys and  cooked event after
the Forth  interpretation . Socooked event  is equivalent to EKEY.
I read once a controller that made a difference between an escape
char that was part of a sequence and a loose escape char, by inspecting
the timing. Worst piece of code I have ever seen, but anyway.
Quote:
>You think that raw keyboard events are single events from the keyboard
>controller. That's wrong. PC keyboards translate extended keys (cursor
>keys, function keys) into a sequence of events on the keyboard

What did it say in the bible? Great harvest, few workers ...

Quote:
>controller. To combine those events back into raw keyboard events, the
>application has to understand the keyboard protocol. Unfortunately,
>ANSI.SYS doesn't change the input, only the output. Feel free to add the
>patterns necessary for the event sequence provided by DOS keyboards to
>ekey.fs, and send us a patch.

>Remember: The DOS port for Gforth still seeks a maintainer, as noone of

--
This aricle copyright Albert van der Horst DFW The Netherlands. It may be
freely distributed on terms that redistribution shall not be restricted.
Techniques and knowledge revealed here in are public domain, hence not
patentable. Acronyms STNT, MT e.a. are scientific terms not trademarks.
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.



Mon, 08 Mar 2004 05:04:12 GMT  
 EKEY in gforth in DOS

Quote:

>I would interpret it this way: pressing a function key on a vt100
>is one event, although the vt100 sends an escape char followed by more
>characters over the 9600 baud line. A decent implementation reconstructs
>what happened and passes a single event to the application.
>Although I think we share the same insight, I would prefer the terminology
>raw event for the single keys and  cooked event after
>the Forth  interpretation.

My question was more what the standard means by keyboard event.  It
seems to me that when a user presses a key, or a specific combination
of key supported by the keyboard hardware, that's a keyboard event.
EKEY says nothing about returning values for *every* keyboard event,
it simply says that it returns a value for keyboard events, and the
definition of EKEY>CHAR implies that the cells returned by EKEY can be
checked to see whether they are characters values or "something else",
without putting any additional restrictions on what "something else"
might be.

So if EKEY returns a row code in the lower 8 bits and a column code in
the next 8 bits, that's fine, so long as EKEY>CHAR knows how to get a
char out of that.

If pressed, I think I prefer the term keyboard event for striking a
key at a keyboard, and the term ekey-value for what is dropped onto
the stack when EKEY lets go of it.

(
----------
Virtually,

Bruce McFarling, Newcastle,

)



Tue, 09 Mar 2004 20:09:40 GMT  
 EKEY in gforth in DOS
Quote:

> I have the following.  I obtained the values for the dos k-"name"
> constants by writing a function like

[source snipped]

Ok, thanks. I checked that into Gforth's CVS repository.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/



Thu, 11 Mar 2004 06:48:43 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software