There hasn’t been much discussion lately regarding concepts for repurposing the 20b. But I started thinking about it a while back and put some time and effort into developing my concept for such a project, so I figured I’d go ahead and present it for review and comment. Here’s my concept for what it might look like:

(Sorry for the illegibility of some of the legends. The gold legends above the x, - and + keys are :CFIT:, :I/O: and :TIME:, respectively.

Salient points:

• command set, programming paradigm, etc. are intended to be basically the same as the 42S with maybe some 35s features thrown in. Alpha capabilities for program and variable names would be included if at all possible, but that capability will likely depend on memory constraints.
  
• on the keyboard, legends which represent menus are surrounded by colons and legends not surrounded by colons are direct functions. (I’m pretty sure that this was originally proposed by Pavneet Arora, and I like the idea so I used it, but full credit goes to Pavneet.)
  
• commands in menus would be displayed in the 6 x 43 dot-matrix area, two commands per “page”. The two leftmost keys in the top row would be the soft keys used to access the commands. (Note that the 6 x 43 grid provides two 6 x 21 arrays, with one “blank” column of pixels between them. The 42S utilizes 7 x 21 pixel arrays to display its soft-key labels, but the characters are only 5 pixels high. So 6 x 21 ought to work.) Might look something like this:

  

• menus would be limited to at most 6 commands if possible, to enable all of their functions to be accessed either directly after calling up the menu or by scrolling up or down only one time.
  
• Complex number entry would be as on the 35s, i.e. key in real component or magnitude, press “i” or the angle symbol, then key in the imaginary component or angle.
  
• Complex number display: My preferred plan would be to display the real (or magnitude) in the 7-segment display area and the imaginary part (or angle) in the dot-matrix area. I believe that it would be possible to display at least four significant figures of any number in this area. Based on the display simulations I did, and tests using the ability of the 20b to display a message when it is first turned on, I think it might look okay. I tried to simulate this as best I could in the above large image. If numbers just don’t look right displayed in dot-matrix area, I would propose the method used by the 15C: a parallel, unseen stack that would hold the imaginary component or angle. In this case I would work in the Re<>Im and (i) commands of the 15C to either swap the real and imaginary parts or temporarily display the imaginary, respectively.
  
• there would be no polar or rectangular display mode. Complex numbers would be entered in either form and would be stored and displayed in whatever form they were entered. Two numbers in different display modes could be used in functions using two arguments. (The form of the result in such cases would be a selectable option by the user.) This leads to a new suite of polar/rectangular/complex/real conversion functions, as follows:
  
  
  • R->P: Rectangular to Polar conversion. If stack x and stack y both contain real numbers, treats stack x as real and stack y as imaginary components and returns the magnitude and angle (in current angular mode) to stack x and stack y, respectively. If stack x contains a complex value in rectangular form, converts it to a complex value in polar form. Otherwise takes no action.
    
  • P->R: Polar to Rectangular conversion. If stack x and stack y both contain real numbers, treats stack x as magnitude and stack y as angle (in current angular mode) and returns the real and imaginary components to stack x and stack y, respectively. If stack x contains a complex value in polar form, converts it to a complex value in rectangular form. Otherwise takes no action.
    
  • R->C: Rectangular to Complex conversion. If stack x and stack y both contain real numbers, treats stack x as real and stack y as imaginary components and assembles a rectangular-form complex value in stack x. Otherwise takes no action.
    
  • P->C: Polar to Complex conversion. If stack x and stack y both contain real numbers, treats stack x as magnitude and stack y as angle and assembles a polar-form complex value in stack x. Otherwise takes no action.
    
  • ->REAL: Complex to real. If stack x contains a complex value, places the imaginary component (if rectangular-form) or angle (if polar-form) in stack y, and real component or magnitude in stack x. Otherwise takes no action.
    
  • C->C*: Complex Conjugate. If stack x contains a complex value, replaces that value with its complex conjugate. Otherwise takes no action.
• Assuming numeric display looks okay, when a real value is in the x register, the dot-matrix area would be used to display the y, z, t or Last x register (or other stack levels if a different stack height is selected), or perhaps the time of day as I would hope to include time functions.

The biggest question I have concerns available memory. If I understand correctly, the 20b has 128 KB of flash for the calculator firmware, which I presume (hope) would be adequate for the functionality I am proposing. But there is only 6 KB of RAM, of which only 2 KB is battery backed. The other 4 KB goes away every time the processor shuts down, which happens after every operation. So the stack, storage registers, program data and various status flags all have to fit in the 2 KB battery-backed memory, which does not sound like nearly enough to me. The 20b offers several “access points” into its system. Could external RAM be accessed via any of those? If not, would 2 KB be enough for just data and status? If so, could programs be developed on a PC, and get flashed into the flash memory with the calculator firmware? (I have no clue how feasible that would be; it is just the only way around the memory limitations of which I can conceive if it is not possible to somehow expand the 2 KB of continuous RAM.)

I did consult with Paul Dale regarding his scientific 20b firmware project. Paul kindly provided details on his work (actually his and Walter B’s), and we communicated back and forth a few times. The work is very impressive, and would produce a very capable device. But I thought that there could be room for something with a little less capability. I did not thoroughly study Walter's documentation for his and Paul’s project, so I probably copied many of the ideas or concepts. If so, I give full credit to Paul and Walter.

Conceptualization and visualization is as far as I can go with this project as I have no skills related to the development of the code or loading and running it on a 20b. To those who do possess those skills, would it be possible to repurpose the 20b as described above? If so, does anybody care to take a crack at it? I started fleshing out some of the other details regarding menu structure, etc. which I would be happy to share. But I thought it might be wise to see if it is even possible before completing that and presenting it.

Best regards,

Jeff

.

Quote:

---

on the keyboard, legends which represent menus are surrounded by colons

---

Quote:

---

commands in menus would be displayed in the 6 x 43 dot-matrix area, two commands per “page”.

---

To make this useable, you'd have to display the shifted function when the shift key is pressed (or pressed and held), but that should be easy. This would simplify entry and might let you free up some functionality in the navigation keys.

Quote:

---

there would be no polar or rectangular display mode. Complex numbers would be entered in either form and would be stored and displayed in whatever form they were entered.

---

The sticking point unfortunately remains the key top legends.

The rest can be fixed with a nice template overlay, but the key tops still show those weird financial thingos...

Dave.

Quote:

---

The sticking point unfortunately remains the key top legends.

The rest can be fixed with a nice template overlay, but the key tops still show those weird financial thingos...

---

No overlay is required. I've successfully removed the legends from a set of 20b keys. I'll get my wife to engrave legends which I'll paint by hand to finish things.

Sadly, no time for non-essentials at this time of year so the project is stalled at least until January :-(

- Pauli

Quote:

---

Sadly, no time for non-essentials at this time of year so the project is stalled at least until January

---

Ceterum censeo: HP, launch a 43S (but if you stubbornly refuse to do so, we'll tickle you a bit with a 34S)

Walter

Quote:

---

No overlay is required. I've successfully removed the legends from a set of 20b keys. I'll get my wife to engrave legends which I'll paint by hand to finish things.

---

You still need an overlay for the secondary functions that aren't on the key tops. But that's not nearly as hard as the keys themselves.

Removing existing legends and hand painting is so medieval! Someone needs to model the key and produce a blank duplicate.

Dave.

Quote:

---

You still need an overlay for the secondary functions that aren't on the key tops. But that's not nearly as hard as the keys themselves.

---

Actually, I'm planning on engraving the face plate too. Again, no overlay.

Quote:

---

Removing existing legends and hand painting is so medieval! Someone needs to model the key and produce a blank duplicate.

---

I agree but it was a heap faster than making moulds for the three different keys and casting some blanks.

- Pauli

Hello Jeff,

That would be a nice feature set. Your design made me wonder whether anyone could make light plastic overlays that could rest on the surface within the lip.

What im thinking is, overlays could accommodate an evolutionary product. Let’s say there was a repurposing project. It’s highly likely that elements of the layout would change from one release to the next (sadly inevitable!). So, each major release would come with its own function overlay. Could these be made at low cost? I don’t know.

Now, if it happened that the project layout was stable, you could just glue your overlay to the unit and be done with it!

?

In the SDK for the 20b the readme.doc file says:

Quote:

---

If you represent a company that has a need for large volumes, please contact cyrille@hp.com as HP might be able (depending on the cases) to make a special manufacturing run with your program pre-loaded and/or modification to the calculator color and artwork.

---

I suppose that means that if enough of us wanted your design you could ask HP to customize the keys and faceplate. I wonder how much a "large volume" is?

-Katie

I have a vague recollection that it was of the order of 2k units for a custom screen printing and over 10k for a different LCD. No idea what the per unit price would be for either in these quantities.

I cannot imagine hitting either of these marks or even getting close.

- Pauli

2000, that's less than 4 percent of the promised-to-purchase units on the "bring back the HP 15C" site. Since HP has so far not brought back the 15C (even though it would be easy given the 12C+ architecture), you might easily get the minimum number of units. I think there is a lot of pent-up demand for a small, inexpensive calculator that does a good job with complex numbers, etc..

-Katie

Edited: 10 Dec 2009, 10:40 p.m.

IMHO the number of potential orders at "bring back the HP 15C" site is heavily exaggerated, not up-to-date and unreliable. I'd bet if the HP 15C is re-realized it won't sell even 10% of what the site claims.
Cheers

Jeff

Thanks to all for your kind comments.

I considered adding discussion of the keyboard and keytop labelling issue, but was trying to keep my post as short as possible. Too bad that such a relatively low-tech issue should be the one that generates the most discussion and may be the biggest stumbling block. For the record, my concept for the keyboard is typical, a sticker or overlay with the labels and holes for the keys. At the HHC 2009 conference, Cyrille mentioned a company called “Skinit”. They make decorative custom skins for lots of electronic devices. They ignored me when I inquired about a custom skin for the 20b, but maybe Cyrille could get their attention. If “Skinit” can’t do it, I believe Tim Wessman produced stickers for the 50g (prior to his joining HP), so there must be a way. For the keys, first I would not try to put the blue legends on the slanted fronts of the keys; that looks too hard. Those legends would go on the keyboard below the keys. For the key tops, I tried to keep as many stock legends as possible, but my design would require 16 keys to have new legends on the top of the key. As Paul mentioned, he successfully removed the legends from his keys. To put them back (without custom engraving), the only ideas I have are either small stickers or custom rub-on transfers sealed with clear lacquer.

^{-edited to correct !@#**! typos}

Edited: 11 Dec 2009, 1:09 p.m. after one or more responses were posted

Hi Jeff!

Looks great, but do you really think any serious effort towards the 20b pays off? While I like the LCD and keytops, the fact that the keys are not hinged and do not register reliably along with the case being quite wobbly at pressing outer keys is a show stopper here.

A final product would probably cost more than a 32SII oder even 42S on TAS.

Maybe I got you completely wrong.

Thomas

Hi Thomas,

I guess my goal is to create something that fixes the one major shortcoming of the 42S (lack of I/O) plus improves its complex number capabilities by adding the "i" key from the 35s. In the past, I have developed concepts that were basically complete flights of fancy which would have required complete new hardware development or major hacking of the 35s hardware. I'm not crazy about the key-press feel of the 20b, but it does offer a complete package with keyboard, display and reconfigurable processor.

As for cost, if everyone who wanted to repurpose their 20b had to get all of the hardware and software tools, the cost would likely exceed the cost of a 32sii or 42S at TAS. But if it is some sort of community effort, I’d think the cost could be kept reasonable.

Jeff

Quote:

---

Cyrille mentioned a company called “Skinit”.

---

Looks like they have already targeted some models:
nice!

Greetings,
Massimo

A modest suggestion:

Since the 20B already has many "scientific" functions printed on the sloping key faces, and no functions at all printed in the spaces above the keys, why not design the repurposing project to retain all the keycap legends, then only an overlay is needed. So you would have both scientific and business capabilities in the same calculator, like the 27S. (Maybe call it a 20BS?)*

I know this approach limits the number of function possible, but it makes the project much more easily doable.

*Insert tongue-in-cheek emoticon here

Edited: 11 Dec 2009, 3:16 p.m.

this would be my pitch too - keep the keycaps the same. i know it could be better with new caps, but it would make the overlay project feasible.

on 15C functionality; it would take quite a while to replicate all that. however comprehensive complex support is very possible.

one of the big drawbacks of this unit is that the "customers" cannot flash their units without special connectors. this would make it a serious problem for people to load up the latest firmware. furthermore, there is no easy way to get user programs on or off the machine (assuming it could support programming).

I disagree.

Demand for products like this is usually under stated until the product is actually available, and then all the buyers come out of the woodwork.

If the price point is right they'll sell in the 6 figure range, easily.

Dave.

Before anyone else points it out, I just realized one problem with my approach - the one shift key is already used for the sloped faces - so some way would have to be devised to get another shift function.

I'll be glad to be proven wrong. I'd buy what I promised just to support the project. That is if the new HP-15C is only quicker than the original. If it has IO, more memory and mnemonics it's another story.


Cheers,
Reth

Jeff;
Looks like a good general purpose layout you came up with. It should please most folks. DO IT!

The only suggestion/request you'll get from me is; to make it available in a normal, readable-by-my-computer format that can be downloaded by mere mortals. I think that the 20b is a nice (and cheap) little platform but i don't have time to sink hours into some comp-u-nerd's proof that he is smarter than me. I just want to load it and use it.

Quote:

---

Looks like they have already targeted some models:
nice!

Greetings,
Massimo

---

these are only cosmetic changes to the body.

Hi Jeff. This looks like an ambitious project and I wish you good luck.

Did you consider moving the +,-,x,/ keys over to the left in order to group them with the Enter key? That is where HP placed them with their original designs. I'm not sure when HP changed the placement but they were on the left on the 34c and then on the right with the 32sii. I prefer having them grouped with the Enter key.

Regards,

John

Quote:

---

these are only cosmetic changes to the body.

---

Yeah, I know... but I find it amazing that such a market does exist: I mean, how many of these will they ever sell?

Now, if we can find more interesting uses for those skins, and if they will market the front bezel too...

Greetings,
Massimo

db,

Thanks for your comments. Rest assured, I want it to be simple. I wish I was a comp-u-nerd!

Hi John,

No I did not consider moving the +,-,x,/ keys over to the left. I actually like the idea, but it would add even more complexity to the key labelling problem.

Hi Martin,

One of my goals was to create a "scientific four-banger," with as many the most used scientific functions as possible being primary key functions, and the rest only one shift away. I don't think I can "waste" a bunch of primary functions on financial functions :-)

You would just have to swap the keytops due to labelling and the half-height ON key :^).

This might be wandering slightly off topic, but it was triggered by the positioning of the i-key where the = was previously. This is one of those small things that just works (and it immediately makes it apparent that this calculator handles complex numbers).

One of the reasons it appealed to me is that I've recently been contemplating the 20b's keypad layout. While I think that its functionality is outstanding (particularly the inclusion of the probability distributions), I find its keypad layout to be underwhelming. Like Jake Schwartz (http://www.pahhc.org/2008/Improving%20Keystroke%20Efficiency.pdf), I'd like to see all a calculator's mathematical functions on its keypad (where one can find them) rather than in menus. After all, they're a calculator's raison d'etre.

The trouble with this approach is that the keypad can quickly become a dog's breakfast: it becomes very important to group like keys with like so that users can actually find them.

Rather than try to design the keypad of an entirely new 20b-based calculator as Jeff has, as an exercise I have rearranged the 20b's keypad with this in mind. The result is as follows.

  P/YR    |IRR|   |NPV|  |Amort| |Bond|  |CshFl|

    N     I/YR     PV      PMT     FV      up   

 x P/YR  |IConv| |BrkEv| |Depr|  |Date|   |INS| 

                   y^x     e^x   (10^x)  |Data| 

    f       g     sqrt     1/x      %     down  

                   x^2     LN      LOG     DEL  

     |Reset|    |Memory| |Mode|  |%calc| |Stats|

      INPUT         (       )      EEX     +/-  

       ANS       (R up)    BEG     END     ABS  

     HYP      SIN      COS      TAN       F     

     STO       7        8        9        /     

    AHYP     ASIN     ACOS     ATAN     INV F   

  (-> H.MS) [TOTAL -- PART -- %TOTAL]   chi2    

     RCL       4        5        6        *     

   (-> H)      !       nCr      nPr   INV chi2  

  (-> RAD)   [OLD ---- NEW -- DELTA%]     t     

     <-        1        2        3        -     

  (-> DEG)    RND     RAND      pi      INV t   

             [CST ---- PRC ---- MAR]      n     

    ON/CE      0        .        =        +     

     OFF    (INTG)   (FRAC)   (SHOW)    INV n   

Notes

1. All the functions in the Math menu now appear on the keypad, and the Math menu itself has been eliminated.
   
2. HYP and AHYP would work as for the 11C and 15C.
   
3. For clarity, menus are enlosed in vertical lines || rather than colons ::.
   
4. Functions in brackets () are not found on the 20b: they are potential additions.
   
5. -> H.MS and -> H are very useful on a business calculator for summing times in hours and minutes.
   
6. The 3-variable solver equations enclosed in square brackets on the bottom 3 rows are suggestions; other possibilities are P -- NOM% -- EFF% (from the IConv menu) and DATE1 -- DATE2 -- DELTADAYS (from the Date menu).
   
7. Almost all the keys of a standard 4-banger calculator (including STO and RCL but except for %) are found in the bottom 5 rows.
   
8. Pi belongs on the 3 key - where else?
   
9. The back space and CE keys are grouped together.
   
10. Factorial-based functions are grouped together.
    
11. The display of the 20b only has one secondary-function-active indicator, which would be displayed whenever either the gold (f) or the blue (g) keys was active.
    
12. It might be worth considering DF1 and DF2 registers and associated keypad short-cuts (e.g. STO . 1 to set DF1) for repetitive calculations of the chi2-, t-, and F-distributions.
    

My questions are:

1. Is this an improvement; and
   
2. Is HP paying enough attention to keypad layout?
   

Hi Andrew,

Short answers: 1. Yes, in some parts. 2. Not always.

More feelings: Nice layout carrying some new ideas. Your layout reminds me of the 22S, though its function set aims to the 27S. - I miss some (for me) vital keyboard operations like Sigma+ and its relatives. Your mileage varies obviously. - Keyboard layout is often influenced, if not governed by personal preferences and applications used frequently by the designers. Layouting a math-bussiness calc is even harder than a pure scientific or pure business calc.

How do you browse menus without the up and down arrows?

All this is my opinion only. YMMV

Edited: 13 Dec 2009, 4:53 a.m.

Walter,

I'd replace = with SIGMA+ if I were to include it, but I didn't consider doing so because I didn't want to deviate from the approach that the designers of the 20b had taken. Part of the reason for undertaking the exercise was to see whether just rearranging the keypad layout without necessarily adding any additional functionality might significantly improve the 20b. In doing so, it became apparent that the keypad could naturally accommodate additional functions (e.g. 10^x).

The up- and down-arrow keys are at the top right of the keypad. This is consistent with the position of the cursor keys on the 35s and the 50g. You might have noticed that I have erroneously indicated that INS is a menu.

You're quite right about the influence of personal preferences, which is why I've tried to be guided by the principle of grouping like with like, even if it has resulted in a deviation from what has been common practice in the past. An example of this is placing the <- key above the ON/CE key.