check now
In article <3rqktj$a4s_001@cc.utah.edu> vhadley@ee.utah.edu (Vince Hadley)
writes (comparing the TI-92 to the HP 48):
> I think in order for HP to compete, they are going to have to rethink
> their basic architecture in order to succeed. Everyone wants power, power,
> power- Power to handle more complex and diverse forms of symbolic math,
> power to do it and numerical calculations faster, and a more powerful user
> interface.
IMHO, the "basic architecture" you are asking HP to rethink really boils down to the RPL code embedded in the HP 48, and RPL is sufficiently powerful to handle more complex and diverse forms of symbolic math, and to provide a more powerful user interface. This leaves the issue of "faster".
While RPL is fine, the Saturn processor architecture that has fallen behind the times. The Saturn architecture was designed as a more general replacement for the Harvard architecture processors used in earlier HP calculators from the HP-35 through the HP-41 and -10 series. These earlier processors were amazingly well suited to simple BCD floating point calculation. For example, the HP-35 implemented a full featured non-programmable scientific calculator with only 768 words of ROM! Unfortunately they were not as capable for general purpose computing, and even the HP-41 stretched them to their limits. The Harvard architecture required many HP-41 microcode routines to handle two special cases depending on whether the "user code" program was stored in ROM or RAM.
Some of the Saturn design goals must have been (in no particular order):
Goal 1 (low power consumption) will always be critical for handheld devices. A major part of the traditional way HP (and most vendors) handled this goal was by keeping the clock rate low. This is fine when you press the cosine key manually and get an answer in a half a second, but more sophisticated calculators will require more horsepower. It can in fact be shown that reduced operating frequency is actually less energy efficient (Burd and Brodersen '95, Proceedings of the 28th Annual HICSS Conference, Jan. 1995; Vol. I, section 5.2, available on the web from http://infopad.eecs.berkeley.edu:80/infopad-ftp/papers/1995/energy_efficient_uproc.hicss28/.
Goal 2 (unified address space) remains quite worthwhile today, and any Saturn successor will likely have this.
Goal 3 (automatic configuration) is still important but can be provided by different means than Saturn used.
Goal 4 (low bus pin count) has been rendered obsolete and goal 3 _must_ be achieved in a different fashion because of cost issues that have been recognized more recently. With the advent of the HP-28S, HP realized that the only practical way to offer larger memory capacity was to use industry standard RAM chips rather than the custom RAM chips with the Saturn bus structure which were used in the HP-71B, HP-18C, and HP-28C. Then when the HP 48SX was desgined they extended this reasoning to memory cards.
Advances in technology have allowed each successive generation of Saturn processors to be faster, from the original 650 KHz (if memory serves) of the HP-71B to the 4.0 MHz of the HP 48G and HP 48GX. Unfortunately one of the drawbacks of using a proprietary processor is that you typically can't take advantage of the cutting-edge process technology that is available to mass-marketed processors. The Saturn processor in the HP 48G is probably faster at BCD floating point math than the 68000-derivative processor in the TI-92, but for non-numeric problems (including symbolic algebra and calculus), the 68000 is probably the winner. Over time we are calling on our calculators to do more and more non-numeric operations.
Part of the reason the Saturn can't keep up with the 68000 for non-numeric operation is that the 68000 was designed to take advantage of a wide data bus, whereas the deliberately narrow bus of the Saturn keeps the memory bandwidth low. Since the narrow bus requirement no longer exists, it is reasonable to expect that HP will switch to a new processor architecture for future calculators.
Fortunately, RPL is not strongly tied to the Saturn architecture, although the current implementation is. It is very plausible to expect to see RPL running on a RISC processor. There have recently been many silly claims posted to this newsgroup that the next generation HP would have a PowerPC, Sparc, or similar high-end RISC processor. While these claims can certainly be dismissed as wishful thinking, there are a number of power-efficient RISC and hybrid RISC/CISC chips which would be quite suitable, such as the ARM, the Hitachi SH series, the NEC V8xx series, etc. It isn't completely inconceivable that they could use a low end HP Precision Architecture processor, although I don't know of any existing HP PA implementation that would be suitable.
> The thing that will always win out for me though is "STAY with
> RPN" while doing the rest.
To increase market share it may be necessary to put more "traditional" (i.e., non-RPN) functionality into future units. Yes, I know about algebraic objects in RPL, but to fully take advantage of the power of the HP 48 it is necessary for the user to learn RPN. Many people resist this. HP has flirted in recent years with non-RPN calculators such as the 17B and 19B, but I must surmise that they realized that they had alienated loyal customers since they added RPN capabilites back in with the 17BII and 19BII.
I am personally not the least bit opposed to HP making efforts to increase the accessibility of future high-end HP calculators to the masses by making more capabilities usable with algebraic entry, as long as they don't forget their loyal customer base who want RPN. If RPN is removed, or becomes the less-supported "other" mode, I will be much less inclined to buy HP.
Cheers,
Eric
Back to my HP Calculator page
Back to my home page
Last updated September 7, 2000
Copyright 1995, 2000 Eric Smith