The Museum of HP Calculators

HP Forum Archive 07

[ Return to Index | Top of Index ]

PPCCJ Editorial: HP-42 (1981)
Message #1 Posted by Ernie Malaga on 11 Mar 2002, 1:13 a.m.

I read the following Editorial in the PPCCJ (V8N1P4, Jan/Feb 1981). Comments?


* * * * * * * * * * * * * * * * * *

EDITORIAL by Richard Nelson (1) From PPCCJ, V8N1P4 (Jan/Feb 1981)

The HP-41C was announced 19 months ago. Its power and capability caught TI without a competing product "on the shelf," and they are rushing a new TI-59 replacement to market as fast as they can. The introduction of a new top-of-the-line PPC from TI will cause users to focus on the future of PPCs. The HHC Sharp PC1211, soon to be available in the U.S., adds a new dimension to the PPC vs. HHC discussion. The PC 1211, even though it is slow and has too little memory to be a serious computer -- see box -- has the features of extended accuracy numerical functions that have been the mainstray of PPCs. If future machines follow this trend, the HHC will absorb the PPC. If this is indeed true, there will never be an HP-42. HP PPC history will be recorded as 65-67-41, two generations of products.

The question is, do we want, do we need, a product that continues along the design trends that the 65-67-41 have set? I, for one, believe that we need and want an HP-42. Here are a few thoughts on the 42 and its general features.

* The 42 should carry on the tradition of the PPC. It should have full alpha capability, but its design should emphasize the numerical processing of data. In computer terminology, it should be scientific rather than business.

* The 42 should retain a key-to-function keyboard operation. Prefix, shift, and fully assignable keys should be the guiding philosophy. A full keyboard is OK, typing for alpha is OK, but one- or two-key, machine functions, should be designed in. Typing SIN for sin is not acceptable. This convenience PPC users are accustomed to will require new keyboard designs. Keyboards have been static for 5 years, yet this is the primary man/machine input interface.

* The 42 should provide increased numeric handling capability. Full logic compares; data packing; full functions like quotient/remainder instead of MOD; characteristic/mantissa operations; digit rotate, invert; and Register Block operations such as exchange, increment, move, rotate, extremes, sum, statistics, sort, etc.

* The 42 should be micro-programmable in that the user may allocate memory stacks and registers as he wishes. Subroutine levels, argument ranges, program/data, etc. could be restructured by the user under program control. The basic machine would be structured and disciplined like the 41, but a lower-level capability would exist for the skilled programmer.

* The 42 should be a _programmer's_ machine. It will be up to the _programmer_ to make the machine a user's machine. The 41C is _not_ a programmer's machine; it is a compromise to appeal to the layman. The 42 should not be a raw microprocessor where every bit must be managed by the programmer. It should have a higher-level user calculator language, but not a computer language that manages everything for you.

* The 42 should be functionally built upon the 65-67-41 "logic," but should break free from the obsolete architecture of the HP-35. The 42 should be a mainframe that is capable of communicating with other peripherals as a system just like the 41.

* The 42 microprogramming capability should provide for a programmable clock rate so the user can trade off power consumption for speed if he desires. It _must_ be crystal controlled so time becomes a dimension for the programmer to manage if this is the optimum solution.

* The 42 must be hardware alterable. EPROM capability must be designed in the machine, and it should be hand held and operated. Perhaps an extended keyboard could be a peripheral for "full" microprogrammability.

* The 42 should be a shirt pocket machine in the PPC tradition.

The HP-41C was probably designed as a 5-year product. Its life is 1/3 over. The 42 should be well into the product definition stage. If it is not, perhaps we, the users, should "design our own" here, in the pages of the Journal. I know Bill Kolb believes in the 42. Perhaps a design team could be assembled to oversee various aspects of the design. A "42" column could be run each issue with the various group leaders coordinating readership input. Members could take charge of such aspects as math functions, data handling functions, keyboard layout, instruction syntax, etc., etc.

If we are to get an RPN-like machine in the future, we will have to make the manufacturers aware of our desires, otherwise we will have to live with BASIC, a desktop machine, and the inconvenience of spelling out the function instead of pressing a key.


How sad HP never listened to the man who knows best
Message #2 Posted by Gene on 11 Mar 2002, 7:37 a.m.,
in response to message #1 by Ernie Malaga

Imagine the state of things today had HP hired Richard 20 years ago.

Makes me want to cry. Gene

Re: How sad HP never listened to the man who knows best
Message #3 Posted by Steve Borowsky on 12 Mar 2002, 1:50 a.m.,
in response to message #2 by Gene

It's not that simple. The HP of 20 years ago was not unsympathetic to Richard's vision. Just look at the 41. Where the lack of sympathy ultimately manifested was in the public mind - a huge potential market that didn't have the willingness to be open to a different but better way of doing things, and instead took refuge in a prideful scorn based on self-chosen ignorance. HP didn't have to hire Richard; he was already tirelessly working to promote the ideas embodied in HP's calculators. He probably did more for HP from the outside than he could have done from within.

Re: How sad HP never listened to the man who knows best
Message #4 Posted by John K. (US) on 13 Mar 2002, 1:59 a.m.,
in response to message #3 by Steve Borowsky

All too true. But, unfortunately, virtually irrelevant.

These types of high-end computing devices generally appealed to two types of users: those who needed to perform a well-defined set of relatively complex calculations of a predetermined nature on a regular basis, and those who were -- for lack of a better term -- hackers (in the non-pejorative sense). In both cases, the general purpose computer now fills that niche.

Your average personal computer, equiped with a decent spread-sheet app, is orders of magnitude more efficient than a programmable calculator at performing complex, multi-variable calculations on multiple sets of data -- the raison detre of programmables. For truly specialized fields, there are other equally specialized apps available.

Hackers, on the other hand, have always gravitated toward the most "powerful" and "elegant" (quotes because each tends to define these differently) new toy available, so again that role is filled by the personal general purpose machine.

Even in the handheld and high-end calculator arena, the trend has been toward general purpose processors. With the exception of the HP line (and, arguably, to their detriment), all of the current graphing calculators I know of are built around general purpose chips. The TI line, for example, uses the same Motorola 68K architecture also used by current Palm OS devices and all pre-PowerPC (c. 1993 and earlier) Apple Macintosh systems.

Though sad, it is not entirely surprising that HP decided not to persue Richard's vision. It is said that the surest way to go out of business is to chase after a larger share of an ever-diminishing market. In their glory days, HP calculators were a premium product for which HP charged a premium price. The unfortunate truth is that the economics of the market changed with its demographics; there are no longer enough people willing to pay that premium.

Where does that leave us? Well, I guess we are simply the Last True Believers in a now-fading and somewhat tarnished icon of technology. Ours is the pursuit and preservation of what is, ultimately, a genetic dead-end of computerdom, eclipsed by the fitter and more agressive general-purpose microprocessor. Though a case can be made that portability and convenience have been sacrificed on the alter of progress, omens abound and things auger badly for the offspring of Corvallis.

[N.B. If anyone is so depressed by the above that they decided to abandon their HP collection, please contact me directly. I am more than willing to give a good home to technological dinosaurs. ;^) ]

Re: How sad HP never listened to the man who knows best
Message #5 Posted by Steve Borowsky on 13 Mar 2002, 7:33 a.m.,
in response to message #4 by John K. (US)

Yup. Very well said, John. The one option for HP as the market shifted was to appeal to the growing education market, but HP's engineering-optimized interface didn't appeal so readily to the student-teacher crowd. The fact that TI Sharp and Casio all went with AOS also made RPN a particularly hard sell in a market that was looking for a universal standard and didn't have much time to find it. The higher selling price and the 'odd-man-out' user interface made HP calculators both intellectually and physically expensive for the budget-conscious education market.

Re: How sad HP never listened to the man who knows best
Message #6 Posted by John K. (US) on 13 Mar 2002, 7:39 p.m.,
in response to message #5 by Steve Borowsky

Thanks, Steve. Actually, I had intended that in reply to Gene's post. I guess that what I get for trusting my browser's "Back" button to do its thing unsupervised.

"Why, back in the good ol' days, when you pushed an honest-to-goodness physical button, the machine did something, by gum..."

Re: How sad HP never listened to the man who knows best
Message #7 Posted by Steve Borowsky on 14 Mar 2002, 5:34 a.m.,
in response to message #6 by John K. (US)

Oh well, that's alright. I think you're right though that this is mainly an issue of technology changing the focus of problem solving from calculators to other platforms. Where esle do you find high-end calculators today except in classrooms?

Sure, it would be nice if HP's had a large part of that market but it didn't work out that way.

I find it interesting that 20 million Palm Pilots, including clones, have been sold since 1996. Shows there's a need for a handheld computing platform; it's just not exclusively focused on math/engineering as it once was, though that option is available.

Re: How sad HP never listened to the man who knows best
Message #8 Posted by Ren on 14 Mar 2002, 10:37 a.m.,
in response to message #7 by Steve Borowsky

Steve B. wrote: >I find it interesting that 20 million Palm Pilots, including clones, have been sold since 1996. Shows there's a need for a handheld computing platform; it's just not exclusively focused on math/engineering as it once was, though that option is available. <

Ren writes: Ah! but the main function of a PDA versus a calculator (IMHO) is the calendar, alarm, address book capabilities. That is why my PDA came with only a 4-banger calc program and I downloaded a scientific calc program and a "metric" converter program to extend its functionality. If those programs had not been available, I'd have to carry the PDA and a calc.

PDAs v. Calculators
Message #9 Posted by John K. (US) on 15 Mar 2002, 1:37 a.m.,
in response to message #8 by Ren

[T]he main function of a PDA versus a calculator (IMHO) is the calendar, alarm, address book capabilities. That is why my PDA came with only a 4-banger calc program and I downloaded a scientific calc program[...]

Well, it seems to me that a PDA really has no "main function" -- though they typically provide the functions you mention "out of the box". Rather, they are a generalized machine with a highly customizable interface. The fact that you were able to download a software calculator that met your needs argues strongly to my point. Though the size and power restrictions impose a number of limitations on what can be done with one, the user of a PDA has a much greater degree of control over how it is used than do the engineers who create them. Contrast that with, say, the HP 42S or 49G, or even a 41CX, and I think you'll see what I'm talking about.

PDSs v. Calculators
Message #10 Posted by Paul Brogger on 15 Mar 2002, 12:18 p.m.,
in response to message #8 by Ren

The evolving PDA is indeed a general-purpose computer, as opposed to a calculator. But I don't know that customization, in the form of easily-utilized programmability, has been brought to the PDA to anywhere near the degree that HP brought it to their calculators.

I just found a version of EMU48 (an HP-48/49 emulator) that works (more or less) on my iPAQ. (If interested, look for Leo Bueno's download page, or "EMU48" anywhere -- the sources are available under the GPL.) It has some serious limitations, but may be the basis for an RPN, HP-based programmable calculator for my future.

It's interesting (if not actually ironic) that hardware speeds are such that we can more easily emulate an HP product than re-develop an application as complex and easily used. (A telling feature of this EMU48 PDA implementation is that, in the simulated graphical display, one may touch the menu entries to activate them, and this behaves exactly as if one had pushed the corresponding top-row button.)

The mistake, I'm coming to believe, in most PDA calculator implementations is that the developer tries to simulate a calculator keyboard, and generally ignores the PDA's native input method (handwriting recognition and the point-to-click graphical screen). Without the original device's physical presence and tactile feedback, trying to cram four functions on a simulated button in an impaired graphical environment becomes an exercise in eyestrain.

Better, I think, to minimize the number of simulated buttons (maybe only "Enter", if even that) and maximize the use of screen real estate for display of, say, the entire stack and/or many lines of program code, with more indentation than might otherwise be displayed.

So, rather than a "SIN" button, simply enter "S", "I", "N" in the text recognizer (perhaps with a line feed to simulate keypress) and see more of the data being worked on, etc. A "catalog" function hanging off a menu somewhere can serve some of the function that the calculator keyboard has traditionally served -- that of a selection of most-used functions, readily presented.

I'm suspecting that, as an experiment, a "meta keyboard" layer can be inserted between the PDA and the HP-48G emulation, that the native text entry method may be used to simulate keystrokes, and that the graphical display might be but one window in a richer presentation. But I haven't thought it all through yet, and I'm going to have to re-learn C/C++ to try anything, so it's going to be a while. (But I can't imagine a more involving project!)

Anyway, the PDA is here for a while, and is an inherently more flexible and powerful machine than older calculators. As soon as its programmability is brought out to the average (non-programmer) user with an easy-to-use and -understand interface, I'll have more use for mine!

Re: PDSs v. Calculators
Message #11 Posted by John K. (US) on 15 Mar 2002, 11:09 p.m.,
in response to message #10 by Paul Brogger

Indeed. It's only fair to say, however, that several of the RPN calculator simulators for Palm OS (the platform I'm most familiar with) are just as easy -- if not easier -- to program than the HP calculators we all know and love. And it is much easier to add apps to (i.e. customize) both Palm OS and Windows CE machines than to any of the HP calculators I'm familiar with. Not only that, but if someone has the time and inclination, it is also possible to write software for both in high-level languages. Compared to the intricate fiddling required to safely create synthetic routines on a 41 or the maddening constraints of RPL on those small calculator screens, one has a very free hand to roll-your-own on a PDA. The learning curve is steeper, true, but much more rewarding.

While both of these are for Palm OS, you may want to take a (another?) quick peek at MathU Pro or Coconut. To a greater or lesser extent, both suffer from the screen-crowding problem you mentioned, but try to overcome them in interesting and, in the case of Coconut, novel ways.

One of the main limitations with PDAs in general, which your message touches on, is that they really are not suitable for non-trivial data input. Palm goes to great lengths to warn developers not to attempt to create apps that require the user to enter lots of info -- advise a surprising number of them seem to ignore. Considering Microsoft's "everything-including-the-kitchen-sink" approach to software design, I wouldn't be too surprised if the situation was actually worse on CE-based handhelds.

The meta-keyboard layer you mentioned is pretty much already there in Palm OS. The only thing required would be to trap the character entry events and assemble the command string in the application. I imagine that a similar technique would work for CE apps. Not trivial, but not rocket science either.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall