The Museum of HP Calculators

HP Forum Archive 06

[ Return to Index | Top of Index ]

HP-42s -- The INPUT Project!
Message #1 Posted by Paul Brogger on 6 Sept 2001, 8:53 p.m.

With the successful conversion of my HP-42s calculators to 32K, some sort of input/download capability is more desirable than ever. Interested parties may wish to consider the following:

I think a very workable solution would be use PC software and a hardware interface to simulate keystrokes on the HP-42s. This could be done by building a "key pusher" (some sort of device which would push the keys by computer command), or by intelligently shorting the keyboard traces in computer-controlled sequence -- perhaps using magnetic relays.

I like the second approach. If we could bring the keyboard electrical connections outside the calculator (without damaging it, of course), then we could simulate keystrokes by activating correctly connected relays. Relays will easily work at normal keyboard entry speeds, and there should be no concern about polarity or voltage levels that there might be with silicon switches.

If you look at my pictures posted as part of the HP-42s article in the MoHPC, you'll see that the keyboard ( is connected to the PCB ( through 15 contacts. 15 electrical traces on an exposed mylar strip from the keyboard are pressed against 15 gold contact pads on the PCB when the PCB is attached to the front of the calculator. (This is how the LCD is connected to the PCB as well, but that involves MANY more points of contact.) For the keyboard, there are 7 "row" connections, 6 "column" connections, and two more connections devoted to the ON/reset key.

One might think it necessary to remove the PCB and insert some sort of 15-conductor "ribbon cable" between the keyboard and PCB to access the keyboard traces. Perhaps this would indeed be a viable approach.

However, all 15 of these traces "feed through" the PCB to the other (component) side, where they are exposed without separating the PCB from the keyboard. Therefore, a probably better method might be to solder 15 wires to the PCB at the spots where the keyboard traces feed through the PCB. (This would get around PCB removal and avoid disassembly/reassembly problems.)

I think a tiny 15-pin connector of some sort could be attached to a hole in one side of the HP-42s back case, and the pins carried to the keyboard traces by either of the means just mentioned.

Externally, something like 14 magnetic relays, appropriately wired, could then simulate all the keystrokes possible. If those relays were driven by a PC card interface (or, perhaps, an HP-48GX card?), then programs (each a series of keystrokes) from the controlling machine could be entered into the HP-42s via automated means. These would go in at a relatively slow speed, but would not require laborious manual entry.

The only risks would be: possibly damaging the HP-42s CPU when soldering the connector leads, and when hooking and unhooking the relays. (Perhaps the edge connector could be so designed and connected as to minimize the likelihood of connect-related damage?)

I'm NOT an electrical engineer, but I believe this is a very realistic plan for implementing input into the HP-42s.

Would anyone like to review the feasibility of this approach? I do have two HP-42s units which I would be glad to use in a test of this approach. If the relays could be mocked up and hooked to an RS-232 connector, I'd gladly wire an HP-42s with a corresponding connector and make it available for tests. I'd certainly like to help flesh out the details of the relay wiring, etc. (I just worked out the internal keyboard connection map while diagnosing a problem machine.)

Indeed, there is no need to risk an HP-42s during early testing. Any other Pioneer calculator could be so wired, and its keyboard behavior simulated, in order to evaluate the feasibility of this idea. I've got, for instance, an older-technology HP-14B which should work nicely. An HP-17BII is another good candidate. (And the HP-17B has the advantage that it's very replaceable!) In fact, I think I'm going to go ahead and wire one, and evaluate its behavior using mechanical pushbuttons.

What I need to actually implement a (hopefully, shared) solution is someone expert enough to do the PC (or HP-48) interface part of the project. Do you know of anyone? Does anyone want to volunteer?

Re: HP-42s -- The INPUT Project!
Message #2 Posted by Raymond Hellstern on 7 Sept 2001, 7:25 a.m.,
in response to message #1 by Paul Brogger


I thought I have heard somewhere that the 42S has some built-in, but deactivated I/O functions.

Are there any pins on the pcb which could build a serial I/O? maybe near the IR I/O?

If so, and if these fcns exist, one would 'only' have to connect those two pins to the outer world.

Just an idea...


Re: HP-42s -- The INPUT Project!
Message #3 Posted by Vieira, Luiz C. on 7 Sept 2001, 10:56 a.m.,
in response to message #2 by Raymond Hellstern

HewPack designers have based the 42S over the 41's operating system and resources plus the new Saturn concepts. It's my belief that they begun working on the project thinking of the future extensions. The future extension itself became the 48, a new concept. I also read somewhere in here that a 42SX was planned, but offered as a final product. If so, wouldn't they - HewPack designers - left those 41's based I/O routines already inside the 42S?

I believe they would not need so much more effort improving it. The fact is: is it worth enough looking for them? I think so.

Re: HP-42s INPUT -- 1st Test Successful
Message #4 Posted by Paul Brogger on 7 Sept 2001, 11:07 a.m.,
in response to message #1 by Paul Brogger

FYI, I was up 'til midnight last night. Wired a 17BII board with a foot-long fifteen-wire section of a blue ribbon cable taken from an old PC floppy harness. Stripped, tinned, and soldered them into the feed-through holes on traces followed from the keyboard pads. Then stripped and tinned the other ends, attached the PCB to the keyboard (actually, and old 14B front case) and started playing.

At first, everything looked bleak, with all sorts of violent objections showing up on the LCD whenever I touched two wires together. "INSUFFICIENT MEMORY" "MEMORY LOST" "MACHINE RESET" . . . or just gibberish. I felt pretty disheartened!

Then, out of frustration, I grabbed a 100k-Ohm resistor and tried connecting wires with that. Voila! Eureka! Cool! (A subsequent measurement of resistance across keypresses shows that the two affected wires typically change from ~140k-Ohms to ~8k-Oms with a key closure -- this with an old Radio Shack analog multimeter.)

So, for what it's worth: 14 relays and two resistors, appropriately wired, could serve to effect automated input into an HP-42s. All the relevant traces are available from the exposed side of the PCB, and my intentionally brutal experiments with similar 17B technology would indicate that dire consequences are not inevitable.

This just could work.

Re: HP-42s -- The INPUT Project!
Message #5 Posted by Tony Duell (UK) on 7 Sept 2001, 1:44 p.m.,
in response to message #1 by Paul Brogger

Several thoughts... My first worry is that the connections you bring out from the 42S CPU might be very sensitive to electrostatic discharge. A 'zap' on a pin of the new connector might ruin the CPU, or damage it so that it fails weeks or months later (ESD damage does not always show up at the time!). However, if you are prepared to take the risk, then it should be possible to do something like this. I would assume that the keyboard is a rectangular matrix of keys, and that pressing a key shorts a row line to a column line. My first task would be to figure out the connections to this matrix, since shorting together 2 row lines or 2 column lines won't do anything useful, and might, again, damage the CPU chip. Doing this might involve totally dismanlting the keyboard of a dead machine so that the traces on the keyboard membrane can be examined. Once you've done that, you could probably use 2 banks of switching devices (more on these in a moment). One bank from each column line to a common point, one bank from the common point to the row lines. 'Pressing a key' would involve closing one switch in each bank. I wouldn't use relays -- they're large, slow, and electrically noisy. I wonder if the HP42S would treat a pair of opto-isolator phototransistorsin series as a 'short'. If so, then these would be ideal for the 'switches'. If not, I'd try CMOS analogue switches/multiplexers. You could probably power them off the 42S batteries and opto-isolate the control inputs to them. AS regards driving the switching devices, a microcontroller (PIC, for example) is what I'd use. Let it take in commands over a serial interface, and energise the appropriate switches. If I had an HP42S (or similar) that I was prepared to risk, then I'd have a go at this (and , of course, GPL all appropriate schematics and source code), bnt I only have 1 machines and I use it. I'm no good at working on 'shared projects', I find it easier, quicker and less hassle to do the whole thing myself...

Re: HP-42s -- The INPUT Project!
Message #6 Posted by Paul Brogger on 7 Sept 2001, 2:20 p.m.,
in response to message #5 by Tony Duell (UK)


Thanks again (on behalf of us all) for your complete and detailed response.

I have dismantled a keyboard completely -- from a bashed-up 27s. The layout is relatively straightforward -- 6 columns, seven rows, and two extra devoted to the "ON" button. I agree that only appropriate combinations of row/column lines should be shorted.

Your idea of the wiring is like that I've alluded to: one relay/switch for each row trace, one for each column, and one for the "ON" button, for a total of 14.
All of the rows (normally "open") would be connected through a resistor to all of the columns. A simulated keypress would be closing one each, row and column (or the "ON" switch, alone).

Yes, static discharge is the worry, if the traces were carried out "naked" (as it were). If a connector were to be inserted in the calculator, it should have well-protected pins. I've already risked a 17BII PCB, and it seems (albeit, only "so far") to be doing fine.

I wouldn't think relays would be any noisier than the keyswitches themselves, which must be debounced, and hence will be inherently slow. I wonder whether the voltage drop across opto-isolators' or CMOS switches' transistors (isn't it something like 0.6V minimum?) would negatively affect the keypress simulation? (Not having any such devices, I haven't experimented with that.)

Anyway, I've done what I can -- I'm hoping someone else is interested in proceeding. If so, I'll gladly mail 'em my experimental machine and explain the wiring.

When I get time, I'll document what I've done so far and submit it all to the MoHPC Articles Forum.

Re: HP-42s -- The INPUT Project!
Message #7 Posted by Andrés C. Rodríguez (Argentina) on 7 Sept 2001, 3:49 p.m.,
in response to message #6 by Paul Brogger

Tony, Paul:

While not ready to "risk" my mint (service exchanged in 1999) HP-42S on input experiments, I am glad you are discussing and/or advancing these techniques.

Being an EE, and having done similar things (controlling keyboards from the outside) some 20 years ago, I think that CMOS analog bidirectional switches (particularly the 21-century successors of the CMOS CD4051-52-53 analog multiplexors) should be a way worth to explore. The 4051, if memory helps, is a nice device, which works like a 8- position rotary switch. Three bit lines control which of the eight "inputs-outputs" is connected to the single "output-input". Note that (as in a physical rotary switch), current may flow bidirectionally. For the purposes of the following ideas, let us view this single "output-input" as the "arm" of this electronic rotary switch.

If you cascade two of such devices back to back (perhaps using a suitable resistor in the range of 47 to 100 Kohm between the two "arms" with the apropriate resistance that Paul measured), you have a six-bit controlled assembly, where any of eight lines may be connected to any of the other eight lines. One nice feature of such arrangement is that it guarantees that no more than one combination is active at each time.

Both CMOS devices may be powered from the HP42S batteries, and the six bit lines may be connected to Vcc via individual pull-up resistors (470 Kohm?). Then, a set of six optocouplers should be used to pull down the bit lines, effecting the "keypress" while avoiding ESD concerns.

Since the "no signal" state will keep all bit lines as "1" values, the "111" input should not be connected to any keyboard line (at least in one of the switches)...

I wonder if there is enough room inside an HP42 to install some 4 ICs and 7 resistors inside the case... Again, mine is in "mint" condition, and I will not dare to open it, even after enjoying the reading of Paul's experienced counsel.

I hope this may help... Be cautious !!

Re: HP-42s -- The INPUT Project!
Message #8 Posted by Tony Duell (UK) on 7 Sept 2001, 6:46 p.m.,
in response to message #7 by Andrés C. Rodríguez (Argentina)

Yes, the 4051 was the sort of chip I was thinking of. As you said, it's like an 8 way rotary switch, digitally controlled. A couple of them with the common pins linked (via a resistor) is exactly what I was thinking of as well. I assume the 7 resistors you mention are the one between the 2 common pins on the muxes and pull up/pull down resistors for the control inputs (with CMOS there's no reason to always pull lines up by resistors and down by the optoisolators like you would with TTL -- the reverse is OK too). And the 4 chips are 2 4051's and 6 stages of optoisolators (q 4 way, 1 2 way, perhaps. Or a couple of 4 ways with the last one doing the ON key). Paul has said the keyboard is a 6*7 matrix, so the 8*8 switching capability of this circuit would fit rather well. As regards fitting it inside the 42, all the chips are available in SOIC (surface mount) packages, so it should be possible to make a fairly small PCB containing this circuitry. I don't know it it would be small enough, though. This has got to be worth trying -- now to find an old Pioneer....

Re: HP-42s -- The INPUT Project!
Message #9 Posted by Tony Duell (UK) on 7 Sept 2001, 6:38 p.m.,
in response to message #6 by Paul Brogger

When you mentioned the 14 relays I guessed you had to be doing something like I suggested (a row array and a column array), but I wanted to be sure you weren't (say) connected each of 14 lines to one common one (which is certainly the wrong thing to do). As regards using optoisolators and/or CMOS muxes, a quick experiment would tell whether they can work or not (my guess, without trying it, is that the CMOS muxes would almost certainly be OK). As I said, if I had a Pioneer to risk for this, I'd give it a go sometime fairly soon. I don't like the idea of relays -- they should be alright, and the contacts won't bounce any more than the original HP keyswitches, sure. But I think semiconductor switching is a more elegant solution if it can be got to work. I guess I now have to hunt around for soem dead (and not so dead) Pioneers to experiment with...

Re: HP-42s -- The INPUT Project!
Message #10 Posted by Steve (Australia) on 7 Sept 2001, 7:43 p.m.,
in response to message #9 by Tony Duell (UK)

From way back in my memory I remember that there were two CMOS Quad Bilateral Switches. One was the 4066. I can't remember what the other one was. The "off" resistance of these is quite phenominal, while the "on" resistance in one of the versions is something like 600 ohms (and I think that is the cheaper low performance one).

Naturally these devices do not suffer from contact bounce :-)

Re: HP-42s -- The INPUT Project!
Message #11 Posted by Tony Duell (UK) on 7 Sept 2001, 8:46 p.m.,
in response to message #10 by Steve (Australia)

Without running to get a CMOS 4000 series databook, so this is from memory, yes there were 2 quad bilateral switches, the 4016 and the 4066. They were pin-compatible, and IIRC one had a lower on-resistance than the other (but I can't remember which is which). There are also some analogue multiplexers. These contained several bilateral switches, with one end of each linked to a common pin and the other ends of the switches linked to separate pins. There was a digital 1-of-n decoder circuit also on the chuip so that only one switch was on at a time. It's basically an electronic multi-way switch. There's the 4051 (8 input mux), 4052 (dual 4 input mux, but with common control circuitry so that both of the '4 way switches' are in the same 'position' at any time), 4053 (3 2 way switches, independantly controlled) and 4067 (16 way, expensive, hard to find). I would suggest a couple of 4051s for the 'keyboard simulator', since they would suit thr 6*7 matrix layout.

Re: HP-42s -- The INPUT Project!
Message #12 Posted by Andrés C. Rodríguez (Argentina) on 7 Sept 2001, 10:44 p.m.,
in response to message #11 by Tony Duell (UK)

It is amazing that many of us are remembering the same things from memory (ours) without a CMOS databook in hand. The 4066 has lower on resistance than the 4016, IIRC; but for this end the muxes are more convenient. Yes, the resistors are pull-ups (or pull-downs), but NEEDED not to leave floating CMOS inputs which can latch-up (was it so...?); and the other ICs were some 4-optocoupler packages (I am not sure about part numbers).

Re: HP-42s -- The INPUT Project!
Message #13 Posted by Mark Sims on 8 Sept 2001, 3:52 p.m.,
in response to message #1 by Paul Brogger

All this talk of relays and CMOS switches and multiplexers seems way to complex and kludgy to the task. I have wedged external interfaces into many a keyboard over the years. Here is what I would do:

1) Take a 28 pin PIC chip and (probably) one of the Dallas Semiconductor solid state oscillator chips with the ultra low power standby mode. You should be able to power them directly from the 42S battery.

2) Program one pin of the PIC as a serial input. No need for a level converter chip, just a resistor and a couple of clamp diodes is needed.

3) Program one PIC port as inputs. This port will connect to the actively scanned inputs of the keyboard. I have not checked my junky 42S to see if it it the rows or columns or what the polarity of the signals should be. For this discussion assume that the ROW pins are driven by the 42S CPU. Also assume that each row pin will be driven high in sequence.

4) Program the other PIC port as as open drain outputs with no pins actively driven low. Connect it to the output side of the keyboard matrix. For this discussion assume this will be the COLUMN pins.

5) Normally the PIC will just sit there doing nothing. When it detects a serial port request to press a key it will monitor its input port (ROW) pins waiting for the corresponding one to go (HIGH). When this occurs, program the proper (COLUMN) pin to be active HIGH.

Some keyboard scanners will stop scanning the keyboard when it sees a key press on the (COLUMN) lines. If the 42S is like this delay long enough for the 42S CPU to register a keypress then switch the (COLUMN) output port to be inactive open drains again.

Other keyboard scanners will keep scanning the keyboard looking for a change in the keypress state. If the 42S is like this then you will need to switch the (COLUMN) port drivers off in sync with the (ROW) signal. You will need keep pulsing the proper (COLUMN) pin in sync with the (ROW) signal from the 42S CPU for long enough to register a keypress.

6) To keep the PIC/oscillator combo from draining the 42S battery you should probably add some kind of power management. One way would be to add a switch to turn off the oscillator, a much more graceful way would be to add another diode and capacitor to the RS232 input line. This would enable the oscillator chip when the RS232 signal starting changing. Once the signal stopped, the capacitor would discharge after a while and stop the oscillator chip.

Depending upon the required PIC speed you may be able to use it's internal low power mode/oscillator and dispense with the external one. You would then use the SLEEP instruction to power down the PIC.

This circuit could of surface mounnt components on a tiny circuit board and mounted in the bottom of the 42S case below the CPU card. If I remember right, there is quite a bit of room available. You would only need to mount a two pin connector.

Re: HP-42s -- The INPUT Project!
Message #14 Posted by Tony Duell (UK) on 8 Sept 2001, 4:17 p.m.,
in response to message #13 by Mark Sims

There are many ways to do this, and a microcontroller directly simutin the keyboard is certainly one of them. Howerver, I don't have any 28 pin PCIs in the junk box, nor do I have a progrmamer for them. And as an old-stuyyle hardware hacker I find it much easer to wire up chips (which I am likely to find in the 'junk box') than to program a microcontroller. Incidentally, I now have 4 broken Pioneer machines on the bench (thanks to HPCC, and more particularly Wlodek Mier-J) so I should be able to have a go at this soon.

Re: HP-42s -- The INPUT (or a new calc) Project!
Message #15 Posted by Vieira, Luiz C. on 8 Sept 2001, 9:48 p.m.,
in response to message #14 by Tony Duell (UK)

It's amazing reading it all. I feel as if a new design is about to emerge from here.

Just to mention: a few weeks ago, I have posted this:

Re: 12C, 11C, 15C - Let´s create ours! (

I believe that a hardware-emulation for hewpack machines is about to come from here...

HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #16 Posted by Andrés C. Rodríguez on 9 Sept 2001, 6:20 p.m.,
in response to message #15 by Vieira, Luiz C.

Luiz: What we are discussing is just how to simulate keypresses on a HP42S or similar machine, in order to load large programs. As you know, the lack of a input port or other backup (should I say restore?) means is a big - perhaps the only one - drawback of the 42; even bitter when you look as the many I/O options of the HP41. While Paul showed how to add memory to a HP42, the fact remains that the proposition to fill such memory with individual keypresses, and even to reenter them if there is a memory loss, accidental deletion or whatever, seems not very attractive. If there are no other input means, the "synthetic keypressing" may be the only option.

This has little to do with a new calc design. For such, I am still looking for a good calculator (RPN, perhaps like the calculator application on the HP200LX) to run on my Compaq (er... HP?) iPAQ Windows PocketPC.

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #17 Posted by Vieira, Luiz C. on 10 Sept 2001, 8:42 a.m.,
in response to message #16 by Andrés C. Rodríguez

OK; lets put things in another view.

Isn't there a way to directly access the contents of the calculator's memory? I have not followed the 32K feature adding, but I believe that when the calculator is turned on, the mem chip can be accessed at least to be read. Would it be easy to map the control signals so that a calculator backup is generated to be later used, I mean, by loading this backup directly to the calculator's memory? A terminal with a HOLD (or DMA) like feature, I don't know. People who already know the HP71B's internals would be able to tell it.

Just wondering...

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #18 Posted by Paul Brogger on 10 Sept 2001, 11:37 a.m.,
in response to message #16 by Andrés C. Rodríguez

To be correct, it was actually Tony Duell who showed us how to increase the -42s memory to 32K -- I merely performed the most recent such conversion (with his help), and wrote it up.

The microcontroller approach would certainly be most elegant from the "chip count" and "minimum-number-of-external-connections" points of view, and (assuming everything works) would be the approach to take if a mass-produced product were the object. But I think we're all playing with the tools that come most readily to hand.

With regard to bulk-load of the HP-42s memory -- that would be complicated (and perhaps enabled by) the wiring and behavior of the calculator itself. In attaching leads to the PCB to bring the keyboard traces out for testing, I've found that a number of the rows and/or column lines (I haven't done the schematic yet) are actually shared with the memory's address and/or data lines. If, as Mr. Sims suggests, the -42s CPU interrupts keyboard scanning until the keypress is finished, then perhaps it could be induced to "step aside" while bulk loading is accomplished. But conversely, if address and data lines are tied high or low to simulate a keypress, it will be hard to load the memory with anything . . .

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #19 Posted by Andrés C. Rodríguez (Argentina) on 10 Sept 2001, 12:52 p.m.,
in response to message #18 by Paul Brogger

I agree with Paul with respect of the "simple and dirty" approach of switches (electronic or not) to simulate keypresses, given that we don't have enough technical information about all signals and overlapping between address lines and such (do we?).

I don't know if the Saturn-based machines kept some or all of the previous HP calculator architecture, the use of standard CMOS RAM suggests otherwise, but it is very possible that each bus lines is used for more than a single purpose.

About Luiz comments: Even if we may find a way to dump all the memory contents (shadow RAM techniques?) to a hex file, it would be a monolithic file. The "synthetic keypresses" appoach may be generalized to move individual programs to the calculator, perhaps we could edit the programs in a PC and then ship them to the calculator in a cross-assembler fashion... To use a HP41 metaphor, I would prefer to use individual cards for programs than the WALL (write all) massive backup.

Oh, the "keypresses" method also allows for DATA input, to be read with the nifty GETKEY function (which also handles the no-data timeout), so it can input values to running programs, such as a datalogger. A simple datalogger could also benefit from the IR output from the calculator, not decoding it, but simply sensing the mere activity of the IR LED as a mean to synchronize things.

If (and this is a big "if") the 4051-optocoupler approach works, a datalogger which TURNS ON the calculator at presetted times, waits for an IR pulse to check calculator readyness, transfer a value simulating keypresses (perhaps using a look-up table in an external ROM), etc. ... looks very doable. For instance, we may capture a time-temperature matrix and graphics with ease!

Granted, most of this could be easier with a 48G+, still available and with decent I/O features, and also with timer and alarms...

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #20 Posted by Paul Brogger on 10 Sept 2001, 5:39 p.m.,
in response to message #19 by Andrés C. Rodríguez (Argentina)

>Granted, most of this could be easier with a 48G+, still available and with decent I/O features, and also with timer and alarms...

Sure, but where's the fun in that? ;-)

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #21 Posted by Andrés C. Rodríguez (Argentina) on 10 Sept 2001, 7:42 p.m.,
in response to message #20 by Paul Brogger

Agreed, no fun there. In fact, I recently bought a new 48G+ for about 100 US$, just to add to my very small collection.

While I was able to master the HP25, the HP41, and the HP42 in a very short time; I was almost unable to do anything with the HP48. It keeps nagging at me all the time, and offers no help or hints on what syntax is it expecting.

The HP41 was friendlier with prompts like STO _ _, and the NULL feature; even the HP25 had CLEAR PREFIX and the "keyphrases" for STO + 5 were more orientative...

I was even unable to find a reference in the manuals (perhaps because I have the Spanish version of them) to know the serial pin-out and voltages of the HP48.

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #22 Posted by Tony Duell on 10 Sept 2001, 2:06 p.m.,
in response to message #18 by Paul Brogger

I have traced out rather more of the HP42S keyboard than Paul (I think). From what I can see, the 'ON' key is connected between the +ve supply line and a pin on the CPU (presumably some kind of power on/interrupt input). The other keys form a 6(column) * 7 (row) matrix. All the scan lines (row and column) do double-duty as memory address lines. Well, actually, there's one that doesn't but I would guess it's still really A16 (the memotry chips, ROM and RAM, on the Pioneer board only use address lines up to A15, and A14, A15, etc are also keyboard scan lines). This may complicate the microcontroller approach -- I've not investigated that idea yet. The HP42S may be based on a Saturn CPU, but the hardware is very different from the HP71 (I've read that IDS many times...). The original Saturn processor was designed to talk to special HP memory chips (ROM and RAM) with built-in memory control logic. The chip used in the 42S has the memory controller built into the CPU package and uses normal, industry-standard RAMs. I don't think the traditional Saturn bus, like on the 71, appears outside the CPU package in the 71.. Oh well, more investigations to do when the component order comes back...

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #23 Posted by Mark Sims on 10 Sept 2001, 11:00 p.m.,
in response to message #22 by Tony Duell

Have you 'scoped out the keyboard scan waveforms to get an idea of how fast these things are running? With HP using the RAM address lines for the keyboard scan (boo, hiss), I suspect that they are going fairly fast (but probably not anything like a modern processor). This could definitely pose some problems with using optoisolators and mayby CMOS switches.

Scenix makes a PIC compatible CPU that can run at 100MHz and execute instructions in 1 clock cycle. I've done some wicked things with these little beasties... only thing is they draw about 1ma/MHz when running. But then it should not have to be on for very long, very often.

Re: HP-42s -- INPUT Project! (or "synthetic keypressing")
Message #24 Posted by Tony Duell on 12 Sept 2001, 2:09 p.m.,
in response to message #23 by Mark Sims

It's a Saturn CPU. I am not sure what speed it's clocking at, but I doubt it's much faster than 1MHz. That's for 4 bit words, so I guess the byte access frequency is about half that. I should stick a logic analyser on it and see... I think most switching technologies are going to manage that... Still, the only way to know is to try it, which is what I intend to do in the next week or so. I've read about these Scenix chips, but as I don't (yet) have a programmer that can handle them, I've not considered them for any of my projects. In any case, I really do prefer soldering up connections to writing code...

HP42S Bus Speed
Message #25 Posted by Tony Duell (UK) on 12 Sept 2001, 5:10 p.m.,
in response to message #24 by Tony Duell

I've just stuck a logic analyser on the keyboard scan lines of an HP42S (Like Paul, I've made a hacked 42S with ribbon cable soldered to the right points on the PCB), and the narrowest pulse I've seen it 10uS wide. So that gives some idea of the speed of the address bus (== pretty slow, actually).

Re: HP42S Bus Speed
Message #26 Posted by Vieira, Luiz C. (Brazil) on 12 Sept 2001, 5:36 p.m.,
in response to message #25 by Tony Duell (UK)

This an external signal (clock), right?

Should one consider that, inside, the chip is running faster? In a multiple of this external 100KHz (considering this is the clock)? It could be the display clock.

Does it make sense?

Re: HP42S Bus Speed
Message #27 Posted by Andrés C. Rodríguez (Argentina) on 12 Sept 2001, 6:02 p.m.,
in response to message #26 by Vieira, Luiz C. (Brazil)

Clock multipliers were not usual in 1980's designs, 100 kHz is not unusual in portable devices which batteries are expected to run for months-years... I have not seen many (any?) microprocessors running at higher frequencies WITHOUT a crystal-based clock (most HP calculators have no crystal for CPU clock).

Re: HP42S Bus Speed
Message #28 Posted by Tony Duell on 12 Sept 2001, 7:10 p.m.,
in response to message #27 by Andrés C. Rodríguez (Argentina)

Actually, the HP42S does have an Xtal clock. It's a 32.768kHz crystal in the 'wristwatch' can (tiny cylindrical package). It's also used (not suprinsingly) on the 17B and 17B-II, where it's needed for the real time clock functions. The 42S doesn't have the software to support an RTC, but the hardware is still there. IIRC, the CPU clock is clock-multiplied (PLL in the CPU package) to give the CPU clock.

Correction accepted
Message #29 Posted by Andrés C. Rodríguez (Argentina) on 13 Sept 2001, 8:49 a.m.,
in response to message #28 by Tony Duell

The lack of timing functions on the HP42S, and my somehow better knowledge of previous models (HP25, HP45 "standard" and HP 41) made me assume there was no crystal on the HP42.

Re: HP42S Bus Speed
Message #30 Posted by Tony Duell (UK) on 12 Sept 2001, 7:01 p.m.,
in response to message #26 by Vieira, Luiz C. (Brazil)

No, not a clock input. The only lines I've looked at are the ones to the keyboard matrix (which also happen to be address lines to the RAM (and external ROM, not fitted on the 42S) chip. Some bits of the CPU might well be running faster internally, but as I am not connecting to those, it doesn't bother me.

Re: HP42S Bus Speed
Message #31 Posted by Vieira, Luiz C. on 12 Sept 2001, 9:23 p.m.,
in response to message #30 by Tony Duell (UK)

Yes, yes; the 100KHz is not an input signal. It is generated internally and, for sure, what happens inside the black box is irrelevant.

Should we consider this as being the external RAM clock? It's really too slow... As RAM and display share the same bus, they must be synchronized or share the same clock, right?

I still believe there is a way to make this fella talk to the external world in a somewhat easy way. Is it true that HP intended to substitute the HP42 for the HP41? The HP42SX is just rumor or a future xpandable version? If so, as HP have been done all these years, the base for the xpansion might already be inside the calculator.

Is there any I/O terminal available at the former Saturn architecture? How was it accomplished?

HP42S Direct Input
Message #32 Posted by Tony Duell (UK) on 13 Sept 2001, 4:34 p.m.,
in response to message #31 by Vieira, Luiz C.

Looking at the PCB of a very dead HP42S that I pulled to bits, it appears there are a few pins on the CPU chip that aren't used. And some of them are linked to test pads (the little gold pads with no holes, used for the factory tester) so presumably they go somewhere inside the CPU. It is possible that one of these could be an input port line, I don't know. There is also space on the PCB for another ROM chip. In some 17Bs (same PCB, and similar CPU with different firmware) this ROM contains the internatinalisation strings (messages in languages other than English, etc). It is possible that there was going to be a version of the 42S with the ROM fitted, with time functions (the clock hardware is almost certainly present), real I/O, and so on. I would be very suprised if the firmware in a standard 42S CPU chip knew anything about input ports, though. And I for one am not going to attempt to write said extension firmware.

Re: HP42S Direct Input
Message #33 Posted by Andrés C. Rodríguez (Argentina) on 13 Sept 2001, 4:56 p.m.,
in response to message #32 by Tony Duell (UK)

I would assume that CPUS are the same (between the 17B or 27B and the 42S), and just the contents of the ROM define personality of each model. IIRC, in an old article Paul Brogger said that the 27B has an extra component (perhaps a transistor).

I think the CPU, RAM and PCB may be the same, the differences between models would only be the ROM contents (eventually, the presence of an additional ROM), the keys and the legends on the keyboard plate. I don't think the firmware in the CPU (microcode?) should differ.

All of these are just thoughts, I don't have any of these machines to test (again, I will not open my 42S!) nor HP manuals or whatever documents to help.

The fact that there are unused pads or ROM positions in the 42S is no evidence of a 42SX intention, the board may be a generic one for x7B-42S. Since the 48SX and the 42S were introduced at the same time, we may assume that someone at HP decided (wrongly IMHO) which features will *never* be present in the 42S, not to clutter the product line.

Re: HP42S Direct Input
Message #34 Posted by Paul Brogger on 13 Sept 2001, 6:32 p.m.,
in response to message #33 by Andrés C. Rodríguez (Argentina)

As far as HP-42S, -27s, -17B & -17Bii PCBs are concerned, they all looked essentially identical to me. (They have revision numbers, so there must be some subtle differences.)

There is a surface-mount diode soldered to two contacts near the empty 28-pin chip position on the -42s, while the other devices had a transistor soldered nearby, and the diode was absent. (I've only got -42s and -17Bii PCB's available right now, and what I'm calling a "transistor" is a little black block with three soldered contacts.)

I've assumed the componentry differs in accordance with the timer functions implemented only on the non-42s models.

Re: HP42S Direct Input
Message #35 Posted by Tony Duell (UK) on 13 Sept 2001, 7:15 p.m.,
in response to message #34 by Paul Brogger

If this is the area I think you mean, you'll see that 2 of the connections to that 3-terminal 'transistor' are connected together. The resulting pair of leads goes to the ends of that SMD diode you mentioned I think that the 'transistor' is just an SMD diode in a different package (SOT23?) and that which was used in a particular machine was simply a production choice. From the fact that it's also connected to a medium-sized capacitor (the other side of which is grounded), I assumed this was part of the CPU power-on reset circuitry, but I might well be wrong. I don't think it's anything to do with the real-time clock.

Re: HP42S Direct Input
Message #36 Posted by Tony Duell (UK) on 13 Sept 2001, 7:11 p.m.,
in response to message #33 by Andrés C. Rodríguez (Argentina)

There is space on the PCB for a little 3 terminal SMD component, but I think it's just a diode. It's in parallel with another component, which is an SMD diode in a 2 terminal cylindrical package. My guess is that the PCB was designed so that either could be used, depending on which was the easier one to get at the time of manufacture. By 'firmware in the CPU' I didn't mean microcode. The CPU functionality is probably the same on all Pioneers. But the system firmware ROM -- the Saturn machine code that makes the machine behave as a 42S, for example -- is on the same piece of silicon as the CPU logic. The 42S board contains one TAB (Tape Automatic Bonded) package (The CPU + system firmware), an industry-standard 8K*8 static RAM, the 32.768kHz crystal, a few (a very few) passive components, and the IR transmitter LED. While the Saturn itself can handle reading input ports, I doubt that the 42S firmware knows anything about them. One other thing. I mentioned a few 'test pins' brought out to test pads only. A couple of them are next to the pin that links to the IR LED. Now, it's easy to jump to incorrect conclusions, but if HP grouped the pins by function (and often they did...) then it may be that these other pins are I/O port lines too. The hardware for an input port may be mostly present, even if the software/firmware isn't

Re: HP42S Direct Input
Message #37 Posted by Vieira, Luiz C. on 13 Sept 2001, 9:41 p.m.,
in response to message #36 by Tony Duell (UK)

As you have mentioned, Tony, there are some terminals grouped together in the 42's CPU. I do not know Saturn's architecture, but I will try a hunch.

Is it difficult to establish a relationship between used terminals in the 42's board, the equivalent ones used in the 71B and try to get to those not used in the 42?

Just a guess...

Re: HP42S Direct Input
Message #38 Posted by Tony Duell (UK) on 14 Sept 2001, 1:31 p.m.,
in response to message #37 by Vieira, Luiz C.

It's not so much difficult to compare the pinouts of the Saturn CPU in the HP71 with that in the 42S as impossible. The chip in the HP71 is the processor only. The external connections are the power supply, LC clock oscillator, the 4-bit Staturn bus (to link to special HP memory and peripheral devices) and a few input and output lines used to scan the keyboard, control the 6 configuration chains in the 71, operate the beeper, etc. The chip in the HP42S is the processor, firmware ROM, display driver and memory interface to standard ROM and RAM parts. Many of those functions are external on the HP71 (if they exist at all). And we know that even the keyboard interface is very different (it shares pins with the memory address bus in the 42S). Not suprinsingly, therefore, there's no similarity between the chip pinouts in the 2 machines.

Re: HP42S Direct Input
Message #39 Posted by Andrés C. Rodríguez (Argentina) on 14 Sept 2001, 7:30 a.m.,
in response to message #36 by Tony Duell (UK)

Tony: thank you for such detailed and valuable clarifications.

Re: HP42S Direct Input
Message #40 Posted by Raymond Hellstern on 14 Sept 2001, 2:10 a.m.,
in response to message #32 by Tony Duell (UK)


maybe one or two of the 'unused' CPU pins are for the CPU single step (or test) mode.

At least the Clarke chip has three serial I/O paths, of which I don't know if they're all used. Maybe the Lewis has them, too.


Re: HP42S Direct Input
Message #41 Posted by Tony Duell (UK) on 14 Sept 2001, 1:26 p.m.,
in response to message #40 by Raymond Hellstern

Another possibility is that one of the unused pins disables the internal ROM if pulled to one of the supply lines. And allow the thing to run from external ROM only. I don't know.

Re: HP42S Direct Input
Message #42 Posted by Ellis Easley on 18 Sept 2001, 6:42 a.m.,
in response to message #40 by Raymond Hellstern

Three IC pins, connected to nothing but test pads, might be for JTAG. I don't know all the details but JTAG is a way to wiggle all the pins on an IC during factory testing of a PCB assembly to verify they are not open or shorted, without the test programmer needing to know the function of the IC. I first heard of it in the late '80s (back in the 20th century!) As I recall, it needs a test mode pin, a serial input and a clock. The test mode pin switches all the non-JTAG, non-power pins to an internal shift register which is loaded and clocked by the other two pins.

Another reason for JTAG is that some chips need huge numbers of clock cycles to get some pins to switch. I know I have seen chips (without JTAG) that had test mode pins that just changed the division ratio of internal counters to speed up testing.

Also, I have seen some RAM-based PLDs that use the JTAG pins to load the program RAM.

Re: HP-42s -- The INPUT Project!
Message #43 Posted by Vieira, Luiz C. on 10 Sept 2001, 12:51 p.m.,
in response to message #16 by Andrés C. Rodríguez

Another question: would it be necessary a supervision from the operator? One single key lost and part of the process may be lost or even stopped. The key-lost is meant by noise, irregular resistence from the solid state switches, wrong sequence...

Say: an ENTER key lost after an ALPHA entry. ALPHA mode will be enable untill another ALPHA entry is request, which would disable ALPHA mode instead of enabling it, and the next sequence wont work, since ALPHA mode ON is expected. A direct load would avoid it.

I am by no means being against this research. I just believe other options should be considered, just that.

I would open my HP42S to add 32K. By the way, would anyone tell me please where can I find the procedure to do so?


Re: HP-42s -- The INPUT Project!
Message #44 Posted by Andrés C. Rodríguez (Argentina) on 10 Sept 2001, 12:55 p.m.,
in response to message #43 by Vieira, Luiz C.

Luiz: For the 32K upgrade, see previous postings from Paul Brogger and Tony Duell, and also look at the latest aditions at the Articles Forum here at the MoHPC.

Re: HP-42s -- The INPUT Project!
Message #45 Posted by Vieira, Luiz C. on 10 Sept 2001, 1:01 p.m.,
in response to message #44 by Andrés C. Rodríguez (Argentina)

Muchas gratias, Andrés.

Re: HP-42s -- The INPUT Project!
Message #46 Posted by Tony Duell on 10 Sept 2001, 2:20 p.m.,
in response to message #43 by Vieira, Luiz C.

It should be possible to find some way of reading or writing the 8K/32K RAM in a 42S. One obvious way is to add 3-state buffers on all the lines to the RAM chip, and then, with the 42S 'off' (CPU inactive) to disable the CPU's access to the RAM and control it by some external device. Or even to replace the RAM by a true dual ported-part (although 8K*8 dual-ported RAMs are not common IIRC). However, there are a few problems with this approach Firstly, is there any RAM on the CPU chip at all (do we know). If so, what is stored there? We wouldn't have access to that. Secondly, is there any form of checksum on the data in RAM? If so, and stuff is also stored in the CPU, then the situation is pretty much hopeless (you'd have to get the checksum right for the data that's in the external RAM and that in the CPU). If the checksum only applies to stuff in external memory, then you'd be able to make a backup of the machine and restore it, but not edit the backup, load new programs, and so on, without understanding the checksum. Ditton, for any pointers to programs, any global label chain, etc. If you edit program memory directly, you'd have to get that right too. It's not impossible, but it's not trivial either (or at least, it may not be trivial). The 'synthetic keypress' aproach is simple, and may work. We will have to experiment to see if key loss is a problem. Interestingly, the input box for the HP97S is a 'synthetic keyboard' -- it connects to the keyboard scan lines in that machine and simulates keypresses for digit entry. So there is some precedent for this :-)

Re: HP-42s -- The INPUT Project!
Message #47 Posted by Andrés C. Rodríguez (Argentina) on 10 Sept 2001, 5:02 p.m.,
in response to message #46 by Tony Duell

I agree with you 100% about the convenience of the keyboard emulation, which is also generic (applicable to other models).

Just for a comment, in the late 70s, I built some "digital event counters" which, in fact were simple 4 function calculators, with a sequencer circuit (CD4017) which, by means of standard transistors, simulated the pressing of (CLR) (1) (+) (+) (0), initializing the calculator to "add 1" constantly each time an input pulse simulated the pressing of the (=) key. The cost of ICs, display (8 digits!), power supply and plastic case was much more in the case of a "traditional" design using CMOS or TTL parts...

Keyboard simulation
Message #48 Posted by Tony Duell (UK) on 10 Sept 2001, 7:27 p.m.,
in response to message #47 by Andrés C. Rodríguez (Argentina)

IIRC, one of the UK electronics magazines (ETI) published a project to 'convert your calculator into a stopwatch'. It did basically what you described, but there was an extra circuit to press the '=' key once a second, thus giving a seconds timer. I will have to look for that article sometime....

Re: HP-42s -- The INPUT Project!
Message #49 Posted by Ellis Easley on 18 Sept 2001, 7:56 a.m.,
in response to message #43 by Vieira, Luiz C.

One way to improve the reliablity of the automated keypresses would be to find some way to return an acknowledgement to the controller. Human controllers use visual acknowledgement to verify the correct key was successfully pressed. In keeping with the approach being used to press the keys, acknowledgement could be accomplished by monitoring the display driver signals. This could get hairy.

I've noticed that the total amount of light from my LED alarm clock, which produces enough light to illuminate the surface it sits on, changes quite noticeably when the minute changes (some changes result in the same number of segments lit but even then, the variation in LEDs or the distribution of the light produces a noticable change). A light source and detector could be positioned over the calculator display in such a way that the total light reflected from the LCD could be sensed and converted and input to the controller. Then the controller could first measure the reflected light, then "press" the key and then monitor the light sensor until the total light changes. (This doesn't help verify the correct digit is pressed, but I think the matrix approach is reliable enough for that. A robot digit key presser might need better acknowledgment.)

Since only a change needs to be sensed, AC coupling and AGC could be used to increase the sensitivity (such a circuit was described and recommended in the IRDA specification). Allowing a suitable time for the circuit to settle before pressing the key, and assuming enough gain and a schmitt trigger input, only a single bit input to the controller would be required. Another controller output pin would be needed to set the direction of light change to be sensed (increase or decrease) since some keypresses darken new segments (decreasing the light) while some keypresses clear the display (increasing the light). I don't have a 42S but I just pressed a few keys in program mode on my 12C and noticed that every keypress causes the display to blank momentarily. This should be easy to sense.

Re: HP-42s -- The INPUT Project!
Message #50 Posted by Andrés C. Rodríguez (Argentina) on 18 Sept 2001, 3:09 p.m.,
in response to message #49 by Ellis Easley

The same keypress will produce different light variation depending on the context (the HP42 is affected because of menues, alpha input, etc.). I think that an open-loop approach is valid in this case.

For programmatic "output" I would count the TONE pulse train (as described in my article "Calculator Memories from Argentina", in the Memories forum of the MoHPC), or would sense the presence of IR pulses at the LED, even without decoding them.

Re: HP-42s -- The INPUT Project!
Message #51 Posted by Tony Duell (UK) on 18 Sept 2001, 6:07 p.m.,
in response to message #49 by Ellis Easley

Yes, some kind of feedback would be nice, if we can find a way to do it that doesn't involve too much hackery of the 42, and too many extra components. The display in a 42 is a dot matrix LCD, and even though it's got lots of connections, it still must be multiplexed in some way (multiple backplanes). Thus decoding the signals going to the display is decidedly non-trivial, and I'd rather not have to attempt it. I don't think you'd see much from the change in reflected light either -- think of the change to the display when, say, a decimal point is entereed after a few digits. One more pixel on. It's not going to be easy to detect that. As an aside, LED digital clocks have notoriously poorly regulated PSUs (especially if the 'dimmer switch' is in the dim position), so when more segments are turned on, they all get dimmer. This does not apply to LCD displays as used in the HP42, which take very little current anyway. It's a pity there's no way of getting a keyclick from the 42 -- it would be trivial to pick up the signal going to the beeper and detect a pulse there. The IR output is no help for this either. I think the sensible thing to do is to try it as an open-loop system (just simulating keypresses and hoping the calculator gets all of them), and then if we have problems with missed keypresses we have to look for a suitable acknowledgement method.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall