|Re: 30b repurposing Status|
Message #32 Posted by Paul Dale on 2 Oct 2010, 3:34 a.m.,
in response to message #1 by Thomas Chrapkiewicz
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.