HP Forums

Full Version: HP-82164A
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I want to use the 82164A RS232C interface to connect my 41CX to my PC and up/download programs. The idea is to edit them on the PC and then Download into the 41.

I am interested if any one knows if there is software (both ends) and/or other useful instructions on how to do this.

Alex

Yes, it's possible. I've done it, using an HP41CV, and I see no reason why a CX wouldn't work.
You need an Extended I/O ROM in the 41 -- the necessary functions are not in
the HPIL Development (DEVIL) or XIL ROMs as far as I know. The Extended I/O ROM
has 2 functions OUTP and INP that will transfer a program in hexadecimal format (using printable ASCII characters) to any
HPIL device, such as the 82164.
I don't know what OS you're running on the PC, but the software I've written for the PC end runs under linux. You can
get it (as C source) from the hpcc web site, it's part of the LIF utilities for linux distribution.
It's released under the GPL, so you're welcome to try porting it to other operating systems (the 2 programs in question won't be that hard to port).
These programs turn the HP41 hex transfer into a binary program file (essentially the bytes that would be stored in user memory for that program), but there's also
a program in the distribution to produce a printable listing of an HP41 binary program. I've not written the reverse of that program (a 'user code compiler') because I've never needed it, but I am told that my binary format is the same as the .raw format used by MS-DOS HP41 tools, so you might try that program.
Alternatively, if you want to try writing your own software, then my C source contains a description of the HP41 hex format, something that's missed out of the user manuals

Hi Tony-

For your instructions on this site, did you make the "signal adapter" external to the 82164, or did you open it up, remove the jumper block, and make the connections there?

I use WindowsME (though I LIKE linux). Isn't it true that I ought to be able to use a terminal emulation program that has text capture to get the transfer if the inp and outp commands send PRINTABLE ASCII?

Have you ever tried transferring files with just a simple 3-wire cable and software handshake (XON,XOFF)?

I'll try finding a BASIC compiler (I wonder if there's a GNU one out there), and compile your inp41 and outp41 programs and try them on WindowsME.

Thanks for your help!

-Mike

To answer your questions in order : I made an external adapter for the 82164. I used one of those little
boxes that take a DB connector at each end (the sort of thing that's used for null-modem adapters, etc). The jumper plug inside the 82164 is left in the DTE position.
I find the only sane way to use the 82164 is to leave that jumper in the DTE position and make a cable up for each application I have for the interface. It's easier than having to open up the unit, set the jumper and find a cable with the right connectors.
INP and OUTP do, indeed, just use printable ASCII characters. 0-9 and A-F only. They never send CR or LF, for example. And INP will complain (and abort the transfer) if you put spaces, or CRs or LFs or anything else in the data stream. This is one thing I don't like about these functions.
I have never tried to use a terminal emulator to do the transfer, but it should work.
I have also never tried to use a 3 wire cable and software handshaking. I use the same hardware to transfer files to/from the HP71, and that machine sends 'binary', not printable ascii, so I can't use software handshaking there. But for the HP41 it should work if the 82164 is configured for it.
And I am not sure what you want a BASIC compiler for. I wrote the PC (linux) programs in C, and GNU C will, indeed, compile them. You will have to fiddle the I/O side for other OSes, of course.

this will be just about useless, but may inspire some hope.

when i bought my 82164A, i tested it with a 41CX w/ an 82160A on one side, and my 200LX using the serial cable on the other. as i recall, i used a print function to send programs from the 41CX extended memory to the 200LX which was running the built in terminal program. i could capture the program into a text file.

always meant to see if i could send programs the other way, but haven't pursued it to date. if you like, i could hook the stuff up again and be more specific about the transfer to the 200LX (which is just a DOS PC). if there are any tricks to send programs and data the other way, i'd like to know myself. my original purpose was to send programs in text format to an emulator on the 200LX.

AFAIK there is no 'inverse' to the PRP function in any of the HP (or other) ROM modules for the HP41. There is no way to read in a program listing from
an interface (such as the 82164) and store it in program memory.
The functions built-in to the HPIL module will load and save programs to mass storage devices (82161 tape, 9114 disk) only. PRP will list a program to a interface (or to a printer), but there's no way of doing the opposite.
The extended I/O ROM has 2 functions INP and OUTP that will transfer a program to an interface. They do this in a hex form using the printable characters 0-9 and A-F. This is a representation of the actual bytes
stored in the HP41 program memory, so things like synthetic programming instructions are handled correctly. The actual format of the hex information is not documented anywhere that I can find, but it's not hard to work out (or ask me, or look at the comments in my lifutils-for-linux source).
AFAIK that's the only 'official' way to load an HP41 program over HPIL from anything other than an mass storage device. Doubtless it's possible to do something clever with synthetic programming (read in a byte and directly write it to program memory), but I've never tried it and don't think
I am going to do so anytime soon.

An update, and thanks to those who have responded so far.

I'm using Windows-ME, so I've been working on trying in ME Tony's serial port instructions (given in the software section of hpmuseum.org). I wired my "adapter" as he specified and I successfully compiled his C-program using gcc from the Cygnus distribution (www.cygwin.com). I figured I'd use cygwin, because it would allow me to use his program "as-is," because it adds unix-like capability to Windows.

I then tried using stty to set the com1 port as he indicated, but realized that Windows does not allow direct access of the port. Hence, I was unable to set raw crtrts mode.

Because I'm not a C-programmer [yet! :) I write Verilog for IC design], I've tried to come up with ways that would allow me to get the data from the HP41 without programming. I looked for off-the-shelf programs that would help. www.windmill.com has a commdebug program, but that didn't quite help either, though they have some great stuff.

I've now started to look for C-source code examples for using the windows API to access the port, and have found some stuff: http://www.cpcug.org/user/clemenzi/technical/Languages/SerialIO.htm and more. It's quite new to me as a non-C-programmer, but I think I can figure it out. C seems quite similar to verilog.

Anyway, I'm thinking in the short-run that I'll temporarily "bag" the hardware handshaking mode, re-wire the cable adapter to loopback the control signals on each side, cross the TXD and RXD signals (DTE to DTE) and see if I can just get hyperterminal to work with software handshaking (Xon,Xoff).

I'll post updates as I have a chance. If anybody else has already easily transferred programs using the 82164A and Windows (95,98,ME), please let us know!


-Mike

I don't use Windows at all (never have, hopefully never will have to!), but I can tell you what the
'raw' and 'crtscts' options to stty do in linux. 'raw' mode is sometimes
called 'binary' mode in other OSes -- it means that characters won't be translated (e.g. carriage returns will not be added before linefeeds). This option is not
necessary for the HP41 INP/OUTP programs since they only use printable ascii characters anyway. The crtscts mode is known
as 'hardware handshaking' on other OSes. It means that the PC will stop sending if the CTS input is deasserted, and that the PC will deassert RTS (so the remote device should stop sending) if the PC's buffer
gets full. In practice the latter never happens on fast-ish PCs. So all you need to do is find a way to make the PC stop sending if
CTS is deasserted. Surely that's possible -- even MS-DOS managed to get that right :-). Oh, and for what it's worth,
I'm not a programmer either. I only write code when I have to do so to support my
hardware projects....

Well, it turns out that communications between an HP41 (or other HP-IL talker) and a Windows-based PC can be VERY easy!
Just connect the HP-82164A to a DB25F to DB9F adapter (Radio Shack Part #950-0275) and Null Modem (Radio Shack Part #26-264) and then to the 9pin COM port of the PC.

Use Hilgraeve's Hyperterminal (that comes with Windows or download the free and updated Personal Edition v6.1 or newer which has some corrections for direct-to-COM-port connections). Choose 9600baud, 8 data bits, No parity, 1 stop bit and hardware handshaking. The HP-82164A's defaults match this from power-up.

With all of this setup and running, all one has to do to send a program from the HP41 to the PC is execute the command PRP and give the program name. If the HP41 "complains" that there is no printer, execute MANIO first.
This works wonderfully for printing out a text version of a program to the PC, and one does NOT have to have an EXTENDED I/O module. One does NOT need the Extended I/O module in this case, because one does not have to send any "REMOTE" mode commands to the 82164 (and thereby get "stuck" in remote mode), because the hardware settings and handshaking defaults are correct!

One can then use the hp41uc.exe program (http://doc.hp41.org/Doc/HP41/Download/Hp41uc.zip) to "compile" the program on the PC. The two drawbacks are that one cannot send a program from the PC to the HP41 this way, nor can one necessarily output a program that contains "synthetics" to the PC (as Tony has already mentioned). If you have a wand, the first problem isn't so bad, because you can use that same hp41uc program to print out your programs in barcode and then scan them into the '41 to go the other way.

If one is lucky enough to have an Extended I/O module, then both problems are solved, because one can use the OUTP and INP commands to send and received programs from/to the HP41.
Again, the hp41uc program can be used to compile and decompile the results.

Hope this helps everyone else out. It turns out that my original difficulties in getting this "simple" communications to work was that my first cable had a bad wire!

-Mike

p.s. I've got another related problem, but I'll add it to another response in this thread.

I hope my previous post in this thread can be used as a reference to help others easily transfer files between an HP41 and a Windows-based PC.

Now I have another, but related problem: I said my instructions worked beautifully on my PC. That is true - it is a SONY laptop. However, when I try the same thing on my father's desktop computer (with a TAIWANESE motherboard), it does NOT work.

What I notice is that the CTS and DTR signals on his computer "idle" (logic 0) at about 12V, instead of about 7V as do the HP82165A and my SONY. The levels seem well within the RS232C thresholds. I don't have an oscilloscope nor logic analyzer to do more useful measurements, but I'm wondering what the deal is?!

Does anybody have any thoughts?

What about using a USB-to-RS232C adapter? Could I add another port to my father's computer that way as a means to get a more up-to-date com port? Do these USB-to-RS232C adapters support hardware handshaking? CTS/RTS, DTR/DSR, etc?

-Mike

I assume you meant to say 82164. The 82615 is the GPIO interface, and works at TTL levels. If you've applied 7V to that unit you'll have cooked some
chips.... Anyway, back to the 82164 RS232 interface. Let's look at the RS232 port on it :
It uses the well-known 1488 driver and 1489 receiver. The latter will work with just about any
RS232 compatible voltages. The former is run at +/-9V in the 82164 (these voltages are produced by stepping up the
AC output of the mains adapter with a little transformer, rectifying, smoothing and regulating the result). So the output voltage of the 82164 should be a little less than 9V. Your 7V measurement sounds fine,
but if you want you can measure the voltage on pin 1 (-9V) and 14 (+9V) of the 1488 driver chip inside the
82164. This is the 'horizontal' chip near the RS232 connector. For the ground reference, use either pin 7 of the same chip, or the heatsink.
When I was testing my 82164 to work out just what all the handshake options did, I used a breakout box that put 12V on the inputs, and as I expected (from the data I have on the the 1489), it worked fine.
So I really don't think that's the problem. I wonder if your PC has some kind of noise filtering
on the RS232 port (to meet the FCC rules) that is corrupting the data. There's no obvious reason why the 82164 would object to this (no internal termination resistors, or anything), but I've seen this happen with other devices.
Can you try reducing the baud rate (say to 1200 baud) and see what happens.
Also, what are the exact symptoms? Doesn't work at all (complains about handshake problems)? Corrupted data? What?
I've never tried a USB RS232 adapter (heck, I don't have a machine that could take a USB port), but I can confirm that my 82164 works fine with my desktop
PC (1488 driver, 1489 receiver, 12V output voltage).

Well, I can put this issue to bed now: I bought a USB-to-RS232 adapter cable with active electronics, of course, and that did the trick! So something about the "native" RS232 ports on my father's computer are just enough different so that it won't work with the HP-82164A, even though those ports work for his Palm Pilot and Digital Camera. Odd! Perhaps it is some sort of noise filtering that Tony mentioned.

Anyway,
I'm taking this way out for now, but someday may go back and analyze the problem with an oscilloscope if I can borrow one or buy one from ebay. But we're both happy for now!
And the instructions that I posted two posts back worked exactly the same now for my father's computer with this usb-to-rs232 adapter as they did for my Sony laptop.

I guess this is the difference between me and the average user. If I had
a hardware problem with a serial port like that, I'd not go to bed (seriously) until at least I understood what was going on, and preferably had fixed it.

I can sympathize with such sentiments, Tony, but my time is far more valuable to me right now while I'm working than the money is! I'll therefore spend the money to solve a problem simply so that I can concentrate on "bigger" and more-fun-to-me problems.
Plus, his ports work for other things so I followed the adage: If it ain't [fully] broken, don't fix it." (Note that I twisted this adage, because one could argue that it is "broken." ;)

Anyway, I thank you for your help and I continue to enjoy your posts, in particular, because you have taken the time to solve so many problems that you are able to give so many people good advice based on experience. I tend to look specifically for your posts to topics just to see what you have to say and note that you have a good record for solving the issues. (The module contacts problem is one that comes immediately to mind as a recent example.)
Hence, I think you are right when you say that that separates you from the average user!

Cheers!
-Mike

Oh, it's not the money. It sometimes costs me more to fix something than to buy a replacement. I guess I just enjoy fixinig things :-)
As regards the serial ports, my experience suggests that 'marginal' hardware will come and 'bite' you one day. It'll fail, probably at a very inconvenient time. That's why I always
invetigate hardware problems, so I know if it's a design issue, a failing component, or what. Then I can fix or modify it as appropriate.
I'm glad you enjoy my posts here, I'll carry on posting, then :-). As regards that HP41 module problem, I've been inside enough HP41s to know that this is a stock fault (IMHO it's a piece of
somewhat marginal design), so it was worth suggesting it. And as regards some other problems, I've had to learn to fix my own machines -- and fix them properly by understanding the fault and curing it, not swapping parts until it seems to work again -- so
I don't mind sharing what I've discovered. In almost all cases the fixes were discovered by pulling machines into rather more parts than the manufactuerer intended :-)

If I was to be stranded on a desert island with just one oscilloscope I would probably choose a Tektronix 475 (or 475A). It is very reliable and probably the best general purpose analog scope ever made. You can find them on Ebay for anywhere from 50 to 400 dollars depending upon the condition, probes, accessories offered, etc. You shouldn't have much trouble finding a nice fully equiped one for 200 bucks.

Thanks, David, for the idea about the 475. I haved used one before and it worked quite nicely. And $200.00 wouldn't be too bad.

I have seen those Tektronix TDS720 (I think that's the number) "handheld" units which seem really neat, and the Fluke 190-series Scopemeters and the really cool Tektronix TDS3000-series (trying to remember the numbers correctly here) with the "digital phosphor". I was trying to debate saving up for one of these "toys," but they do seem a bit expensive yet...

Maybe the 475 would hold me over (and in fact be better in some cases, because it is analog)...
In any case, because I keep putting off getting a scope, I don't get to the root of the problems as Tony has mentioned. And, perhaps, by buying replacements, I end up spending what I could have gotten an inexpensive scope for!
Hmmmm....

I know a guy who bought a lot of four Tek 475's on Ebay for less than $100 (with probes!). They were local and he didn't even need to pay shipping. They were supposedly dead. The problem... the power line voltage selectors were set to 220V. Some guys have all the luck... he resold them for $300-$400 bucks a copy.