30b repurposing Status



#59

Hello:

At the HHC2010, the HP30b repurposing was mentioned -

What is the status of this effort? My interest is in the 34s repurposing as my concern is in a scientific version.

(I've searched the 20b wiki and could not find any information.)

Thanks and Regards,
TomC


#60

FWIW, Tim Wessman at HP did not think it would be that difficult to get the code onto a machine.

So, Walter? What's the status? What do you need to load the code onto a 30b and try it out?

#61

Quote:
What is the status of this effort? My interest is in the 34s repurposing as my concern is in a scientific version.

Jake Schwartz gave a presentation at HHC2010 since neither Paul nor me have the $$$$ for a short transpacific or transatlantic trip just for a two-days meeting. The answer to your question is given in said presentation. If Jake didn't distribute it at the meeting (I have no idea), please drop me a mail and I'll send it to you.
Quote:
I've searched the 20b wiki and could not find any information.

As expected - I didn't write anything in that wiki. And since documentation is my task in our two-person design team I'm pretty sure Paul didn't as well.

HTH (else please explain your wishes once more since then I was unable to understand them)

Walter


#62

Walter, the presentation was given, but the HP people present did not understand what the exact hold up is / was for you to try the code on the actual unit.

Perhaps if you laid out a specific short list of 1. I need X. 2. I don't know how to do Y. etc. then someone can get that specific stuff available to you and testing on a unit can begin.

HP was willing to help, but after the presentation, they weren't sure exactly what you needed.

Just ask and be specific. :-)

It was well received. We all just want to help push it to the next level!


#63

Gene,

thanks for your explanation and the offer. We'll sit down and compose a little list of bare necessities :) to get this homegrown thing up and running.


#64

Hello Walter:

The links to the source and the documentation are 'dead'.

http://hpwiki.fatcity.com/lib/exe/fetch.php?media=20b:sci34s.tgz
http://hpwiki.fatcity.com/lib/exe/fetch.php?media=20b:enter_20b_1_1.pdf

The binary would also be helpful (if available).

Are these still available?

Thank you,
TomC


#65

Thomas,

just checked the addresses you mentioned and their roots. IMHO that wiki may be interesting, but doesn't look very active to me. Another enthousiastic attempt fading out d:( As I did mention in a previous post already, I did never publish anything in that wiki - what was published there was the first edition of Pauli's and my 34s documentation (v1.1 of Dec. 2008 to be precise), meant as an appetizer IIRC.

This is outdated for long, so I'm quite happy that link is dead. FYI, Jake's presentation was based on v1.11. If you want that documentation, some 2MB pdf, please drop me a message stating your e-mail address. Please note, however, this is a moving project - we are writing v1.12.

Regarding the SW, even I myself don't have the recent version. And it seems to be foggy over the Indian Ocean, so that continent down under is cut off. A soon as I get my collaborator to read my messages, I'll return with more as promised above.

Hope this answers your questions. Else continue asking ...


#66

Hey Walter.

Regarding the SW...

Do you have an edition that runs in emulation? Anything we can actually play with to help with testing?

Perhaps we could find someone outside HP who has the compiler who might be able to compile the code?

I wonder...Does the licensing agreement to the compiler say you cannot compile code for a friend? I understand why HP would not want to do that (really) but a compiler is a compiler...of course, I haven't read the byzantine licensing agreement, so ...

Basic question: is there an executable in any form we can play with?


#67

I think the concern with the compiler is that Tim most likely has a clause in his employment agreement that says that anything created with HP-owned equipment becomes HP property. Therefore he presumably can't do personal stuff on his work machine without risking loss of intellectual property.

If someone else has a license to the compiler they should be able to help. HP-GCC is the only compiler I have ever dealt with that has such Draconian restrictions on what you compile.


#68

Agreed, which is why I said I understood the objection. :-)

But, I bet we can find someone, somewhere, for whom that is not a concern. All we need is someone who has the compiler who can take a couple of minutes to do it.

#69

It's not active, but that's because I am just too busy these days to update it. I would LOVE some help from those here in the forums, but I think others are busy too.

I would appreciate any input as to what priority I should put on certain things on the wiki. For example, if I only had a couple of hours per week, would it be best to focus on just putting up .BIN files? Or do people need technical details? Or ??

I really do want to keep it current and active, but I'm just swamped.

thanks,

Bruce

#70

One impediment that I can think of is.....

IIRC the code for this project would occupy more than 32K of ROM. The free IAR Kickstart system only allows you to compile code up to 32K. So you'd need to have a full version of the IAR Embedded Workbench for ARM (which allows up to 256K of code) to compile this and that costs $3,400 for a single user license. That's a pretty big commitment.


#71

Hmm... wonder if we have any friends who could take the source code **and compile** it for us? ;-)


#72

Nope. I would not use an HP licensed program to do work for a non-HP entity/purpose - myself included. I could possibly give it an attempt to see if it fits, but could not distribute that.

However, a very good thing people could do to help would be to get a different toolchain that builds for ARM and that chip in something like GCC. Any ARM compiler should be able to do the job. HP just went with the one that was recommended by the manufacturer and for which they provided a pre-built project.

TW


Edited: 29 Sept 2010, 11:15 a.m.


#73

Hey, I didn't know we were friends!

Seriously, I understand. :-)

#74

Quote:
However, a very good thing people could do to help would be to get a different toolchain that builds for ARM and that chip in something like GCC. Any ARM compiler should be able to do the job. HP just went with the one that was recommended by the manufacturer and for which they provided a pre-built project.

Code Sourcery provides ARM cross compilers based on GCC. They provide a few versions depending on the target OS. Perhaps one of them might work? (Not sure what binary API the calc needs...) The Lite edition is free:

Lite Downloads

(It can be hosted on Linux or Windows. They also sell and support "Pro" and "Personal" editions.)

sdb


#75

I've used the CodeSourcery toolchain (arm-none-eabi) for other projects, and it works pretty well. It is the GNU toolchain (GCC, Binutils, etc.), but with many improvements for the ARM. CodeSourcery sends their updates to the FSF, but it takes a long time for them to make it into the official GCC releases.

In the past I've often been told that GCC doesn't have ARM code generation as good as other compilers, but I don't know whether that is still the case, as I haven't attempted to compare it to other compilers.


#76

Quote:
CodeSourcery sends their updates to the FSF, but it takes a long time for them to make it into the official GCC releases.

Don't I know this. Getting code into GCC felt like an uphill battle at times.


Quote:
In the past I've often been told that GCC doesn't have ARM code generation as good as other compilers, but I don't know whether that is still the case, as I haven't attempted to compare it to other compilers.

GCC-4 seems to have improved quite a bit on this front but I've nothing to compare it against not having used an alternative. That said, ARM is quite different from the "assumed" processor GCC is designed for.


- Pauli

#77

Another idea would be a paypal account for donations to be sent to for the compiler purchase.

$3400 is $20 from 170 people.

Eh, maybe?


#78

What's the point of spending $3400 for tools, when there are perfectly good tools available at no charge?


#79

Is this an offer to assist finishing the port??? ;-)


- Pauli


#80

How does using a compiler available at no charge require any more porting than a $3400 compiler? I was under the impression that the $3400 needed for the compiler was a stumbling block, so surely a free compiler solves that problem and allows the project to make progress. Or am I missing something?

I'm not volunteering to do anything. Between school and trying to make a living, I've barely got any time to work on my own calculator project.

#81

Well, at the risk of asking redundant questions (of both Walter and/or HP), I will request some specifics:

1. 34s Source Code.

2. 34s executable to be downloaded to the 30b.

3. Any other notes/docs to support 1 and 2 above.

4. 30b SDK (perhaps this is the same as the 20b SDK).

5. 12c SDK (I suspect this is not like the 20b/30b SDK due to LCD differences).

I understand that this stuff is in a very raw state and as such do not intend to nag any of the source(s).

Thanks,
TomC


#82

Thomas,

Quote:
12c SDK (I suspect this is not like the 20b/30b SDK due to LCD differences).

I concur. Since we've tailored the output to fit the 20b/30b LCD, however, I doubt the SW will fit the 12C as is. And the 12C provides 39 keys, while the 20b/30b has 37 only arranged significantly different, so a minor redesign will become inevitable. Please understand we want to prove the design before we start a redesign d;-)

I'll return for the other points.

#83

There is currently only the 20b dev kit and there really isn't much of value you'd get out of the other units. The screen on the 20b is identical, so possibly a screen diagram and keyboard layout for the 12c is the only missing piece there.

TW


#84

Agreed; Hardware details for the 12c would be most helpful!

TomC

#85

Tim,

While it might not be an official SDK, I got a sort-of SDK for the 12C+ from Cyrille. It's got the all LCD and keyboard code and a simple 4-banger calculator.

-Katie


#86

The 20B SDK should be very close, if you need to see schematics.

I reversed enough of the 12C+ to figure out the LCD and keys, but my planned projects on that one have stalled due to my poor time management.

Tools: I'm using GCC. The HP programming cable is nice if you plan on doing crash and burn debugging, but you could do without if you rig some pogos or just solder down some wires and dig up a TTL/232 level converter (or gut a cheap USB/serial adapter). With the 20B (and I assume the 30B) JTAG is an option as well. I've used a parallel port wiggler (cheap and slow) and a Luminary dev board (not as cheap, much faster) with OpenOCD. I found the free SAM-BA tools from Atmel ran *much* faster on XP than on windows 2k. A small power supply would allow you to run without worrying about coin cells. As with any embedded project, a 'scope is nice but certainly not required.


#87

hello,

I made a 12C SDK, if you want it, email me and I will try to dig it up and email it...


#88

Thank you again Cyrille. I anxiously await it!
[I emailed you via this site.]
TomC

#89

Quote:
...just solder down some wires and dig up a TTL/232 level converter (or gut a cheap USB/serial adapter)...

FTDI sells a USB/Serial cable that has TTL level. Nowerdays this is the best option, I think. I used it to link a Canon X-7 to my PC (see here: http://www.silicium.org/forum/viewtopic.php?f=46&t=22257&start=15 in French).
#90

The current status is that the firmware compiles in a custom emulator for Linux and Mac terminal both using the curses library -- I'm happy to send this to folks who want to see it. Text based graphics, a weird QWERTY key mapping and some debug aids only. But fully functional. If the folks here want to have a play with the source, I can put something together fairly quickly. Earlier versions are available on the 20b re-purposing site but they are quite dated now.

I've compiled the full source code using HP-GCC for ARM on both a Mac and a Linux machine. We're still fairly comfortably within the 128kb flash space and we're just within the 2kb battery backed RAM limit -- sub 20 bytes free currently & program steps will be taken as required but I hope they aren't. We're well within the 4kb volatile RAM limit. In fact, there are a number of functions that aren't included in Walter's documentation that are ready to go: Reimann Zeta function for complex argument, digamma function, Jacobi's Elliptical functions, real bessel functions of first and second order (& almost complex versions of the same), cube and cube root, fused multiply add, x!!, !n, Easter & more. All depending on final space limits.

I started integrating HP's development environment into my source code but that failed, well at least I think it failed. Of course I was trying to merge their stuff into mine not the reverse which in hindsight was a mistake -- also losing my job at a work environment with all the facilities available to do the hardware port and debug hasn't helped.

I don't have IAR Embedded Workbench or even a windows machine to run it on and that would be the fastest way to progress the project by using HP's development environment. My code and theirs are structurally fairly similar -- both are reactive based on keystrokes being received -- mine is pure C, HP uses minimal C++ but on the whole there aren't a lot of differences (great minds or fools :-)

At the moment, my biggest limitation is free time to devote to the project -- I'm still on probation at my new job (GPS controlled tractor driving which is rather unrelated to my previous experience but fun nonetheless) which means I'm rather busy. I don't have a 30b but do have a 20b and programming cable which seems to be identical hardware-wise. If someone with access to the full version of IAR Embedded Workbench and the inclination to finish the port was interested, I'd be happy to assist and I don't think it would take very long to get a working result.


I've previously sent my code to Cyrille at HP in case they were interested in making a product of it -- they weren't. Regardless, we've made a number of major changes recently (larger stack, more lettered registers).


Finally, some random thoughts that aren't in the presentation.

* I've aimed for numerical accuracy over speed -- registers and stack are 16 digits BCD reals (including subnormals, infinities, NaNs, + & - zero all packed into 8 bytes). Internal calculations use 39 decimal digits almost exclusively. The calculator stress test "9 SIN COS TAN ATAN ACOS ASIN" returns the correct result for a correctly rounded 16 digit format. Quixotically, I'm aiming for correctly rounded results in the sixteenth digit -- yes I know this isn't really possible but I'd like to try.

* All program steps are fully merged (excepting the three character alphanumeric labels and the commands that call these which take two steps). 18555 different command codes currently -- mostly commands with arguments for various arguments and indirections.

* Every command that takes an argument can be executed indirectly (excepting LBL of course).

* Almost every function that takes a real argument has a complex equivalent. The exceptions are few: triadic commands and the error function.

* Matrix maths (e.g. JMB's) could be included via user programs in flash. Solve, integrate, sum and product are implemented as user RPN code and the associated commands hook into these routines directly. To include matrix code, we'd have to lose something else I suspect.

* Integrate uses a 10/21 Gauss Kronrod quadrature and thus isn't adaptive. I'd like to replace it with something more robust eventually. Solve uses secant, bisection, quadratic interpolation and optionally a ridder's step (this last isn't used since it is larger and doesn't seem to help a lot). The solve code is used internally to provide the inverse statistical distributions.


- Pauli


#91

Paul wrote:

"If the folks here want to have a play with the source, I can put something together fairly quickly. Earlier versions are available on the 20b re-purposing site but they are quite dated now."

Yes, I would suggest if you can to post the source code. Maybe someone will find access to the proper resources.


#92

The sources are available to all. From a command line under linux or mac, just type make to build a console based executable.

- Pauli


#93

Quote:
From a command line under linux or mac, just type make to build a console based executable.

Just for curiosity: Did anyone try this already? Preliminary results?

#94

I have downloaded and attempted to use the software an HP NW8440 running Fedora 12. The 'make' was successful but attempting to run the calculator gave the following in the terminal. I'm not sure how to proceed.


BEG

360 RPN

--
| |
| |

| |
| |
--


#95

OK, sorry, I should have RTFM. It's working now.


#96

What "make" command?

Doofus moment here.

In Terminal, once I have changed directories to the "sci" directory created, what next?

Make is not a recognized command.

doh!


#97

"make - GNU make utility to maintain groups of programs"

Try "man make" for a command description. make (small m) executes the commands in the Makefile of current directory.

#98

You need to install XCode Gene.

TW


#99

Ah, if XCode is required in OSX, you must be registered as a developer.

"make" by itself in OSX without xcode is not a valid command.


It costs nothing to register, just use your iTunes ID.

I can send you the build if you like, just verify that you have the following libs:

/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
So, where is the manual? Tired of adding numbers, I'd like to write a program.

Quote:
So, where is the manual?

When you send me a little mail containing your e-mail address, you'll get a 2MB pdf file almost immediately (as long as Europe doesn't sleep already).

Done. Thanks!

Hi Walter; if possible please send a copy to a.rodriguez AT ieee.org. Thank you very much in advance.


Egan, Andrés, you've got mail.


Thanks. Below is my setup. I do have an issue with key assignments. E.g. A = STO. Is the keymaping for the emulator documented somewhere outside of the source?

Thanks.

Screenshot:


Not sure I got your point, however: All shifted operations are printed *below* of the respective keys. So "A" in alpha mode is entered by "pressing" Sum+.


Since the emulator has to use a QWERTY keyboard, what is the mapping of the QWERTY keyboard to the virtual 34s keys? I would assume that if I press A on my Mac keyboard that I should get Sigma+ in the emulator, but I get STO.

After checking some older mails I guess this is what you need:

Currently the program works in text mode using the curses library. The keyboard is mapped thus:

q w e r t y top row of keys left to right
a s d f g h
z/x c v b n enter row of keys
u 7 8 9 /
j 5 6 7 *
m 1 2 3 -
spc 0 . , + bottom row of keys

There are also the extra characters 'Q' for quit, 'F' to show lots of nice internal status information and 'T' to trace programs being executed.

This information was true in January. Please check.

HTH


Perfect. Thanks.

This information is still correct. See doc/layout for the key to keyboard mapping -- the function assignments have changed since I last updated that.


keyboard mapping
q w e r t y
a s d f g h
z/x c v b n
u 7 8 9 /
j 5 6 7 *
m 1 2 3 -
spc 0 . , +

Additionally, Q to quit, F for status flags etc & T to enter trace mode. The latter two aren't going to be much use to people apart from me, however F does display the entire stack badly formatted.


- Pauli

Walter, he means the mapping to a computer keyboard, where pressing a invokes STO. It also appears that some of the characters in the keymap file are typed incorrectly. T is CMPLX but is labeled f in the file.

          CALCULATOR KEYBOARD LAYOUT            COMPUTER KEY MAP
sig+ B C D CMPLX h q w e r t y
STO RCL Rv -> f g a s d f g h
ENTER^ x<>y CHS EEX <- z/x c v b n
XEQ 7 8 9 / u 7 8 9 /
BST 4 5 6 * j 5 6 7 *
SST 1 2 3 - m 1 2 3 -
ON/C 0 . R/S + spc 0 . , +

If not defined in a program B == 1/x; C == y^x and D = PI


I think we clarified this question in a combined action d:-)) See ... ummh, read you tomorrow d|-)

P.S.: Watch out:

Quote:
If not defined in a program B == 1/x; C == y^x and D = PI

Now, D == SQRT(x) !

Edited: 5 Oct 2010, 5:16 p.m.


As I mentioned, the layout file is dated. We had a big rearrangement of the top couple of keyboard rows to better fit hex characters in & I never updated the layout since I don't use the file having learnt the positions of most of the keys already.

On the plus side, the three shift keys are now f, g & h on the QWERTY keyboard :-)


- Pauli

The manual is in the doc subdirectory. ENTER_20b_1_11.pdf
The keyboard mapping has been elucidated already.

- Pauli

Builds fine on OSX once I removed the call to gcc-4. Any reason the make is using that instead of just CC :=gcc for a non-linux system?

TW


No real reason, just what I've got installed. I did want to use gcc-4 at one stage and the default was gcc-3 so it is likely a residue of that.


- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime battery status Chris Pem10 0 171 12-03-2013, 01:07 AM
Last Post: Chris Pem10
  Repurposing the HP Prime? John Ioannidis 4 273 09-21-2013, 05:38 AM
Last Post: Pier Aiello
  Flashing cable for HP 20 / 30B Stefan Koenig 3 305 09-19-2013, 05:53 AM
Last Post: Marcus von Cube, Germany
  Any 30b cables left? patryk 7 407 09-16-2013, 02:54 PM
Last Post: Marcus von Cube, Germany
  HP-30B (WP-34S) Technical Documentation Barry Mead 3 261 09-09-2013, 03:07 PM
Last Post: Harald
  HP's thinking behind the 20b/30b? John Ioannidis 3 277 09-07-2013, 10:21 AM
Last Post: Tim Wessman
  HP-41: CLR & STATUS Geir Isene 0 152 07-01-2013, 03:19 PM
Last Post: Geir Isene
  30b/34s interfacing? ross sponholtz 5 321 06-26-2013, 01:41 AM
Last Post: Walter B
  Inexpensive HP 30b Matthew Richards 23 936 05-22-2013, 10:10 AM
Last Post: Dave
  hp-30b with free shipping sjthomas 9 506 04-14-2013, 02:46 AM
Last Post: Gerson W. Barbosa

Forum Jump: