bio_zwbb@jhunix.HCF.JHU.EDU (Dr. William B. Busa) (08/03/90)
Having searched repeatedly through the FM (as in RTFM), I cannot determine how to turn alpha mode on *from a program* in the HP48. Surely there must be a way -- hard to imagine the 48 would lack a capability of the 41! Am I missing something, or is it impossible? Is there a pair of SYSEVALs which will turn alpha on and off? By the way, I realize that INPUT allows you to specify alpha on, but that's no help -- I'm writing a program which serves as an alternative to INPUT, allowing one to design whatever sort of input screen one wants in PICT. HELP!
billw@hpcvra.CV.HP.COM (William C Wickes) (08/07/90)
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?
bio_zwbb@jhunix.HCF.JHU.EDU (William Busa) (08/07/90)
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!
bill@videovax.tv.tek.com (William K. McFadden) (08/07/90)
Could you use 0 WAIT in a loop with a lookup table to achieve this? I agree
it's not pretty, but it might be a way around having to use INPUT.
--
Bill McFadden Tektronix, Inc. P.O. Box 500 MS 58-639 Beaverton, OR 97077
bill@videovax.tv.tek.com, {hplabs,uw-beaver,decvax}!tektronix!videovax!bill
Phone: (503) 627-6920 "The biggest difference between developing a missle
component and a toy is the 'cost constraint.'" -- John Anderson, Engineer, TIpedz@bigben.mpd.tandem.com (Perry Smith) (08/07/90)
I agree completely with William Busa. The thing that HP might have missed is they have produced too good of a machine. I did not buy the 48 for a "calculator". Instead I bought it as an electronic check book. (Something which the market still has not addressed.) I use it to hold all my check entries and I sorta went off the deep end and added all of my credit card transactions and all sorts of neat stuff. Sure it is not a qwerty keyboard but alot of the personal orginanizer things are not qwerty either. Plus I am such an HP bigot that I literally can not deal with anything but RPN when I want to use a calculator. So the point is that I think I am probably using the machine for something they never envisioned. Back to the basic question though: the INPUT and PROMPT things are not enough. I think the original intent was to use menus more than I do now but it just doesn't fit in my application. It might also be that I am use to the 41's style of input which is not really what the 48 does. pedz
scottb@hpcvia.CV.HP.COM (Scott_Burke) (08/11/90)
Yes, 0 WAIT with lookup table is the way to go. See the Equation Library interactive molecular weight calculator for an example that uses GROBs and the graphic display. Also see my later post on this subject. scott.