This is the journal for the Calculator001 (dubbed "DL 13C") project. This is in chronological order (oldest to newest).
For some time I have off-and-on thought about a ‘cryptographic calculator’ – which is imagined as a specialized calculator that has functions for doing fundamental operations for encryption, such as bignum arithmetic, but also built-in primitives for doing DES, AES, RSA, DH, etc. There have been many times where I could use such a device, and have written several utility programs for performing various general and specialized operations.
Also for some time I have had a minor obsession with HP Voyager calculators (i.e. the HP-11C and family). The HP-11C was my first engineering calculator. O! To be sure, I did own a TI-30, and other contemporaries, but the 11C was different in some way. If you had one, you’ll understand. These calculators appealed to their owners in a way that somehow elicited a sense of ‘connection’, and the calculator became a sort of extension of the self as a kind of ‘numeric companion’. It was quite like owning a pet.
Anyway, I had given my 11C in favor of a 41CX, a 28S, and finally a 32SII. I got out of electrical engineering and didn’t really need a scientific calculator anymore, but still longed for my 11C. (Actually, I always longed for a 15C but I couldn’t afford it at the time, and anyway it wasn’t available at the Sam Solomon’s where I shopped.) The 11C (and friends) had a horizontal layout, which was unconventional for calculators. Calculators were (and still are) largely vertical, presumably to better facilitate holding in the non-preferred hand, but I liked the horizontal layout because I could better see the ‘function’ are of the keyboard to the left of the ‘digit’ area, and plan my hand-eye coordination better. And usually I use the calculator on the desk.
I admit having felt a little embarrassed about being reminiscent about a calculator made in the 1980’s, but I was vindicated when I stumbled across several museums devoted to the calculator, petitions for their reproduction, and quite a healthy collector’s market in online auctions where the devices sell at a multiple of their new cost in the 1980’s! So I was definitely not alone in this thinking.
[I am breaking this initial post into parts, because these ideas came in different periods in the past, and wanted to somehow convey that, rather than making it seem that it all came together this way at once.]
So, ‘just the other day’ (which really means anywhere from years to months ago) I got the idea of physically making the ‘cryptographic calculator’. Also as of late I got the idea of making it resemble the design of the HP-1xC, which I loved so much. I have a tendency of enjoying putting a little bit of artistry in one-off designs like this. I am no artist, to be sure, but as one rarely gets to be strictly autocratic in one’s professional work, these little projects provide an outlet for doing something fun (and sometimes even outrageous).
I don’t have the wherewithal or time to try to knock off a design like the HP-11C. The beauty of the device is in the physical construction, and I have never been so good at the physical. I got a kooky idea: why not re-purpose an existing calculator? Gut the processor, and reuse the case, keyboard, maybe display.
This would be a heresy to Voyager officianodos, and also a costly prospect for me to acquire a device to hack, however there is one odd thing about this collectable: while almost all the Voyagers were discontinued in 1989, one of them is still in production even today: the 12C. It is the version focused on doing finance-related calculations, and became such a hit that it never went out-of-production. As a result, this model is so commonplace that I can get a used unit for a few tens of dollars. I don’t think anyone would curse me for Frankensteining a 12C – even a vintage one. So now I scour eBay for used 12C’s, and intend to get 3-4 units.
It is common for an engineer, at the beginning of a project, to come up with a lot of kooky ideas. Usually these are kept in check by other stakeholders, but since none of those folks are around here, I happily can do anything I want without respect for marketability, timelines, budgets (OK, well yes only to a degree), or pesky technical feasibility issues like battery lifetime.
Some ‘mad’ ideas that have arisen so far:
The first calculator specimen arrived today. It is in great shape, made in 1998.
Also arrived is a development board for the PIC32MX460, called the ‘USB BitWhacker 32’, which I got from SparkFun Electronics.
No work done.
The second calculator specimen arrived today. It is in more worn shape, made in Singapore 1994. This is the one I’ve chosen to disassemble first since it is in the worse shape.
No work done.
I began disassembling the 12C today. Everyone knows what a 12C looks like, so I didn't take a 'before' shot, but in retrospect, this was a mistake for the posterity of this particular unit, so 'note to self' on that. I took other photos during the process of disassembly.
First, I removed the feet, which cover the screws, and unscrewed it. The back came off easily, which cannot be said for other units I have disassembled before. This is because HP used to put a wad of double-sided foam tape between the PCB and the back panel, requiring careful separation. There are two grounding springs that need to be watched-out-for to avoid losing them. These springs provide electrical continuity amongst the three metal plates on the front and back.
This is a late model, and is of the single PCB design, rather than the two PCB design of prior times. The prior design had a separate display and keyboard circuit. I don't know if this is good or bad news for me, but I know it means there is a Dremel in our future(!).
As anyone knows, the Voyagers have their PCB secured by way of 'rivets' formed by melting the ends of plastic studs that extend from the front half of the case, thereby creating the rivet 'heads'. These heads must somehow be cut off in order to remove the PCB. Rather than shear them off, I meticulously (tediously!) carved around the head to take the fastener back to approximately the original unmelted state. The idea being that maybe I would re-melt the restored studs to refasten the board. I don't know if this is what I'll wind up doing, though; we'll see. You have to take care when removing the PCB to not over stress the board, and shattering the LCD.
The separated case and boards are shown:
The small screwdriver and Exacto knife would be my friends for a few hours…
You can see the unit still works:
And the keyboard is functional:
I also ran a self-test (not shown) and the display works as expected. This will be the last naturally intended thing this calculator will display before receiving a new brain....
Removing the LCD was straightforward, but a little troublesome because the steel frame is a bit springy, confounding attempts to straighten the bent-over tabs, which secure it to the PCB. I found it easiest to straighten the tabs as much as possible, and them pull the top edge over the PCB (hinging on the bottom edge), then pushing the bottom tabs through. After the LCD has popped out, it is much easier to finish straightening the tabs.
The keys are separated from the 'snap disk' keyboards by a rubber sheet. This old, worn unit had a few well-used keys that had punctured through the sheet (no big deal), namely the four arithmetic functions, and the Enter, and backspace (and oddly RCL). I removed this sheet (and washed it; it certainly would have provided good DNA material from it's previous owner!), and then faced the array of lose keys. I decided to use a piece of duct tape, and press it against the backs of the keys and remove them en masse. This way the keys could be kept tidily in their original location.
Now that all the internal parts were removed, the daunting task of removing the metal plates remained. I decided to remove the LCD bezel first, because it seemed to have the least surface area with glue. I decided to use a hair-dryer to heat the plate, thus softening the adhesive (somewhat amusingly, the hairdryer is from the 1980’s also, contemporary with the calculator). After about five minutes of heating, I tried applying pressure the back of the LCD bezel. It did show signs of easy separation, so I continued with this approach.
I continued heating and pressing until left side gave way completely. I used my small standard screwdriver to wedge between the separated portion and the plastic case, continuing to heat with the driver. It is important to not separate the plate too far from the case lest one permanently bend it. This is particularly important because, if you dent the front you can hammer it out, but if you bend the top edge (which is at 90º) you will likely have a permanent problem. I continued heating and advancing the wedge of my screwdriver until the plate was completely removed. I took off the logo simply by plucking it off (It is held on by a piece of double-sided foam tape).
I was worried about how to take off the keyboard and back plates. They had such a large surface area. I didn’t think the hairdryer was going to work so well because of the cycling between heating and separating would give the glue time to harden and result in damage to the soft aluminum. I got the idea of submerging the panels in hot water, and doing the work while underwater, to facilitate continuous application of predictable and even heat. ABS plastic (which I’m guessing is what the case is made from – I know it was popular at the time these calculators were produced) has a melting point of 221º F, above boiling for water. I filled a pot mostly full and brought it to boil, and then added tap water to take it down to 195º F to add a margin of safety against over-softening the plastic.
I decided to do the back first in case I caused damage and wanted to try a different approach. This method actually seemed to work well, though, and I used the thin blade of the Exacto to start the separation at an edge, and following with the small screwdriver serving as a wedge to advance the separation.
Incrementally advancing the screwdriver left to right, along the long dimension of the plate, and then downward to the other edge, the plate was eventually separated without any damage, distortion, or denting. The plastic case did not fare quite as well: I had become over-aggressive on the first separation activity (the one in the picture) and the area where I had first inserted the screwdriver/wedge showed some warpage. I put the case back in the hot water for a few minutes and pressed down with implemented while under water for a short while. Then I removed it to a towel and quickly resumed the same pressure while the plastic cooled. This restored it almost completely, leaving only the slightest remaining warpage that will very likely not be noticeable once the unit is reassembled (you have to use light glare to see it now. It actually has a benefit in this instance: the battery cover was hopelessly loose, and the previous owner clearly used scotch tape to hold it in place (because there were tape remnants embedded in the thumb grooves, along with decomposed adhesive.
Encouraged, I finally decided to try the same approach on the keyboard panel, which I was dreading because of the susceptibility to bending that the gridwork of holes produced.
The process started off well enough, however:
Using the thin Exacto to work the front edge side-to-side, and the screwdriver to simultaneously advance the newly created edge front-to-back along the rails of the keyboard grid, the plate was eventually removed. The progress of separation can be viewed as an advancing front, initially perpendicular to the line extended from the top left, to the bottom right, and starting at the bottom right. As this front advanced, it rotated around the top right, so as to finally be horizontal with the top edge. That is, like a clock hand sweeping from 37.5 minutes, to 45 minutes. At the end, the plate was hinging away from the case and was easily pulled away.
NOTE TO RESTORERS:
While it worked well, I’m not so sure I can recommend the water bath approach for all purposes without some caveats. The treatment may have had a bad effect on the paint of the plates, which became very easy to peel off. You can see that when I tried to remove some of the tape remnants from the battery compartment that the paint underneath easily was pulled off. This may be a natural effect, though, and less one of the water bath. The plates are aluminum, which oxidizes readily, and the age may have build up an oxidation layer between the metal and the paint that facilitates easy separation. When the unit was received there was paint removal already, in a circular spot (like from a hole-puncher, and at the upper right edge, and lower edge.
Maybe the hot water bath accelerated what was already happening naturally. This didn’t matter to me because I intended to repaint and rescreen all of this for my custom calculator, but it might matter to restorers/repairers.
Also, the water bath caused lightening of the plastic case. I think this is due to a leach-out of the plastic colorant (styrene is naturally white). I tried some plastic restorant to no avail on an area, and may later try re-melting to confirm the hypothesis, but if my leach-out hypothesis is correct, then the restoration process will either be adding the color back, or removing the bleached material. I will worry about this later. It’s not that critical an issue for me, but I imagine it would be much so for a restorer.
The backs of the removed metal plates are covered with either a gummy film (the display bezel), or a sheet of double-sided tape (the keyboard and back panel).
I decided to simply peel the sheet off the back panel and keyboard. When I did this, I started at a workable corner, and pulled the tape 180º back upon itself. I did this to remove any force perpendicular to the plate, which would cause it to bend and be distorted. Whenever the force needed became large enough to where I feared the metal would give way, I rotated the force vector about its origin to cause the tape to give more easily. In this way, for instance, I peeled the sheet off the back by starting at the lower right corner, pulling straight back upon itself in the 10 o’clock direction until it became a bit snug, and then pulled in the 8 o’clock direction. Eventually the sheet came off and no damage was incurred upon the back panel.
Even more gentle and careful attention was given to the fragile keyboard panel, but the same basic technique was used. It was in some ways easier because the gridwork also weakened the adhesive sheet’s hold upon the plate.
The front bezel consists of the visible plate, with a glued bracket holding a plastic lens in place. I removed the bracket with my Exacto knife by separating the sides, and then the long bottom edge. Then I gently hinged the assembly along the top edge, which was otherwise inaccessible due to the folded-over edge of the plate. I used the Exacto to sever the glue at that hinged edge, and pulled off the plastic lens.
I rubbed off a bit of the glue from all the parts involved, but I think I need to get a proper solvent. I tried what I usually use in a pinch: some Sheila Shine. Sheila Shine works because (I think) of it’s toluolene, but it contains mineral oil, too. I decided that since I also need to get some methylene chloride to strip the paint, I might as well wait and get proper glue solvent (if the paint stripper doesn’t work well enough itself).
I scanned the plates before I stripped them in case for some reason I needed to know what it looked like beforehand (like if I want to match fonts, or placement).
[this is not the original hi-res scan]
I put away all this stuff for later, and set down to write this entry. Writing this entry took far longer than doing the work.
Impatient to do more, I broke out my hot air rework station and desoldered the components from the PCB. There are only three passives, what appears to be an inductor, a resistor, and a capacitor, and then one chip. I stuck these in an antistatic bag for posterity and scanned the back and front of the PCB.
I discovered that I could use hot air from the rework station to quickly melt the surface of the plastic case, and cause the white discoloration – picked up in the water bath plate removal process – to vanish. You have to be quick, of course, or there will be hopeless warpage. I treated the whole unit, though I messed up the bottom piece a bit. I undid the benefit to the battery cover (and tried to make it good again, and made it a little worse). I also made some of the seam on the forward edge of the bottom shell to sag, making a little ‘sad lip’ between the Enter and 0 key. We’ll see how bad it winds up being when reassembled. Restorers will again want to be careful with such a technique. I used 500º C on the hot air with no nozzle. The theory is the high heat would melt just the surface, leaving the bulk of the plastic underneath cool and solid., but I wonder if that was not the best approach since the effect seemed to take some time, and by then so much heat energy had been transferred that the whole body became plastic. Maybe I needed much higher heat for a much shorter duration (I can’t do that) or a lower heat to give more control and just be conscientious about support to prevent warpage. Who knows, I’m done with it for this unit.
Since I am Frankensteining mine, I don’t think it will matter. There’s probably far worse ahead….
[this is not the original hi-res scan]
[this is not the original hi-res scan]
Work work work work work… Anyway, I haven’t had much time to do more. However, I did spend a little time trying to find LCD’s to put in. My perfect world would be an alphanumeric, or graphic display. Alphanumeric is more likely to happen because of the existing aspect ratio of the window – text is implicitly a linear form, whereas graphics tends to be an area.
The window should neatly accommodate the display of the very common 16x1 displays with the super common HD44780-derivative controllers. (Jeez; I remember programming drivers for these in the late 1980’s!).
I have had a lot more trouble finding a suitable unit that I would have expected. The problem is that all the surrounding encasement is to large for the calculator – even if I were to grind out plastic and such. The problem gets even worse if a backlight enters the equation. The original units don’t have backlights, so I am not got to push for it, but it might be nice if the unit is powered from USB or the like.
I finally found something that will fit. It is a 16x2 unit made by Hantronix, called the HDM16216L-S “16 Character x 2 Lines, Very Small Size, LED Backlight” display. It fits in the case! Even with a backlight! However, it is incredibly ugly because it is too small horizontally. If there were a 24-character version, it would be perfect.
In the interest of moving the project forward, I am going to punt on this issue and use the less than optimal display. I got some on the surplus market for $5 each. So I bought 5 of them, which should be more than enough spares if I ruin one.
It’s really a shame on not having a 24 char version. That would turn this from a compromise into a real win… The only thing that would be better would be if the display were graphic (giving total control over the presentation) or if it were old school black-on-white (these are the black-on-yellowgreen kind).
Oh, well. Moving on.
I never really worked out power. Obviously the original “3 button cell” approach will probably not work since I am using common off-the-shelf stuff, but – like with the display – I am going to avoid obsessing over it. I would like to have a lithium ion battery that I can shove somewhere, and forgo the whole ‘constant memory’ thing in favor of persisting to flash, with a ‘soft off’ key that causes the persisting (along with when powering off because of inactivity). Professional designers – as well as amateur designers having more wherewithal – will scoff at this, but as I am neither, I rebuff such scoffs…
Here is the display:
For reference, here is the display next to a ‘common’ 16x2 display (the item pictured is a DUKPT PIN Pad I had constructed some years back).
Here is the unit positioned in the calculator, centered where I will finally place it. You can see this will be a bit ugly because of the wasted horizontal space.
Here I am left-justifying the display to give an idea of how it might look if but only I had a 24 character version of the same.
Oh, here is one other display option I considered. It is an LED alphanumeric display, the popular (and expensive) HDSP-2112. There was no way it could have fit, but it would have been so very cool I think:
The three major problems with using this otherwise exquisite display were
There would have had to be surgery to the plastic case (plastic surgery?) beyond the case’s dimensions. (I am going to have enough of those challenges already with the CPU unit!).
The unit comes in 8-char, but I would want 10 at a minimum to be meaningful. Especially if I don’t have any way of presenting commas, dots, or substitutes for the annunciators.
It’s LED. slurp.
OK, I couldn’t resist messing with it more at least just a little.
So, since I had chosen a display, it was nearing time to cut the PCB to accommodate it. So I needed to map out what were the traces that I needed to keep for the keyboard from the ones I didn’t need that went to the original LCD display.
Frittered away some time thinking about replacing the ‘badge’ on the calculator with something fanciful.
I decided to use the designation ‘13C’ since HP never made a calculator with the number ‘13’ (I guess they are superstitious). I thought this terribly clever, but it appears all the rest of the world already has thought of this already. [Side note: whenever you think a thought you have is clever, it very nearly always means someone else has already thought of it – the likelihood of truly original thought is low, but you shouldn’t let that dissuade you from acting on your thoughts. Validation is a good thing.]
Anyway, I indulged myself by making some mockups. In respect to the brand (and indulgence of the ego) I took off ‘HP’ and replaced it with ‘DL’. I did this a couple ways and am not fully satisfied with any, but whatever – enough time wasted. Here they are:
A logo preserving the 'hp' lettering. The 'L' looks silly:
Here the 'L' looks better, but the balance between dark and light doesn't look so great, I think:
Here is a better light-dark balancing, but still doesn't excite me:
Here is an alternative of the first version, but with a different 'L' treatment:
I spent some time yesterday obsessing over battery matters. This device is so famous partly because of its efficient physical design. Really, it is still fantastic even today when it comes down to it. This isn’t a great thing for me as a re-designer, because I am trying to stuff off-the-shelf stuff into an otherwise very efficient case. Well, all my new fab things do require power, so is a challenge to re-purpose this. As to my post on Aug 29 (d) disregarding power: “ahhnnn; wrong answer!”.
I think trying to power of SR44s will be a problem because my off-the-shelf chips and display will not have the power-sipping demeanour of the originals, so I have been considering rechargeable lithium cells. My original thoughts were thin prismatic cells but event the thinnest are a bit thick. I have about 3mm max. I can squeeze another mm if I cut out of the back case and rely on the backplate to cover up the cutout. It’s still a bit much.
I discovered the most amazing thing, though. A 10180 cylindrical LiPo. This is very similar in size to 3 SR44’s, so conceivably I could stick it in the existing battery compartment! This is really great, I think. Turns out these cells are pretty rare, and folks have been looking for them for a couple years (based on searching through forums; they’re apparently used in some exotic miniature flashlights). Also, fatefully, they have recently appeared and so I bought five of them immediately for fear of them going out of stock for a while. What luck! I didn’t buy more because lithium cells unfortunately do not shelve well – they will become unusable after time even if they aren’t used at all.
My new challenge will be: a) was my impulse buy worthwhile? It’s only half the capacity of the SR44s, and at a lower final voltage; b) lithium is a bitch to deal with. I am old and lithium rechargeable was not a mainstream chemistry in my day, and I don’t have experience designing with it. If you don’t do it right (charging) it will explode, ruining the product, and quite possibly seriously harming the user and causing all sorts of collateral damage. Frankly, it’s quite amazing to me that we even design with this stuff at all. But the power density is quite alluring.
Anyway, my new challenge will be to charge the cell, to transform the cell’s energy into a form that can operate the equipment, and to do that all safely. Oh, and also stuffing any needed electronics in the space available.
The 10180 cells came in. It is about 2.0+ mm little longer than the original 357 stack (and about 1.5 mm less diameter). This is enough to make it not fit as-is. The positive end is formed from plating the PCB, so I can’t modify that end. Instead I tried transferring a couple coils of the spring for the negative end to the outside of the battery compartment (where it meets with the PCB. This, with the help of my small screwdriver, was enough to get the battery in without modding the compartment. It will not be easy to remove and replace without the screwdriver help for leverage) but that’s OK I think. I intend to leave the rechargeable cell in permanently and charge it off USB power.
Now I must devise some charging and power conversion circuitry.
And my next dreaded task is figuring out where/how to place the USB connector….
My USB Bitwhacker 32 has been in for a while, but I haven’t fiddled with it since I was concerned about other aspects of the project. This is a little dev board that seemed to have the desired hardware (namely the PIC32MX460, but also the crystal, some miscellaneous needed passives). I am using this because it is a huge boon to me not to have to fabricate a PCB and solder the quad flatpack. The pictures for the UBW32 are otherwise readily accessible on the web, but nonetheless:
The power connecter is way too big. I removed it and put the board into a trial location:
Alas, the mounted USB is still too big to fit into the case. I could gouge out the back completely to allow the connector to be accessible, but surely I can make it look better. Plus the stress of the insertion force needs to be tolerated. If I had control over the PCB, then I could mount it in the upper right (from rear; upper left from front). Since I will be cutting away that PCB (and it doesn’t have pads for the connector anyway), I am currently thinking about soldering wires directly to the connector, running them to the UBW32, and mounting the USB by epoxying it into place in the case. Here is the location I am thinking of, with a new connector resting in place.
I will need to cut some plastic! Yikes!
I don’t know which will be my first real cut: the PCB, for the LCD, or the case, for the USB connector. Hmm…. Well, I can still do useful work with the CPU card and the battery circuitry before I have to commit on the cutting….
OK, I was too curious and so I cut the plastic for the USB connector.
I did it by first scoring the outline as best as I could with an Exacto knife, then hand-drilling holes along the outline using a .049” drill bit in a pin vise. Then I used an Exacto knife to finish the outline. I should not here that cutting this plastic is very easy. It’s like butter! (well, frozen butter). I was surprised at its softness.
Here the connector is stuffed into it’s hole.
Here’s what it looks like face-on. Sorry about my not-so-great Exacto-ing out of the hole.
and what it would look like with something plugged into the unit.
The astute viewer will notice a downward angle to the connected USB cable. This is because I had to drill from the inside, where I could score the outline of the hole from the connector. But, starting from the inside meant I could not come normal to the case side, but rather at a slight angle. The connector fits in at this angle. I will try to resolve this by removing a little plastic in the hole (which will have the unfortunate effect of also creating a little gap.
Also, you may note that the external plug has some exposed metal guide. This is because the connectors are spec’ed to permit getting through case, and my placing the female connector flush with the outside of the case leaves that allowance exposed. I will try to accommodate for this when I glue it in its final position. I don’t want to take this adjustment too far, though.
I decided to be a little lazy – I bought a ‘breakout board’ for the USB connector. I did this because the SMD connector will be too hard for me and my failing eyesight to reliably solder, so I splurged on a $5 mounted device onto a PCB, breaking out to through-holes which I can manage.
I cut the breakout board down, and shoved it in:
Time to cut the PCB:
Here is where it all fits together:
and imagine if this is where the CPU board goes:
Front and back case closed together; how it looks:
Laying the original display and keyboard bezel on top to make it look a little more ‘final:
OK, now I can either finish up my power problems (charging and regulation), or start on the processor circuit design, or setup the software development environment.
I found a suitable charging controller, and am working on the regulator. I can’t decide whether to use a simple linear regulator or a fancier switcher (perhaps SEPIC or flyback). My battery has such a tiny capacity, and while this off-the-shelf processor has various power saving modes, nothing will compare to the original. Oh yes, in that regard, I also have been thinking about using FRAM for the continuous memory aspect, since it is cheap, has a SPI interface, non-volatile, and has way more erase-write cycles than using a page of on-chip flash.
The minimum circuit design part is not too complicated – just figuring out which IO line I want to use for the display. However, one of the peculiar things about PIC controllers is that all the pins serve more than one function, so you have to be fairly judicious in your choices lest you prevent yourself form using some on-chip peripheral later.
Setting up the development environment will be new territory for me since I have not worked with this chip before. It is a MIPS derivative processor. Of course I will be working mostly in C, but still I’m not familiar with the tools. I’ll probably put the whole dev system in a VMWare image.
Anyway, enough for now. Wish I had more time to fiddle with it all, but I should be on the cusp of doing more fun things than cutting up plastic…
I awoke this morning to discover that I had turned into a giant cockroach.
Today I discovered another ‘repurposing a 12C’ project at:
I’m a little dejected of course in discovering that others are working on a similar thing, and had started dong so before I did but I’m going to press on as (hardly at all) planned. FWIW, this project can be viewed as perhaps a smarter approach, in that it uses the discovery that recent 12C’s are completely revamped, using an ARM-derivative which ostensibly can have it’s firmware replaced (probably via JTAG?). I wasn’t aware of this (my failure in research), but anyway I started this project as a lark on a whim (inside an enigma?), so I excuse myself.
After I’m done with this project, I might explore this other project approach as well!
OK, it’s been nearly two years since I last touched this project. I got too busy with ‘real work’. The other day I had occasion to need to buy an electronic part that I had destroyed (a MAX1771). Since fixed costs for parts in unit quantities are high, I tried to think of what other junk I might need and I remembered that I never worked out the power supply problem for this project. After some research I decided to probably use an MCP7383x and a MCP165x to charge and regulate power coming from USB and the LiPo. Along the way, somehow, I stumbled across a board at SparkFun (where I got my UBW32 long go) that is a similar design and ready-made (the PRT-11231). It is pretty expensive, but I decided since this is a one-off project, and that because I’m losing my vision as it is, that I’d save myself some trouble and ‘cheat’ with the pre-assembled board rather than building it from scratch myself (and hoping that it worked). So that’s on-the-way. They had exactly one left in-stock at the time – lucky me.
Restless in the waiting, I decided to desolder the connector from the Hantronix LCD (oh, btw, it looks like Mouser started carrying that precise display unit, for 6.66usd). I’m a bit embarrassed with my job, but I’m not accustomed to working though a loupe. I got some pad lift on one the backlight lines, but no biggie there. I soldered on Kynar wire to the pads, and in the process got lift and loss of two more pads! This time on D0 and D1. I managed (I think!?) to solder to the trace leading to the pad, but it is anyone’s guess – I just can’t see it. The contact is not strong at all so I put some superglue on all the wires to try to bond them to the board for some strain relief. I didn’t have any gel CA glue, just the watery stuff, so I had to apply several times. Hopefully this will work. I suppose if D0 and D1 are broken, I might be able to still get by in ‘nibble-mode’ since fortunately that works with the high nibble. Let’s hope I don’t have to go there, though.
BTW, as time marched on SparkFun released a nicer UBW32 than mine – 4 times the ram, and also provision for a 32khz xtal. I did want the second oscillator, so I am jealous. I will give it a go on the board I have, but I’m a little bit skeptical that it will work since the lines will be so very far from the chip. We’ll see. Last ditch, I do have an internal RC oscillator but that will be pretty poor for an RTC.
While waiting for glue to dry and the power management parts to come in, I started to think about the keyboard. It’s a conventional matrix keyboard, laid out 8 x 5, presumably to minimize the number of lines needed for a rectangular array. Mapping out these lines started me on the bigger task of I/O resource allocation for the chip. This is one of my least favorite things….
Microchip makes interesting micro-controllers that are typically low cost. They have always had a favorable posture to the hobbyist market when the rest of the industry was not particularly so inclined (things are much better these days in general, but a couple decades ago you had to lie and politic to get ‘samples’ of chips for projects you had no intention of mass-marketing).
The other thing that makes them popular is that they are so highly integrated, containing nearly everything you could hope for in a peripheral on-chip. Well, some chip at least. There are two tasks in the early phase of a project: a) selecting a device, b) allocating resources on the device. There are only so many lines bonded-out on a chip, so you have to sift through the datasheets to find the chip that has the lines to the peripherals you want. Of course you want everything! The second part is similar in that – even if you can buy the top-of-the-line chip with everything possible – the various peripherals are multiplexed on the pins available to the package. So if you want one peripheral, you can’t use the other one (or two!). It’s not necessarily so bad if you have an exact project definition in mind, but since this is a pie-in-the-key project, I wanted to conserve as much future functionality as possible. And that keyboard and lcd eat up a bunch of gpio lines!
OK, enough whining about it. After many hours of sifting through the datasheet, I’ve decided (for now at least), to actually do nibble-mode on the lcd with hard-wired write enable, and allocate lines this way:
OK, that was easy now that I wrote it down, but I assure you I deliberated! Anyway, part of it is also deciding not to unwire the stuff that came on the UBW32 board. I.e. lights, buttons, etc. I figure I’ll rip that out after I get it basically working – those might come in handy during the initial phases of developing the software.
Also, some other considerations were:
Since the on-board buttons are on high RE lines along with my lcd data output, I’ll need to configure them as open-drain for safety; there’s already pull-ups on the board.
I’ll also open-drain all the RA for the keyboard rows, and also RG15 for the LED backlight.
This should keep as much presently unused functionality still within reach should the opportunity arise.
Happily, I did notice that all the gpio retain their logic level even when in the SLEEP state. That, coupled with the ‘change notify’ wake-up, should mean that I can implement a soft ‘on’-key function while keeping the system in the lowest possible power mode while logically ‘off’.
While on the subject of power, ‘no’, it will not run 20 years on a set of SR44’s. We’ll see what can be squeezed out, but I’d be pretty happy with a full day or two continuous run without backlight. Sort of like a contemporary cell-phone on standby. The theory is that USB charging should typically be in arm’s reach. Who knows, maybe I’ll get fancy with power and keep in low speed while interactive and kick it into full speed only while calculating. But I get ahead of myself. A couple things I could do right now:
OK, new USB connector it is. Thanks for sticking with my while I thought that through…
Since USB is high speed data, I didn’t want to just solder on some loose Kynar wire. I have a broken USB cable that I snipped off a 4” length from. Oh whoops color code. Hmm. Well, wikipedia. OK now I have to figure out USBID, which ‘normally’ is hardwired, but I don’t want to preclude OTG (nevermind I don’t have the right connector anyway, but still). OK, so I’m going to fudge a little and I’m going to make black USBID and use shield/ground for ground. So sue me!
Ah this flexible wire is not really meant for hand soldering. I managed to tin the ends.
And I managed to get one end soldered to the external jack. I used some forceps to manipulate the wires such that they didn’t touch while soldering. The solder makes the insulation liquid, and if the wires touch they can melt together into a short.
This piece is so fragile I’m a little bit scared since I’m not ready to mount in the enclosure yet. We’ll see how it goes. Maybe I can use some gel CA to get some strain relief. I don’t love to do that because, if it breaks anyway, then the old CA is a mess while soldering a second time.
This cable is thick! I hope it wasn’t a bad choice. OK I’m removing the on-board jack. Oh, glee, I lifted a pad again. (sigh). I swear I used to be good at this!
One thing, if I can shave off a little of the board, then I can fit it in between the screw tubes, and save some case space. However it looks like (on the bottom of the board) that there is a thin connection between along that desired-to-be-shaved-off section. It carries 5V. If I cut it off, I can jumper it with Kynar. Hmm. Well, good thing this is a two-layer board…
OK, I cut it off. I also broke my dikes in the process. :( but I just remembered that they are Craftsman, so now after all these years I am going to put the unconditional guarantee to the test! But it does now (snugly) fit between the lower two
I did buzz out the power and discovered that yes that trace was important. So I am going to install a replacement jumper.
OK, now for the USB external connector. Hope for the best!
The board still enumerates, driver loads, I can connect, command prompt!
OK enough for today….
It’s probably about time to start setting up for compiling code now that I have a board that is connectable to a host dev system.
I think I will go ahead and try to get the LCD hookup up. As mentioned, it’s nice to have an I/O peripheral for debugging, and plus it will give some satisfaction.
There are a bunch of wires that don’t need to go to the cpu board (like series resistor for the backlight, and hardwired logic lines), and that board doesn’t really have any spare pads anyway. I used a spare pad on the LCD itself for some ground stuff, and the backlight pad was pretty big, so I soldered the series resistor right there and used the other side of it as a junction for Vdd stuff.
I stuck it to a 5v supply and got a top row of black boxes, which usually is a good sign with these LCDs.
I soldered the LCD to the board.
It’s fragile, and I’m not ready to case it until more parts get in, so I rubber banded it to a piece of perfboard for support in the short term.
OK, now I can start to build the dev system and write some code….
I installed the MPLAB and C32 and MAL and installed them in a virtual machine. I like to setup VMs for distinct build environments.
I built a ‘hello world’ program to verify the tools were all setup. This program simply blinked an LED to verify that it is running. I loaded the resulting firmware on the board and verified it. Then I built a similar ‘usb hello world’ to verify the usb port. That also went well.
Lastly, I created the DL13C project, and added an LCD module. Incrementally built and tested all of that.
You may be able to just barely see the backlight glowing. The backlight is pretty lame, but there it is in a pinch, I suppose. Actually the readability is a bit better than I expected for the size.
Oh, my ‘cheater’ power board came in.
I will be removing the connectors, and I can also see some Dremel work in it’s future as well, probably trimming the outline close to the components. I’m looking forward to this part of the project for some reason – maybe because the power part was the biggest uncertainty to me. All the other stuff is just work, I know those things can be done, but working with a LiPo is new to me.
OK, I’ve got to do other things for a few days. I don’t know what’s next, could be any of:
While researching if anyone had already implemented some sort of threading library, I came across a project ‘FreeRTOS’, which as the name implies is a ‘free’ Real-Time Operating System for embedded applications. Looking further, Lo! And Behold!, it has even had ports made for the PIC32MX460. How incredibly handy! Now my concerns are:
I downloaded the source, reviewed it. Turns out Microchip themselves had done some investigation into it and published AN1264 which talks about the experience. Handy! They made a change to the source to use Timer 5 for the system tick timer instead of the out-of-box Timer 1. They did this because many of their libraries use Timer 1. I followed suit with this change because I wanted to be able to use the Microchip libs as easily as possible.
I incorporated the source, and the port-specific source, into the project. I made my config header and added the MPLAB_PIC32MX_PORT definition to it.
I reworked the program to a minimal degree to incorporate the FreeRTOS, without adding any new functionality. In this scheme, I moved the main() ‘infinite loop’ state-machine processor into a low-priority FreeRTOS ‘task’, and added a new ‘task’ of higher priority that just printed something to the screen. The theory being that the low-priority infinite loop task can continue to use the existing USB code for the time being, saving me the trouble of converting it to interrupt driven. I would prefer to be interrupt-driven, of course, and will probably do that later, but I want to get to the other functionality just now.
Immediately nothing worked and I started poking around,
using the LEDs to tell me where the processor was. I discovered I had a malloc failure. OK, something about FreeRTOS, you need to incorporate a
memory manager to service it’s internal allocation activities.
They provide you with three, a alloc-only one (#1), a alloc-and-free-but-trivial
one (#2), and a wrapper around ‘malloc/free’ (#3).
I was using #3. No biggie,
but… On PIC32, you need to specify a linker option that will cause
the ‘heap’ to be allocated out of unused space in the .bss segment.
Easy enough. Now things work. However,
for ‘fun’ I went back to allocator #1.
Reason being is that I am going to create all my FreeRTOS stuff up-front
and just go (i.e. no dynamically created tasks). Plus, when I use #1 and #2, I have a call
xPortGetFreeHeapSize() available whereby I can see how much heap is left. I don’t know of a way to do that with the libc malloc()
implementation. This lets me fiddle
OK fiddling with things, I find that, having two tasks with a 512-byte stack each causes me to need about a 6k heap for the ‘kernel’. Adding/removing the ‘calc’ task seems to show about 2120 bytes difference, so it looks like the kernel has a couple k for itself, and a couple k per task as presently defined. Hopefully a 512-byte stack is enough? We’ll see! Code seems to take up about 25k or so. Code I’m less worried about righ now since I have 512k for that.
So… I’m going to continue with the FreeTOS for now, sure will make development easier.
Now what? Well, there’s always the keyboard (blick), and the power unit. Also, I had been thinking about maybe porting/adapting/whatever the Nonpareil HP calculator emulator. This will be certainly interesting if it works, could be a quick trip to a really good proof-point. Of course the final goal is to make a /new/ calculator…
I started out putting in some code from the original UBW32 project, namely the USB CDC component, and where it facilitates a kind of ‘monitor’ to which you can submit commands. I cut this down to just one command – ‘version’ – initially.
Immediately my lcd croaked. I started cutting pieces out incrementally until it stopped croaking, and then refined the cutting. It seemed at first it was due to something in the stdlib because I could macro-out printf to a stub. OK, that’s disappointing but not too shocking since printf is a pretty messy piece of machinery. Then it started croaking again, this time coincident to simple code changes, like between flicking on an LED, or not. Hmm. That’s not good news. When the code becomes mysteriously sensitive like, it usually means things like linker weirdness, variable/library initialization, non-crashy stack overflows, etc. Things not expressly stated in your code, but rater implied by the form of its statement. Stuff you can’t see. So you have to make yourself see it!
Throughout the day, I did a lot of poking and prodding looking for sensitive areas, and in each instance a carnival of cockroaches issued forth. I found several problems arising either from my ignorance or from error, but eventually all of them were resolved and understood.
This makes for a complete, though not particularly satisfying, day.
I desoldered the two jacks from the board, and connected a test battery. This isn’t the real battery (the 10180 that will fit in the existing battery compartment), but this one is small and has leads so it is easier for me to work with in the interim.
The output looked good, so I tried powering the board from it and it worked just fine. Later I’ll take a set of current measurements under various conditions to estimate lifetime, but I’ve got plenty of stuff to do in the meanwhile.
Oh, if you’re curious, here’s the board powered and running:
This itself isn’t exactly something to write home about -- it’s just a board with a garden-variety lcd on it -- but it is an incremental step forward in having the foundation laid.
Next, I’m either going to work on keyboard, or researching the feasibility of deriving some simulation code from the Nonpareil project. The Voyager stuff is taken down for some reason, but I believe it uses the same processor architecture as the 41c, so it’s still probably worth my taking a look to understand it.
Lazily, perhaps, I have shunned keyboard work for the moment, and been studying the nonpareil code. I did reach out to the author to hay hi and inquire about the removal of the voyager stuff. The original ROMs are not available, so I’ll have to forgo that approach for the time being, but figured researching the processor emulation would be instructive. Also I did a web search and came across another thing called the NEWT, which is a hardware board that emulates (and extends) the HP41’s process, which is the same architecture. Happily, it has documentation including the programmer’s model (the registers, etc), and instruction set details.
It’s really quite stunning what folks have done already, and I am a little bit chagrined that most of my current efforts are really yesterday’s news. However, I am gong to carry on for sever reasons:
The ramp-up for understanding the existing code and historic instruction set may be a greater cost than just writing it from scratch, but I can’t help feeling compelled to at least give a good look at what has already been done, and maybe learn some things about calculators in general. Anyway, I’ll give it maybe a week. Of course, knowing me, the prospect of some intricate machinery to understand may absorb me for who-knows-how-long….
But, back to the code. A quick scan over it indicates some stuff I won’t be needing, like parsing of definitions, support for other processors or even some features of this processor. There’s bindings at a low-level (e.g. in the processor emulation) to the GUI toolkit (gtk) that I’ll have to cut off, and there appears to be some static memory allocations that are fine for the desktop but probably not fine for this processor. But all that’s part of it, no?
So, we’ll see what we’ll see!
On-and-off over the past few days I have managed to extract the core of the nonpareil emulator that I need, and I extracted just the pieces from other modules needed to support it. I have no expectation that this will work – I just wanted to see if this could be done. I did get it to link as well (which surprised me a little), and it looks like the emulator adds about 32k to the ROM, bringing it to 93k total. Since this device has 512k program ROM, it looks like I have plenty of space for extra stuff. But first I need to now try and get the emulator to actually run… Oh, and do the keyboard (haha).
I still need to verify that this software actually does what it’s supposed to, and that would be painful to do on the board, so I made a little Windows project using the code that will be much easier to step/debug/investigate. After dealing with cross-platform/-tools annoyances, I have it compiling and apparently running in some manner (not running actually calculator code, but just the processor emulator is running). I also took a peek at dynamic memory usage. As expected, it is way too much for my board. It’s well over a 1MB! Remember, it was written for the desktop, and it has a huge number of debugging features and other things to make analysis easy.
So now I am incrementally cutting out all that stuff, and the processor abstraction framework, so that I will just be left with the Nut-specific processor. I suspect it will collapse down to one module, with a couple callbacks out of it to optionally hook any important events.
Oh, along the way I found some other useful info:
The aforementioned ‘Newt’ manual referenced hp41.org, which has scans of old HP engineering documents on the Nut processor. It is intended for the 41C, but the Voyager processor is essentially a non-expandable version of that, with a special display controller. That controller chip has the ROM, RAM, and Display Driver (RRDD, or R2D2 as it is lovingly known). Which leads into the next thing….
Allyn F. Tennant wrote an article called ‘Synthetic Methods on the HP-15C’. Essentially he reverse-engineered a lot of stuff on that calculator by exploiting some anomalies involving a reset/self-test function. You can use a side effect of this function to create and artificial (hence ‘synthetic’) matrix descriptor that covers explicitly specified areas of RAM. With it, you can see into the internals. He reverse-engineered a bunch of interesting stuff in low-RAM, like details of the display control!
The display, being 7-segment LCD, is controlled by bitmapping segments to bits in the two memory locations (0x09 and 0x0a). For reasons unknown to me, the segments are strewn about the two registers apparently hurdy-gurdy, and I could not glean a pattern. However, I know that sometimes what makes bad software sense makes great hardware sense, and it could be that this pattern gives some advantage, like if all the lines from the physical LCD can make a direct path to the chip’s respective pin without crossing other lines. If so, that would make for a more reliable manufacturing process, but this is speculative of course. It’s pain for software, but hey software is soft and hardware is hard, hence the names.
Anyway, I’ll only really have to deal with that if I were to get hold of some ROM images that presume the existence of that display. Oh, haha, and I have another little problem if I do: that is a 7-segment display, whereas I have an ascii display. So I would have to first de-convolve the bits in the display registers into a form where one memory location contains all it’s segments, and then transform the 7-segment to ascii. Easy? Well, the catch is that there can easily be 7-segment ‘art’ characters that have no ascii equivalent. So I would have to substitute those (this happens infrequently, but for instance the keyboard and lamp test do this). Also, the display has a decimal and comma that is bound to the digit position, which must become a separate, discrete, character in my ascii lcd. But again, all this is only relevant if I am going to run a ROM image. I would like to do that so that I can have a stable unit test, but it’s not critical since ultimately I am going to make new firmware for it.
On the plus side, I notice that the keyboard is handled by the CPU, with keyboard-specific instructions. That is great because it will make abstracting my keyboard implementation through the CPU so much easier to do at a higher level (than, say, trapping instructions reading hardware state and emulating that way).
OK, at length I cut out an ocean of stuff, whittling it down to the register set, and the opcode implementation, and simplified the RAM/ROM allocation (which were generalized for other calculators), and transformed the instruction dispatch to a combination switch/table lookup which will be stored in ROM rather than RAM.
At the moment, I am now down to just under 4K RAM usage, comprised of 192 bytes for the cpu emulation, and 256 numeric register locations. I can further cut that in about half because I noticed that the implementation uses 1-byte per digit, instead of 1 nybble. But since changing that is (I think) some significant surgery, I’ll save that for another day. It’s small enough now that I can try putting it back on the board, maybe even actually running it in a thread…
OK at last I am going to start working on my dreaded keyboard. Why do I dread thee? Who knows, I just do. But it has to be done. So I did it:
Now I set me down to writing the keyboard scanner/debouncer. This is the actual part for which I have so little love.
Keyboard scanner seems to be working. Here’s pi read in:
Its time to think about casing this thing up. I wired on the batter charger/regulator. One design deficiency is that this will require there to be a battery present, even if running off of USB power. I’m going to leave it that way for now, because I don’t feel like making the needed change.
I shoved all the stuff into the case. I’ve got a space crisis, and I removed the power board, so it’s just going to be USB for the moment until I figure something out. I can cut the power board down a bit, and possibly route out some sections of the back to create a little more space.
I connected it up to see if it was still alive.
I messed up in positioning the LCD, it’s off-center about 1/16”, and now it’s hotglued so there it stays for now. Also, the original gold bezel is just laying on top for fun; it’s not secured into place.
Now I can use the keys! Confusing as the 12C key labeling will be in doing so.
Anyway, I have some sort of power problem because the battery never finishes charging. I hope I don’t have a bad battery, but I did wait two years to actually try to use it, and it is lithium. We’ll see…
The keyboard is a mixed bag when it comes to registering keys, the ‘8’ is particularly problematic. It might just be that this is an old used calculator, but doubtless melting the various ‘heat stakes’ will secure the keyboard against the keys and work better. I haven’t done this yet because I wanted to make sure it’s working enough that I won’t need to pull the board out again.
OK, I’m tired of hardware for now; now I am going to work on some firmware. It will be a couple days before I get back to this, though…