Path: utzoo!attcan!uunet!aplcen!jhunix!bio_zwbb
From: bio_zwbb@jhunix.HCF.JHU.EDU (William Busa)
Newsgroups: comp.sys.handhelds
Subject: Re: Programmable alpha on for HP48?
Message-ID: <6036@jhunix.HCF.JHU.EDU>
Date: 7 Aug 90 13:28:31 GMT
References: <5998@jhunix.HCF.JHU.EDU> <25590042@hpcvra.CV.HP.COM>
Reply-To: bio_zwbb@jhunix.UUCP (Dr. William B. Busa)
Organization: Dept. of Biology, The Johns Hopkins University
Lines: 61

In article <25590042@hpcvra.CV.HP.COM> billw@hpcvra.CV.HP.COM (William C Wickes) writes:
>There is no way (other than with INPUT) to turn on alpha mode in HP 48SX
>user language.  An oversight? No; INPUT seems the right place to provide
>that capability--the ROM is full and there's 10000 other capabilities
>that are just as desirable.   Terrible? Hardly.  Something the 41 has 
>that the 48 doesn't?  Well, the 48 doesn't have an alpha register either.
>
>Before suggesting any alternate approach, we'd need to know more about
>your program.  I fear that turning on alpha mode may be the least of your
>problems if you're trying to emulate INPUT; for example, how are you
>going to freeze the display (longer than to the next keypress) to keep
>your graphics in view while data entry is happening?

	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.

	The HP-48SX is a superb machine with a host of long-prayed-for
features which, I think, make it the first true hand-held computer (in the
sense of a general purpose computing device, as opposed to a more
restricted *devoted* device such as a calculator). A hallmark of modern
computers is *a high degree of flexibility in the design of interactive
I/O* -- in particular, in the programmer's ability to control the screen
as the user employs the keyboard. On this one count, I find the 48 to fall
well short of what I consider reasonable expectations. 

	The available programmable user commands controlling
keyboard-based I/O -- i.e., PROMPT and INPUT -- are handy for their
intended purposes, but do not permit the programmer to control the screen
fully during input. In particular, INPUT is restricted to the stack
display (although stack operations are disabled). The programmer who
wishes to display the graphics screen during data input is, apparently,
out of luck. This lack of functionality *severely* restricts the
programmer's options.

	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
machine language, which is well beyond me!). The alternative of
"automating" this coding process by assigning alpha strings to keys in
USER mode is even slower, and the key assignments take forever to load.
Perhaps I have overlooked the correct approach to the problem (stranger
things have happened!) or perhaps there simply is no solution, short of
machine-language programming (shudder).

	I (and, I hope, HP) would be interested in hearing other users'
opinions on the subject. Am I expecting too much from the machine? Are
there instances in which "Life is short and ROM is full" is not the
appropriate answer? And if this is not such an instance, could HP supply a
RAM-based solution (i.e., a set of *fast* -- and presumably
machine-language-based -- programs for *flexibly* controlling the screen
during input? Would other users welcome this as much as I would?

	Again, congratulations to Mr. Wickes and the rest of HP on
building a marvelous machine. After a month of intensive use, the above is
my *only* significant gripe -- which, considering the fact that I'm a
dyed-in-the-wool curmudgeon, is high praise, indeed!