HP Forum Archive 16

[ Return to Index | Top of Index ]

Spice construction Message #1 Posted by Hal on 15 June 2006, 6:40 p.m. Hi folks. Can anyone tell me, in addition to the early 34C's, do any other of the Spice series use that quirky solderless construction tecnique? Thanks and best regards, Hal

Re: Spice construction Message #2 Posted by Etienne Victoria on 15 June 2006, 7:37 p.m., in response to message #1 by Hal Hi Hal, I've seen this petty-savings construction in each of my former Spice models except my 38Cs. Maybe somebody else has more precise information. The no-solder-pressure-connection wizards at Hp also issued another type of "very excellent" connector scheme in the Hp-41 fullnut. Look at this... Pretty...uh ? :-((( Now THAT's *quirky* ! Best regards. Etienne

Re: Spice construction Message #3 Posted by GE on 16 June 2006, 6:42 a.m., in response to message #2 by Etienne Victoria There is reference to the same kind of technique for fitting the hybrid CPU onto the PC board in the HP9825, on the **very excellent** site http://www.hp9825.com . That time, it seemed to give excellent results. So maybe if well done, this can work reliably.

Calculator construction problems Message #4 Posted by Palmer O. Hanson, Jr. on 17 June 2006, 3:24 a.m., in response to message #3 by GE Soldering didn't always work that well either. One of the early Rockwell units in my collection (I think it was the 24RD) didn't use a minus sign to indicate a negative display value, but rather lit up a single LED in the upper right hand corner of the calculator. In the first two in my collection the LED didn't work so, without a manual, I wondered how one knew when the display value was negative. Then I lucked out and purchased a unit where the LED worked intermittently. I opened the units and found that the solder joint between one lead od the LED and the printed circuit board had not been properly made. I touched up the joint with my soldering iron and VIOLA! the sign display worked. The bad connection was the kind that was symptomatic during the early days of wave soldering. A note on "It works reliably if it is well done." I used to respond that I would prefer use of a technique which which would work reliably even if it wasn't well done.

Re: Calculator construction problems Message #5 Posted by GE on 19 June 2006, 5:48 a.m., in response to message #4 by Palmer O. Hanson, Jr. I read somewhere that USSR machines were **designed** around bad assembly. Would work even with low-quality labor force. Also, a guy named Antoine de Saint Exupéry once said "Something is not perfect when nothing can be added to it, but when nothing can be removed from it".

Antoine de Saint Exupéry, the HP-15C, and Einstein Message #6 Posted by Karl Schneider on 19 June 2006, 3:03 p.m., in response to message #5 by GE Hello, GE -- Quote: Also, a guy named Antoine de Saint Exupéry once said "Something is not perfect when nothing can be added to it, but when nothing can be removed from it". I would qualify that statement by appending the phrase, "without causing diminishment", which I believe is implicit. This thought is in a similar vein to one that I believe is atributed to Albert Einstein: "Simplify, but do not oversimplify." Even more to the point is last year's advertising tagline for the Nissan Xterra sport-utility vehicle: "Everything you need; nothing you don't." An example: For its form factor and hardware, the HP-15C is perfect. To remove any functionality could diminish it toward an HP-11C or HP-10C, without adding any ease of use. Antoine de Saint Exupéry is, of course, the author of The Little Prince, not to be confused with Machiavelli's The Prince. The Little Prince pokes some fun at common thought processes of adults, in the form of the people encountered by the child prince during his voyages. One is an astronomer who obsessively inventories the stars in the heavens: "I can count them; I am accurate." Too bad he didn't have an HP calculator... :-) -- KS Edited: 19 June 2006, 9:18 p.m.

Re: Antoine de Saint Exupéry, the HP-15C, and Einstein Message #7 Posted by Valentin Albillo on 20 June 2006, 5:00 a.m., in response to message #6 by Karl Schneider Hi, Karl: Excellent reflections the ones you made in your post. I think there are basically two things that could be added to an already perfect HP-15C to make it even better, without altering its style and ergonomy in the least, namely: More RAM. 448 steps are pretty fine for this calculator, but a little more would be useful. I think 4 Kb would be ideal, matter of fact some SHARP models of its size and age do have 4 Kb to 10 Kb RAM. Those 4 Kb would be very useful to keep up to 5 reasonably sized programs in RAM at once while being able to deal with decent-sized matrices and linear systems, say up to 15x15 or so. As it is now, 448 bytes are on the scarce side, as a number of program instructions take 2 bytes of RAM, a single 8x8 matrix takes the whole RAM, and INTEG needs 23 registers (out of 64) to do its things. 4 Kb would be enough for all reasonable purposes on this machine, and it would be absolutely transparent to users who don't need it. More speed. It's marvelous that batteries will last up to 10 years and more, but the HP-15C is really quite slow. This isn't very noticeable in lesser models, but when dealing with matrices, SOLVE, INTEG, and running user programs, it's certainly very noticeable. A 5-fold to 10-fold increase in speed (also typical of SHARP models of its size and age) would make this little machine much more useful, specially when dealing with these advanced features, which are actually germane to such and advanced calculator, else you would be better off with an HP-11C, say. This modification would also benefit each and every user without upsetting anything. Best regards from V.

Re: Antoine de Saint Exupéry, the HP-15C, and Einstein Message #8 Posted by Eric Smith on 20 June 2006, 1:18 p.m., in response to message #7 by Valentin Albillo Quote: there are basically two things that could be added to an already perfect HP-15C to make it even better [...] More RAM I'm working on it. Without a major rewrite of the code, it won't be possible to have more than 1568 bytes of user memory (plus registers 0, 1, and I). Of that, the most that can be used for registers is 98 (plus 0 and 1, for a total of 100 numbered registers). Potentially all of it can be used for matrices or program steps. The step number does not display correctly above 999, though. I've verified that simple matrix operations seem to work OK on matrices with more than 64 elements. Would anyone care to suggest test cases they'd like me to try, requiring fewer than 128 matrix elements total (operands and results)? Preferably not something that will take hours of runtime. Quote: 4 Kb would be very useful to keep up to 5 reasonably sized programs in RAM Typically I ran out of labels before program steps, so I don't think making more memory available to programs is all that helpful unless it is changed to allow two digit numeric labels. And that would be a really major change to the code. Of course, if one develops new 15C-equivalent firmware from scratch, then it is much easier to make changes like that. Edited: 20 June 2006, 4:32 p.m.

Re: Antoine de Saint Exupéry, the HP-15C, and Einstein Message #9 Posted by Antoine M. Couëtte on 21 June 2006, 2:40 a.m., in response to message #8 by Eric Smith HRAST, are you here for Memory extension ? Antoine :-) + :-))

Re: Antoine de Saint Exupéry, the HP-15C, and Einstein Message #10 Posted by HrastProgrammer on 2 July 2006, 3:30 a.m., in response to message #9 by Antoine M. Couëtte Sorry, I was out of the calculator "bussiness" for the last few weeks ... As soon as I will find some time for the emulators again, I will probably turn to HP-15X :-) Best regards. Hrast

Re: Antoine de Saint Exupéry, the HP-15C, and Einstein Message #11 Posted by Valentin Albillo on 21 June 2006, 4:40 a.m., in response to message #8 by Eric Smith Hi, Eric: Eric posted: "I'm working on it." That's great news, thanks a lot for your valuable efforts. May I ask if this upgraded functionality is meant for Nonpareil or for some custom-built hardware or both ? "Without a major rewrite of the code, it won't be possible to have more than 1568 bytes of user memory (plus registers 0, 1, and I)." That should be more than enough, nearly 4 times as much memory as a physical HP-15C. "The step number does not display correctly above 999, though." I don't see a problem with this. 999 steps are more than enough. They would probably require nearly all of the 1568 bytes available, anyway, and such a large program or programs would undoubtely need bytes for storage registers, so it's highly unlikey such a large program would actually be necessary without being contrived. "Would anyone care to suggest test cases they'd like me to try, requiring fewer than 128 matrix elements total (operands and results)? Preferably not something that will take hours of runtime. I would simply write a short program that would dimension two suitably large matrices (say 10x10), would fill one of them with random values from an starting seed (so that the test is repeatable), compute and store its inverse in the other matrix, then multiply both, take norms of the result, compare them against theoretical values for a 10x10 identity matrix, and record the largest discrepancies. They all should be very small if everything's ok. "Typically I ran out of labels before program steps, so I don't think making more memory available to programs is all that helpful unless it is changed to allow two digit numeric labels." That's not so for two reasons. First of all, though the HP-15C only has 25 different labels (LBL 0-9, .0-.9, A-E), they can be re-used: a running program's GTO 3 will always find the nearest LBL 3 onwards, even if there are other LBL 3 present somewhere. This essentially means you have an indefinite number of labels available for forward searching, and backward searching is much more infrequent, so 20-25 labels would be more than adequate for any large program or up to 5 medium size programs resident at once in program memory. Second, the HP-15C does allow indirect branching to any step number by simply storing its negative number in Register I, then performing a GTO I. This means than if -127 is stored in RI, then GTO I will directly branch to step 127, same goes for subroutines. This essentially means you'll never run out of ways of branching to arbitrary steps, as you can either repeat labels or use indirect addressing, contrary to what happens in the HP33S, where you're absolutely stuck with 26 labels which can't be repeated or reused, nor can you branch to a given program step without a label. So, I hope I've proved to you that making more memory available to programs is indeed helpful in the HP-15C. Again, many thanks for your efforts, I really look forward to see what you come up with, and Best regards from V.

Re: Antoine de Saint Exupéry, the HP-15C, and Einstein Message #12 Posted by Eric Smith on 21 June 2006, 11:47 a.m., in response to message #11 by Valentin Albillo Quote: May I ask if this upgraded functionality is meant for Nonpareil or for some custom-built hardware or both ? You may ask. And if you did ask, the answer would be "yes". Quote: I would simply write a short program that would dimension two suitably large matrices (say 10x10) At the moment I only have 128 pool registers max, so I was looking for a problem that would fit into that.

Re: Antoine de Saint Exupéry, the HP-15C, and Einstein Message #13 Posted by Valentin Albillo on 21 June 2006, 11:58 a.m., in response to message #12 by Eric Smith Hi, Eric: Eric posted: "At the moment I only have 128 pool registers max, so I was looking for a problem that would fit into that." In that case, instead of defining two 10x10 matrices, which wouldn't fit in 128 registers, use only one, like this: initialize the random-number generator with a user-provided seed, which will be stored for later use dimension matrix A to be 10x10 loop to fill all its elements with random values invert matrix A in place invert matrix A in place again reset the random-number generator with the original seed loop to subtract each element of A from the corresponding re-generated random value now compute the norms; ideally they should be zero; record the largest. Running this in a loop to test 100, say, random matrices and keeping score of the largest value of the norms will be a good test of matrix operations working properly for 10x10 matrices. If some norm deviates significantly from zero, the particular matrix can be traced to see if it's abnormal or else something's wrong with the extended RAM management. Best regards from V.

HP-15C RAM and speed improvements Message #14 Posted by Karl Schneider on 21 June 2006, 3:32 a.m., in response to message #7 by Valentin Albillo Hi, Valentin -- Good to hear from you on the matters of the HP-15C and "other reflections" regarding quotes from famous people. [BTW, I've been following your fine contributions regarding Gaussian quadrature, but haven't yet formulated my own response, because I've needed to do some investigation and reading. I hope to make that post late Thursday.] We've had several Forum exchanges in the past regarding potential improvements to the HP-15C. I agree with you fundamentally that more user RAM and faster speed would have been useful and welcome. However, I believe that those wishes should be framed by the capabilities of the base hardware -- including the CPU, display unit, RAM chips, keyboard, and overall package. What more would have been possible and practical to include without re-engineering the product? More RAM: As I understand it (from reading Eric Smith's prior posts), the HP-15C had two R2D2 chips, while all other Voyager-series models had only one. This is why the HP-15C had 448 bytes (64 allocatable registers) plus three non-allocatable registers, compared with the 203 bytes (29 registers) and one non-allocatable registers of the HP-11C and HP-16C. Now, if one more R2D2 chip could have been incorporated, up to 100 or so numbered registers (98 allocatable) would have been possible. I'd consider this amount optimal for practicality and cost, providing enough for the following: A 9x9 real matrix and 9x1 vector with room to spare An 8x8 matrix with room for INTEG and some programming Eric pointed out some upper-limit software restrictions. There were some other things of which to be mindful, including the display, having 10 digits and a leading negative sign: The MEM readout " RR FF PP-B" with RR = highest allocated register; FF = number of free registers; PP = number of programming registers; and B = number of free bytes. Providing enough RAM for triple-digit values of RR, FF, or PP would have required some changes to the display (i.e., making the leading negative sign a full 7-segment field) or revising the code for the MEM command. The program keycode readout " LLL-C1,C2,C3" where LLL = the line number; C1,C2,C3 are the three keycodes allowed. Obviously, LLL > 999 would cause a problem, unless another digit were made available. In short, the ability to accommodate matrices or matrix systems modestly larger than 64 elements without the user's having to delete programming would have been useful and practical. However, more storage for large programs without electronic I/O or an effective means of grouping and managing programs (using the END statement) would have been questionable. More than 100 registers (indirect access only above the 20th) would not have been particularly useful. So, how else could the extra RAM have been employed? Programs that created very large matrices might run slowly, and reviewing the full contents of such matrices (for debugging) might have been tedious. One has to think about cost, too: HP charged a considerable premium for the extra 1792 bytes (256 registers) of the HP-41CV over the base HP-41C, until 1985, when the HP-41C was discontinued. More speed: As I remember from Eric's previous posts, The HP-15C and other Voyagers share the same CPU with the HP-41, which also incorporates a voltage regulator and something else (I forgot what it was), that the Voyagers lack. These other componenets allow the HP-41 to use a higher-frequency LC resonant circuit and faster clock speed than the Voyagers, while still maintaining reliable operation at low battery voltage and temperatures. I have accelerated one of my HP-11C's by a factor of 2.5 by simply adding 33 uH of parallel inductance to the LC circuit. I have seen no undesirable side effects, and I plan to make the same change to many of my other Voyagers, including my present HP-15C or another one. The quicker response of this HP-11C is pleasing, as a trigonometric calculation no longer requires a full second. On the HP-15C, more speed for executing programs within the advanced functions or performing matrix function or complex-valued mathematics would certainly be welcomed. As for the comparison with the RAM and computational speed of the Sharp machines of the same era, I believe that you are referring to their pocket-computer models. I'd think that these devices have different hardware inside. One must consider what hardware HP could use at the time. The Saturn processor was still several years away... Best regards, -- KS Edited: 22 June 2006, 1:31 a.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall