41CL: Linux/Mac connection solution (soon)


My USB41 program is about to get an extension so that you can also use it for bidirectional transfer for the HP-41CL...

BUT; I need a way to send an end-of-file (EOF) character (ascii character 26) from the HP-41. How can this be most easily done from the HP-41CL?


Use YPOKE to write directly to the transmit buffer. It's at I/O port address F.

Edited: 8 June 2012, 2:44 p.m.


Fixed it. I now got transfer going both ways - but, there's a snag.. When I load the Games module to 80C and then do "80C000-0FFF" YEXP, I get something less than the Games module transfered. It's pretty close, but something is wrong. Take a look at the file HERE


It looks like the receiver may be getting overrun. Have you tried a lower data rate? You could also try doing the transfer as a series of smaller blocks. The 41CL blasts out the data at full speed, with no inter-character gaps.


In the WP 34S all transmissions are protected by a checksum. Serial transfers are prone to character loss or corruption even at low baud rates because the receiver hardware does not come with large buffers or built-in checksumming. Relying on delays or very low baud rates to assure correct transmissions is flaky and slow at best.

Hardware handshaking and fast interrupt routines may help but require special cabling. XON/XOFF handshake is another option but requires a special translation to be able to transfer binary data.


I tried BAUD12 (1200) - exactly the same file was produced.

I will try even lower (300) and see what happens.

It does work with small transfers (I did a transfer of the Alpha registers, and that seemed to work just fine).

Has anyone seen similar issue with the Windows program? ...especially taking into account the issues raised by Marcus here.


Hmm... can't set the CL to a Baud rate lower than 1200...

Crap, what to do?

Has anyone had issues with Antti's Python scripts in transferring pages from the CL to a PC?


1) Make sure that you're at TURBO50.

2) If the PC is sending faster than the 41CL can receive, even at 1200 baud, try a small delay between each character sent. At 1200 baud, each character takes about 10 ms, so adding a delay of 10 ms between characters should give you a character rate approximately the same as what 600 baud would give you.

That said, I *think* that I was able to use YIMP at 9600 baud, with no padding, sometime last year.


Hi Raymond, apologies for the slightly OT request, but I believe some 41CL users would really be grateful if you could write a program to "up" transfer from the 41CL to the PC.
Your help would really be appreciated.
Thanks and best regards

BTW thanks for the download program - works well

Edited: 9 June 2012, 7:18 a.m.


I'm actually working on such a program - unsurprisingly called "CLReader" :-)

I have something that *should* work... but doesn't. I'll have to do some more testing to figure out what the problem is.


Thanks Raymond, looking forward to it!


Code posted at github. I just tested it with a PL2303-based USB-Serial adapter, and it was able to transmit a full module (actually, yfnz-1e.rom) at 9600 baud.


The problem is the other way around; Sending from the 41CL to the PC. And now I am getting variable results (it was consistently wrong yesterday - now it's randomly wrong). With the USB41 there is absolutly no problem - but with the 41CL, I cannot get it right.


Geir would you share the "pointers" on how to do it with the USB41? Does it require NoV-64 or it´s also doable without it?? Thanks.


Well, first you plug the USB41 module into the HP-41 (any model) and plug the USB end into the PC, Then you simply fire up THIS SCRIPT on the PC and issue any Printer commant (like PRP "ANYPROG") and the printer output appears in the terminal.


Hi all,

I didn't notice it until now, sorry, but is this USB41 you're using the USB-41 interface module for the 82143A simulation? (just to know if I might be involved -or useful- if this was the case)

Frist thing to note is that USB-41 firmware (in 82143A simulation) is set to 115200bps, and this is by desing (unless you modify the Clonix-P.asm file)

On the other hand, using the "printing" functions to dump pages from CL (or any 41) is going to be in my opinion very slow.

I'm preparing a more specific solution for this purpose which may save a lot of effort, by dedicating two NOP's and a couple of "buffers" for data transfer between PC and 41's

Nonetheless, as a programming exercice, (and funtional tool) your approach looks very interesting.



Edited: 9 June 2012, 4:45 p.m.


A bidirectional USB41 module running at 115200 baud with easy read/write of pages and registers would be HIGHLY welcome.


The baud rate isn't as important as it might look here. WP 34S exchanges data at 9600 baud and the delays are barely noticeable.


It´s not the printing what I can´t get to work, it´s the SENDING of a rom from the CL to the PC. Your quote below seemed to indicate you have it figured out, did I read it wrong?

With the USB41 there is absolutly no problem - but with the 41CL, I cannot get it right.



No - output through Diego's USB41 module works just fine with the script I linked to. But output from a CL via the CL-only serial port does not work. So far, I have only tried transfer from the CL to the PC and not the other way.


Turbo50 is appropriate when the 41CL is receiving, to keep the processing time to a minimum. But when transmitting, if the receiver on the other end is having trouble keeping up, it's best to run the 41CL 1x. This should create gaps between serial characters to help the receiver on the other end.


Thanks for that. With the CL set to 1X Turbo speed I got at least a transfer of exactly 8192 bytes (before it was 8025). But the bytes are still mostly wrong. Debugging further...


Geir, that looks very much like a framing/parity issue. Make sure that the data formats on both sided match.


Right. But as I am on very deep water here (not knowing much about parity/frames, etc), I am considering leaving this and instead waiting for Diego to come up with a bidirectional USB41 module.

I have tried to set parity to NONE, ODD and EVEN - but the results are the same.

I would like to know though if there are any users transferring modules to/from the 41CL using the serial interface - either with Antti's Python script or some Windows solution - and if that is successful or if there are issues also with that. My usual way of transferring modules to/from my 41 is via the PIL-BOX with EMU41 running in dosbox on my PC - rather cumbersome, and that's why I have spent some time trying to do this via Ruby - also because I have been unable to get Antti's Python script to work.

Edited: 9 June 2012, 6:55 p.m.


I did some testing yesterday, mainly to find out whether I had a broken serial cable. On my MacBook Pro, I was able to transfer from the 41CL by doing something like

(stty 9600 cs8 -parenb -cstopb raw; cat) < /dev/cu.PL2303-00002006 > capture.96

where cs8 means 8-bit data, -parenb means no parity, -cstopb means 1 stop bit,and raw means to pass the data through unchanged (instead of mucking about with CR/LF characters etc). I would then run YEXP on the calculator, and hit Ctrl-C on the computer when the calculator finished exporting.

Prior to this, I tested using minicom, but got incorrect results. This was probably because minicom changed the line endings (and possibly also other things), and also stripping away null bytes.

Note that the command above does not do byte-swapping; one possible way of doing this is something like

dd if=infile of=outfile conv=swab

So, to summarize:

Transferring data from the 41CL works fine under OSX at least, but the details of the setup needs to be exactly right. I also found that I needed to do SERINI followed by BAUD96 if the calculator had been power off (still on YFNS 1E, so this may not be necessary on newer units.)

Oh, and this was all at TURBO50 - there is no excuse for a relatively modern computer not to be able to keep up with a 9600 baud serial stream :-)


This seems like an excellent pointer :) I will try debugging some more with your input as a guideline. It may be an issue with LF handling.

One question: Byte swapping - could you explain what this is and why it is needed?


Byte swapping means swapping the odd and even bytes. This is necessary with the CL-41 images, because YIMP expects the bytes in the serial stream to be in a particular order - which happens to be exactly the opposite of their actual order (that was certainly the case for the earlier images, and I strongly suspect that this has not changed).



Byte swapping was the key.

Thank you very much :)


I *think* that I was able to use YIMP at 9600 baud, with no padding

Interesting, maybe I should push the envelope: my standard settings so far are 2400 / 2ms, flawless even if I'm using a USB/Serial convertor too.

Edited: 10 June 2012, 1:23 p.m.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Prime Emulator Connection Problem John Colvin 3 900 12-14-2013, 11:00 PM
Last Post: Han
  [HP-PIRME] BUG Pretty Print, Solution: abs => |...|, ABS => ||...|| CompSystems 2 801 12-13-2013, 09:36 AM
Last Post: CompSystems
  Is Linux common among us RPN types? db (martinez, ca.) 46 5,321 12-11-2013, 08:25 PM
Last Post: Paul Guertin
  HP-41CL setup troubleshooting Xavier A. (Brazil) 2 730 12-02-2013, 06:29 AM
Last Post: Xavier A. (Brazil)
  EMU41; Dosbox on Linux; Excruciatingly sloooow Geir Isene 9 1,263 12-01-2013, 05:10 PM
Last Post: Geir Isene
  HP-Prime firmware update on a Mac Javier Goizueta 5 961 11-15-2013, 10:52 AM
Last Post: Javier Goizueta
  [41CL] New Extra Functions version Monte Dalrymple 0 437 11-08-2013, 04:32 PM
Last Post: Monte Dalrymple
  So, latest 41CL / Library 4 config is... Gene Wright 4 795 09-22-2013, 02:59 AM
Last Post: Ángel Martin
  HP-41CL anyone? Matt Agajanian 8 1,113 08-31-2013, 12:27 AM
Last Post: Sylvain Cote
  [HP-Prime xCAS] Arrays: Programming Commands (solution to the ambiguity) CompSystems 6 953 08-30-2013, 06:32 PM
Last Post: CompSystems

Forum Jump: