Hoping for a new high-end RPN calculator



#43

I'm hoping for a new high-end RPN calculator. It might be called the HP 45s or 65s for historical reasons, as was the new 35s. But it would draw inspiration mostly from the 41CX, 42S, 35s, and 50g. It would continue or improve on the newly-rediscovered (35s, 50g) traditional, professional look and quality key-feel.

It would have alphanumeric capability for globally naming programs (and variables?), as well as for constructing prompts and labeling outputs. It would have local numeric labels.

It would have modern I/O, such as USB for direct connect to computers and peripherals (such as a small printer), as well as an SD card slot.

It would have a large memory, a large function set (including time functions), and be fast.

How powerful can/should a top-of-the-line RPN calculator be? What features do you want in such a machine?


#44

GPS...

That would be way, way cooool man!


#45

For what? Tracking fool who steel your calculator?

I would like something that have softkeys as well.


#46

Seriously, I think that would be usefull for a lot of application (survey type, navigation(!), atronomical, recretional) and now that we see nokia putting it in more and more telephones why not.

It would also give you access to accurate atomic time.

Edited: 21 Aug 2007, 3:46 p.m.

#47

GPS functionality might be useful in surveying. GPS plus timer functions would be great for geocaching competitions. A rugged, rain-proof case would be helpful for all outdoor applications.

How about a large display, perhaps square for distortion-free plotting and graphics? Perhaps the display could be faster, higher-resolution, and even color.


#48

I am going to be hated for this...., but here goes....

Java SE with special API's to the native machine, done right could be a killer in terms of third party development.


#49

Oh, please. No Java.

The GPS is a great idea, though. Fantastic for astronomy.

Another Norwegian... cool.

#50

Quote:
GPS...

USB host would get you GPS plus a lot more.

Regards,
Howard


#51

As would bluetooth.


#52

Quote:
As would bluetooth.


Ah, yes. But USB host would get you bluetooth. 8)

Regards,
Howard

#53

Yea... but (and I'm the only one, I mean history flooded with navigation (aviation!), survey apps of hp41* stuff), and soon every cell phone size less than this will have gps... Get out of the box I say...

Thing is, I programmed years ago some embedded java stuff connected to raw gps receiver, that was cool programing stuff...

And (sorry to repeat myself), it take cares of your time needs..., those birds are flying atomic clocks...

#54

My calculator has GPS, and long range (1/2 mile) bluetooth already. . . :-)

TW


#55

Not all of us can go out and design/build a cool system extension for the 50g, Tim. 8)

Although, that's a darned good point. We know that the 50g is capable of doing microcode simulation of the HP41, the Voyagers, the 71B, and 42S. Why not turn it into the ultimate RPN keystroke programmable calculator, not through emulation but with a new implementation. Why wait for hobbyist hardware (sorry, Eric) when you've got a fairly stable mainframe that is flash upgradeable, has a choice of targetable architectures (i.e. ARM or Saturn, C/C++, User or System RPL,) and a solid keyboard, though with an under-endowed ENTER key? (What do you want to bet that the follow-on high end machine will remedy that deficiency?) You get flash, a large RAM and SD out of the box. And with your nifty enclosure, Tim, it could have bluetooth too. (Dual bluetooth, right?)

I wonder if a collaborative project to build software for something like that could work? OpenRPN seems to have made quite a bit more progress on the software side than the hardware, for example. And you wouldn't be breaking new ground as to the development or distribution models. It could be hosted on Source Forge, for cryin' out loud!

I vote for 50rpn as the project name. 8)

Regards,
Howard


#56

50g features that could be made available to an RPN OS running on the machine:

  • Nice display
  • Solid keyboard, though busy.
  • Secure Digital Storage
  • Sorta-kinda RS-232
  • USB slave
  • Bluetooth via Tim's surveying case
  • Flashable OS
  • Lots of RAM
  • Anything else?

The form factor isn;t what most people here would like to see, but check out how well the above tallies with the rest of the wish list!

Regards
Howard


#57

Quote:
50g features that could be made available to an RPN OS running on the machine:

But the 50g already has an "RPN OS" built-in!

Perhaps you'd like to handicap it with a 4-level stack? Require line numbers for each program step? Require GOTO instructions instead of using program structures? Add more restrictions to what names can be used?

I don't think that the RPL models are perfect, but any of the above seem to me like steps in the wrong direction.

If anyone feels up to the task of writing a new OS for the 50g, suit yourself; no doubt the hardware is capable of quite a lot.

Regards,
James


#58

Actually, I was sort of toying around with this idea.

Someone, somewhere, here, earlier mumbled something about having a "generic calculator" platform to develop, well, calculators. The "Generic" or "Blank" Calculator.

And, frankly, modulo the form factor, the 48-50g series is, essentially, exatly that.

Anyone so motivated can make those machines do most anything.

There is a line crossed by the RPL machines when they crept away from being "keystroke" programmable. I mean, I guess you could program these things using all of he soft keys and what not, but it doesn't take long for one to drop that and simply key the program in on the alpha keyboard.

What make keystroke programmables nice is their coarsness and simplicity. Keystroke programs start as little more than "watch me" macros, which makes it much easier for someone trying to replicate a complicated equation. Obviously folks can take it far beyond that, but more casual users can more easily program a keystroke progammable simply because doing so is little more than what they would normally do on the calculator.

So, for some, that's what makes somethng like the 35s more compelling than a behemoth like the 50g. That keystroke ease of use.

But it would be interesting for someone to try and convert a 50 into a keystroke machine, rather than a RPL machine. At the core, all of the capability is there. The 50 series will pretty much do anything a calculator can do, and has all of the core routines. So, the game isn't so much function and algorithm design, rather it's a design of user interface.

Realistically, that's all a calculator is today. A compromise between functionality and interface. How to cram usable and friendly power and functionality into a bunch of buttons and 1 or 2 lines of text.

There other non-functional requirements, mostly battery life and performance, but the balance and elegance of a calculator is pretty much all interface.

An interesting example of this comes from an industrial applicaton I wrote for the 48 series several years ago. This fellow was working on a design for resource tracking, and he started out with a bar code scanner. It was interesting to see how his design expanded until the user was expected to run around with a bunch of double sided flip cards packed to the gills with bar codes to scan. Eventually, he was even considering giving them a single card with 10 barcodes (one for each digit) on it and a list of code to be scanned in, digit by digit, with the scanner.

I asked him "So, you expect the users to basically key in numbers using a bar code scanner?"

Yea, it does sound silly. But with the bar code scanner as the hammer of the day, that was how the design was progressing. At that point the bar code scanner was obviously the wrong tool for the job.

But the core problem we found wasn't the data, or the process, but it was all form factor and interface.

Turns out that a 48 with a serial port, those bright orange nylon pouches, and some custom software, and a bit of "White out" and a ball point pen for some custom keys was the hot, outside the box solution to the problem.

And interface is what defines a calculator, and seperates the good from the bad.

Back to the 50, as I said all of the math is there. But also, all of the interface is there as well. You can reprogram (even from just User RPL) pretty much every key on the keyboard. Most likely the ON and R/L Shift keys may not be available from User RPL, but every other one is. And with a bit of Sys RPL, those too may be up for grabs. You can address every pixel on the display, and make the thing sing Yankee Doodle Dandy. I/O, clocks, gobs of RAM.

So, to me, it seems that the 50, with a little bit of sofware to handle some infrastructure, would be a calculator hackers dream experimenters tool.

The truly motivated could obivously reflash the entire machine from the core with compiled code. But so much is available to even the "lowly" User RPL user.

No doubt, much of this work would be done with an emulator, but the samples can then be downloaded to the machine to try out in real life. Heck, strip the case and make some custom dry transfer labels for your custom key sets. A little paint and a steady hand can redo the keys themselves (though they may not last).

Basically, for folks motivated to reinvent the calculator, there's a machine out there that's reinventable: The HP 50. (I dunno if the TI's are as flexible)


#59

Quote:
The truly motivated could obivously reflash the entire machine from the core with compiled code. But so much is available to even the "lowly" User RPL user.

That's what I meant by "has a choice of targetable architectures." There are multiple levels at which you could implement your dream calculator. (Why use compiled code? ARM machine code at 75MHz just might have a performance edge.)

Regards,
Howard

#60

Quote:

So, to me, it seems that the 50, with a little bit of sofware to handle some infrastructure, would be a calculator hackers dream experimenters tool.


The 48 series was certainly exactly that. Metakernel, anyone?

Regards,
Howard

#61

A bridge to HP-IL would be cool, though (reuse of all HP-41/71 equipment)...

#62

Quote:
There is a line crossed by the RPL machines when they crept away
from being "keystroke" programmable.

Well, with all the operations available on the RPL models, even
with the various shift keys, you'd need an awful lot of keys to
make them truly "keystroke programmable". When you have too many
operations to fit on the available key combinations, you pretty
much have to use alternative entry methods such as menus or named
commands keyed in from the keyboard for some operations.
Quote:
I mean, I guess you could program these things using all of he
soft keys and what not, but it doesn't take long for one to drop
that and simply key the program in on the alpha keyboard.

True, RPL models give you some choices as to which method to use.
If I'm going to use commands found on one or two menus several
times, then I'll probably use the menus, and otherwise simply key
in the command name from the keyboard.
Quote:
What make keystroke programmables nice is their coarsness and
simplicity. Keystroke programs start as little more than "watch
me" macros, which makes it much easier for someone trying to
replicate a complicated equation.

So with the RPL models, instead of simply recording keystrokes,
you're recording named commands keyed in from the keyboard or a
menu. What's difficult about that?
Quote:
Obviously folks can take it far beyond that, but more casual users
can more easily program a keystroke progammable simply because
doing so is little more than what they would normally do on the
calculator.

It seems to me that a casual user ought to be able to write a
simple UserRPL program simply by starting the command line editor
with the UserRPL program delimiters, pressing whatever keys he
normally would for the problem, and then pressing ENTER.

Of course using program structures for branching and so on takes
more thought, but isn't the same true of using labels, GOTO
instructions, and so on the Classic RPN models?

Quote:
You can reprogram (even from just User RPL) pretty much every key
on the keyboard. Most likely the ON and R/L Shift keys may not be
available from User RPL, but every other one is.

Even those can be assigned, if you really want to do so, with
either the ASN or STOKEYS command. Offhand, I don't think that I'd
want to make any assignments to the ALPHA, LeftShift, or
RightShift keys, or combinations that include them, but in case
you're not actually using them as shift keys, why not? But do
leave yourself an easy way to switch out of user mode.

Certain of the "Shift Hold" key combinations could be assigned,
but wouldn't be usable: 70.41 (hold down ALPHA and press ALPHA),
80.21 (hold down LeftShift and press LeftShift), 80.51 (ALPHA hold
down LeftShift and press LeftShift), 90.31 (hold down RightShift
and press RightShift), and 90.61 (ALPHA hold down RightShift and
press RightShift).

Other than the above, including the various "Shift" and "Shift
Hold" combinations, each key can have as up to 11 user key
assignments.

The ON key, including all six key "planes" and the "shift hold
flag", can be assigned however you wish. In case you assign
anything to 101.10, with the calculator off, pressing ON simply
turns it on, and with the calculator already on, pressing ON
invokes the assignment.

But would you want to assign anything to the ON key? Well, you
could replace the standand 101.10 assignment of the CANCEL
operation (which beeps and displays an "Interrupted" message box
if a program is running) with the program \<< #DFFh DOERR \>>,
which is normally used to abort any execution to run a control
alarm, and seems less annoying. If you have a STARTOFF program,
then you might want to replace the standard 101.30 assignment of
the OFF command with the reserved variable name 'STARTOFF', so
that the program will run with you manually turn the calculator
off, instead of when it does an automatic turnoff.

What can't be assigned are the various "hold down ON" key
combinations.

You can also use the DELKEYS or STOKEYS commands to suppress some
or all standard key assignments while in user mode; pressing an
unassigned key simply causes a "bad keystroke" beep.

Note that you can get yourself into a situation where you can't
easily get out of user mode because 70.20 doesn't have its
standard assignment, or even have all keys disabled while in user
mode, so that you can't even use -62 CF. If this occurs, to get
out of user mode, invoke a warmstart by holding down ON while
pressing C, or use the "paperclip reset".

Wolfgang's Keyman library, among other things, adds the ability to
assign to "double-click" and "long-pressed" keys; see
http://page.mi.fu-berlin.de/raut/WR49/index.htm#Keys.

KEYEVAL is a somewhat related command that can invoke whatever
operation is assigned to a keycode. While in user mode, if a
positive keycode is used, then the user key assignment is invoked,
and if a negative keycode is used, then the standard key
assignment is invoked. When not in user mode, the standard key
assignment is invoked, regardless of whether the keycode is
positive or negative. This could be used to invoke
non-programmable operations, but do so with caution; there may be
a very good reason for not making such an operation a programmable
UserRPL command.

Regards,
James

Edited: 24 Aug 2007, 2:16 p.m.

#63

Hi, James.

We've been down this road before, have we not? 8)

Regardless of what you implement, the point is that the 50g offers a great deal of flexibility in how to go about the implementation. You could use ARM targeted C code for performance critical routines, and SysRPL calls to leverage what is already on the machine. You could add hooks to UserRPL so that your simpler RPN programming environment could call UserRPL subs and be called by it. That would allow this to be an extension of the current OS.

My imagination about where to go with this would tend one way, and yours might tend another. But surely you have some idea of how you would improve the OS, if you had a bunch of help to rewrite code in C and create new stuff? If the 50g isn't "perfect" then that implies you would like to make changes, right?

Regards,
Howard

#64

Quote:
OpenRPN seems to have made quite a bit more progress on the software side than the hardware, for example.

The OpenRPN software is (was) aimed at making *fix which is essentially a beefed up RPL so it isn't going to be directly relevant to a key stroke programmable environment.

I had some nefarious ideas on how to implement key stroke programming under *fix without interpreting stored key codes. See sflib/rpn.sfix from the repository for details.


- Pauli


#65

Have you considered targeting the HP50g with the OpenRPN stuff? (Regardless if it's what this crew is after, you could blaze a trail for us. 8)

Regards,
Howard


#66

Personally, I hadn't. I believe there were discussions about it but I've no recollection what became of them.

- Pauli


#67

It was discussed and even attempted on the 49g+ but as I recall there were some issues getting code compiled and running on that platform. In terms of long-term goals I want to see *fix running on an HP someday.

For more details on *fix and OpenRPN check out www.openrpn.org in the coming weeks. The project has picked up a new host, so the site will be up all the time. Short-term plans are to restore the wiki and implement a simplified main webpage.

-Hugh

#68

You've basically described the concept behind the *fix core, which is a minimal subset of commands that provide the necessary foundation for all other commands. That way you can use it to build RPL, keystroke RPN, BASIC, or whatever else you please without too brutal of a learning curve.

If current 50g c++ development tools are up to the task I think it would make a great platform for the testing and development of *fix, with a great potential to generate more interest within the HP community.

#69

given its size and weight it should do a lot better than that ;)

#70

While some of these thoughts may be mutually exclusive, I'll continue:

1. Package size of HP42s (i.e. 32sii)-truly shirtpocket size.

2. Some sort of I/O - preferably wireless.

3. Memory Card Slot.

4. Clock / Calendar.

5. Beeper (some sort of audible output).

6. Graphic Display (not too big - perhaps like the 42s).

Further thoughts:

Actually, having a Memory Card slot would defeat part of the reason for the I/O - this card would be used to get programs in and out of the machine. Of course the output for an 'Execution-Time' printer is handy. On that note, thermal printer mechanisms are so ubiquitous these days (credit card machines, gas-station printers), that it would seem someone could make a HP IR style printer quite cost effectively. Thus perhaps just an IR I/O like the 42s would be sufficient. I would suspect that Bluetooth or 802.11 would be cost and power prohibitive.


#71

I think memory card slot not just for I/O, but also for extra storage, so it not redundant, but good thing.

#72

Um, you're kinda describing the HP-48s family. Except for size. ;-)

thanks,
bruce

#73

I've said this before, but I'll repeat myself...

My perfect high-end HP calculator already exists, and it's called the HP-50g ;^) The only things I would do to improve it would be as follows.

  1. Replace the keys with the same type used on the HP 35s.
  2. LARGE ENTER KEY!
  3. Optional Higher resolution display. Maybe the same as the TI-89, 160x100 pixels.
  4. Optional Move the SD card slot to the top, for easier use with SD expansion options such as SD GPS cards.

Note that these are very minor and simple changes. Nothing too crazy here. I don't want it to toast my bread, walk my dog, hover, pick up the kids after school, and tell me it loves me while brushing my teeth. I just want it to be a great calculator. The 50g is already a great calculator, and a 50gII with 1 & 2 (and optionally 3 & 4) would just be that much better!

* Caveat: I grew up with RPL. I learned it first, on my HP 48SX. Pure 4-level-stack RPN is new to me, and while it is very fun, it's still not as natural to me as RPL is. So your milage may vary!

Edited: 22 Aug 2007, 12:50 a.m.


#74

I don't agree that HP calculators need a double-width ENTER key. For a given keyboard layout design with a single-width ENTER key, substituting the double-wide key would result in the loss of one key with its several functions. I would like to see a high-end RPN machine as well as future even-better RPL machines, but I personally prefer a single-wide ENTER key in the easy-to-find lower-right corner, like the 50g.


#75

GASP!

I... I don't know what to say! It's like you've just blasphemed against all that is holy!

;) ;) ;) (three smilies, to be extra sure that my ribbing is understood to be good natured)

#76

Dear friend! See the beheaded bodies lying there on the ground? Those were the last ones who didn't believe in DOUBLE WIDTH ENTER. Now, it's all up to you, make your choice ... (taking out my wand, grinning evilly, thinking about "cruciatus").

Caveat for USA: Statements in this post may look more dangerous than they are. This post MUST NOT be used for frightening children ;)

Edited: 22 Aug 2007, 2:52 a.m.


#77

Oops! I think I'll get out of town for a while.


#78

Are the same folks who would seemingly kill to keep a double-wide ENTER key the very *same* folks complaining about the lack of R->P and P->R function keys?

Just curious which people would rather see/have to use regularly.

#79

I have recently upgraded from the 48g to the 50g. Sorry everyone, but the double wide enter key is not that big of a thing to me. In fact, if you enter information with two thumbs while holding the calculator with both hands, the enter button at the lower right corner is actually more convenient to me.

I've really enjoyed using the 50g so far. Durability, of course, remains to be seen whether it will last as long as my 48g (which still works fine by the way).


#80

Just my own personal opinions:

1. Use the basic 35S shell, but add one row of soft keys.

2. Make the display 4 lines; default would show all 4 levels of the stack;

3. Add a SD slot capable of SD I/O, open up the programming interface so that device drivers could be written for various SDIO cards, and make the slot SDHC compatible as well.

4. Think about changing the battery pack to a rechargeable pack of some sort, with the ability to use AAA batteries. The rechargeable pack could be optional.

5. Address the software bugs, and fix the base conversion and complex math/Polar-Rectangular irritations. Possibly add Matrix math capabilities.

Try to get all this done for $100-$120. The 50G has a graphical display; this would be an RPN calculator that fits above the current 35S, NOT as a replacement for the 50G.

Kostas


#81

Kalinichta sou, Kostas,

we have something almost in line with your proposal here already. What you cannot see, of course, is the SD slot and the socket to connect the charger ;-)


#82

Walter:

I think most people would still want a set of soft keys, perhaps as the top row of keys. Could also be used as alphanumeric keys when not being used for calling programs/routines. The additional keys would allow for the base conversion to be added as shifted functions to the other keys, as well as the complex math/matrix functions. It would be a nice to have to have a really fast CPU, but the HP-35s hasn't really generated many complaints regarding execution speed. Another nice to have would be more on-board RAM, to allow even larger programs to execute. I would think that the bracket keys could also be dispensed with, making this a true, RPN only, calculator.

The 45s concept is really good, and a very nice keyboard layout.

Kostas

PS. Have a nice day (Kali Mera Sas).

#83

In all honesty, I think my desire for the wide ENTER key is a matter of familiarity and tradition more than anything else.

I find it difficult to get used to a calculator that has a small ENTER key in the lower right, because I've been using HPs for so long that my motion memory just expects it to be above and to the left of the number keys, as it is on the classics, spices, coconuts, pioneers, and 48s. It's just what I'm used to, so that's where my finger goes by default.

I could probably retrain my brain, and it's really not a deal-breaker. I can live with an small enter key. But I greatly prefer the big enter key :)

#84

I definitely DON'T want a machine with a large screen like the 50g. I want a machine with the feature set of the 42s plus I/O (e.g. usb) that I can fit into my shirt pocket.

I want the keyboard feel of the new 35s.

I also want it to have base conversion that works in the base currently selected that I don't always have to prefix when I enter a hex number.

In fact there is probably scope for 2 new machines. The first as I have described above and the second which would eventually replace the the 50g, if required, which would be a large screen graphic calculator.

I want a proper high end CALCULATOR, not something that's competing with my mobile phone or laptop, e.g. with GPS, Java (read sloooooow, etc).

Cheers, James.


Possibly Related Threads...
Thread Author Replies Views Last Post
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 1,228 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  Another non-HP RPN vintage calculator joins the collection Michael de Estrada 2 974 07-23-2013, 04:10 PM
Last Post: Walter B
  OT: RPN calculator/dmm by ESI Kees van der Sanden 2 822 05-25-2013, 01:38 PM
Last Post: Kees van der Sanden
  "HP RPN Calculator Users" group on LinkedIn Philippe Lasnier 6 1,224 04-27-2013, 03:27 AM
Last Post: BruceH
  HP85 tape reader; end of tape detection inaki 9 1,598 04-25-2013, 02:25 PM
Last Post: Paul Berger (Canada)
  New high def picture of new TI-84 Plus Color SE Mic 17 2,303 11-26-2012, 04:17 PM
Last Post: Luiz C. Vieira (Brazil)
  HIGH END HPs.. Status Symbols?? John W Kercheval 13 1,742 05-09-2012, 12:55 AM
Last Post: Matt Agajanian
  End of my 32SII? kc 2 535 04-07-2012, 10:57 AM
Last Post: Jim Yohe
  HP 20S with very high "off" current Neil Hamilton (Ottawa) 2 578 04-01-2012, 11:49 AM
Last Post: Neil Hamilton (Ottawa)
  OT: RPN calculator for Garmin GPS hpnut 3 692 03-22-2012, 08:44 AM
Last Post: Andrés C. Rodríguez (Argentina)

Forum Jump: