HP Forum Archive 06

[ Return to Index | Top of Index ]

Hardcore 16C enthusiasts wanted Message #1 Posted by Cameron on 25 Sept 2001, 12:04 p.m. A month or so ago, I wrote to David and asked his advice about testing a simulation of the 16C I'm writing for myself, the museum and anyone else that wants it. This is not a commercial venture. He suggested that I ask the fine people who post on the message board. I've lurked for a while getting a feel for this place and you seem like an enthusiastic and knowledgable bunch. So I feel that the time is right to pop the question... I'd like to hear from anyone who knows their 16C intimately and who would be willing to test the software and report bugs. The software currently runs on wintel PCs. By Christmas I hope to have it running on the Pcoket PC too. If you're interested, drop me an email or post a message here. Thanks in advance. Cameron

Re: Hardcore 16C enthusiasts wanted Message #2 Posted by Raymond Hellstern on 25 Sept 2001, 1:30 p.m., in response to message #1 by Cameron Hi, you said you want to make a version for PocketPC. Can you make one for WinCE2.11 for Handheld PC, too? I have a Jornada 690... Thanks, Raymond

An interesting challenge Message #3 Posted by Cameron on 25 Sept 2001, 8:34 p.m., in response to message #2 by Raymond Hellstern Hmmmm, in theory I can generate a binary for that platform. However, I only have the wince 3.0 developer tools and I suspect there will be gross incompatibilities. The other problem I forsee for my software on a clam-shell is the lack of a keyboard interface. I know you can use a stylus but I'm thinking that this would be clumsy on the 690 form factor. What do you think? Once I've finished the PPC version, I'd be willing to give it a go. I'd be relying on you for most of the QA though. Do you have the dev tools for that platform? The source is about 6,000 lines of C++. Of those, 5k lines are architecture neutral. I plan to GPL the source when I'm finished but I can see a time in the not-too-distant future where forking the dev tree would be practical. Cameron

Re: An interesting challenge Message #4 Posted by Raymond Hellstern on 27 Sept 2001, 2:04 a.m., in response to message #3 by Cameron Hi, I have the dev tools for WCE2.11 . I think if you separate the ui stuff (display, keypresses) from the calculator engine, it could be possible to retain the engine version independent. This way 'only' the user interface would have to be modified for different CE versions and form factors. I think of a kind of engine16C.dll, which could be compiled for 'normal' Win32 on the desktop PC, too. Regards, Raymond

WinCE development for calculator simulator Message #5 Posted by Andrés C. Rodríguez (Argentina) on 27 Sept 2001, 7:28 a.m., in response to message #4 by Raymond Hellstern While I am not particularly expert on these matters (apart from having a PocketPC and a yet-unfulfilled interest for a good RPN calculator emulator), I would suggest you to check the new Microsoft tools (such as VisualStudio.net) for the upcoming ".net" platform. It is supposed that software developed for this platform will run in WinCE, or WinXX almost without modification. A plea: if you can, make it as "generic" as possible, so in a near future you may offer also a 11C or 12C simulator...

Re: WinCE development for calculator simulator Message #6 Posted by Raymond Hellstern on 27 Sept 2001, 1:01 p.m., in response to message #5 by Andrés C. Rodríguez (Argentina) Sounds interesting. Is .net already available? Last time I checked it was a kind of announcement only. I'm not sure if the .net tools will be able to produce code for older CE machines. Or, in other words, I doubt that MS will provide a software adapter to run on CE 2.x machines... Regards, Raymond

...and extensions Message #7 Posted by Cameron on 27 Sept 2001, 3:21 p.m., in response to message #5 by Andrés C. Rodríguez (Argentina) Andres, the design could probably extend to other RPN calculators. Operators are encapsulated in classes that are bound to (virtual) keystrokes. Any functionality that can be built inside the abstract operator interface would be easily added. The only limitation I forsee is that the engine simulates the 16C's storage and programming model precisely (except that you can turn off the 203 byte limit ;-). If that needed to be changed to support other calculators, a re-write would be simpler. I won't be porting the code to .NET because .NET requires that I use a proprietary programming language. Microsoft's agenda is to polarise the industry and to force developers into a them or us position. I refuse to be party to this travesty. I encourage you to weigh the costs and benefits of porting millions of lines of working code to a new architecture simply because Microsoft's revenue streams are drying up. The .NET push is the finest example yet of their unbridled abuse of monopoly power. Forgive the soapbox-style rant but this one really winds me up. The cost to humanity of the avaricious decisions made in the Microsoft board room are truly mind boggling. Cameron

Re: ...and extensions Message #8 Posted by Andrés C. Rodríguez (Argentina) on 27 Sept 2001, 4:30 p.m., in response to message #7 by Cameron I am not arguing in favor or against any particular vendor, but just note there are (or will be; granted) many languages for ".net": at least C++, C# and VBasic.net. The "common runtime environment" should allow for programs written in different languages to interact; and also it is supposed to allow for a piece of code to run in different platforms (the same code for WinCE, Win desktops, Win servers, etc.). Again, these is just what I heard from developers and what I read. I am not able to offer any advice about these "virtues", or how much the "promises" will be met on the upcoming implementation. BTW, it's a real pity that great software (many thousands lines at least) written by HP for their calculators will be sleeping forever because they were written for a proprietary microprocessor (no longer manufactured), and because they were not ported to a "standard" platform, or to a portable virtual machine... Keep the emulators coming! (and Thanks!!)

Re: ...and extensions Message #9 Posted by Vieira, Luiz C. (Brazil) on 27 Sept 2001, 5:10 p.m., in response to message #7 by Cameron Just to know: if you have emulated the 16C completely, you already have the floating-point machinery ready to run not only square root, reciprocal and +, -, × and ÷, but any other algebraic operation that can be written. Of course, there will be no free position at the keyboard, BUT a new overlay would allow new additions. I know the target is the 16C, and I have one 16C as I also have the 15C. I believe internal SW for both do not share anything but the shrunk version of the floating point interface. If I am not wrong, basics would begin with trig functions and angle modes (retrieval), logs & hyperbolics and inverses and so. Anyway, I´m looking forward to testing the simulator...

Re: WinCE development for calculator simulator Message #10 Posted by Paul Brogger on 27 Sept 2001, 7:26 p.m., in response to message #5 by Andrés C. Rodríguez (Argentina) I'm just beginning to look at related stuff, as I've just got an iPAQ 3150 (monochrome, darn it!) PDA. There's some info about Microsoft's "eMbedded Visual Tools" (free-ish!) at http://www.microsoft.com/mobile/downloads/emvt30.asp and some PocketPC development info at http://members.home.net/hhfann/ .

Re: WinCE development for calculator simulator Message #11 Posted by Cameron on 1 Oct 2001, 11:25 a.m., in response to message #10 by Paul Brogger Paul, The embedded visual tools contain: a copy of Visual C++ 6.0 that's been nobbled to only work with wince projects. the compilers for all the PPC target processors, including the X86 emulator. the X86 emulator. remote debuggers for each of the target platforms. the MFC DLLs for each of the target platforms. Things you should be aware of if you're familiar with Win32 on desktop and server platforms. Wince has no support for C++ exceptions. It does support a limited kind of SEH. You must use the old MFC macros if you want to use exception handling. There is (emphatically) no support for the standard C++ library (STL). That's right, no containers, no algorithms and NO IOSTREAMS! There is diminished ATL support. Basically, if you want to do anything useful, you are compelled to use MFC. Don't however expect your MFC code to be portable. They've managed to introduce a whole swag of irritating differences. One of the goals of my calculator project was to assess the ease/difficulty of building applications with a common code base. If you're prepared to jump through some hoops and riddle your code with ugly macros, it can be done. I'm happy to share what I've learned. Drop me a line if you need to know more. Cameron

Design ... Message #12 Posted by Cameron on 27 Sept 2001, 2:54 p.m., in response to message #4 by Raymond Hellstern Raymond, The "engine" is a C++ class with a single input method and five output methods that each drive a logical display. Within the engine and its service classes, few assumptions have been made about the target platform; none are made about the user interface. The ALU assumes a little-endian processor--although that can be trivially abstracted with a small performance hit. The "continuous memory" requires an iostreams-based data source/sink to serialise persistent data. The engine is currently packaged in a static library. A DLL would be possible (but I loathe DLLs because they require source-code level support). I also considered packaging it as a COM server but rejected it because it's too Microsoft-centric and adds unnecessary complexity. I'll be in touch when I'm ready to release the engine code. In the meantime, you're welcome to exercise the desktop executable. Cameron

Re: Hardcore 16C enthusiasts wanted Message #13 Posted by Vieira, Luiz C. on 25 Sept 2001, 2:26 p.m., in response to message #1 by Cameron Mr. Cameron; I own an HP16C since 1986 and I use it in most of my own digital simulations. I have tested many digital circuits on it (her?), so I could 'build' them virtually. It proved being more than a helpfull calculating device. I would like testing the simulator and I ensure that it will be used this way, only. Also, I ensure I will notice any bugs detected. Thanks and good luck.

Thanks Message #14 Posted by Cameron on 25 Sept 2001, 8:27 p.m., in response to message #13 by Vieira, Luiz C. Thanks Luiz, I'll be in touch. Cameron

Re: HP16C emulation for HP48GX/G+ calculator Message #15 Posted by Frank Travis on 26 Sept 2001, 1:50 p.m., in response to message #1 by Cameron Anyone interested in an HP16C emulation package for the HPGX/G+ graphing calculators should go to website www.magpage.com/~jakes. I bought mine in 1998 from Jake Schwartz. I keep in touch with him every week. It works perfectly on my HP48GX (w/ 128K RAM). I bought the floppy disk based version. I had problems with it when on my HP48G (because this unit has only has 32 K RAM). Your best bet is buying an HP48GX (expandable, about $150) or HP48G+ (not expandable, but has 128K RAM, about $100) and PC Connectivity kit from Calcpro website www.calcpro.com. I have purchased from Calcpro several times and have talked on many occasions to their manager, Paul Nelson. Good Luck!

HP 22: I've blown it! Message #16 Posted by Ren Tescher on 2 Oct 2001, 9:49 a.m., in response to message #1 by Cameron (First time poster) Last year I bought a bare HP 22 at Goodwill for a quarter. Of course its NiCads were dead. I hooked it up to a 3volt power supply but it still didn't work. Then I realized this power supply didn't supply enough current (the 22 was pulling it down to just above a volt). So I hooked up a supply with more current. At power up, the display lit up briefly and then dimmed. Then I realized I had the 2nd supply set for 12 volts not 3!!!! Now (at 3 volts) the LED's glow dimly and then fade away. Does Anyone have any idea if this thing is fixable? I'm guessing (looking at the circuit board where the power hooks up, that I might have blown a 3 terminal device in a TO-92 package (a transistor? an integrated voltage regulator?) Any repair advice will be appreciated. Thank You Ren dona nobis pacem

Re: HP 22: I've blown it! (this should be a new thread) Message #17 Posted by Cameron on 2 Oct 2001, 1:29 p.m., in response to message #16 by Ren Tescher Ren, You've inadvertently attached your request to an existing discussion thread. You might want to repost it and thereby start a new thread about your HP22 woes. (I'd like to help but I'm a software guy (but I do know what a TO92 package is (but I don't know what the device in the package is))). There seems to be quite a few cluey hardware folk here. I'm sure someone will whip out a schematic and identify a replacement part in no time. Cameron

Re: HP 22: I've blown it! Message #18 Posted by Tony Duell (UK) on 2 Oct 2001, 2:51 p.m., in response to message #16 by Ren Tescher The TO92 packages on the Woodstock (HP2x) circuit board are NPN transistors. THey're used in a little switching PSU to step up the 2.5V battery votlage to +6.2V (Vss to all the chips) and -12V (Vgg to all the chips). The bad news is that the design of the PSU means that the Vss line can never be lower than the battery voltage input. So you've just applied +12V to all the chips :-(. I don't think they like that. You could try replacing the transsitor and seeing what happens but my guess is that it still won't work. Now, I've not really worked on a 22 (I know the 21, which is somewhat similar), but IIRC the chips are : 22 pin at the front -- ACT (CPU) ; 18 pin at the back left -- ROM and display anode driver; 20 pin at back right -- display cathode driver; 8 pin at the front left --RAM. All are HP custom parts. The ROM is specific to the 22, the others may be able to be raided from similar calculators. Once you've replaced the transistor, you can check the PSU voltages on pin 1 (Vss) and pin 2 (Vgg) of the ACT -- use the battery -ve terminal as the ground connection. If both voltages are OK, then suspect a chip failure. If Vgg is high, then suspect one of the chips has shorted internally and is pulling Vss down -- the PSU will try to work harder as a result and Vgg will rise.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall