|My concept for a 20b repurposing project|
Message #1 Posted by Jeff O. on 10 Dec 2009, 12:33 p.m.
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.
- 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.