HP Forums

Full Version: HP42S Input Project Status Report
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

As promised, some results of my investigations. I have an old HP42S with a piece of 20 way ribbon cable soldered to it. The connections I've brought out are Battery +ve (2 wires), Ground (2 wires), the other side of the Exit/On key (one side is battery +ve), the 6 key column lines nad the 7 key row lines. That leaves 2 unused wires. The end of the cable carries a 20 pin IDC header socket.
This plugs into a piece of stripboard containing 2 4051 CMOS analogue mux chips and 2 quad optoisolators. One mux is connected to the 7 row lines (input 0 is not connected and I take the row nearest the display as 1). The other mux is connected to the 6 column lines (inputs 0 and 7 not used, column 1 is on the left)
The common terminals of the muxes are linked by a 47K resistor, to replace the resistance of the HP keyboard.
The inhibit inputs of the muxes are linked, pulled high by a 100K resistor (to battery +ve) and low by one section of the optoisolators. Tunring on the LED of that optoisolator enables the muxes and simulates a keypress.
The select (address) inputs of the muxes are simlarly pulled high by 6 more 100K resistors (3 inputs on each mux) and low by 6 more sections of the optoisolators. Finally the last section of the optoisolators has its collector connected to battery +ve and its emitter connected to the Exit/On key line by a 10k resistor.
The LEDs of the optoisolators are wired to another plug on the stripnboard. All the anodes to 2 of the pins in parallel, the cathodes to the remaining 8 pin via 330R resistors (8 off).
So I have 8 inputs that I can externally pull low to turn on the LEDs. 3 of them select the column of the key (low = 0, 3 bit binary code from 001 to 110). 3 select the row of the key (similar 3 bit code, low = 0, from 001 to 111). One causes the circuit to simulate that keypress when it's low. The last one simulates pressing the Exit/On key when low.
The circuitry on this board (the muxes and the transistor sides of the optoisolators) runs off the calculator batteries. The LEDs in the optoisolators are powered by an external supply (which will eventually also power a computer interface -- for the moment I'm using my bench PSU set to 5V for this). And as I've not built (or even designed) the computer interface, I am controlling the LEDs by wires stuck into a plugblock breadboard).
The good news is that it seems to work fine. I can select one of the 'keys' and press it. I can turn the machine on and off via the interface too. My next job is to design a nice, general-purpose computer interface for it and attempt to automatically control the 42S.

Tony: Congratulations!!

I'm happy that the ideas we were discussing were right!

For the computer-side interface, you may try to find an old article on Circuit Cellar Ink or its succesor (Microelectronics?, not sure about the title), in which a serial interface board was used for a simple I/O board: remove the UART chip, and use the data lines arriving to the UART socket to drive the optoisolators. Perhaps some extra work is needed to make the pulses long enough, but after that, any programming language is good for easily sending a byte (keycode) to a serial port...

Of course, a parallel port adapter may work without ever opening the PC case, but the interface must at least accept the STROBE to latch the data, and generate an ACK back to the PC; also it must take care of the PAPER OUT and other status lines.

I would put a hardware timer on the interface, to be sure the keypresses are not very short, nor long enough to cause a NULL on the HP42... Also we must be sure that the pauses between keypresses are long enough.

I was a promoter of the back-to-back muxes design, but I note now that multikey sequences (machine reset, master clear and diagnostics) are not possible with this approach :-)

You've read my mind :-). I've designed many things to connect to PC parallel ports and pretent to be printers, so I know what to do with the status lines. I was planning on latching/buffering the data, and using a little state machine to generate a key-press pulse and to drive the busy signal. You don't actually need the Acknowledge signal unless you
have an interrupt-driven parallel port (I don't do that on my PC). It's just a matter of designing the thing -- something that's no trouble for me (I've designed things a lot more complex than this) and soldering it up...
As regards the multiple-keypress sequences, you can't do the hard reset, because that involves pressing 2 normal keys and On/Exit at the same time. But you can do all the others (one normal key and On/Exit) because On/Exit is a special key not in the matrix. So you can drive the debugger, diagnostics, etc.
In any case, the main reason for building this thing is to download programs into the 42S, which doesn't depend on being able to press several normal keys at once.

Tony:

Keep in mind that, at least in the Windows environment, it is not easy to send arbitrary bytes to the parallel port. The printer drivers take care of any control codes (below 20 hex), even the "generic text" driver masks (filters) any non-printable characters.

I found this out last year, trying to drive a thermal printer from Windows. The thermal ticket printer has a lot of functions like graphics, barcodes, etc, which are activated sending special escape sequences. Since a Windows driver was not available, I was not able to access such functions. (I found a way to "hack" it, but that is another story)

So, our options are:

a1) Restrict the codes to printable characters... this may need clever use of the possible codes (*), or

a2) Same as a1) but using a EPROM to translate some codes into others...

b) Write a Windows printer driver

c) Use a serial port (even without "serial" hardware!)

d) Avoid the Windows environment

The option a1) marked with an asterisk seems the most convenient from my point of view...

I'll do (d) :-). I don't run Windows at all (I think I have an old version for my HP150, but that hardly counts). I know for a fact that the linux printer driver will send
any byte to the parallel port, because I've used it to drive an HP41 barcode simulator (links to the hybrid circuit in an HP41 wand and lets you download programs from a PC to a 41 without needing HPIL).
The parallel port is easier than the serial port for this sort of project because there's a handshake on each character (in other words, the PC outputs a strobe pulse, the peripheral assertes BUSY, the PC then doesn't send any more characters until BUSY is deasserted). So you can handle one character at a time. On serial ports, even with hardware handshaking, I've had problems with
machines (not necessarily PCs) that output a few more characters after the handshake line is deasserted, thus meaning you have to have a multi-character buffer in the peripheral.

If you are (bless you) trying Linux, are you aware of TCL/TK? Every C++ resource to access any PC hardware can be acomplished by using TCL/TK on a Linux environment. In fact, Windows environment also has a WISH (WIndow SHell) version. The clue is writting the low level hardwork on C++ routines and all high-level resources on TCL/TK. Even the code translation.

I have some stuff about TCL/TK, if you want so.

Gee, what a mind job you got here...

Yes, I'll use linux, it's all I have :-) (not strictly true, but linux on a PC is the platform that others are most likely to have (as opposed, say to POS on a PERQ 2) so that's what I tend to use for projects like this.
As regards TK/TCL, I've heard of it, but never really used it. I don't think it'll be a lot of help for this project, though. I intend to make the hardware appear exactly like a printer to the PC, so I can use the standard lp driver. Then all I need to do is write a filter to convert some suitable input format into keypress-bytes for the HP42 interface. And yes, it'll be a filter, reading input from stdin, and writing the translated bytes to stdout. Most of my programs are written that way -- I much prefer that to a 'user friendly' interface...
I'v had some thoughts on the PC interface design and think I can do it in half a dozen common TTL chips, although I've not had time to actually build and test it yet. When I do, and have got it working, I'll release all the info (schematics, program source, etc) so others can play about with it, modify it, and so on. Just don't expect it to happen very soon :-)

O.K.

When I mentioned TCL/TK, I really thought about a user-friendly interface; in fact, when I write my own programs, I prefer using a direct, less-intuitive input (say: PRGM_NAME DTA1 DTA2 <ENTER>, as in many programs). I just sometimes forget the way data must be input, and I am always thanked to others that build graphics interfaces ;-)

Please, share with us as you get time to... I still will delve into the direct I/O, as far as I can go. If I find something, I'm also sharing.

Good luck.