The 42S input project

[Randy Sloyer]

It was a joint effort by Paul Brogger and Tony Duall. The last thread was here: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv006.cgi?read=11137.

I was able to duplicate Tonys circuit and add a PIC to help out. I had one talking serial comms at 75 baud with a PIC mpu interfaced to the analog muxs connected to the keyboard lines. It worked for loading programs into the 42S, but I was not able to complete the project and contain it within the calculator. The problems I encountered are:

1. Trying to fit the PIC, cmos mux, and MAX232 chips inside the 42S. With a .032" pc board, the surface mount chips are still too thick to fit without hitting the metal shield on the back plate.

2. Finding a suitable connector for the serial comms to fit inside the case.

3. Capturing the I/R output stream and decoding to redirect to a PC via standard ASCII. The actual decode is easy from a software standpoint, but it is the increase in processing power required leads to significantly decreased battery life. I figured I would want upload ability if I changed or wrote a program in the field and wanted to archive it.

It all came down to anything I did to add external circuitry would tax the weak little 90mah button cells big time. That lead to supplying power from the pc. Sounds easy, but I couldn't find a decent 4 pin connector that would fit inside the case. The super mini-usb connector used on the new digital cameras seemed like a good idea, but I couldn't figure out a way to secure and connect it. The 4 pin 2mm connector on the 48 would work with some case hacking, but I didn't want to bother.

I put the whole thing aside months ago and haven't given it further thought. It seems to me the proper way to do it is to disassemble the ROM and add the input via I/R through an unused input pin on the Saturn processor. The extension code could go in a 28 pin otp eprom and be soldered onto the logic board in the vacant position used by the language rom on the international version 17Bii. Very clean, but requiring a large effort to find the menu handling and key assignments in the rom. The I/R stream handling is probably already done somewhere in Saturn assembly as it exsists in the 48. Christof had started some disassembly, I don't know what progress he made.

As much as I wanted to make this work, I just don't have the time to devote to it. Maybe if I win the lottery...

[Kim]

I have been reading through this thread and started to think about a project I was involved with MANY moons ago.

In my efforts of trying to increase the memory of a 28C with the CMT ram module I bumped into a fellow 'nerd' that
was trying to make a serial port on the 28C. You can easily make the connection why we started talking. Even on a 28 with 32K ram "Memory lost" was bad news.

The gentleman and I connected to Wlodeck in UK and found the right pad on the PCB to use for serial IN (using the IR out pad (before the open collector transitor) for OUT)

We effectively made a two wire serial port on the 28C.

Assuming (and this might be where it falls on it's face) that the hardware and some software is similar. This should be possible on the 42S. The trick was to make an object into text and transmit the text through the I/O and this worked well. A small piece of SW helped this look like an I/O with commads like SEND filename and RECIEVE filename.

Has anybody looked into something like this?

I don't own a 42S (i used to and GAVE it away to a family member who in turn GAVE it away to someone in his school)
so I'm not much help here. (Other than - maybe this)

[Christof]

I'm still trying to get the disassemblers themselves to work.

I do agree that probably the best way to do it is to build the functionality needed into rom. I also recall reports of one of the HP engineers who worked on the 42 actually completing this. (wiht a big old eeprom hanging out of the back.)

Things to remember: the 42 'looks' for a second rom first, this means that instructions to do nearly anything possible can just be put into a second rom on the second set of pads.

there do exist utilities to translate the printer stream into text. So it doesn't *really* have to output ascii, though it would be a massive help

also, someone somewhere has disassembled the rom. I just wish I knew which process he used to do it so I could duplicate the work for this project.

[Glynn]

Randy;

It's always a trade-off, of course-- with little or no space, little or no power, and little or no support for control; designers ALWAYS have to make decisions based on working around what IS, not necessarily what would make most SENSE. Given what you had in circumstances and the laudable mission you set out to get as CLOSE to as possible, I'd say you got very far indeed, and I applaud your work (and Paul's and Tony's) to create what HP did NOT implement: an integrated I/O solution.

Not having a 42s myself, I have no means to look at the layout of one of these little jewels. But I am interested in following your project. I may not be able to help much, but I love to watch. ;-)

Randy, you say that "With a .032" pc board, the surface mount chips are still too thick to fit without hitting the metal shield on the back plate."

Okay, so what space inside the calc do you really have to work with?

What spaces are there, and what is the L-H-W of these?

(p.s.-- I wouldn't, barring electrical interconnection with it, worry too much about merely butting something against a plate-- maybe with a teflon film between-- UNLESS it would lead to undue stresses or flexure failures of the calc.)

Would a mylar flexible "pc board" solve the problem of space, or is it all even tighter than that?

[Paul Brogger]

The tight spaces involved are another reason to absolutely minimize what gets installed in the calculator.

How about NOTHING? Just program a robotic "finger" to press the keys as directed from a computer. (An array of electromechanical "pushers" would work too, but not nearly as elegantly . . . )

Imagine surfing the Web while, nearby, your 42s is being gently massaged by a delicate mechanical digit with several joints and a loving touch . . .

[Glynn]

LOL Paul!!

You know the "mission creep" that occurs around here, whenever we get involved in a project. Everybody will keep adding wished-for extra features and accessories.

Only a matter of time, and we'll have something designed to bring us beer, knead our tense shoulders, and...

...well, such a project just might get out of hand!

=;-0

[Paul Brogger]

Well, I was only being half humorous. In fact, a robotic finger would have the advantages of: no invasive electronic work involved, no tight spaces and fewer power supply issues, and the disadvantage of cycling the keys however many more times they'd be physically pushed . . .

(But our robot would need a second "finger" if we wanted to automate the self-test.)

And to minimize power drain by the IR output, one could train a digital camera on the screen and teach some monitoring software to do character recognition . . .

I can see it now: "My HP-42S Web Cam" . . . In fact, a REALLY cool virtual 42s would be a web link to control the finger, and a web cam to show the results -- virtual access to a real device! (With several people trying simultaneously to manipulate the stack . . . )