HP-41/PC User-Code Transfers and Barcodes


Although I do not have access to HP-IL equipment, I appreciate your posting as a very good introduction to some deep aspects of HP 41 programming and software distribution.

I would like to know how to generate barcodes from a standard HP 41 program code (such as STO 11, XEQ 02, etc.) and numeric or alpha data. I would like to do so without HP-IL accessories, but with a PC in which the programs or data can be keyed manually, for instance, as a text file.

If your posting allows for this, please let me know what pieces and in which order are to be used; if not, please suggest any way you know that may allow for this function. Thank you very much.


My utility does not generate barcode-ready output. But it does generate RAW code, which is compiled user-code.

Pay attention to the program size, as it may not be the same as the generated file size( the file size is always a multiple of 256). The program size is displayed in hex form.

You can use the RAW data as input to your barcode generating program. Read "Creating your own Barcode". Basically, you can write up-to 16 bytes per line: a 3-byte header,plus 13 bytes of code. The 3-byte header is a sequence (row count) and check-sum information. Also, each row has fixed STARTing bars( I think 3), which precede the 16-bytes. Plus there are also some fixed ENDing bars (I think 2 bars). You're basically writing 0 bars and 1 bars.

I may not be correct in all of this, as I'm giving you from memory. But it should be real close.

Also, check the "Articles" section in this forum. DanMcDonald posted an article on generating barcode. Good luck.


HP41 barcode has 2 start bard and 2 stop bars (they are different so that the wand can figure out which way you're scanning).

For the beginner the problems are:

1) how to get the bars to print correctly. The trick is a) having the thick bars twice as wide as the thin bars and the gap between them a fixed (thin bar) width. This is a relatively simple requirement.

b) having the bars print dark enough and with sufficient edge definition. This is child's play these days, but was a real problem with the older Epson FX-80 printers! A note to those that try it. I have made bar code that has 1 pixel wide thin bars (and gaps) and 2 pixel wide thick bars, and used a program like photoshop to blow it up to a reasonable size for printing (makes the stored program small). If you do this, make absolitely sure that the program that blows up the bar code keeps the sharp edges, and doesn't fade them from black to white at the edges. My first try did this, and although seemingly OK to the naked eye, refused to read at all.

c) printing them large enough. Have a look at your favorite PPC issue, or Wlodek's red book for examples of the smallest practical size

d) beware dot gain. Not a huge problem today, but one that was an issue for small bar code on certain dot matrix printers (and lithographic reproduction). The black dots spread slightly wider than they should, widening the bars, and thinning the gaps. The barcode manual gives you the limits for this, but if you're printing on a laser, even at 300 dpi with a HUGE dot gain, you'd never even get close to having to worry. Same for today's inkjets.

2) getting the byte sequence. Well, at least that's been solved :-)

3) creating the checksum byte. From memory it's a 1 byte end around carry checksum, but there are several examples in bar-code printing programs (for the HP41) on the net, or read the manual (And it's a good scan too :-)

4) Calculating the byte containing the count of bytes preceeding/following this row of bar-code. A byte in the header contains 2 4 bit fields that tell the HP41 if an instruction is split across the boundary between one bar row and another. To figure this out, you need to have your bar-code program understand the HP41 byte table. You can fudge this and place $00 in this byte, but if you ever have an unreadable row, you may be left with bytes before and after that are incomplete instructions. This can cause some interesting effects.

5) Pretty printing. Well, we _all_ want it to look nice :-) Again, fairly trivial in windows.

A _really_ easy way of printing barcode is to use MS-WORD to format a text document. The text document might look like this:

(I bet it doesn't format right)

|| | || || | ||...

then you use word to change the horizontal spacing until the vertical bar characters join up (use a fixed font like courier). You may have to use 4 bars for a wide bar, 2 for a narrow, and 2 spaces for a space.

This makes it _really_ easy without going through hoops to create the graphics.

If you're really clever you set up a style for the compressed vertical bars, then you can send the word document to almost anyone. By using a style, the recipient can easily change the horozontal spacing, should it not suit their printer.


Check out my article about generating your own BarCode in the articles section.

I enjoyed reading about the good old days and how difficult it was to create barcode with either plotters ($$$fine tip pens$$$) or dot matrix printers.

But as fun as that all sounded, I made up my own font for windows using a freeware true-type font creator. The font file location is referenced in the article. It would have been a lot easier for me if I had a copy of the "Creating your Own Barcode" book at the time...

I think there are some differences in generating single-key barcode vs. program-length barcode, but pretty minor.

Making this barcode is fun and fast on a PC. Faster certainly, but maybe not quite as much fun as doing it on a pen plotter.

Good luck, and feel free to email me if you have questions about my barcode generating program.



Thank you for all the responses, and please let me ask some simple questions that may be clear for you all, but are not 100% clear for me:

Suppose I have a "standard" HP 41 program, made up with keycodes such as STO, XEQ, RDN, AON, etc. I would like to convert it to barcodes. As far as I have seen (perhaps I missed something), the barcode articles take a "binary" program as input. So my "standard" program has to be converted to "binary" up front.

I assume one way out is to compile by hand using a synthetic programming utility and/or byte opcode table. Other possible answer is to use the "Printing your own Barcode" manual from HP (Is it on the Museum CDs? - I don't have the CDs yet; nor HP-IL components BTW)

Is any of the programs mentioned in the articles able to convert fron "standard" to "binary" programs?

Could it be used as part of a process that convers from "standard" to "binary" and then to barcode in a seamless way?

And, last, how are numeric and alpha strings converted to barcode?

Thank you all again. Andres.


Yes, the program must be in binary. There are many ways to do this:

1) output the binary from the HP41 via RS232 interface

2) output to hpil disk then read on PC

3) capture printout (rs232 again) then use a pc based program to "compile" it.

4) type in program then compile as above

5) hand compile it.

and probably others.

oh yeah! 6) capture output of HP41 IR printer interface (my personal favorite)

There's programs out there that do most of this (capture, compile, print bar code) in bits and pieces. So far I don't think anyone has written a single program to do it all.

I started on some of it, but pressure of work (you know, the stuff that pays the bills) ensured that it's on the back burner.


Check out my article:HP-41/PC User-Code Transfers. My utulity: HP41UC.EXE can, among a few other things, compile user-code(standard HP-41 code, as well as synthetic instructions). There's a link to download.

You edit a file in ASCII form (txt) and compile it to a binary (raw) file:

Example: "prog.txt" is your program. LBL "TEST" RCL 00 ST0 01 RTN END

You run HP41UC from a DOS window:

hp41uc /t=prog.txt /r

HP41UC will display the program size (##) in hex, and create a default output file: prog.raw. The size of the output file will be a multiple of 256-bytes. Try it out, it will be much clearer to you after that.

If you like to reverse the process (de-compile), try:

hp41uc /r=prog.raw /t /s=##

where ## is the size of your program in hex. You may even add line numbers when you de-compile:

hp41uc /r=prog.raw /t /s=## /n

Will create prog.txt as: 01 LBL "TEST" 02 RCL 00 03 STO 01 04 RTN 05 END

Hope this helps.


Why does it write a multiple of 256 bytes?

Why not the actual length of the program?

(Just curiosity)


There's a checksum appended to the program bytes, followed by "filler" (do nothing) trailing bytes. The idea is to make it simpler to use with LIFUTIL(referenced in the article) and eventually to be able to read the program from the "real" calculator. If the checksum is not present, the HP-41 will give you a READ error.

Now that you bring this up, I will add a command-line option to generate RAW files with just the program bytes in it. How about that? I'm also adding a new file format: ".DAT", which is a binary file, like RAW, except that the hex digits are represented in ASCII form. Just like OUTP generates in the calculator with an ExtI/O module. By the way, EMU41, the emulator by J-F Garnier, can read and write programs in this form (ASCII) using INP and OUTP commands.

Another note, the de-compiler does not care about the checksum byte or the "filler" trailing bytes. So, it will work with a stripped-down file (just the program bytes),the only requirement is that you specify the program size in hex. I will add: "/sd=##", to allow the size to be entered with decimal digits. Also, if the size is not specified, I will attempt to use the filesize, and de-compile until I reach an "END" intruction. Look for version 1.10.


The raw option sounds great. It could certainly prevent some of us from having to write our own ;-)

Good job!


i have just come into ownership of the PC-HP IL card, but played at getting the IR module to print to my HP 200LX for code transfer purposes. after playing with it for awhile, i was able to record a data stream on the 200LX, but never successfully decoded it.

could you tell me what program or method you used to capture IR data?


Yeah, sure.

I simply used a photo transistor connected to the input of my sound card. I then found some callable routines for recording sound (I used 44100 samples per second, but you can get away with less). Then I figures out the encoding, and voila!

Actually, it's not anywhere as easy as that. There are a large number of signal processing issues that you come across, but I solved most of those.

I have not looked at the program for some time.

If you want to save yourself a day or so's work, I can try to get a working version to you.

I'm in the middle of moving house at the moment, so email me and I'll try to get one out to as many that ask as soon as I can.

please title the email "HP41 IR" to help me spot it as I get lots of email.


Thank you very much, Steve and Leo

Possibly Related Threads...
Thread Author Replies Views Last Post
  Does the HP Prime really compiles the user programs? CompSystems 3 510 12-13-2013, 01:55 PM
Last Post: Mike Morrow
  HP 50g switching two keys in the user keyboard Sean Freeman 9 778 12-05-2013, 11:44 AM
Last Post: Mark Puscas
  HP-41(CL): The easiest way to transfer FOCAL programs from a Linux PC to the HP-41 Geir Isene 13 1,129 12-05-2013, 02:40 AM
Last Post: Hans Brueggemann
  HP PRIME: APP program code DISAPPEARS !! Joseph Ec 0 214 11-25-2013, 11:35 AM
Last Post: Joseph Ec
  HP Prime - User manual lack bluesun08 6 614 11-08-2013, 05:38 PM
Last Post: bluesun08
  HP PRIME : strange behavior when trying user key capability Damien 12 874 11-03-2013, 11:02 AM
Last Post: Joe Horn
  HP-Prime Polynomials: User Guide and Request CompSystems 4 403 09-30-2013, 09:48 PM
Last Post: Han
  HP Prime Tip: Setting Up User Keys Eddie W. Shore 2 333 09-27-2013, 09:53 PM
Last Post: Eddie W. Shore
  Where to the 32-bit version of User Code Utiltiy for HP-41 ? Olivier (Wa) 2 275 09-26-2013, 01:55 AM
Last Post: Olivier (Wa)
  A HP42S Code Editor Andreas 9 748 09-22-2013, 03:17 AM
Last Post: Andreas

Forum Jump: