The following warnings occurred:
Warning [2] Undefined array key 5693 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 5696 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 5714 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 5741 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 5772 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 5779 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 5784 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $thread - Line: 295 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 295 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Trying to access array offset on value of type null - Line: 295 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 295 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $fid - Line: 295 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 295 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 5784 - Line: 331 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 331 errorHandler->error_callback
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 304 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $theme - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Trying to access array offset on value of type null - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $theme - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Trying to access array offset on value of type null - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $lang - Line: 5 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 5 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Attempt to read property "messages_in_thread" on null - Line: 5 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 5 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks





42S & RPN Fanatics should cooperate on an Open Software project



#2

This group's devotion to RPN in general, and the much-lamented HP-42S in particular, combined with HP's indifference make fertile ground for the creation of a cooperative, Open Software development project. Set up a project design bulletin board, share design parameters, agree on product requirements, survey available free/shareware for something to start with, distribute the work, and develop OUR OWN code base of calculator functionality for use in, say, Windows CE &/or Palm devices. Heck, if dedicated folks can do it with HTTP servers (Apache) and a whole damn operating system (Linux), how impossible can it be? Who knows, if the "interfaces" layer is well modularized, we could some day be burning custom replacement ROMs for HP-17B bodies (or whatever). Maybe it's time to give up on HP and do it ourselves . . . (Read "The Cathedral & the Bazaar", by Eric S. Raymond, from O'Reilly!)


#3

Paul;
I understand your enthusiasm for Eric Raymond's work and ideas. I agree, an "OSF" model is a good one under which a shared library of routines could be developed for a NEW, homebrew calculator emulator.

Some shareware/freeware emulators already exist, and I believe one or two of them are "programmable" in that you can use any of the commands on the emulation that you would have on the calculator. Thus, picking one and using that emulator as a base for your efforts is certainly possible. If you really want "control", you could write your own, of course. (Linux and Apache are examples of efforts which in essence duplicated the functionality of already existing systems, because the user community wanted the control of the source).

I must say I am not familiar with what exactly is out there for the Palm, I don't have one... but perhaps since Palm has introduced some smaller "budget" models, maybe I will get acquainted. If we all agreed on an emulator, and thus on a standard for sharing programs, all would be as you suggest-- as long as we agree to use Palms.

But Paul, we don't lament the loss of a GREAT dedicated numeric calculator for no good reason. The Palm and other devices may be better for many things than a plain old calculator; but the fact is, nothing will quite match the user interface that the dedicated calculator presents. Smaller, only displaying the essential, having buttons matched directly to tasks--- any calculator, even TIs, will beat a palm-emulation of that machine, for efficient numeric problem-solving.

So a machine needs to exist, one professional enough to handle serious tasks with a minimum of fuss, one small enough to keep always at hand, one robust enough to count on in a work environment: a tool shaped for the job. All-in-one solutions are fine, but their versatility comes with a cost-- the immediate fit of the dedicated tool.

Further, the RPN method is, in many ways, one that NEEDS to be taught. AOS systems have an advantage for novices; you key in as things are written, not as things are to be evaluated. An AOS user needn't really even understand basic math. But RPN, once taught, is actually the more "automatic" of the two; storing numbers and recalling them back when needed is "handled" because of the stack structure.

Unfortunately, emulators will hardly make an impact on the teaching of math problem-solving, nor introduce new users. This is just sort of a truism: if it isn't "shipped" with your Palm, it won't create a new base of RPN users. It will merely service the users that install it INTO their Palm, for the purpose of having an already-familiar model of operation available to them.

A part of what gets said in this forum is an appeal directly to HP and those within HP who may happen in or lurk. They ought to know what people with experience in these matters say... and I still harbor a hope that, perhaps, they will listen, or perhaps some upstart company that wants to make an impact will heed the comments here.

Heck, maybe I'll start a calculator company. :-) In the meantime, the extant machines will still have their users, and will still need to be serviced, and will still be loved and preferred over many of the newer models (some of the newer HP calc series since the 42s are fairly good ones, just not, in my opinion, GREAT ones).

I for one, LOVE to hear what other users say about the "ideal" machine; I count your vote, too, Paul. But I personally agree with many here that the 42s got a lot of things RIGHT in that direction... and that while we can look at a substitution for the ideal, the real thing would be worth a lot more, to me.


#4

Glynn:

To start off with, I agree with everything you say.

In fact, I wrote my little piece in complete ignorance of what is available, and a quick Google search turned up a couple of well-received RPN emulators, one of which has had several revisions and is programmable. This would cast doubt upon whether such a cooperative effort is at all necessary.

(My comment about programming ROMs for extant machines is almost certainly off-base -- the effort of understanding that proprietary technology and actually utilizing is no doubt prohibitive, not to mention considerations of possibly infringing on patent or proprietary rights.)

From a "purely functional" point of view, there is no doubt a program on a connectable, general-purpose computing device (e.g., a Palm) is "better". But that certainly doesn't answer the desire for an aesthetically pleasing handheld, with the molded-in keycap quality and the tactile feedback that only the former HP seems to have been able to (or, indeed, ever will?) provide.

[By the way, another approach might be somehow "slimming down" the HP-49G's. If you take the back off, the circuit board, display, and keys actualy comprise a very compact unit, if rather too-large in plan dimensions. A slim back with a different battery arrangment and (probably) a smaller capacitor would be a nice step toward making that beast more acceptable. Not to mention its connectivity and programmability -- I understand that four-level stack and large-display routines are available.]

Anyway, you're right on all counts, and I was shooting from the hip. Thanks for your thoughtful response.

Too bad HP can't recognize the good things it once had and simply keep supplying some of them!


#5

( This is a long post... please read it though).

Hang on Paul!
I've been thinking ever since I wrote my response to your letter in the MoHPC Forum... and I so HATE having to think... ;-) but you were suggesting something which was bigger than I initially perceived. It crept up on me finally. And once you got my wheels to creakily turn....

The initial impetus, a Palm-based emulation as a 42S replacement/substitute, is an okay idea, just not where I ultimately want the calculator world to go.

So although an emulation on a Palm is not out of hand (pun), I remain convinced that it IS a limited potential.

But there may well be a project or two within the spirit of your suggestion that are really worthy of discussion by everyone, and (who knows?) maybe even implementation. I am going to suggest one possible road, for discussion, consideration and debate.

In the same vein as a cooperative of "netted" software experts, development of other things along the lines of an "open software" model ARE likely feasible, limited to an extent by the resources that can be shared on the web, as opposed to what would have to be "touched"-- either shipped or individually built from plan.

We are a fairly technically-savvy group of enthusiasts. We are interdisciplinary: some of us have business backgrounds, others engineering, a few of us program, some of us are craftsmen; and ALL of us are calculator users. Some of us deal with math all the time-- others (like me) are clueless to things that are not "canned", but would like to achieve a deeper understanding we never got in school.

While we are waiting for HP (cough, cough), I betcha that each of us has something to contribute intellectually to the prospect of BETTER calculators.

Imagine for a moment that we were a team of people in the mid-sixties, charged with creating a calculator--- like the group at Palo Alto designing the 9100a. Like them, we could look at the extant machinery of Sharp, Friden and Monroe and tell where it "worked" for the use, and what its deficiencies were operationally. Imagine we had the freedom and the mandate to design in what we liked, leave off the tail-fins or add a stripe.

Now imagine that we had (have) the technology of today to play with.

Instead of transistor logic, we could pull out a peppy little "ARM" RISC-based CMOS CPU (from about a dozen manufacturers, some fairly low-power implementations, and available as an ASIC core component)... or maybe even a DSP chip that would make some of the calculations sooo easy...

...and instead of a CRT or Nixie tubes as our display choices, we could choose a cheap Epson LCD panel (for an inexpensive model) or a new Noritake EL display for a higher-end 4-line calculator. Or find someone to manufacture decent panels from that nifty polymer-based LED stuff that always seems to be "just around the corner"....

We could skip the mag-cards phase and go for something like the SmartMedia cards that go in digital cameras and MP3 players.... say 32MB or 64MB of program space? Heehee, yeehah.

(We would choose things which could work in small calculators, even if in the beginning we were not making a small calc. A "family" outlook...)

For continuous RAM memory, Dallas Semiconductor and STMicroelectronics both make NV-SRAM that holds data for 10 years on its own... if we are really looking ahead, we might get Raytheon to make some of the static memory they have licensed to experiment with recently from Ovonyx (check this stuff out at www.ovonyx.com).

We could have IrDA communication and also a CAN interface or something--- whatever we want to hook peripherals up to... and not be bound to HPIL peripherals that use discontinued chips and not a lot of documentation.

And that's just the hardware....

In software, we could also make the implementation decisions that suited US. An "RPN Plus", if you will. We would decide how we wanted our machine to act, and diagram the pieces of the puzzle from there.

Some of the math nuts might want to explore CORDIC on the web, apparently the basis for doing transcendentals on calculators... and we could revise many existing published algorithms to match the precision and error-trapping we require. We could start haunting book-sales for old copies of the "International Journal of Computer Mathematics" and such, and discuss the methods and their advantages or drawbacks.

We would diagram the actions our software needed to take, bit by bit.

The buttons would be ours to assign... ;-)

((I always wanted a four-line calc with one button to the right of each display line, X,Y,Z,T. Hit Exchange, the Z button, and the X button, and the numbers in each of those lines switch places... just a convenience, but why not?))

I am convinced that imaginary maths, statistics, "Solver" and ALL that stuff is reduceable to an understandable set of subroutines that would, in addition (pun) to being a real part of the calculator firmware, ALSO make for good documentation of the subject of computational mathematics in general.

Okay, so What in the heck am I talking about? :-) Well, I am not exactly sure. Maybe a home-made calculator project. No, maybe a calculator plan, or specification. Maybe a design organization.

The basic idea would be to NOT look deeply into the guts and soul of any HP hardware or software. No patent-searching, no disassembly, no reverse-engineering. Reinvent the wheel? Maybe... much as Linux was a reinvention of Unix. Free of intellectual-property fetters. Operationally the same or similar; internally from a different planet.

But with the reinvention, we would start off with technological building-blocks no one in the Sixties, Seventies or Eighties would have dreamed of. And our clean implementation would have the benefit of being OPEN, much as Linux is, to use and adapt, to grow.

It would likely start off ugly and simple, and hopefully build into its own sort of grace and skill.

Our GENERAL expertise would always be welcome. For instance... the explanation of how Friden extracted a square-root on their mechanical machines *(see "The Amazing Friden SRW" in MoHPC)* might have an influence on how WE handle something. Or just knowing that the HP 9100a handled math in floating-point, by serial BCD manipulation, one digit, then the next (who needs a 64-bit accumulator when someone has practically done it in 4?). And also all of that wide body of knowledge that we have gleaned just by being USERS with real problems and uses. All of that is not a patent issue, not a copyright problem... it is in OUR heads and not straining to see "how HP does it".

Like Linux, if we were to find something we later can't touch due to legal issues (as Linux found with de-CSS, MP3) we can just create an alternative, a "better mousetrap"... and who can say we won't? We can make what fits OUR calculator.

Eventually, of course, we would want to have a product. A real pocket-size calculator. Or two, or three.... we would be taking our "black boxes" and filling them in with our own detail, then producing next-generation designs which take these concepts to a particular audience.

Not any products to immediately compete with existing HP product (which is looking at a different market now than us, anyway), but something ALL OUR OWN, which we have designed the architecture of, and which we eventually refine and scale down to pocket-size if we can resolve the engineering and utility issues. The manufacturing issues can be wrangled, once we have something firmly describable.

((Searching the web with Google, I've found some interesting things-- like people who do double-shot keys, and precision engineering-plastics molding. I found two companies that specialize in flexible circuit boards. Cool, huh?)) Money would be the primary issue at that late point. What would it cost? It depends greatly on the scale of the expected market.

When Tom Peddle (UK) wrote lately of possibly asking HP for a subscription of 42Ses, he estimated that we could dispose 1000 or so at $100 each. Actually, I think that is probably overly optimistic for the 42S on a one-off buy. They would be here, then gone; only the few enthusiasts would ever know or care.

But I am asking a different thing: what professionals around the world would pay for a decently-built calculator that was designed and supported by a volunteer/open community? A calculator that is available 24/7 for purchase from a website-- and all its docs, internals and "application pacs" are online? A calculator available always from someone, because in a pinch, schematics, CAD layouts and parts lists were there?

What would people pay for a calculator that was OPEN-ARCHITECTURE and well-known: bit-by-bit, flag-by-flag documented, that used technology designed AFTER 1988 and would evolve with the times and parts? That could, most likely, do virtually all we now laud HP's "former" design and engineering departments at PaloAlto, Loveland, and Corvallis for?

One where we could insist, say, on real Keys that work, not sticky rubber mats; a display that can be read in most places, a functions system with a less-cumbersome, better menu structure? One that is not "binary-compatible" with the 40-series HP machines, but which does offer all the functionality a user could wish for?

(Heck, much as I hate using them, I would even make a rubber-mat version IF it could be produced in mass quantities and sent to schools to teach STUDENTS and TEACHERS about RPN, and prepare them for the REAL THING.)

I think this project would introduce people to a more intimate study of math, of systems design, of technology out there, of evaluating a market, of making manufacturing decisions, of ergonomics and reliability... and their participation would both deserve public mention and privately enhance their own resumes. How often can one say they helped give birth to a new product from scratch?

Now, I hate to say this, but chances are that none of us would get rich. Likely, a manufacturer could comply with our specs, produce our product, wear our penguin (oops, that one is taken... um, have our stamp of approval), and they would get the money to be made, as it should be. In doing that, we would insure RPN lived, but not our local BMW dealer.

To make our own fortunes, I would suggest that a new product needs new peripherals, new offshoots and adaptations to hitch it to older hardware, that sort of thing. Our participants would have to seize those moments by themselves... but the Project, in and of itself, would have no material gain as its object, other than world-domination... much like Linux.

So, why WOULD people participate?

1. to know a great deal more about calculators and calculating

2. to insure the existence, nay, predominance!!! of RPN

3. to see a better machine than is now produced, one for PROFESSIONALS

4. to maybe spur HP into living up to its potential rather than resting on its laurels

5. to see lower costs of new calculators as competition in manufacturing and diversity of product becomes more likely

6. to see the specific kind of expertise on numerical calculating machines PUBLIC, rather than some proprietary implementation

7. to see their name on the development of something significant

8. to be a big fish in a somewhat small pond

9. to advocate their particular tastes on the development of a product

10. to have more to talk about and tackle daily than "the hardships of buying on eBay"; to DO more than watch cable with your evenings.

11. you just love calculators, and would want to be the first on your block to own one of these puppies.


I personally came up with these reasons because I feel an affinity for each and every one of them. Perhaps there are more reasons I can't see. Community spirit? Might happen. Prototype collectability? Maybe (who can ever tell in advance?) Other potentials exist.

Pitfalls exist as well. What, you thought this would be EASY?

But as ambitious as all this sounds, I just happen to believe that you really learn by DOING. Call it "understanDoing"... you grasp it better when you are a part of it. If ALL we were able to accomplish was a table-top box the size of a six-pack that added two five-digit numbers in ten seconds and displayed the result in hex while not tripping a circuit-breaker, I would still figure we had DONE something cool, and learned by it.

Obviously, though, I'm citing >40MHz CMOS parts and new memory technologies and such because I think we can do so much better than a homebrew "Science Fair" kit. I think it is JUST possible, and indeed it should be our stated goal, to BETTER the state of calculating machines-- to make a calculator with better overall performance and more to offer the user, than any that currently exist.

Could we do it? I think we could.

I can't even come up with a catchy name for all this... (suggestions welcome). It is only my feeling that GNU and Linux and open-software have done some of the groundwork that leads me to suggest these "notions":

1. We should have an agreement among all participants that no proprietary works of intellectual property should be exploited, referred to, or used as a "blueprint" in the development of our project's architecture or system firmware.

2. We should agree that all that is developed for use in the project is to be freely available to all participants, and subject to the rules of the GPL, freely distributable via internet, CD, and so forth, and "copyleft"-protected. To quote gnu.org:

"The freedom to run the program, for any purpose (freedom 0).

"The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.

"The freedom to redistribute copies so you can help your neighbor (freedom 2).

"The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. (freedom 3). Access to the source code is a precondition for this."

and,

"copyleft (very simply stated) is the rule that when redistributing the program, you cannot add restrictions to deny other people the central freedoms. This rule does not conflict with the central freedoms; rather it protects them."

3. We should implement a steering organization, which holds that copyright/copyleft legally, and determines the future direction (though not energies) of the overall project, and acts as a clearinghouse for questions and documentation on the status of the ongoing project, including the assignment of version numbers etc.

4. We should authorize the use of an official symbol or emblem to denote compliance with the specifications and performance characteristics we have defined, for any device that does comply.

5. We should, as quickly as possible, come to a consensus on what the project is to ultimately offer. Linux's primary goal has been Unix compatibility-- and so kernel development proceeded without a lot of thrashing around about whether the basic console cursor should be a dancing raisin or a twinkling star. In my opinion, it should be fairly easy, even at a naive stage, to identify the characteristics you are ultimately aiming for in a product. Aim high.

6. We should agree that the mission of the organization is to "foster and promote the advancement of better, more connected, expandable RPN-based calculators using open architectures", or something like that, and the organizational purpose "to promote cooperation among individuals wishing to contribute to the mission, and to make freely available the results of those cooperative efforts", or similar...

7. We should, in my opinion, look for a venue. Dave Hicks may want to host this as an offshoot of the MoHPC site, and if he wants to offer to become an active part of it, I'd be thrilled. But, I have to admit, it is likely the project in itself would be a distraction to the Museum and not part of ITS mission, and a community of people working on a new calculator might not help Dave's amicable professional relationships in his own successful and continuing labor of love. We wouldn't want to screw MoHPC up.

So, like the user community that built up around open-software, there oughta be web and ftp space made available, and a mail-list with an administrator who can disseminate to all, answer FAQ requests for newbies, and keep an archive of communication so all are aware of events past and present, and nobody is left out. While the venue can be mirrored, it should not be "distributed", but "central"--- all should have the same access at all times. (Not a "web-ring"; Imagine if design decisions are being made in one broom-closet which obviate the activity going on in another... people oughta be a part of everything, including offering steering advice). None of this should be difficult to figure out. But we need to have community-minded people open to hosting and maintaining such resources.

Volunteers? :-)


Well, enough "notions" for now. But Paul, I want to come back to something you mentioned in your second post, because it has maybe more immediate merit to MoHPC. You were saying, I think, that the major objection to the HP49G was its size, and that something could possibly be done about that. I think you are right. A better battery arrangement might allow a newly-engineered back to slim down the thing, and make it a better machine. I would guess that a cooperative arrangement here to do that would be a simple matter, and well worth the effort.

THAT is an idea where the concept of a "subscription" as advanced by Tom Peddle might work. After design and initial legwork to define the piece, the costs of tooling and production, asking for subscribers to pay for the cost with a deposit, and waiting till enough was collected to place the order.... yeh, a bit of an odd arrangement these days, but it used to be very familiar to book-publishers for works which were not meant "for the masses". I'd think you might get someone to vacu-form colored Lexan sheet or Sintra expanded PVC sheet to your specs rather inexpensively. Wonder how many 49G owners want to put their machines on a diet? ;-) How many would maybe BUY a "49G-skinny"?

Another project that might be worthwhile in that vein is the matter of the "Classic" displays. They rely on an obsolete and hard-to-find five-digit seven-segment LED. Matched brightness on the three sets of five-digit displays are tough. BUT... A project to make a "drop-in" replacement for the display... a circuit-card with fifteen matched LED digits, is possible, if enough people want to do this. Single LED digits are easy to source, in many sizes. Design could probably proceed NOW.

Virtually all the calcs I know of have SOME silicone rubber. This stuff is always the first to go. We COULD get all the parts together that we KNOW disintegrate, and measure them for a refit. Then go to one of many manufacturers that mold rubber parts and order replacements, stuff that would keep our calcs healthy for another 20 years.

So, here I advanced a BIG open-dev model project, and there we have a coupla other ideas more along the MoHPC groove; the question may be, "Does anyone really care?"

Notice that nowhere am I going to beg HP to do something. If you care enough to care, it's up to you, collectors and enthusiasts.

Any Forum response, good or bad, is welcomed. Feel free to propose YOUR vision.

grharris@altinet.net


#6

Glynn, I tip my hat to you! A dreamer you are, and a died-in-the-wool RPN devotee to boot! I am astonished by the breadth and depth of your vision, and hope something can come of it. Let's see how much response your excellent post will generate.

In particular, I will say that I, too have wished for more menu keys around a graphic display as a way of achieving greater "customization" of the calculator interface. (I hadn't thought of the stack interaction potentials.) How about a '48-sized screen SURROUNDED by keys -- say six across the top and 4-6 down each side? (And one in each corner -- what the heck?)

In fact, a "PDA/calculator-button hybrid" approach might be a "button tray" into which one could slide a Palm-like device. This would capitalize on the PDA or Win/CE device's programmability and product maturity (development tools, expandability, etc.) with a calculator "feel-alike" add-on ...

Another approach to the electronics end might be to buy the "guts" of a successful PDA or Win/CE device in quantity, and wrap it in an improved case, with improved software. Again, the existing software and hardware base would jump-start development, and we could concentrate upon the application and keyboard interface aspects.

And I have meant to do a one-off "slim 49" just so I could add it as a three-hole insert in my minder binder and have a PDA substitute. I thought I'd line the triple-A's AND the capacitor along one side, reducing the total thickness to not much more than an AAA cell. (Unfortunately, the width of the beast would grow even more, but I wasn't thinking of replacing my shirt-pocket -42S.) I should follow through & see how it goes.

Yet ANOTHER approach would be to use the guts of a -49G, and reconfigure the keyboard interface somehow with a PAL chip (or whatever -- I'm a little out of my league here) as part of an effort to minimize overall device dimensions and provide a smaller, customizable keyboard layout.

Apropos of nothing at all, I'd like to note the following subtle change of spelling and the resultant not-so-subtle (but deliciously ironic) change in meaning:
"Imagine for a moment that we were a team of people in the mid-sixties ... "
"Imagine for a moment that we were a team of people in their mid-sixties ... "
(I misread your sentence and had to do a double-take!)


Thanks for responding so positively -- we'll have to let things simmer a bit and see if a chain reaction gets underway.


#7

Ooohh, is that simmering I hear?

<crickets chirping>

Oh, well... :-)

----

Paul, regarding the 49G-slim, if you want to see just how thin you can get it, consider:

1. That fat capacitor can be replaced by some smaller size caps, smaller values (in parallel, sum their individual values).

2. Three AAA alkalines are hard to replace with button batteries, you would have an array the size of your notebook; BUT take a look at National's LM2653 DC-DC downconverter. It and a few small discrete components would nicely regulate 6v down to the 4.5 range, at 85-90% efficiency. (The docs even show a sample layout circuit-- I estimate the size of the circuit board needed at approx 2" x 2", and not much taller than an I.C. on a board; maybe 3/8" or so).

Why 6v? Why, the Polaroid Polapulse battery, of course! Go to Polaroid and check out OEM products; they have the same kind you salvage out of film packs (the Polapulse 80), but fresh.

Drawback? You'd have to order lots. Well, they DO have a five-year shelf-life. :-)

But Polaroid ALSO sells the same battery in a sleeve (the Polapulse 100) that is meant to slide in, as they say, as simply as putting a credit-card into an ATM machine. And THAT one, you might check with a camera dealer in your locale, they perhaps can special-order you a small box of them.

The Polapulse, in addition to being the right size, compares favorably to AA alkalines, so I would expect at least 25-30 percent longer operating time on the polapulse and converter than you would get with only 3 AAA.

I can't wait for you to upload pictures of your 49G being slipped under a door...

----

I am intrigued by your idea of a "button-tray" for a Palm. What expansion ports do those devices have, and do all models share them?

----

As far as buying the "guts" of a PDA, I know that a few companies make what they call "development platforms", which are circuit cards with cpu, memory, a flat-panel LCD, and such, hoping that companies will use their architecture (and therefore their chips) in the design of a mobile "internet appliance". Intel has one, NatSemi has one ("Geode"), and I think Cirrus may as well. They are not cheap--- golly, you could buy Palms retail and take them apart cheaper. But where the development systems shine is the software and documentation: they have PC-software that enables you to customise the flash-ROMs of these PDAs to do anything you want, really.

----

Sorry if my clumsy wording led you to think I was referring to aged engineers. I just recently got fitted for bifocals-- and I am not particularly pleased about that.... ;-)


#8

Thanks for all the input. I typo'd -49G, but I don't (and won't likely) own any of them.

I've got two -48G's upgraded to something like 256K RAM -- I'll probably try to reposition the AAA's along the side first, and see if I can make a strong and cosmetically acceptable back for it -- probably slice the upper edge of the current back piece, and try to bond it to a flat sheet of something. (You can see my plans are not all that well-formed . . . )

Regarding Palms, I really know nothing -- just that everyone seems to have one, and that there are something like four different models. There also appear to be at least two RPN calculator programs (free/shareware) available for it. Someone showed me a Palm with a cable port and an IR port, either of which may connect to a PC.

Gotta run. Thanks again!


Possibly Related Threads…
Thread Author Replies Views Last Post
  Hook-µP software by Rush Systems Lute Kamstra 5 2,221 11-29-2013, 01:30 AM
Last Post: Lute Kamstra
  FRAM71 Project aj04062 1 1,186 11-25-2013, 01:59 PM
Last Post: Hans Brueggemann
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 2,382 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  Prime: Pedagoguery Software pop up banner Matt Kernal 1 1,315 10-20-2013, 01:54 AM
Last Post: Mic
  latest prime software release? Geoff Quickfall 3 1,612 10-12-2013, 03:53 PM
Last Post: Tim Wessman
  Does the HP Prime software only work with Win 7/ 8 ? Michael de Estrada 3 1,613 10-12-2013, 02:52 PM
Last Post: John Ioannidis
  [HP-PRIME] QPI project CompSystems 0 863 10-09-2013, 02:51 PM
Last Post: CompSystems
  Prime Software Buttons kris223 2 1,272 09-21-2013, 08:19 PM
Last Post: Jonathan Cameron
  RPN-1200 Project Benoit Maag 0 815 08-25-2013, 01:05 AM
Last Post: Benoit Maag
  Latest HP Prime "emulator" software available :) Adrien Bertrand 46 13,113 08-21-2013, 10:48 PM
Last Post: Joe Horn

Forum Jump: