horlache@sun1.ruf.uni-freiburg.de (Ullrich Horlacher) (08/10/90)
I was just about to write a question about a programmable ALPHA (using in an own INPUT-command) when I read the following mail, which represents ABSOLUTELY that, what I wanted to post by myself: >From: UUCP%"bio_zwbb@jhunix.UUCP" 8-AUG-1990 14:21:15.45 > > First let me say that, in responding to Mr. Wickes' timely and >helpful answer to my question concerning the lack of a programmable >alpha-on in the 48, it is most definitely *NOT* my intention to start a >flame war or a round of HP-bashing, nor to second-guess the 48 design >team. What I *do* wish to do is to initiate a round of constructive user >feedback so that HP might better meet users' needs in future products. >(...) > I have recently tried to write a work-around for this problem, but >with little success. Using "0 WAIT" to catch keypresses while displaying >the graphics screen works, but is too slow when key location numbers must >be converted to alpha characters using user commands (as opposed to >(...) I have the same problem: I want an input-command, which can control the whole screen AND which doesn't erase it when invoking it. The main-reason is, that I have a lot of games (*shame*) programmed on the 28, which I wanted to port to the 48. The PROMPT and INPUT command don't fit exactly the behavior of the IN-command (a programm of my own for the 28), so I converted my IN-programm to the 48. But I'm not happy with its speed. Also I have problems with the type-ahead- buffer, which works not proberly. Say: sometimes some keys are not recognized. I would be very happy, if someone post a better and flexibel input-programm. Nevertheless, here is my version: IN is a program for interactive input, like INPUT in BASIC or readln in Pascal. It returns the input-string to the stack. If you press the ALPHA-key, the program is HALTed and you can do other things, like visit variables, and then CONTinue the program. Program: IN %%HP: T(3)A(R)F(.); \<< \->INL \-> s p t \<< s "" \=/ s ":" + s IFTE 's' STO "" WHILE DUP s SWAP + "_" + p DISP DO UNTIL KEY END DUP 51 \=/ REPEAT DUP IF 61 == THEN DROP LCD\-> \-> s d \<< HALT s "" d \->LCD \>> END DUP IF 55 == THEN DROP 1 OVER SIZE 1 - SUB ELSE t DUP ROT POS 1 + IF DUP 1 \=/ THEN GET + ELSE DROP2 END END END DROP s OVER + p DISP \>> \>> ------------------------------------------------------------------------------ Program: ->INL @ converting-table %%HP: T(3)A(R)F(.); { 93 "." 92 "0" 82 "1" 83 "2" 84 "3" 72 "4" 73 "5" 74 "6" 62 "7" 63 "8" 64 "9" 11 "A" 12 "B" 13 "C" 14 "D" 15 "E" 16 "F" 21 "G" 22 "H" 23 "I" 24 "J" 25 "K" 26 "L" 31 "M" 32 "N" 33 "O" 34 "P" 35 "Q" 36 "R" 41 "S" 42 "T" 43 "U" 44 "V" 45 "W" 46 "X" 52 "Y" 53 "Z" 94 " " } ----------------------------------------------------------------------------- use: 2: <prompt-string> 1: <display-line-number> IN e.g.: 2: "Value" 1: 3 IN or << CLLCD "Value" 3 IN 'VALUE' STO >> ==> +----------------------+ | | |Value:_ | | | | | +----------------------+ #----------------------------------------------------------------------------# this mail came from Framstag! | asta@dulruu51.bitnet (sometimes known as Ulli Horlacher) | asta@rz.uni-ulm.dbp.de University of Ulm/Danube W-Germany | asta@main01.rz.uni-ulm.de "Waiting for the prompt" -Marillion | framstag@dtupev5a.bitnet #----------------------------------------------------------------------------#
scottb@hpcvia.CV.HP.COM (Scott_Burke) (08/11/90)
Regarding the current thread of an INPUT work-alike:
One alternative to the program just posted is to use PICT and GROBs.
Every time a character is received, convert it to the appropriate
alphanumeric character, convert it to a GROB, and paste it onto the
end of the existing command line. Backspacing is simple if you use
a monospaced font (i.e., NOT size 1). If you have access to the HP
Equation Solve Library Application Card, then take a look at the
interactive molecular weight calculator (accessed by pressing alpha
when running the Periodic Table application). This uses the method
I just described, and is reasonably fast. It would run faster if
there didn't have to be checks on the subscript widths (they are
smaller than the normal characters). (Note: This discussion about
the molecular weight calculator is all reverse engineering; I have
never seen the actual code. But I did try to duplicate it.)
The bottleneck when using user code is the conversion from the row-
column.plane description of a keypress (using WAIT) to the correct
alpha-numeric character. The approach taken in the previous program
is a list look-up table. This is not the fastest way available.
A speedier way would be to first explode a list of the available
characters onto the stack:
{ "A" "B" "C" "D" "E" etc. } OBJ->
6: etc.
5: "D"
4: "C"
3: "B"
2: "A"
1: size
Then, when you receive a character code, find its POS in a different
list:
{ 11 12 13 14 15 16 21 22 23 etc. } code POS
Then use that result to do a PICK to get the right character.
The general point is it's MUCH faster to use the stack than to
search through a list.
Other notes about the code: It is faster to do IFT and IFTE commands
than to do actual IF-THEN-ELSE-END constructs. The IN program can
be easily rewritten to make use of this. It's not a huge difference,
but it can be detected. There are other simple optimizations that can
be made, such as replacing "DUP s SWAP" with "s OVER", but I won't go
through it all. Seeing these sorts of 'packs' just comes with lots of
programming.
Overall, IN, with a few modifications, is one of the most useful
interface tools I've seen posted. Good job!
scott.