Input wanted


The 34s is pretty much finalised now. The F distribution still needs some work and no doubt there are other bugs which will eat into the available space. I'd like some serial IO which might or might not be possible even with a hardware modification.

Anyways, if we've some space left after the above, I'd like to ask for suggestions for extra conversions and constants to include. Straight multiplicative conversions (both ways) take 20 bytes and constants take 12 so we can squeeze them in pretty well.

I've added the WGS84 constants recently and the rest are documented in the manual. So any others we should include???

The WGS constants are: a, b, e^2, e'^2, 1/f, gm and omega. The constants b, e^2 and e'^2 are derived from the other four but are more commonly used. If you don't know what I'm talking about then don't worry, if you do I'm sure you'll appreciate having them.

- Pauli


I personally wouldn't mind some astronomical constants... you know, Earth/Sun/Moon mass, peri- and apo- distances (sorry, I don't recall the English name now) of some important orbits - again, Earth, Moon for example... I've often had to do some orbital calculations and these constants would be useful.



Apogee and perigee.

Will see what we can do. No promises yet, I've got some more work to do on the statistical functions and the possibility of another page of user programs remains open.

- Pauli


Thanks! :) If apogee and perigee (are they called apohelios and perihelios in case of orbits around the sun? :) can't make it in the library, then Earth/sun/moon masses are more important... in my direct, personal experience of course! :)


apohelion, perihelion (helios) are the terms I recall,
apolune and perilune, (lunar) IIRC from Walter Cronkite and CBS's coverage of the Apollo missions. so maybe apogee and perigee only relate to Earth (geo).

So what would they be for Kronos B^)


dona nobis pacem


Ren; slightly nearer target and slightly farther target. shields up!


It has certainly been mentioned a few times here that the missing matrix math is probably the biggest disadvantage of this (otherwise outstanding) WP34s calculator.

Now I've read in the manual that this missing matrix math is "due to display restrictions!!?

What's this??? Sorry, but I don't understand this at all, what special display capabilities would be needed for matrix input and output?

Ok, there's of course no way for a 2-dimensional display, but the matrix could still be entered, displayed and edited by single elements (e.g. showing the row and column at the upper dot matrix display).

I could have understood if the reason would have been explained by "not enough memory for coding all those matrix routines", but not those "display" reasons.

So can someone please enlighten me about the 'true' reason for NOT implementing matrix math - or about what I'm mis- or not understanding in this "display restrictions"?


Edited: 23 June 2011, 7:35 a.m.


Walter wrote the manual so he'll have to explain that phrase (and he's away from the Internet for a while).

The display on the 34s is pretty poor. Not being able to display two numbers properly was part of our reason to support the 32s's complex mode rather than the 42s's. Memory was of course the other major reason. Matrix support was omitted for basically the same two reasons: it is impossible to nicely display a matrix on the display and there isn't memory to do the job properly. I'm also of the opinion that if you want matrix operations, you should be using a real maths package like matlab or equivalent :-) I'd never be able to fit robust and fast routines for many of the desirable operations in -- numeric stability of matrix operations has many very heavy books written about it.

That said, there is easily space for a reasonable selection of user code matrix operations. I've thought about porting JMB's matrix code a couple of times. One or two pages of flash should be sufficient to hold the important routines and the conversion should be fairly straightforward. The biggest change I'd make would be to reformat the the matrix descriptors into something more user friendly e.g. bb.ccrr where bb is the base register, cc is the number of columns and rr the number of rows.

- Pauli


it is impossible to nicely display a matrix on the display and there isn't memory to do the job properly.

Displaying the row and column numbers in the upper line, and scrolling through the single elements with the 4 cursor keys would be a quite comfortable method IMO.

But of course you're right with the limited code space.
I'm also of the opinion that if you want matrix operations, you should be using a real maths package like matlab or equivalent :-)

Well, this would be true for doing ANY kind of maths, so for what should a pocket calculator be needed at all? For portability!

If I'm at home sitting on my computer then I'm of course using one of those powerful math/CAS programs but not any pocket calc ... ;-)


If somebody donates user code for matrix operations, we'd be quite happy to include it as a library. There is no way we're squeezing matrix support into the base firmware so it will have to be keystroke programming that saves the day here. Fortunately, this device is very capable on this front.

- Pauli


A question only, not a request. I'm happy with my 34 as is, and it's stability. However; some people might want to do matrices but not need (lets say) hyperbolic trig and constants. Did you guys think of having a couple of packages or the capability of assembling a semi custom 34 from some building blocks? This would of course complicate youall's and Eric's lives something fierce. Maybe we should forget i asked that.


No way am I going to do several different releases. One is quite enough :-)

If somebody else wants to put the effort into conditionally including some of the features already present and also into implementing other functionality again conditionally included, I'd be happy include that.

We've got conditional inclusion for a few features already (bessel, digamma, subfactorial, double factorial, Jacobi elliptic functions, factorisation and a few others). Adding more is straightforward.

The difficult part will be locating substantial pieces of functionality and cleanly removing them. The constants e.g. are relatively small at 12 bytes each. So removing them won't save much space but it will cause some big internal changes to the keyboard handling, the catalogue display, command display etc.

- Pauli


RE: "One is quite enough :-)"

One is simply amazing. Who would have thought it possible? You guys are the Gods of the programmable calculator, along with Katie, who is the Goddess because of the HP 94 RPN.

When Gene finishes that matrix program we will have a close approximation of the fabled "hp43", albeit with no more memory.


Thanks for the plug, but the HP94 RPN thing I wrote is just a dumb BASIC program to almost simulate an HP35. It was an attempt to justify having the HP94's in a calculator collection. The real challenge was to figure out how to use the development tools for the HP94 and rebuild the battery packs.


Oh, it really will not take huge programming skills to translate the M1 through M5 and RRM programs for the 34s.

Anyone *could* do it. I may end up being the one who does it only because no one else gets around to it.

I'll be back in the country tomorrow from an international trip and will be able to spend time getting it done.


Add an easy to read row/column display in the matrix display and we have a reasonably capable matrix package as an optional feature.

To load the package I'm still thinking of serial I/O. I've ordered the 3.3V FTDI cable and I plan to mod one of my calculators with an additional connector. I don't like the way HP's cable is connected to the back, there must be smarter ways.


I have been doin some early work to convert the ppc rom m1 thru m5 routines to the 34s and then the matrix, determinant and inverse and systems of equations program.

Should work and not take that much room

If someone writes something better ... Good :-)



You might want to give the WP-34s assembler/disassembler a try for this. There will be a bunch of examples go online tonight in the 'library' directory and I hope to see a manual by the weekend. The mnemonic syntax is the hardest thing but you can generate a reference table by using the following (undocumented) command:

$ ./trunk/tools/ -syntax syntax.lst
$ more syntax.lst

You might find the tool useful in 2 ways:

1) If you have already loaded the programs into the calculator, you can download the images from memory (emulator or actual calculator) and convert them to an ASCII source listing (which I am calling *.wp34s) for archive, distribution, or program merging:

$ ./trunk/tools/ -dis wp34s-0.dat > myProgs.wp34s

These source listings should also be immune to "opcode creep" as I am starting to call it. :-) Once your programs are in this form, if the opcodes evolve, you just reassemble with the current assembler. The assembler will be continually updated as part of the development process to use the latest opcode map by default. The tool can also read in historical opcode maps to convert between opcode revisions by specifying an older map (which you must have on hand -- usually just a SVN effort). Thus you can bring an old flash image "forward" by disassembling it using the old opcode map it was written under (you need the calculator's current 'VERS' number for this) and then reassembling it using the new map.

2) You can also assemble one or more ASCII source files into a single concatenated flash image (subject to the flash 506 word limit, of course) which can then be uploaded to either the emulator or calculator. This will allow you to have a library of programs that you load on a case-by-case basis.

$ ./trunk/tools/ myProg1.wp34s [myProg2.wp34s [myProg3.wp34s ...]] -o wp34s-1.dat

If you can't wait for the weekend to try it :-), let me know and I'll give you a boost.

The help screen combined with the stuff that will go up tonight in the 'library' directory should get you a fair distance down the road.

$ ./trunk/tools/ -h

You do need Perl on your system to run it but that is not such a big stretch. Info will be forthcoming if that presents some problems.



Oh, I just want to get it working first on the real machine. Haven't been able to devote enough time to it yet.

I believe all the pieces should fit in the 506 steps. Limiting factor here is the 100 registers. That limits the size of the matrix / system you can solve here...but it would STILL be much larger than any I would ever need to solve.


There is a second set of 112 registers in flash :-) You don't want to write to them often but they are usable and directly addressable via the RCF instructions and R-COPY.

But yes, the 100 registers is a big limit. That leaves a few over for the matrix code to use internally.

- Pauli


You could also go well beyond the 506 steps. There are several flash banks and more than one could be used at a pinch. It would also be possible to fake things and get four extra steps but it probably isn't worth the effort and would make the program not able to be entered via the keyboard.

- Pauli


I've been looking at Jean-Marc Baillard's matrix code and the programs looks like they will convert over pretty much as is. This is certainly true for the basic matrix operations. Some of the more advanced routines use the block register operations from the extended functions module & the 34s has a slightly different syntax here.

Of course, this won't produce optimal code for the 34s but it would do as a start.

- Pauli



I cannot think of any new constant right now, but having just keyed in a 100-step program I realized it doesn't make much sense the soft keys A through D keep assigned to existing user programs when in program mode. 1/x, y^x and SQRT are way more frequent than XEQ B, XEQ C and XED D in programs. Would this be easy to change?




This would be another "bad patch" in the not very cleanly designed keyboard state machine. I doubt Pauli will be implementing this change.


This one wouldn't be too difficult I think. It would probably simplify this part of the keyboard state machine -- not having the keys change function based on the presence of labels means a tiny bit less code. Those keys would still change their primary meaning in integer mode with bases > 10.

We'd also free up four other keyboard position and make sigma-'s location awful.

So it is a large change from an interface viewpoint even though the underlying code changes wouldn't be too awful.

I'll also agree that the keyboard state engine is big and ugly. Too much organic growth and stuffing additional functionality onto the keyboard.

- Pauli

Edited: 24 June 2011, 2:23 a.m.


This one wouldn't be too difficult I think. It would probably simplify this part of the keyboard state machine -- not having the keys change function based on the presence of labels means a tiny bit less code. Those keys would still change their primary meaning in integer mode with bases > 10.

I think this was only meant in program entry mode, not generally.

For a general change, we need a USER mode then.


For a general change, we need a USER mode then.

Insufficient RAM to keep keyboard definition.
At the moment at least.

- Pauli


What about a simple mode setting for those who prefer the simple functions. If the mode is set, you need XEQ A to run program A and get Sigma+ by just hitting A. Without the mode, the behavior is the same as it is now. This would be similar to the USER mode of the 15C.


That would complicate the keyboard engine :-(

I'll leave these questions to Walter....

- Pauli


Of course it can be changed but to what?
Those functions are elsewhere on the keyboard of course.

Walter is the custodian of the keyboard and he's off the Internet for a while longer.

- Pauli


I would leave the space empty for now in case more bugs show up. If/when there is another release, you might add some constants then.

It would really be a shame if bug fixes took up so much space that you had to remove functionality or constants. It's better to leave the extra room for now and add more later.

At least that's my opinion :)


Possibly Related Threads...
Thread Author Replies Views Last Post
  INPUT for HP Prime Eddie W. Shore 3 458 11-17-2013, 04:46 PM
Last Post: Michael de Estrada
  HP Prime Tutorial #4 is up (CASE/CHOOSE/INPUT) Eddie W. Shore 1 389 11-15-2013, 07:32 AM
Last Post: Davi Ribeiro de Oliveira
  HP Prime Programming Tutorial #3: WHILE, INPUT, KILL, REPEAT, GETKEY Eddie W. Shore 5 704 11-07-2013, 12:25 AM
Last Post: Han
  An easy course in using the HP16c-wanted- Frank 4 560 10-29-2013, 11:50 AM
Last Post: Mark Hardman
  minor visual bug in INPUT Han 0 240 10-03-2013, 01:13 PM
Last Post: Han
  Input syntax on the Prime Gilles Carpentier 6 606 08-23-2013, 04:31 AM
Last Post: Gilles Carpentier
  Input CAS var on HP Prime Mic 2 342 08-22-2013, 02:29 PM
Last Post: Mic
  HP 85 Serial Interface; INPUT Example? inaki 1 342 06-12-2013, 11:09 PM
Last Post: Paul Berger (Canada)
  HP33E how to input numbers RalfGeiger 6 570 05-07-2013, 02:41 PM
Last Post: Ron Ross
  HP 35s - multiple program input values? Arno 3 468 04-29-2013, 11:27 AM
Last Post: Gerson W. Barbosa

Forum Jump: