I have been seaching for information on the new 33S. From what I have read it will have 32K of memory. While this is only a small memory by todays standards, it is a lot to enter by hand more than once. It doesn't look like the 33S will have a main power supply and a battery back-up for program memory. So you could end up re-entering the programs after changing batteries. Has anyone read something I have missed? I am interested in putting my surveying programs into the 33S and reselling them if it had input/output capabilities.


I understand it will have no I/O. Memory should withstand a prompt battery change, even without a backup battery, but I agree that the risk of losing contents is more than acceptable for such models and memory amount.

Please note I have no special information on this model, this is just from what I have read about it.


You can safely assume that the 33S *won't* have IR capability. All calcs with IR, including every HP48 model and the 49G+, were recently banned by NCEES for use on the professional engineering and surveying exams. But NCEES has also announced that the 33S has their "seal of approval". That can only mean that it lacks IR.

It probably won't have a serial or USB port either. The 33S looks like a modified 32SII, and the 32SII didn't have them. The most detailed prerelease info about the 33S, at http://www.hpcalc.org/images/datasheet33s.pdf, makes no mention of any I/O ports.

I wouldn't expect memory loss during battery changes, as long as this is done reasonably quickly. I've never had a problem with other HP calcs in this respect.


Well, with my FIRST HP, the 34C, I believe we were told in the manual (if anyone likes, I'll go look it up) that we had about a minute or two before programs and values stored in memory began to be lost or corrupted. I do recall that times I was able to swap battery packs efficiently, my programs were not lost, but when I was slow, there was the dreaded "Pr Error" message staring at me in glowing red.

I have not yet had to change (the disposable) batteries in my Pioneer series or Charlemagne series models yet, so for those, I have no idea.


I just checked my manual for the 42S. It states that the batteries must be replace within 1 minute of there removal to prevent memory loss.


For the record, the 32SII and 48G Series manuals give you 2 minutes to swap batteries without memory loss.

The 11C manual states that the memory is preserved without batteries for a "short time". This interval, though unspecified, supposedly allows "ample time" for battery replacement. Memory may be lost if the batteries are out for an "extended period".

Edited: 29 Sept 2003, 3:50 p.m.


"I wouldn't expect memory loss during battery changes, as long as this is done reasonably quickly. I've never had a problem with other HP calcs in this respect. "

Just you try an HP-28C/HP-28S. You'll discover a new definition of hair-pulling ! Worst design ever for a
battery door/battery compartment ...

Best regards from V.


I don't use the IR communications of my 48GX very often. But I use the wire communications port very regular. It would be great if the 33S would get a USB port to enable upload and download capability. This should allow the 33S to obtain the "seal of approval" from NCEES.


Some observant lurker noticed that the product sheet for the 33s' microprocessor (as announced, the "SPLB31A") notes 32K BITS of RAM, which translates to 4K bytes. Given the rough-cut nature of those early PDF product summaries, it wouldn't be surprising at all that the 33s has only 4k bytes of memory. For my part, I've been assuming the 33s has 4K, and will be pleasantly surprised if it has more than that.

Now, maybe that's enough for surveying applications, maybe not. It's still a whole lot of one-finger typing!


Yipes. And here I was thinking that the 32Kbytes of the 48G was confining.


The original message with the 4k warning has URLs for the SPLB31A datasheet.

(Now I'll go see if the work . . . )


There is a pre-release PDF product summary for the 17bii+, dated May 30, 2003, at: http://www.davik.plus.com/17bii+.pdf

According to this sheet, the 17bii+ has the "SPLB31A" CPU, and "32K bytes" of memory. Seems suspiciously similar to the 33S.

The 17bii+ is now available, and it has 28KB of memory. So the 33S may be similar.

By the way, the 17bii+ sheet also indicates that this model offers "Currency conversations". Apparently money talks.


Well, that's interesting. This from a datasheet that says (and I quote): "Memory Capacity -- Unlimited within available memory". I suspect they're using the same translation program for these datasheets that they used for the 49G+ manual.

Anyway, following the SPLB31A "confirmation sheet" link (see also earlier post), it doesn't exactly say "32K Bits", but does specifically say 4096 Bytes of data RAM (and 192 bytes of "zero page RAM", plus 256 Kb ROM). Well, maybe they added a memory chip, or somehow got parts with upgraded specs?

If it's got tens of thousands of bytes available, I'll be the last to complain! The 384 bytes (or whatever) in the 32s/sII was those models' major drawback, as far as I'm concerned. (Especially inasmuch as that limited space was needed for both programs and registers.)

However, even if it's got something like 32K of program space, it will be crippled if it's still only got the 32s/sII's 27 registers for data memory . . .

Hey! I'm ever-hopeful. I've pre-ordered a 33s from Samson Cables, and am blindly optimistic that the thing will act more rationally than it looks!


The available prerelease info indicates that the 33S will only have 27 storage registers, like the 32SII.

But look again at the 17bII+. I don't have one, but the manual is online; follow the "product manual" link from: http://www.hp.com/calculators/financial/17bIIplus/

At first glance, the 17bII+ seems even worse: it only has 10 storage registers. But if I understand the manual correctly,up to 28KB of equations and variables can be defined for use by the Equation Solver. The variables can have names up to 10 characters long. The values within the variables can be stored and reused by different equations.

If the 33S has a similar Solver, and if programs can invoke the Solver (as they do in the 32SII), then it may be possible to use Equation variables for data storage.



If someone were to offer a service whereby your programming, obtained as, say, a .txt file, was accurately entered into your calculator (mailed, I presume, to a post office box somewhere -- and returned promptly afterward), how much might you be willing to pay each time you needed it?


Nothing, because who could trust another finger pusher. Unless you develop a quick downloading method, you probably won't get any customers (even though they realize your effort is worth $$$$). Just no one can trust to pay you up front and you could not trust to be paid after the fact. Therefore It won't be worth your while.

And you could get an ocassional reset or memory loss from the customer (or he could inadvertainly delete) and want you to rekey.

Only way it works is if you develop a download technique that is fast and sure. Then maybe market that.


No, typing is much time-consuming than *checking*, so a suspiscious customer could fast-scan the program for correctness.
So this service has value.
However, from experience I think not a lot of people would put say $10 for service around a $70 calculator. Just a problem of perceived value.


And while checking, screw up your work, and expect you to again correct. May happen in 1 out of 20 cases (many people are much dumber than can be imagined, even an occasional RPN user). 8o) (BUT NOT ME!!!! well sometimes)

But when it does, and the person doesn't realize he is the one at fault, he will cause you 20 times the grief of your fee. Therefore you will break even and be stress out. Doesn't sound attractive to me. But if you can develop a fast download method, you could overcome this shortcoming.


(I'm not planning to have my high schooler type in calculator programs to earn his milk money!)

For the sake of this question, assume there's no accuracy issue. (The 42s' contents could be fully and automatically verified against the input by comparing an IR-output listing to the original .TXT file -- the 33s would have to have the MEM sizes of the programs checked manually against predicted values.)

Assume no physical changes to the calculator, except perhaps an optional 32K upgrade to the 42s, and/or a capacitor replacement to insure retention of memory during battery changes. Would it be worth sending it away to get its memory "refreshed"?

What if there were a library of useful programs available as well? (What if making your programming available to others helped defray any costs to you?)

The tone of the other responses is negative, though most of those objections relate to the accuracy question. I wonder if the value of these compact and otherwise powerful units would be enhanced enough to make a viable service of overcoming their external storage and bulk-input problems . . .


Recently, I was thinking about designing a machine to enter programs into calculators that don't have external input interfaces. What would be needed is an movable X-Y table and a spring loaded solenoid. The X-Y positioning system could be low-precision since it would only need .1" (or worse) accuracy and would only need to travel a few inches. There might well be some surplus robotics stuff out there that is perfect for such an application and that already has a PC interface. Much of the work would be in writing the program to position the right calculator key under the solenoid, working out the solenoid stroke to avoid key bounce and translating the PC-stored calculator program into the right keystrokes.

This would allow for long programs to be loaded with much less chance of error than a person entering them. But you'd still need some sort of verification to make sure that it loaded correctly. The 20S, 21S and 32S/II provides a checksum for this purpose, but I don't know of any other HP calculators that do. Alternatively, calculators with IR printer output could be matched against the PC-stored program for error checking.

Has anyone tried to make such a machine? (Should I head down to the patent office right away or will they just cart me away when I get there? :)


re: "Has anyone tried to make such a machine?"

I'm not sure about _making_ one, but a while ago (perhaps two-ish years) there was a fair discussion of such a robot button pusher - specifically to overcome the lack of I/O capability for certain of our favorite toys.

Somebody more familiar than me with searching the archives out to be able to find it.


I much prefer an actual add-on, which permanently "enhances" the function of the calculator.

In a 33c, for instance, one could imagine a postage-stamp sized circuit board designed to hide in the internal cavity of the calc. Tagged to the matrix lines of the keyboard, so that it takes on the keyboard entry function electronically. Paralleled, in effect, with the real keyboard. If it is to synchronize with cpu signals on those pins, it might well be able to derive timing for its function from there.

It would communicate with the outside (probably a pc serial port) via the power-port. Your wall-charger would be a modified version of the regular one, but have a serial input port, and the incoming keypress data would modulate the power in a way that could be interpreted by the keypress circuit.

So your 33c would look the same in every way, yet a user could send a file of keypress data into it when needed. In every other circumstance, the extra circuit card would be dormant, benignly silent *(maybe the presence/absence of a modulating signal on the power line would wake/sleep the circuit)*.

I have no idea of the internal workings of a 33c, yet I think this sort of thing SHOULD be in the realm of the possible. Anyone know whether this could or could not be done, and why?

Would darn sure be convenient to have a "library" of programs that might be downloaded rather than "prodded" into the machine.




If you can find an HP Digest issue (perhaps from 1979, I'm just trying to recall back from 25 year old memories), you'll see a black and white photo of an HP Button Pusher "robot", used to simultaneously exercise two or three Woodstock-class machines. I think it was sort of a quality control device, to test serviced units (HP considered calculators as not discardable items at the time).


The discussion about a "paralell keyboard" could be found in the MoHPC archives. Paul Brogger, Tony Duell, others, and I discussed how to arrange a couple of CMOS multiplexers (chip type is CD4052) and some optocouplers to create an electronically driven switch matrix which serves as a program input device for a HP42S. While I was not willing to risk my mint HP42 in the project, Tony Duell actually built and successfully test the circuit. What was left undone (as far as I know) was the PC interface. My idea was to use the printer/paralell port, but I also noticed there were drivers issues to be solved for a Windows environment. Since Tony is a Linux user, he could avoid such limitations...

For everyone else:

If the shipping issues could be solved (I don't think so), I can say (with pity and shame) that in my country you can find many, many unemployed, or almost unemployed, very qualified people (even medical doctors, engineers, PhD, etc.) who would program your calculators for a few dollars and with their degrees as a quality warranty.



I don't know about sending our calcs to Argentina to be programmed, supposedly the US is outsourcing too much high-tech labor already! :)

It's horrible that you have so many well-qualified people that are un/under employed. We complain about the situation here but I think that it's nowhere near as bad as it is in many other countries.




Thank you for your kind comments; as far as outsourcing technology, certainly is not here where it is being done :)

And as far as how the situation goes, while there are many problems generated outside Argentina, I admit that we (as a whole, not individually) are very good in making things worse by ourselves.

I hope you can find some materials related to the HP Button Pusher, supposedly deployed at Corvallis in the '70s.


The article about the HP button pusher is in HP Digest Vol. One, 1976 on page 25. This issue is on one of the museum's cd roms in the directory 'Digests'.



That's it!! Thank you.


I built one once out of a cheap X-Y plotter. By taking off the plotter surface, the calculator could be put down into the machine case. Pen DOWN/UP commands pushed the buttons. Took about an hour to get everything working.


If the checksum is the 'exclusively' identifier, why not remakeable the program from it?

The programming: CK=? [type it...] HOW LONG? [type it, if it's necessary...]



Depending upon the checksum algorithm employed, the checksum will typically have enough information to indicate whether one or two mistakes have been made, but won't tell you where the mistake(s) is (are), and it (almost) certainly won't have enough information to completely rebuild the program.

Two very different programs may have the same checksum value. The idea is that two programs which differ, say, by only one line, will have different checksums. A wrong checksum indicates that the programmer must look more closely to find what is missing, or has been inserted, or may have been misspelled.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Integration Times "Old" 33s vs "New" 33s John Smitherman 21 3,889 12-14-2005, 12:04 AM
Last Post: Karl Schneider

Forum Jump: