HP Forums

There was much discussion late last year regarding the desire for and creation of a new calculator, either by HP or by a dedicated independent group. Many people spent a lot of time and effort defining what such a calculator might look like, the functions it should have, how it might be produced, likely hurdles to an independent production, etc. At some point, the possibility of modifying the 35s instead of building something from the ground up was raised. DaveJ conducted a poll on the idea. In that discussion, a link to the Newhaven Displays web site was provided as a possible source for an LCD display to use in a home-brew or retro-fit project. Just for fun, I poked around that web site and found what appeared to be a number of candidates that could work. I was surprised that they weren’t all that expensive, so, in a fit of irrational exuberance, I ordered six displays of various types and sizes just to see them in person and hold up next to my 35s to assess how they might work. Being primarily interested in a multi-line graphics-capable display, I ordered the following:

NHD-10032AZ-FSPG-YBW, 100 x 32 pixels

NHD-GDSC-12864WM-09-RN-GBW, 128 x 64 pixels

NHD-12032BZ-FSW-GBW, 120 x 32 pixels

NHD-12232DZ-FSPG-GBW, 122 x 32 pixels

NHD-LGC12865AZ-RN-FBW-3V, 128 x 65 pixels

NHD-LGC-12864GG-RN-GBW, 128 x 64 pixels.

This is what they look like next to my 35s:

I really liked the large 128 x 64 pixel display. It compares very favorably in size with the 48G display. Here's what it looks like on top of a 35s:

It looked like there might just be enough room for this display, with the goal of achieving a transformation like this:

I shared the above information with DaveJ and we exchanged some e-mails on the project. It became obvious that to go any further in figuring out which display might work as well as many other things, it would be necessary to fully disassemble a 35s. So, in another fit of irrational exuberance, I ordered a 35s to be used as a dissection subject. (I already had two 35s’s, but didn’t want to tear into either one of those for “sentimental” reasons, I guess.) I ordered a new one from newegg.com and received it shortly before Christmas. The disassembly process went as follows. Opening the case is easy. Remove the rubber plugs in the four corners of the battery compartment, then peel off the rubber strip on the bottom of the calculator, and remove the six screws. The front and back halves of the case are also held together by five plastic catches, one in the middle on the top edge, one in the middle on each side, and one near the bottom on each side. These catches are not exceptionally tenacious; some gentle tugging at the case halves and careful prying between them will fairly easily separate the front and back, yielding this:



(credit and thanks to Lyuka for the above picture.)

It certainly appeared that the PCB was held in by those small screws (25 of them), so I removed them all. Gentle prying on the edges of the PCB did not yield any movement. Close inspection revealed that the posts into which the screws were screwed were mushroomed over at the top, just like the heat stakes in other HP calculators. Taking a cue from the tips for disassembling those calculators, I attempted to trim off just the mushroomed-over portions of the posts, i.e. leave the center part of the post sticking through. Due to lack of skill, lack of close-focus ability (damn presbyopia!), lack of sharp knife, type of plastic, or some combination thereof, I was unable to trim them cleanly enough to free up the PCB. I then decided to just trim the posts off flush with PCB, and with a little gently prying, was finally able to free up the PCB. (I then realized that this was likely to be necessary anyway to enable the screws to hold the PCB back in when it is re-installed. Otherwise, the screws would not be able to tighten down against the board to hold it firmly in place.) Once the PCB comes out, next is a thin rubber membrane, then the keys themselves. The keys are in two groups with a number of keys connected to a plastic frame, with the four cursor keys adhered to their own separate rubber membrane. Here are some pictures of the disassembled calculator:

Main PCB, back side:

Main PCB, front side. The white covering is a thin sheet of plastic of some sort that is adhered to the board. The little bumps, (not all are visible) appear to be metal dome key switches:

Key assemblies, front:

Key assemblies, back. The small post in the center of each key is what actually presses the key contact through the black rubber membrane:

Rubber membrane. Sorry about the poor quality of the photo. This is the side that faces the keys. It is flat except for small circular raised areas below each key, some of which are visible. The back of the membrane (the side toward the PCB) is flat:

Front case half, outside:

Front case half, inside:

There does not appear to be any sort of contact strip or similar which interfaces the key switches on the front of the PCB with the electronics on the back side. My uneducated guess is that the traces that interconnect the key contacts come through the board in various locations, which would make interfacing a new board with the factory key switches challenging. At first I found this disheartening, but then I wondered if it might be possible to basically strip all components and traces off of the back side of the PCB, find the spots where the connections are made to the key contacts on the front side, and solder to those points. (By strip off the components, I mean taking a soldering iron and removing everything that can be unsoldered, scraping the epoxy (or whatever they are) blobs off of the integrated circuits, desoldering or prying or cutting the chips off, then holding the board against a belt sander to take all the traces off.) I shared my above findings and ideas with DaveJ. Suffice it to say that he was not enamored with my idea for stripping the back of the PCB to use the existing key switches. Dave feels it would be entirely feasible to create a new PCB for the new electronics on one side and with new metal-dome key switches on the other. I’ll leave it to Dave to explain this more fully.

I then turned my attention to how or if any of the displays might fit. First I placed the large 128 x 64 pixel display in the display area of the inside of the front half of the case. There are four screw posts in this area. The large display will not fit between these posts side to side or top to bottom; at least two of the posts would have to be removed. I think it would probably be OK to remove the two posts at the very top of the case. The big display might then (barely) fit between the two remaining posts and the top of the case. It might be necessary to remove some of the inside edge of the top portion of the case, which would also necessitate removal of the plastic catch in this location. I don’t know if the remaining fours screws and the plastic catches on the sides would be enough to securely hold the front and back case halves together. Here are a couple of pictures:

Large display with LCD facing front:

Large display with LCD flipped over:

I think that the large display could be made to fit inside the case and would provide a very nice display. With 128 x 64 pixels, I figure a display that would show a row of soft-key labels, the X, Y, Z, T and Last X registers, plus have room on top for some annunciators and a clock display could be created. (That’s based on using nine pixels for the soft-key label and register rows, leaving ten pixels at the top for the annunciators.)

However, if the large 128 x 64 pixel display just won’t fit, the 128 x 65 pixel display would almost certainly fit. It is narrow enough to fit between the two screw posts at the bottom of the display area, but the top two posts would still have to go. However, this would allow the display to move down enough that I don’t think it would be necessary to remove the top plastic catch. This display looks like this:

For completeness, here is the small 128 x 64 display. There would not appear to be any reason to consider this one as the top two screw posts would still have to be removed:

Finally, if none of the above displays would work, the largest of the smaller displays (the 120 x 32 display) should not require the screw posts to be removed.

Other issues and observations – Even if it is possible to make a new PCB with a new processor and install a new display in the case, the issue of re-labelling the keys and the keyboard will remain. It seems like getting new legends on the keyboard itself should be doable via several methods. One way might be to merely paint over the existing keyboard, then apply new legends via silkscreen (never done it, don’t know how hard or costly) or rub-on lettering or other. The whole face of the calculator appears to be a thin aluminum sheet similar to the back labels on the classic calculators, so perhaps it could be removed and a new one fabricated. (Such fabrication should be possible, see the thread of some years back regarding fabrication of replica or “fake” rear labels for classics.) I’m sure there are other possibilities. Re-labelling the keys themselves looks like it will be a tough problem to me. If we could live with the factory legends on the key faces, that would help, but almost any good new layout will require some changes I think. At a minimum, I think all agree that we need “STO” to be an unshifted function, and I’d like Pi to be primary. For example, my idea of a good layout would look something like this:

The above layout would require 21 of the keys to get new primary legends (only 19 if the existing shift keys could be tolerated.) While not everyone would necessarily agree with my layout, I’m guessing most alternatives would require a fair number of keys to get new primary function labels on top. Then of course there are the legends on the sloped front part of the keys. Getting rid of those would be doable with sandpaper or paint, but placing new ones on the keys would appear to me to be very challenging.

About the only thing left that I can try would be to take a dremel and start carving out the case in the display area and see which of the displays will fit. I'm willing to do that, as well as anything else that would require the services of my donor unit, if doing so will actually help this project along. For the time being, I think my unit could be re-assembled, so I don't necessarily want to do anything irreversible yet. In fact, after I took the above pictures, I put the PCB back in and reattached it with the screws. The screws seemed to thread back in OK and hold the PCB securely, and the key-press feel seems to be as good as new. Unfortunately, I broke off one of the battery connection wires (the yellow one) and have not had time to re-solder it. The calculator does turn on this way and seems to function, but it shuts itself off after a few seconds. If I hold the wire in place, it stays on and seems to work fine, but it's a little awkward to give it thorough test. However, I'm confident that it does still work.

At this point, I've probably rambled enough, so I'll invite Dave to comment on my findings, and the next steps in the project.

best regards,

Jeff

Edited: 10 Jan 2008, 9:10 a.m.

WOW!!! Great work, Jeff! Thanks a lot for sharing! Please allow me 3 fast remarks:

+ Vertically, already 32 pixels will suffice for a decent display. 3 rows of full char height (= 9 pixels incl. spacing) plus 1 row containing smaller chars (= 5 pixels for the indicators, Luiz's HP Dot Matrix 1 character set). 3 ENTER 9 x 5 + results in 32. With a menu line in the bottom row you'll still have x and y displayed permanently. 64 pixels will allow for decently displaying stack contents like matrices needing more than one line. So, everything is just fine vertically.

+ Horizontally, the standard HP graphic calc LCD is 132 pixels wide. This allows for 6 soft labels of 21 pixels each plus 1 pixel spacing (of course, only 131 pixels are needed). Actually, the 42S features a 131x16 LCD. A width of 128 pixels takes 1 pixel from each soft label, so some restrictions apply for some command names. I'll check this and post the results later.

+ Unlike Pioneers, the design of the 35s does not feature menu keys like the top row of e.g. the 42s. Still thinking about a nice way around...

Hey, hep, fly Phoenix, fly! d:-))

Best regards, Walter

Edited: 10 Jan 2008, 12:58 p.m.

Good stuff! I think you're on a right track.

Re: using the existing PCB -- I found that easy for my pretty-long-ago lash-up of a 41C keyboard/case with a TI-83+SE. I used wire-wrap wire, and merely found the best row or column trace matches to connect with the ends of each wire.

This was simplified, of course, by the easily-stripped 41C PCB (I only had to remove the display), and by the relatively HUGE traces & spaces on that PCB. (I may have resorted to cutting a trace or two to make the row/column match-ups work better -- I don't remember exactly.)

On the 83+ I could find feed-thru holes that connected to the keypads, and the whole process didn't take all that long. The 41C's "ON" and shift keys were aligned with those of the 83+, so that turning the TI on & off worked with the relevant H-P keys.

For the 35s, you might want to find a solvent that would remove the black mask before chasing traces. As far as scraping off blobs, etc. -- have you considered merely "digging a moat" around them to disconnect all the traces, thus isolating the keyboard rows & columns? It seems to me that, especially for an original mock-up unit, using the existing keyboard would simplify one aspect of the project.

Whatever -- sounds like a fun one!

Excellent work Jeff!

Several points I see with regards to the details presented:

The Display:
I would not try to widen the display window area to fit the screen, that would ruin the look of the calculator. Rather simply, live with whatever display area is left over in the existing window.

The Keys:
I'd just leave them as they are and make use of what you've got, as it all seems too hard and would most likely ruin the look of the calculator.
If you don't like keys that are offered then simply re-map them to the menu system and leave the existing key unused.
The idea (for me) is to create a nice looking DIY calculator with minimal effort, not to create a perfect calculator with perfect layout (which will never be possible anyway).
I like the idea of someone being able to pick it up thinking it's a regular HP 35S, and then being surprised when the big Phoenix logo appears on the screen, and only the "initiated" know how to use it!

The Menu:
I would not try to mimic some other HP calc menu system unless it makes total sense and integrates nicely with the design.
The MODE key is a prime candidate to become the "MENU" button. Press it once and the menu pops up. The Menu can then be scrolled through with the arrow keys. Advantage of that is the menu only takes up room on the screen when called.
Menu options can map the other keys. For example, you could have two rows of three options each (allows for more characters) which would physically map to the
"4 5 6" and
"1 2 3" keys.
You could even have three rows of menu options (9 total) and map the "7 8 9" keys as well.
Not being directly under the display would not be a problem I don't think, it's easy to map these in your head.

The PCB:
A new PCB is by far the best way to go I think. We need a new PCB anyway, so makes sense to replace the old one with new keyswitches. That eliminates any dodgy wiring and makes the upgrade simple enough for anyone to do.

More to follow...

Dave.

Edited: 10 Jan 2008, 3:56 p.m.

A question that will need answering fairly early is processor choice.
This may depend on several factors:

1) What the software developers are familiar with and have the tools for. In-Circuit debugging would be a big requirement I think.

2) What computing power this thing should have.

3) Scope for expandability.

4) Package choice for ease of hand prototype soldering, and cheap small scale production.

5) Software tools should be free and easy to use.

Without doing any research, these are my comments up front:

- An 8 or 16bit microcontroller would seem like the most sensible choice at first glance.
I used a PIC 24F series in my HP-02 uWatch, and Eric used a PIC 18F series in his DIYRPN. Any processor chosen should have at a minimum the following requirements:

a) 64KB+ of Flash memory

b) 8KB of SRAM (probably not that important)

c) In-Circuit serial programming and debug (PIC has the ICSP port for this)

d) The ability to self-program the FLASH, so a bootloader can be used to upgrade the firmware from say the SD card. As very few people would have a Microchip programmer. Ease of firmware upgrade is important, as I suspect it will be done often.
A JTAG port would be nice.

3) A hardware RTCC. Software ones are archaic.

4) Dynamically selectable processing speeds. e.g. 32KHz-128KHz is plenty for just general operation, but you might want to run at say 8MHz when running a program.

So I guess we'd want a pretty good reason to go with anything else but a PIC in the 8/16 bit category?

My first choice would be the 24FJ128GA006

- A square TQFP package seems like the package of choice. Both my uWatch and the DIYRPN use this. BGA should be ruled out as it's difficult to DIY and inspect.

- ARM would be a serious contender too, but is it overkill?, and which actual vendor and part?

- 32bit micros are an option too, but you might as well go for ARM in this case?

- An FPGA would be an outside runner. Has the advantage of being able to use any soft core you like. ARM, 8051, or whatever.
But big disadvantages are the package (most are BGA), lack of some useful dedicated hardware, and much more complicated and less mature software toolset. There can be a big hurdle just to get your Hello World working.

Comments please...

Dave.

Edited: 10 Jan 2008, 7:03 p.m.

With respect to the menu keys: one opportunity is to take the top left 4 keys, so we'd have 4 soft labels in the bottom display line. This is 31 pixels per label plus 1 pixel spacing, allowing for longer command names displayed than in the 42S. In the next display line, you'd find another 4 soft labels, being addressed via <shift> + <menu key>. Thus, a total of 8 menu labels will be accessible in one single view.

Under these conditions I vote for a visible display area showing at least 41 pixels vertically. This is for 4 lines plus indicators then in full analogy to my previous post. IMHO a display window extended some 5mm towards the bottom would not destroy any valuable design but make the calc even looking better.

With respect to key labelling I'd leave the bottom 5 rows as is. For a preliminary DIY calc (and to test designs), I'd propose the 3 top rows and all the slanted key areas painted white - allowing for individual "manual labelling" using a fine waterproof ink and coating with some clear varnish. This would make heavy use of the ASSIGN functionality, of course.

Quote:

---

With respect to the menu keys: one opportunity is to take the top left 4 keys, so we'd have 4 soft labels in the bottom display line. This is 31 pixels per label plus 1 pixel spacing, allowing for longer command names displayed than in the 42S. In the next display line, you'd find another 4 soft labels, being addressed via <shift> + <menu key>. Thus, a total of 8 menu labels will be accessible in one single view.

Under these conditions I vote for a visible display area showing at least 41 pixels vertically. This is for 4 lines plus indicators then in full analogy to my previous post. IMHO a display window extended some 5mm towards the bottom would not destroy any valuable design but make the calc even looking better.

---

And just how do you propose to widen the display window while being able to guarantee a professional looking molded type edge?

Why not have the menu appear and disappear when you press a menu key? That way you can use as much of the screen for a menu as you like, and you have extra room for stack line display when the menu is not being used. All without having to hack the window bigger.

Quote:

---

With respect to key labelling I'd leave the bottom 5 rows as is. For a preliminary DIY calc (and to test designs), I'd propose the 3 top rows and all the slanted key areas painted white - allowing for individual "manual labelling" using a fine waterproof ink and coating with some clear varnish. This would make heavy use of the ASSIGN functionality, of course.

---

I don't quite understand everyone's apparent obsession with changing the keys. It's going to look just awful. You want to take the best looking calculator on the market and paint bits white and texta in labels?, I don't get it.

Why not simply put everything in the menu system and live with the existing keys?

Dave.

I agree with just about everything DaveJ wrote.

Quote:

---

Any processor chosen should have at a minimum the following requirements:

a) 64KB+ of Flash memory

b) 8KB of SRAM (probably not that important)

---

Flash size will be a problem at the 64kb end. We're not going to be hand coding and size optimising everything. We will use a compiler, we'll probably use standard libraries. This will blow out program (flash) size. Also firmware has an annoying habit of growing over time. The suggested PIC part has 128kb of flash which would be the minimum I think we'll get away with.

As for RAM, for a non-programmable scientific, 8kb will be copious. If we add any form of programmability I'd suggest 32Kb as a minimum and 64kb would be preferred. Again, we're not going to spend many hours tuning code to reduce the memory footprint. We're going to use C and RAM will get wasted. EEPROM might also be acceptable for registers and keystroke program memory with a small amount of RAM for scratch use.

As for ARM vs PIC, I don't really care much either way. ARM will perform better and is better suited to programming in C but fundamentally the choice isn't that important from a software point of view. Other issues like power consumption and on-chip facilities (e.g. USB host controller, LCD controller) will be overriding.

- Pauli

Quote:

---

And just how do you propose to widen the display window while being able to guarantee a professional looking molded type edge?

I don't quite understand everyone's apparent obsession with changing the keys. It's going to look just awful.

---

Dave,

I think those that want to make the display bigger and change the keyboard want to do so because, well, they hope to create their idea of a good calculator, rather than what they might view as a compromise where the display isn't much bigger than existing models and the key kegends don't match the key functions. With that said, I can certainly see that the simpler the project is, the more likely it is to succeed. With that said, as far as making the display window bigger, I have to believe that it would be possible to come up with some way to make it look decent. But, as I stated in my original post, the keys and keyboard will be a tough problem.

However, is it fair to say that at this point, these issues do not have to be resolved? In fact, couldn't such things be left up to the ultimate users? If we pick a good processor and display and make a new PCB, couldn't one user just drop everything in, use the display area that shows through the window and leave the keys and keyboard alone, while another user might choose to make the display window bigger and fully customize the keys and keyboard via whatever methods they can come up with?

Quote:

---

Dave,

I think those that want to make the display bigger and change the keyboard want to do so because, well, they hope to create their idea of a good calculator, rather than what they might view as a compromise where the display isn't much bigger than existing models and the key kegends don't match the key functions. With that said, I can certainly see that the simpler the project is, the more likely it is to succeed. With that said, as far as making the display window bigger, I have to believe that it would be possible to come up with some way to make it look decent. But, as I stated in my original post, the keys and keyboard will be a tough problem.

However, is it fair to say that at this point, these issues do not have to be resolved? In fact, couldn't such things be left up to the ultimate users? If we pick a good processor and display and make a new PCB, couldn't one user just drop everything in, use the display area that shows through the window and leave the keys and keyboard alone, while another user might choose to make the display window bigger and fully customize the keys and keyboard via whatever methods they can come up with?

---

Sure, the end user is free to choose how far they want to take this, that's not a problem. But what is a problem is that the software will be different (perhaps very substantially). And what happens if the software developer(s) don't want to write software for say the "unmodified" version. Then you are forcing everyone into having to hack their calculator, with varying degrees of success. A lot of people may not bother and the project isn't nearly as popular as it could be.

I for one wouldn't want a hacked up looking calculator, but perhaps I'm the only one...

Once you start down the customised key path, the project risks spiraling into failure, as everyone wants something different. I'm just trying to head that off at the pass by simply recommending no modification at all, use it as-is, no choice to be made.

Dave.

Hi,

a small correction regarding your pixel row calculation.

At least on the HP-48 series machines, the menu key row is eight pixels high, not five as you indicated,

and you'll need a minimum of 7 (seven) pixel rows for the menu row;-)

HTH

Raymond

Raymond,

where's the problem? I wrote:

Quote:

---

3 rows of full char height (= 9 pixels incl. spacing) plus 1 row containing smaller chars (= 5 pixels for the indicators, ...

---

Quote:

---

At least on the HP-48 series machines, the menu key row is eight pixels high, not five as you indicated,
and you'll need a minimum of 7 (seven) pixel rows for the menu row;-)

---

Jeff, Dave, all,

Quote:

---

I think those that want to make the display bigger and change the keyboard want to do so because, well, they hope to create their idea of a good calculator, rather than what they might view as a compromise where the display isn't much bigger than existing models and the key kegends don't match the key functions. With that said, I can certainly see that the simpler the project is, the more likely it is to succeed. With that said, as far as making the display window bigger, I have to believe that it would be possible to come up with some way to make it look decent.

---

Quote:

---

But, as I stated in my original post, the keys and keyboard will be a tough problem.

---

Quote:

---

If we pick a good processor and display and make a new PCB, couldn't one user just drop everything in, use the display area that shows through the window and leave the keys and keyboard alone, while another user might choose to make the display window bigger and fully customize the keys and keyboard via whatever methods they can come up with?

---

Quote:

---

(Dave:) But what is a problem is that the software will be different (perhaps very substantially).

---

Quote:

---

I for one wouldn't want a hacked up looking calculator, ...

---

HTH, Walter

Quote:

---

Nor do I. But hey, we are just starting! You will get your golden calc some time anyway ;) And I offer to do the white painting myself, not to spill your calc, as long as the assignment feature is in ;) My proposal was just to assure full flexibility at low cost.

---

In this case you are not getting full flexibility at low cost, you are paying a high price for it because of all the extra hack work you have to do.
With an LCD menu system you have infinite flexibility, there is no need to modify key keyboard in any way.
I personally find the whole idea of hacking the keys and front panel rather distasteful! It's much more elegant to utilise what's already there without changing anything externally.
If you want full flexibility like this with proper mapped function keys, I'd seriously suggest you buy one of Eric's DIYRPN's!

Dave.

You're right, of course:-)

Quote:

---

In this case you are not getting full flexibility at low cost, you are paying a high price for it because of all the extra hack work you have to do.

---

Quote:

---

I personally find the whole idea of hacking the keys and front panel rather distasteful!

---

HTH, Walter

P.S.: Unfortunately (or does it tell anything?), the English language has just one word for design, making it difficult to talk about the difference between good design and good design ;)

Edited: 11 Jan 2008, 12:29 p.m.

Quote:

---

[...]I personally find the whole idea of hacking the keys and front panel rather distasteful! It's much more elegant to utilise what's already there without changing anything externally.[...]

---

I second that - and all the rest of DaveJ's ideas!

BTW: Jeff O. - Great work!

Edited: 11 Jan 2008, 9:23 a.m.

Quote:

---

But what is a problem is that the software will be different (perhaps very substantially). And what happens if the software developer(s) don't want to write software for say the "unmodified" version. Then you are forcing everyone into having to hack their calculator, with varying degrees of success. A lot of people may not bother and the project isn't nearly as popular as it could be.

---

On the other hand, if the option for a modified version with a big display is not there, then you are forcing everyone to "settle" for something that may be viewed as only marginally better than a stock 35s, so a lot of people may not bother, and the project isn't nearly as popular as it might be. As far as the software differences, I'll admit to having essentially no clue as to the level of effort that will be required to develop it. My guess is that a lot of effort will be required to get it from nothing up to something that can do a suite of basic calculations and display the results. My hope is that a proportionally much smaller effort would then be required to provide the capability to choose between different display sizes, menu driven vs. custom keyboard, etc. This may be naïve. (By the way, I’m certainly willing to contribute to that effort. I have no current skills in such things, but I’d be willing to learn if it’s not something that requires four years of school plus 10 years experience to be any good at it.) Again, can’t we proceed on a path that would allow either option? I assume the processor you suggested would have enough power to go either way, correct? Are there likely to be any hardware choices that depend on locking-in on “hacked” vs. “non-hacked?”

Quote:

---

I for one wouldn't want a hacked up looking calculator, but perhaps I'm the only one...

---

I think that there is probably a wide spectrum of what would be acceptable. Some might like it to look hacked as evidence of their hacking skill. Others wouldn’t care how it looked, as long as it did what they wanted it to do. Some might want it to look pretty finished, but wouldn’t mind if it showed evidence of custom work, and some wouldn’t want anything but a total factory appearance.

Quote:

---

BTW: Jeff O. - Great work!

---

This is where we have to start talking software, and how the calculator will be implemented. I suspect there will be a lot more contention over how the thing will ultimately work, so any argument over whether or not a few keys have been changed or how big the display is might become trivial.

After all, a project like this is useless if the person(s) writing the software don't add features and implement things the way people want.

Now, I suspect that how I see the calculator working and what features I want are probably far removed from what others on this forum want. And the same can probably be said of others.

For instance:

I don't need:
- programming capability.

- communication capability.

- advanced math stuff like support for huge matrices and integration.

I do want:
- A good post-fix algebraic mode (I'm not a big RPN user, so do as you please with that)

- A real engineering key that works like the Casio's

- Good and simple support for base-N conversions, up to 64 binary bits.

- A nice big high contrast font with real exponent support (i.e. make the exponent a smaller raised font)

- Conversions that are useful for me (e.g. inches<>mm, not inches<>cm), and I want them easily accessible

- Useful (for me) easy to access constants, like 2*PI, SQRT(2).

- A parallel key as a primary operator with the same precedence as Multiply and Divide.

- (optional) A way to store, recall and use simple formula, preferably with a text based prompt to remind you what it is and what the inputs are. Ideally I'd like to embed some of these into the calculators primary functionality. And I don't mean full programmability here, I don't need loops and such.

- A simple two key storage and recall system (e.g. STO/RCL 0-9), plus a single key store/recall option as well for the most frequent use stuff.

-A history stack of previous results.

and I could go on.

What does all that mean?
I suspect everyone will have a similar list, and how much of it is going to tee up with what the programmer(s) ultimately do?
I know that if I can't get most of that stuff then I'm probably not going to want one of these things.

That might mean that to get what I want, I will probably have to program the thing myself, as might others. Now that takes us into the area of how easy it is for someone to customise their own calc.
From a programmers point of view I'd want a ridiculously easy to use "toolbox" of software functions that for instance handled the display. So I could simply call stuff like this:
InialiseLCD();
SetupLCDfontSize(1);
WriteLCD("message");
etc so I don't have to reinvent the wheel on all that difficult stuff to get to my Hello World working.

If such a simple to use toolbox is not available then I'll have to do it myself. And now here's where it gets interesting from a hardware point of view - in that case I'm not going to want the graphic LCD, as it's just too much work for me to do all that stuff myself. For instance, in my uWatch, the software toolbox code that controls my LCD is little more than a few dozen lines of code, with no memory overhead for fonts. Compared with a graphic display which would require orders of magnitude more code and a lot of memory space to store the font(s).
In that case give me a 2 or 4 line character based LCD as I was discussing in the previous threads. Perhaps even one of the OLED modules. Oh, a 35S screen that glows...

This is how these projects can start to lead down all sorts of garden paths!

Dave.

Edited: 12 Jan 2008, 2:25 a.m.

Jeff --

Impressive efforts! The insights are appreciated.

As we discussed at the 2007 HHC conference, I'm focusing my work on fostering functional improvements to the HP-35s with the calculator team.

-- KS

Edited: 12 Jan 2008, 7:08 p.m.

Hi Karl,

Thanks for your comments. I certainly hope your efforts to encourage the improvements to the HP35s pay off. Even with an improved HP35s, it would still be neat if the Phoenix 35sx could somehow come into existence.

Jeff

I think that most people want programmability and some sort of communication. I don't have a problem with anything on your list - as long as I can get everything on my list too. We obviously need a flexible hardware platform that's easy to program (piece of cake, right?)

Has anyone done any research at what's available in LED displays these days?
I've been having a quick look around and the smallest 7 segment display I can find is the typical 0.3" display at 7.6mm wide. (also available in BLUE!)
There are a couple of slightly smaller ones, but you don't gain much.
At that size you'd only get two rows of 8 characters in the existing display window, but you could have say the top row display the exponent, giving a usable 8 digit display on the bottom.

Imagine a 35S with a luminous Blue 7 segment LED display! ;-)

Dave.

or the luminous blue 17 segment display (the exact pattern as in the 41) that was used in those craig language translators. now THAT would be cool.

I'm partial to these:

http://www.avagotech.com/products/led_displays/smart_alphanumeric_displays/parallel_interface/hdsp-2111/

Quote:

---

I'm partial to these:

http://www.avagotech.com/products/led_displays/smart_alphanumeric_displays/parallel_interface/hdsp-2111/

---

I've seen those. But I don't like the dot matrix look, and the power consumption is very high.

Dave.

Quote:

---

or the luminous blue 17 segment display (the exact pattern as in the 41) that was used in those craig language translators. now THAT would be cool.

---

Like THESE?

Can only fit 6 of the those in the display window though.

Dave.