WP34s

[Paul Dale]

Just to let folks here know, the next revision (1.13) of the documentation is available from the sourceforge site. The sources are available via subversion, although not working on the physical hardware still.

- Pauli

[Paul Dale]

I've also uploaded a current Mac OS/X Intel binary and a recent Windows binary. I've no idea if they will work for other people or not...

- Pauli

[Marcus von Cube, Germany]

Paul, on which platform is your Windows port based? I'm currently working on the HP20b SDK and I'm willing to port WP34s to Cyrille's emulator. I still have to check, if the application follows the same rules as the emulator (or SDK) force, like having an application.cpp file as the central point for the user interface.

Edit: I just had a short look at your sources. I'm not yet sure where to snap in Cyrille's code. I think, a graphical emulation would be very helpful. BTW, it compiles fine under VC++ Express 2010.

Edited: 15 Feb 2011, 9:35 a.m.

[Marcus von Cube, Germany]

I've spent some more time with the sources. A standard main() in keys.c which is acting as a key press dispatcher works fine in a single thread environment, but this is not the proper way to interface to an event driven platform. Both the base code in the SDK for the platform and the Windows MFC emulation need callback functions for the handling of events.

[hugh steers]

for a windows GUI, you'll need to write a new "main" replacing the main loop in keys.c

you'll need to translate any visual buttons into wp34s key events (along with real keys) and call process_keycode. after that signal a display repaint. all other windows events dispatched as normal.

again the display code will need reworking if you plan to render this graphically.

[Paul Dale]

I don't know the version of Windows used to compile this sorry.

Yes, my main() in keys.c is a keystroke dispatcher. To do an event driving GUI interface, just call the guts of my main() on a key press.

There is no way, you'd want to go multi-threaded on the 30b hardware. Single thread take a key press and dispatch is definitely the way to go. HP's code does it this way as does mine.

- Pauli

[Marcus von Cube, Germany]

At least the Windows version in the SDK is multithreaded. On the real hardware, there must be some background processing and interrupt driven actions, too. Think of automatic power down, processor off/on while the display is visible, and the like. I'll check the sources in the SDK to be sure.

For the rest of February, Meindert's Project has priority. So wp34s is on hold from my side.

[Paul Dale]

HP's 30b development firmware is pretty much single threaded. There are interrupt handlers and timers of course but in reality they really don't do much of anything. Everything hinges around the key press.

- Pauli

PS: What's Meindert's Project???

[Marcus von Cube, Germany]

Meindert is working on the MLDL again. He has added an mbed controller and now needs some demo software for networking.

[Paul Dale]

My code isn't immediately compatible with HP's SDK. I started merging the two but never finished. The source as distributed includes this partial merge. I'd figured I was going about it incorrectly and what I had done needed to be removed and my code modified to integrate with HP's to take direct advantage of their low level support. Then life got in the way, not to mention having no access to the development environment HP's sources require.

- Pauli

[Gerson W. Barbosa]

It works on Vista:

                                                    BEG

                                                              360       RPN

                        --   --   --   --        --   --   --

      | |  |    | |  |    | |    |    |    |  |    | |    |  |

      | |  |    | |  |    | |    |    |    |  |    | |    |  |

         --        --   --   --   --   --   --        --   --

      |    |    |    | |    |  |    | |  |    |    | |  |    |

      |    |    |    | |    |  |    | |  |    |    | |  |    |

                 .      --   --   --   --             --   --

Cheers,

Gerson.

[Walter B]

Olá Gerson, this fake is detected most easily - we don't employ BEG d;-D

[Gerson W. Barbosa]

Hallo Walter,

I wonder why the "BEG" annunciator is lit. Anyway, that's what I got when running WP34s.exe from the command prompt and after doing some calculations. Perhaps I pressed a wrong key...

Regards,

Gerson.

[John B. Smitherman]

Bug #1. ;-)

Regards,

John

[Paul Dale]

Nope, not a bug. It is meant to do this.

- Pauli

[Thomas Klemm]

Quote:

---

It isn't respectable to beg

---

-- White King

[Paul Dale]

We do display BEG when the program is at the first step. So this display looks legitimate to me.

- Pauli

[Walter B]

That's one of the unsurpassed advantages of real life: it unveils undocumented features. But now it's documented (it will be in v1.14 at least) d;-)

[Paul Dale]

I mentioned this feature well over a year ago ;-)
When the program counter is at step 000, BEG lights.

It really is kind of useful.

- Pauli

[Gerson W. Barbosa]

Hello Paul,

Quote:

---

So this display looks legitimate to me.

---

It IS legitimate. Here is a link to an UNEDITED copy of my HP notebook screen, as of yesterday:

link

Now, to the mini-challenge. In order to get the number on the wp34s screen, trivially 13 keystrokes are required:

1 4 1 . 4 2 6 5 6 4 7 6 9

The challenge is to get this done using at most 11 keystrokes (not programming steps). My 11-keystroke solution will not work on the HP-42s because it will give an answer in excess of 1 ulp.

Likewise on 10-digit calculators it will be needed no more than 11 keystrokes to get 141.4265648. So far I have been able do it using only 10 keystrokes on the HP-35 (1972), but not on the HP-15C (I think this gives a hint to at least one keystroke). If it can be of any help, the 16-digit result is 141.4265647689814 (The meaning of this is part of the challenge, otherwise the WP 34S solution would be somewhat easier :-)

Cheers,

Gerson.

[Paul Dale]

Not a solution to the specified problem, but I stumbled upon this which qualifies as an elegant near miss I feel:

  command     34s keys             15c keys

    9         9                    9

    e^x       f XEQ                e^x

    ->HR      -> f RCL             g 2

    ->RAD     -> RCL               f 3

answer:       141.4265468089978    141.4265468

keystrokes:   8                    6

- Pauli

[Gerson W. Barbosa]

Paul,

That's only four programming steps for eight correct digits which would be great in calculators with reduced number of steps (if such a number is ever needed in a program).

I submitted 141.4265647689814 to WoframAlpha but it wasn't able to find the correct closed form, neither did other inverse calculators I tried. So, there's at least one thing I know WolframAlpha does not :)

A tip to the 10-keystroke HP-35 solution: Divide 141.4265648 squared by pi then multiply the result by 3. Though this looks like an integer on the HP-35, it's actually an
almost integer. The backwards operations yield an approximation to the real closed form solution, which I hope the WP 34S screen below is a hint to.

Regards,

Gerson.

----------------------------------------------------------

T: 3.141592653589793                    stack depth: 4

Z: 3.141592653589793

Y: 3.141592653589793                    I: 0

X: 141.4265647689814                    L: 138.2849721153916

          [lift]              shft = 0  trig = 0  [lp 001]

          numdig = 0   alpha '                               '   bflags = 000-00

          digval = 0   pc = 000              cmddot = 0  cmdeex = 0  eol = 0

                                                    BEG

                                                              360       RPN

                        --   --   --   --        --   --   --

      | |  |    | |  |    | |    |    |    |  |    | |    |  |

      | |  |    | |  |    | |    |    |    |  |    | |    |  |

         --        --   --   --   --   --   --        --   --

      |    |    |    | |    |  |    | |  |    |    | |  |    |

      |    |    |    | |    |  |    | |  |    |    | |  |    |

                 .      --   --   --   --             --   --

  A: 0                                  J: 0

  B: 0                                  K: 0

  C: 0

  D: 0

[Gerson W. Barbosa]

Ok, here it is:

 141.4265647689814.. = pi + pi^2 + pi^3 + pi^4  

                     ~ sqrt(19100*pi/3)

Alternative closed forms:

(pi^5 - 1)/(pi - 1) - 1

 pi*(pi + 1)*(pi^2 + 1)

WP 34S keystrokes:

h 3 ENTER ENTER ENTER * + * + * +

HP-35 keystrokes:

1 9 1 0 0 pi * 3 / sqrt

[Walter B]

Olá Gerson,

you could have saved one stroke by using FILL on the wp34:

h 3 g ENTER * + * + * +

while on the hp-35 you have to repeat ENTER:

pi ENTER ENTER ENTER * + * + * +

The approximate HP-35 solution you posted deviates from the truth by 1.9e-8.

Cumprimentos,

Walter

Edited: 18 Feb 2011, 2:53 p.m.

[Paul Dale]

Quote:

---

you could have saved one stroke by using FILL on the wp34:

h 3 g ENTER * + * + * +

---

And this works with the stack size set to 8 not 4 :-)

- Pauli

[Walter B]

Quote:

---

Quote:

---

h 3 g ENTER * + * + * +

---

And this works with the stack size set to 8 ...

---

... as well as with 4 levels :)

[Paul Dale]

And if you program it, a further step can be saved when using the 8 level stack:

    PI

    FILL

    LBL 00

    *

    +

    DSZ D

    GTO 00

and one more if the internal BACK is used instead of LBL/GTO but that can't be done from the keyboard.

- Pauli

[Gerson W. Barbosa]

Paul & Walter,

looks like I should have read the manual :-)

What I think it is interesting in the sum of these powers of pi is

pi + pi^2 + pi^3 + pi^4 ~ 100*sqrt(2) + 1/(2^6 + 2^7) (off by ~2e-7

Also interesting is pi^17 (the first five significant digits match those of sqrt(8)).

Combining these and adding a term involving sqrt(2) yields a round near integer:

pi^16/((pi + 1)*(pi^2 + 1)) + 2*sqrt(2)*(20 + sqrt(2)) = 2000000.000349779

Notice the equivalent RPN expression involves mostly 2, sqrt(2) and pi:

pi x2 x2 x2 x2 pi 1 + / pi x2 1 + / 2 sqrt(2) 2 * 2 sqrt(x) 20 + * + 

Or, in terms of WP 34S keystrokes:

h 3 

g * g * g * g *

h 3 1 + /

h 3 g * 1 + /

2 f * 2 *

2 f * 20 +

* +

Regards,

Gerson.

[Walter B]

Quote:

---

looks like I should have read the manual :-)

---

This is a common phenomenon :-)

[Paul Dale]

For more exciting information, make the window a bit higher and press 'F' to show lots of internal state (including the full stack). Pressing 'T' goes into a trace mode and 'Q' quits. None of this will be in the final firmware of course but these commands are great for debugging.

- Pauli

[Paul Dale]

I've just now uploaded a Ubuntu Karmic binary.

Since it is statically linked, it ought to run on most versions of linux as is. It requires a terminal window, just like all the other versions.

- Pauli

[Namir]

Cool stuff!! A Window GUI will be very very nice though. Working the DOS-box emulator is a bit like a juggling act.

:-)

Namir

[Marcus von Cube, Germany]

Namir, I'll take care of that. Be patient.

[Namir]

Thank you!!!! Looking forward to seeing the GUI version.

[Marcus von Cube, Germany]

Meindert comes first, his project has a time limit. But thereafter...

[Walter B]

Oh - it's our fault we haven't set a time limit? That can be corrected most easily d8-)

[Marcus von Cube, Germany]

After having helped Meindert out, I'm back on the wp34s track.

Here is my (clumsy) artwork: http://www.mvcsys.de/temp/wp34s/wp34s_skins.zip

You can unpack the file in the emulator Debug/Release directories and get the modified skins on Cyrille's original number guessing game.

Some work still ahead...

[robert rozee]

a couple of silly questions:

why are 'fix', 'sci', and 'eng' brought out on their own key labels? most folks would surely tend to set the display format to their own personal preference and hardly ever touch it again. that is certainly what i do, in which case these could be put down in a menu.

what are the 'B', 'C', and 'D' keys for? given that these three labels exist exactly the same below the keys. the white functions above (1/x, etc), it would seem, would be better placed on the keys themselves.

cheers,
rob :-)

Edited: 28 Feb 2011, 6:48 a.m.

[Walter B]

Hi Robert,

there are no silly questions - only silly answers, though I hope getting around them ;)

Quote:

---

what are the 'B', 'C', and 'D' keys for? given that these three labels exist exactly the same below the keys. the white functions above (1/x, etc), it would seem, would be better placed on the keys themselves.

---

These are three programmable hotkeys. Compare HP-65, 67, 34C etc. For full information, please take a look to the documentation published (v1.13).

Quote:

---

why are 'fix', 'sci', and 'eng' brought out on their own key labels? most folks would surely tend to set the display format to their own personal preference and hardly ever touch it again. that is certainly what i do, in which case these could be put down in a menu.

---

I concur. One could put the command DISP (this is not a menu, see v1.13) on one shifted location there and gain two shifted locations for whatever you like being placed there - feel free to propose something. Nevertheless there are dissenting votes, too, and in this case I had no better offer than what you see so far.

Added: Personally, I switch between FIX and ENG modes quite a lot, sometimes use SCI instead and hardly ever use ALL. YMMV.

Don't hesitate to ask more.

Edited: 1 Mar 2011, 2:15 a.m.

[Paul Dale]

Nice work Marcus. I toyed with the idea of doing a graphical version using SDL but it never progressed for similar reasons to the real hardware port :-(

We did have FIX, SCI and ENG in a catalogue for a while with DISP on the keyboard but, as Walter pointed out, there really wasn't anything else worthy of and suited to be in those keyboard locations.

Personally, I switch between FIX and ALL modes quite a lot, occasionally use SCI and pretty much never use ENG. Of course, everyone is different.

- Pauli

[Marcus von Cube, Germany]

Paul, Walter, you've mail on your sourcefourge mail addresses.

I've just opened my 20b in order to fit a JTAG connector (the USB/JTAG hardware has been ordered.) I plan to start more or less from scratch, using the SDK modules when it seems useful (keyboard, display) but having more control over what the hardware does. This is partly motivated by pure curiosity. On the other hand, it will ease in fitting in the wp34s software.

[Walter B]

Hallo Marcus,

Quote:

---

you've mail on your sourcefourge mail addresses.

---

Nothing arrived yet. I've just opened the respective channel at SourceForge, so feel free to try again or contact me via the forum mail function.

[Marcus von Cube, Germany]

Forum mail doesn't work for "Walter B", at least not when I click on your name in the previous post. :(

So here you go:

Quote:

---

Hi Pauli & Walter,

if life doesn't get in the way, I'm willing to aid in porting wp34s to Windows
and the real thing. (Life *will* get in the way, but...)

First of all, I'd like to know your "normal" e-mail addresses for easy
collaboration. As an alternative, we can move the discussion to the
sourcefourge infrastructure (blog, forum, what is available?). Can you add me
as a developer? Talking about technical details in the museum forum might not
be the right place.

I have a first point to discuss: memory.

As you should be aware of, the RAM is divided in a battery backed part of 2 KB
at address 0x300000 and a volatile part of 4KB @ 0x200000. I don't know yet at
which point the volatile memory looses its contents but it should only be used
for scratch memory (processor stack, scratch registers for internal
processing) while the persistent RAM should be used for all user data.

Your code simply defines global variables while Cyrille's implementation
assumes a structure MyApplication which is manually allocated to the correct
address (0x300000). From my past experience with embedded systems, the linker
should be capable of putting variable data in designated segments at
designated lcations. This would make us dependent on the tools but that's more
or less always the case. It's just necessary to identify which data goes where
and mark it in the code with the proper qualifiers. I'll have to check how to
do it in IAR and/or GCC.

The Windows emulation can be done without but for state saving, some
seperation is nonetheless necessary. Putting everything in MyApplication might
be the straightest path to success.

---

[Walter B]

Hallo Marcus, you've got mail d8-)

[Gene Wright]

Thanks Marcus.

I know I would be much more likely to play with the 34s emulator if it had a skin rather than a text window.

Can't wait until it is really working just to play with!

[Marcus von Cube, Germany]

The wait is going to be over, soon! I've just compiled a first version which seems to act more like a calculator then a number guessing game. ;)

Hopefully we'll release something shortly for the forum members to toy with.

[Raymund Heuvel]

Hi Marcus

I created a "first shot HP71B keyboard UI" in QT. 

Can I help with the 34S?

BR

Ray

[Marcus von Cube, Germany]

It will not be QT, it is just the (MFC based) framework that Cyrille and Tim have already created. I've done the (clumsy) artwork already. It's just a problem of me existing only once.

[Raymund Heuvel]

OK, I am not familiar with MFC, but .NET/CLR.

Grüße aus dem Allgäu

Ray

[Norman Dziedzic]

Quote:

---

It's just a problem of me existing only once.

---

I'm going to use that one!