HP-75 HP-IL question


I am trying to resurrect an ancient Ludlum counter that uses an HP-IL interface. I'm using an HP-75 as a controller.

I am able to successfuly send commands to the counter via HP-IL using ASSIGNIO and PRINTER IS commands (I know this because I can see that parameters changing) but I don't know how to tell the HP-75 to expect and collect bytes from an HP-IL device. In other words, what is the input equivalent of the PRINTER IS command?

The metacode is something like this:

<ask counter to send count value>
<counter sends a few bytes to HP-IL buffer>
<HP-75 reads bytes and clears buffer>
<repeat ad nauseum>

I'm sure this is simple, but I have no documentation and I'm piecing this together with bits I can glean from the net.

Thanks if you can help.



You probably need to program at a lower level than I/O redirection. Do you have the I/O ROM? it allows you to do more than the base HP-IL implementation will.


Check the I/O Utilities manual (75ioutil.pdf) on the MoHPC web site.
It describes the facilities available on the HPILCMD LEX file

This should allow you to control you HP-IL device. For example the manual shows how to obtain readings from an HP Multimeter.



Those utilities will work. The LEX file contains SENDIO and READIO keywords, which are very low level commands you can use to program HP-IL at the message level. However the I/O ROM is better, if you can get it, because it not only contains improved versioins of those keywords, but a lot of higher level words that allow great power without worrying about the low-level protocol as much. Depending on your application, these may well do the job you want, and with less effort. But the low-level stuff there too, if you need it.


Actually, they are not that different, if all you want to do is control instruments. True the I/O module commands are higher level, but the HPILCMDS commands can be used as macros without really understanding what is going on. E.g. I have this little program that randomly turns on the front panel lights (and associated relays) of an HP59306A relay actuator.

This is the HP-85 version (using the I/O ROM):

and this is the HP-75C version (using the HPILCMDS SENDIO command):


When I ported this program to the HP-75C I expected that I'd only need to change a single line (the one doing the actual I/O). HA!
It is unbelievable how many changes were necessary to move this 20 line program from one machine to another. Especially given that the two machines were nearly contemporary, were made by the same company and were even using the same processor architecture for crying out loud!

So, apart from the I/O statement I had to fix MOD (which is a function on the 75, as opposed to an operator on the 85), VAL$ is called STR$, and FN END is now called END DEF.

Plus, they redefined WAIT, so that instead of milliseconds, it expects seconds on the HP-75C. Surprise!

I am soooo glad I do not have to program these machines for a living :-)


Edited: 28 Aug 2005, 12:45 a.m.



Yeah, I think playing with them is better than work. You get to stop when you get too disgusted!

I just back ported some code from the 71B to the 75C, and I ran into more incompatibilities. (That was made worse by my use of the JPC ROM on the 71, which gives you real structured programming.) Those were the days when HP was creating more standards than they could keep track of. Outside the languages I'm familiar with, BASIC for the 85, 75 and 71, plus RMB, there was HPL, which was a dialect of BASIC running on some of the 98XX machines. There was a BASIC on the 110 and Portable Plus. I'm sure there were many others I
've never heard of.

I would point out that the second example of I/O is a bit more complex than the first. On the 85 you are dealing with HP-IB, and the way you are using it (the normal way) ignores the low level message passing on the bus. It's taken care of for you with the "OUTPUT" statement. That's not the case with the HP-IL example. There you have specified the HP-IL messages to send as controller to achieve communication with your device:

  25 SENDIO 'ra:','unl,ren,lad#';D$

So, you are addressing the device with the name 'ra:' and sending 'unl' which turns off all listeners on the loop. Then you send "ren" which is remote enable, which tells potential listeners that they should accept remote commands, once the become enabled as listeners. Then you send 'lad#' which is the listener address of the guy you are talking to, :ra in this case. This tells the device to start listening for data. Since you set remote mode, that data will consist of commands to execute, rather than data to display or otherwise process. Finally, you send the data itself, in D$.

This all takes some knowledge of the low-level protocol of HP-IL. And you don't need comparable knowledge of HP-IB to get the job done on the 85. The 75 I/O rom provides OUTPUT and ENTER statements that allow you to use the loop in a way that is very similar to how you use the 85, but not exactly:

100 REMOTE ':ra' ! Sends the unt,ren,lad# combination.
110 OUTPUT ':ra',D$ ! Sends the data

Thats more lines, but it's much simpler, too. And it doesn't demand low level knowledge of the protocol.

Sometimes you can't get around using the low level stuff, and then you need knowledge of what messages to send. But that's not such a common case. However, most of the 85 guys I knew, back in the day, were very familiar with the low level workings of HP-IB. I had to get to know that pretty well too, even though I was coding in RMB, which had a very abstract interface to the bus, along with the low level one, of course.

So maybe it's a pipe dream to think you could get away with HP-IL coding on the 75 without learning details of the protocol. But the I/O module gives you choice. In fact, it has an even lower level interface that SENDIO/ENTIO to choose if you wish. It's called SEND, and it lets you compose arbitrary messages and send them on the loop. So instead of using the mnemonics for messages, you use a set of mnemonics for the upper three bits (CMD, IDY, RDY, DATA, END etc.) and an arbitrary bit pattern for the corresponding 8 bits in the message. So two machines with this capability might extend HP-IL in interesting ways, as long as their HP-IL ICs didn't balk! 8)

I just ran across yet another, even lower level interface offered by the I/O ROM. I think this one may be part of the I/O Utilities Pac too. This is RIO/WIO. These words read and write directly to the HP-IL IC's registers. So if your IC doesn't like what you are doing with SEND, you can try some very low level bit banging to coerce it into seeing things your way. 8) This could also be used to implement analyzer mode, where the read and write bits in r0 are both on. That makes the chip stop doing its part in the protocol. It reads the wire, then interrupts the CPU when data shows up. The ISR then must decide how to respond to the data. This is how EMU41 implements its virtual hardware, and also how the DEVIL module does its SCOPE mode. Of course, there's no "ON INTR" in the 75's BASIC, so maybe that wouldn't be possible without a special LEX to implement interrupt handling and ISRs.

Edited: 28 Aug 2005, 2:01 a.m.


Howard Owen wrote:
> there was HPL, which was a dialect of BASIC running on some of the 98XX machines.
Mpouahaha. HPL is as much a dialect of BASIC as English is a dialect of Chinese.

> I would point out that the second example of I/O is a bit more complex than the first. 

I said that the I/O ROM commands were higher level but its OK to use the HPILCMDS commands as macros, ie not to try to understand what is going on, but simply include them in your programs. For simple measurement applications you only need the equivalent of the INPUT and OUTPUT. You can easily write a subroutine or two implementing these two commands and get it over with.

Much easier than trying to find an I/O ROM for the HP-75. One went for more than $100 a couple of weeks ago.

> So maybe it's a pipe dream to think you could get away with HP-IL
> coding on the 75 without learning details of the protocol.

You bet! I had to bring to my desk a bunch of HP manuals and my HP59401 bus analyser to find out why the HP-75C would not make the Relay Actuator actuate any of its relays :-)

It turned out to have been a misunderstanding of the configuration of the HP82169A HP-IL/HP-IB converter, that is a long story.

What can I say, its a hobby, you are supposed to want to know everything about this stuff, its not like you can do something useful with them is it?



What can I say, its a hobby, you are supposed to want to know everything about this stuff, its not like you can do something useful with them is it?

I'm sure some would disagree with that, but not me. 8)

I guess fun is why Mike is doing this. Mike?


Thanks guys! You've done me a big favour:

You've talked me out of ever bothering with doing
ANYTHING with HP-IL. I like it in some ways, but
thought it antiquated and guessed it would be awkward
to use and a hopelessly antiquated pain-in-the-arse.

THANK YOU for confirming my suspicions.

I do wonder WHY people NOW bother with HP-IL instrumentation...

Don W


If you mean "why do people in general use HP-IL, then I think the short answer to your question is "they don't."

Why it was used back in the 1980s is clear. It was an extremely low cost alternative to other systems available. The only thing comparable in cost was RS232, and it had severe problems with varying interpretations of the standard. This was still a probelm in 1985 when I was programming instruments on a 9816.

As far as being ugly, well, have you looked under the hood of your network lately? TCP/IP is complicated. You just never have to think about it much because its details are hidden by multiple layers of fairly mature software. That's the situation with HP-IB nowadays, too. This is the parallel bus that HP invented, and later standardized as IEEE-488. It was a big hit in labs and instrumentation. It was also what HP-IL was patterned on. At a low level, HP-IB looks very much like the fragment of HP-IL you saw above. Today there's a high-speed version of "GPIB" (as National Instruments calls it) called IEEE-488.2. The protocol is still in very widespread use. The biggest difference, other than the speed, is that most people use software from NI called Labview to drive it under Windows. I've never used it, but it's supposed to be a Visual BASIC like environment where you can drag and drop to create a model of your setup. You can then go out and just turn it on. In other words, HP-IB, like TCP/IP, has a layer of software on top of it that hides the lower level details.

HP-IL never got such a layer because it never made the leap into a general standard. This probably has to do with HP not standardizing it like they did HP-IB. Or maybe the economics of hardware caught up with HP-IL so that its cost advantage was no longer attractive. However that was, HP-IL is dead, dead dead.

Which brings us to the question of "why do I use HP-IL? Vassilis put his finger on it. Because I think it's fun. I can well imagine that others might have a different reaction to HP-IL. You seem to have gotten a somewhat different impression. 8) But, the complexity for me is a challenge. Then too, there's the fact that HP-IL is the way a lot of the machines that I also consider to be great fun talk to each other. So something I consider fun (HP-IL) is used to connect machines that I think are fun (HP-41C, HP-75, HP-71) so I can have even more fun with them! The common element there is, of course, sheer misery and desperation. 8)


Hi all. Hi Howard.

I really liked your answer. I wasn't teasing or goading anyone...
I certainly didn't mean to stir anybody up, either.
Well, not much anyway ;-)

Yeah, for it's time HP-IL and (at the time) HP-IB, before it got
picked up and standardized , were really cool "monsters".
I wondered about your background and thought you (and probably
Vassily) were right in the thick of things at that time.
That NI stuff is very smooth...

To me it was an amazing time, with everthing still pretty "raw".
Those were the "good old, bad old" days of computer engineering,
long before that horrid term I.T. was spawned (from the depths of somewhere hot and stinky).

Remember when all those "data clerks" (yes, I know we need them, but...) were in the Electronic Data Processing (EDP) industry?
Now it's I.T. As you guys say over there, "Go Figure..."

Something happened one day when we all blinked ;-)

Anyone who thinks experimenting with HP-IL is WAY COOL with me!

As for me I have my own strange brand of eccentricity.
I am hoping to roll a simple analogue input module for my 41C
and maybe an IR module for it which is a bit faster or just different than the standard one. In my crasier moments I find myself wondering if I should do a module to implement a
logic state analyzer interface for the darn thing...(!)
as I am building a revamped version based loosely on something
I made in 1987 anyway.

I always wondered where the engineers turned experimenters
(or is that the other way around?) hung out on the 'net.
So far I have met a few of you here. Pretty cool...

Best wishes, guys!

Don W


I wrote in another thread about pioneers, and their attitude toward the evolved products of their pioneering. The monks who illuminated manuscripts as a devotional duty would scorn a paperback book. They might even be horrified by it. The same could be said of a watchmaker, seeing cheap quartz crystal driven LED watches being given away in the 1970s, as bait to draw you into a sales pitch for the new department store. And yet, both items, the paperback book and the cheap watch, are marvelous, democratizing miracles. (Well, maybe the paperback is more liberating than the watch.)

The monk never saw a paperback, centuries having elapsed between his cloister and the publishing format. But watchmakers in the 20th century certainly did see their business change when Japan started flooding world markets with cheap and accurate time pieces. But the true change from art to commodity in time-keeping took longer, perhaps on the order of a century. But for us, technology cowboys and girls, we have seen the most astonishing transformation in human history play out in a mere 20 years or so. And our technology was one of the principle driving forces of that change.

But we have to suffer, watching our "toys" being turned into manure scoops. Not only do we cope with the natural, useful, but crass and ungraceful transition from artistic expression by small groups of motivated people, to mass market, lowest-common-denominator
products, but we also are faced with a world that has suddenly drawn in its horns. The crash of 2000 brought an end to unexamined claims of wonderful benefits to be had from just the right piece of software and/or business model. And September 11th, at least in the US, added to the sobering realization that the world wasn't the rosy garden Americans tended to see after the fall of Communism.

So the cautious ones, the actuaries, the managers and so forth, are now in the ascendency in our beloved technical playground. I've tried to show that this is not a unique occurance in history, but it's still painful to watch and live through.

But my real hope is that software will eventually trump all the calcifying calculations of the careful crew. "Thought and code are closely intertwined" I once wrote. That means that ideas still have a fast-track to reality that they never had in the past. Disruptive ideas will emerge. Change will continue to accelerate. None of the underlying conditions that made this true in the late 20th century have changed. The instrumentality of imagination is faster and more powerful every day. The challenges facing us as a global civilization are clearer and more pressing. Thiswill make a difference.

Hallelujah, Amen. 8)


Howard, Vassilis, Don

Wow. Thanks for all the responses. I won't presume to weigh in on the philosphical aspects of your comments, because you all know much more than I do.

Howard, I don't have the I/O module you refer to, all the ROM slots are filled with dummy ROMs.

To answer Howard ("Why is Mike doing this?"): I bought a Ludlum scaler/counter on eBay a while back to run an experiment here in my lab (we're on a budget, just poor university types). The prce was great and the counter works just fine, once you can talke to it. But it has no front panel controls, it was designed ONLY to work via HPIL commands. The manual shows examples of how to run it with an HP-41 via HP-IL, but I didn't have an HP-41 but I did have an HP-75 that a colleague gave me. So I searched on eBay for a few HP-IL cables and eventually made it work (sort of, see next paragraph).

Using PRINTER IS I can send bytes to the device to turn on the high volts, set window sizes and initiate counting. What I can't seem to do is read bytes over HP-IL. The syntax is quite simple, i.e. send a count command, wait for counting to be done, then send a command to initiate the sending of a byte stream back to the HP-75.

Vassilis, thanks for the tip about the HPILCMD.bin file, I have downloaded this multiple times but can't seem to unpack it. My Mac and my PC both think it is MacBinary, but no PDF file results. Maybe it is a different kind of binary file?

Ultimately I will try to control this device via HP-IB, I found an 82169A interface that I am now experimenting with.

Again, thanks for all the help, we'll get it going soon I 'm sure.



The .BIN file is probably the raw bits the 75 needs to have residing in RAM before you can use SENDIO/ENTIO. (It is 'ENTIO', not 'READIO.') To get those bits onto your 75C, you need one of two things. Either an HP-IL disk/tape or other mass storage device onto which you can copy the bits from the PC, or else a copy of those bits on 75C magnetic cards. The former isn't impossible. I outline how I set up my system in an article here at the Museum. ("
HP-IL, Linux and the Internet"

But the easiest way would be to get someone to write the data you need onto cards and mail them to you. I can do that, but I need you to go on eBay and look for the auctions that offer HP-75 magnetic cards. Purchase one package or so. I will send you the cards you need enclosed in the plastic tube they come in. When you get the cards, replace them in the tube with an equal number of blank cards and send them back.

Sound OK?


Ah, right you are. Looking again at the message from Vassilis, the .bin file is the actual code and the manual pages that describe it are in PDF form "75ioutil.pdf".

I do actually have a stack of blank HP-75 ribbon tapes, as it turns out.


What continent are you on? 8)

You should be able to email me through the museum link.


come on guys, HPILCMD is only 1280 BYTES!!!!!

just type them in :-)


(actually I am joking, I do not know how you can enter a LEX file on the HP-75 by just typing in the byte values). I think you need yet another LEX file (kinda chicken and egg situation)

Edited: 29 Aug 2005, 11:36 p.m.


Right. You can do that on the 71B because there's a builtin POKE, albeit a limited one. But the 75 BASIC lacks that facility.

Possibly Related Threads...
Thread Author Replies Views Last Post
  [HP-41][HP-71B][HP-75C/D][HP-IL] Found a mother-lode of programs on ftp.stak.tk rdj 2 552 11-26-2013, 05:31 PM
Last Post: rdj
  How to move lexfiles from PC to 71 w/o HP-IL? Joe Horn 9 994 10-18-2013, 03:50 PM
Last Post: Christoph Giesselink
  Hand Held Products RS232 to HP-IL aj04062 11 1,075 08-31-2013, 07:12 PM
Last Post: Paul Berger (Canada)
  HP IL over wifi ... (ILPer & go71b) Olivier De Smet 12 1,293 08-20-2013, 05:44 AM
Last Post: Olivier De Smet
  Virtual HP-IL Video Interface ILVideo the 2nd! Christoph Giesselink 3 515 08-15-2013, 06:49 PM
Last Post: Sylvain Cote
  Trouble with RS-232/HP-IL Interface (HP 82164A) Hans Holzach 9 894 01-08-2013, 01:52 AM
Last Post: Marcus von Cube, Germany
  HP 75 Assembly Language Michael Fehlhammer 7 712 10-01-2012, 08:32 AM
Last Post: Michael Fehlhammer
  Virtual HP-IL 40 col. video interface simulation Christoph Giesselink 10 963 08-19-2012, 06:46 PM
Last Post: Richard Wagoner
  hp-il/hp-ib interface 82169A vs. C Hans Holzach 5 546 07-12-2012, 03:28 PM
Last Post: J-F Garnier
  HP-IL beginners question John Abbott (S. Africa) 4 531 05-28-2012, 05:45 PM
Last Post: Geoff Quickfall

Forum Jump: