HP Forum Archive 16

[ Return to Index | Top of Index ]

15C keyboard vs today's 12C Message #1 Posted by Bruno Ferard on 9 May 2006, 3:35 p.m. I have read the interest shown by a lot of people to purchase at a reasonnable price the 15C. Given the great similarity between the 15C and the 12C that HP continues to sell, imagine that somebody can get in touch with HP's manufacturer. He would request a little customization to change the keys labelling and have a specific ROM, all the rest being identical. He would then have 2 options: either negociate with HP a licensing agreement to reintroduce the 15C under HP's brand or sell the customized 12C with a different brand and sell directly through the internet to all those people who signed the petition to get the 15C back on the market. What do you think? First, is the current 12C equivalent in term of look and feel with beloved 15C? Would this guy have any chance of succeeding? Has anybody tried that in the past? Any opinion about how HP would receive this initiative?

Re: 15C keyboard vs today's 12C Message #2 Posted by Karl Schneider on 9 May 2006, 10:19 p.m., in response to message #1 by Bruno Ferard Bruno -- One major problem would be to "have a specific ROM", as you put it. The "replacement" models that HP/Kinpo developed in 2002 were based on HP models then or recently in production -- e.g., the HP-12C, HP-32SII, HP-49G, HP-17BII, etc. The mature ROM's of those models could be ported to the new hardware, using emulation layers or however it was done (others here could tell you). The HP-15C, however, was discontinued in 1989. From what I've read in this Forum (posts by Eric Smith), its magnificent documented ROM may have been lost forever. I seriously doubt that Kinpo could replicate the developmental effort, even if given a very generous budget. The other problem is that the HP-15C is behind the times in certain important respects as an advanced non-graphing calculator. Its 7-segment display does not allow for alphanumerics, informative error messages, or symbolic instruction indicators. Its 10-digit display doesn't measure up to other high-end models, which offer 12 or more digits. Its small RAM and slow computational speed could be remedied by modern technology, but most users in this day and age would not accept the other limitations. Sales of a "new 15C" might come largely at the expense of the HP-33S, also. The ROM issue, though, is the likely "show-stopper". Regards, -- KS Edited: 9 May 2006, 11:06 p.m.

Re: 15C keyboard vs today's 12C Message #3 Posted by John Limpert on 10 May 2006, 3:04 a.m., in response to message #2 by Karl Schneider Quote: Its small RAM and slow computational speed could be remedied by modern technology, but most users in this day and age would not accept the other limitations. Sales of a "new 15C" might come largely at the expense of the HP-33S, also. The ROM issue, though, is the likely "show-stopper". How large is the ROM? People have been reverse-engineering ROMs for many years. One of my first programming jobs was to take a binary executable from an old computer, reverse-engineer it, and port it to a new computer. Nobody could find the source code for the original program, and the computer was being replaced with a newer and incompatible model.

Reverse-engineering ROM's Message #4 Posted by Karl Schneider on 11 May 2006, 9:41 p.m., in response to message #3 by John Limpert John posted, Quote: How large is the ROM? People have been reverse-engineering ROMs for many years. Check the posts of Eric Smith in MoHPC Forum Archives #14 and #15 for the work he has done to "extract the ROM's" from many models of calculators, using certain kinds of logic-testing devices. Not being an electronics engineer, I do not fully understand what he has achieved (and might not have been able to), but certainly the valuable documentation and other explanatory information would not be present in the extracted code. The mathematical methods and algorithms in the HP-15C are quite impressive, incorporating very many man-hours of skilled labor. Quote: One of my first programming jobs was to take a binary executable from an old computer, reverse-engineer it, and port it to a new computer. Nobody could find the source code for the original program, and the computer was being replaced with a newer and incompatible model. This reminds me of 1985, when I started work in a group that wrote and maintained Fortran software than ran on mainframes. Loss of source code for operational executables was apparently a problem, and computer upgrades were being planned. One young colleague said that he would eventually "make his million" writing software that could create source code from an executable. Now, certainly, it is generally impossible to re-create the original source code, but a good program might be able to produce a reasonable starting point. I don't know how far he got... -- KS Edited: 11 May 2006, 9:57 p.m.

Re: Reverse-engineering ROM's Message #5 Posted by Eric Smith on 12 May 2006, 1:47 a.m., in response to message #4 by Karl Schneider The 15C has 12 Kwords of ROM. I find that it tends to be somewhat more difficult to reverse engineer Nut code (or Classic or Woodstock) than code for typical microprocessors, because the architecture is so much different. However, with enough experience/practice, I imagine that it would actually be somewhat comparable.

Re: Reverse-engineering ROM's Message #6 Posted by Jacques Laporte on 12 May 2006, 4:31 a.m., in response to message #5 by Eric Smith Hi Eric, I have myself instrumented recently a type 2 buggy HP35 and dumped the instructions of the ROM. IS signal is active during 45-55 bit time ; I strobed it with the SYNC line and the Ø2 MOS clock. It's a non destructive approach. I brought the instructions to the USB port of a PC with a few components : it's just an instruction flow (pattern is logic inverted) for each key actuated. With a few selected keystrokes, I could travel nearly all over the ROM (minimum coverage). But this approach is satisfying only because I already know the ROM I'm checking! I work on the complementary approach inputting addresses on the IA bus (as a “seft test” routine) but that seems much more complicated. Address input must be present serially on the bus, from bit time 19 to bit time 26, and there is no strobe signal. Apparently, each ROM has its own 56 bit counter, synchronized on SYNC. I have to find a way to avoid access conflict to the address register. I plan to do the same on a HP25. Any advice is welcome! Best regards.

Re: Reverse-engineering ROM's Message #7 Posted by Meindert Kuipers on 12 May 2006, 5:21 a.m., in response to message #6 by Jacques Laporte From your description it looks like the ROMS operate in much the same way as in the HP41, for which I know the hardware operation in some detail. Your approach with the USB should work without a problem, Eric Smith uses this and I have done it as well with an FDTI USB interface. It seems that the calc does not have a selftest function that travels through all ROMS, otherwise it would be easy to capture all cycles. You could try to drive the appropriate signals when the CALC is idle, but this could be risky. In any case it may be better not to drive the SYNC signal, since this indicates that an instruction is present. SYNC is not active when the CPU fetches data. Good luck with your experiments, Meindert

Re: Reverse-engineering ROM's Message #8 Posted by HrastProgrammer on 12 May 2006, 8:01 a.m., in response to message #7 by Meindert Kuipers It seems that the calc does not have a selftest function that travels through all ROMS... It does have a ROM test: 173D 1A0 CLRABC 173E 21C PT= 2 173F 310 LC 12 1740 106 A=C X 1741 226 C=C+1 X 1742 0E6 BCEX X 1743 130 LDI 018 1744 018 * 1745 27C RCR 9 1746 0BA ACEX M 1747 15C PT= 6 1748 0CC ?ST=1 10 1749 02B GONC L174E +04 174E 174A 162 A=A+1 PT 174B 162 A=A+1 PT 174C 222 C=C+1 PT 174D 222 C=C+1 PT 174E 330 L174E CXISA 174F 146 A=A+C X 1750 013 GONC L1752 +01 1752 1751 126 A=A+B X 1752 23A L1752 C=C+1 M 1753 37A ?A<>C M 1754 3D7 GOC L174E -07 174E 1755 186 A=A-B X 1756 346 ?A<>0 X 1757 15F GOC L1782 +2A 1782

Re: Reverse-engineering ROM's Message #9 Posted by Jacques Laporte on 12 May 2006, 1:14 p.m., in response to message #8 by HrastProgrammer This code is from the 15c ROM. I was discussing dumping of "classic" or "woodstock" rom. When the machine has a self test routine ... no problem, in fact. Regards, Jacques Edited: 12 May 2006, 1:15 p.m.

Re: Reverse-engineering ROM's Message #10 Posted by HrastProgrammer on 13 May 2006, 12:25 a.m., in response to message #9 by Jacques Laporte This code is from the 15c ROM. I was discussing dumping of "classic" or "woodstock" rom. Sorry, I wasn't sure which ROM was Maindert talking about because this thread started about HP-15C and HP-12C ...

Re: Reverse-engineering ROM's Message #11 Posted by Jacques Laporte on 14 May 2006, 6:39 a.m., in response to message #10 by HrastProgrammer > Sorry, I wasn't sure which ROM was Maindert talking about because this thread started about HP-15C and HP-12C ... No, my fault! I just wanted to share information about dumping the Roms of calculators without self test (like HP35, HP25, HP65 etc…). Maindert suggested to wait for an idle state of the calculator. Due to the dynamic MOS technology, information is constantly circulated, Eric is right. However, I can understand “idle state” as a period when no address is fed and no instruction is executed. In the HP35 (and Woodstock too), the bit time is 5 microseconds (system clock = 200 khz ; 800/4) and the word time is 280 microseconds (56 bits). So the “window” to input 8 bit address on the IA bus is (from bit time 19 to 26) = 40 microseconds. On the working calculator, a ROM (HP35 has 3) seems to count from bit time 55 (trailing edge of SYNC) up to bit time 19 to allow gating addresses in the address register. Is there another method than surgery to input the address? (cutting off the IA bus and providing the right MOS level counting signal – correctly synchronized) ?

Re: Reverse-engineering ROM's Message #12 Posted by Eric Smith on 12 May 2006, 12:18 p.m., in response to message #7 by Meindert Kuipers Quote: You could try to drive the appropriate signals when the CALC is idle The HP calculators before the 41C aren't ever idle. They run continuously any time the power is on.

Re: 15C keyboard vs today's 12C Message #13 Posted by Vassilis Prevelakis on 10 May 2006, 6:25 p.m., in response to message #2 by Karl Schneider I have mentioned this idea in this forum before. Modern HP12C calculators have a single chip that polls the keyboard lines and drives the display, it should be possible to replace this with a new chip emulating the original HP15C binary. I believe there exists a native HP16C emulator so the HP15C ROM should be able to run on this one directly. **vp

Re: 15C keyboard vs today's 12C Message #14 Posted by Bruno Ferard on 12 May 2006, 4:46 p.m., in response to message #13 by Vassilis Prevelakis Thanks for your suggestion. Somebody wrote me in a private message that the keyboard of the current 12C is by far inferior to the original 15C keyboard. This is the key point. Even if the ROM could be copied and emulated, the result would be disappointing.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall