▼
Posts: 896
Threads: 183
Joined: Jul 2005
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?
▼
Posts: 297
Threads: 25
Joined: Nov 2006
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.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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
▼
Posts: 297
Threads: 25
Joined: Nov 2006
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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 896
Threads: 183
Joined: Jul 2005
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.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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?
▼
Posts: 54
Threads: 6
Joined: Sep 2010
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.
▼
Posts: 96
Threads: 20
Joined: Sep 2011
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 John
BTW thanks for the download program - works well
Edited: 9 June 2012, 7:18 a.m.
▼
Posts: 54
Threads: 6
Joined: Sep 2010
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.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Thanks Raymond, looking forward to it!
▼
Posts: 54
Threads: 6
Joined: Sep 2010
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.
Posts: 896
Threads: 183
Joined: Jul 2005
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.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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.
▼
Posts: 774
Threads: 93
Joined: Aug 2005
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.
Cheers.
Diego.
Edited: 9 June 2012, 4:45 p.m.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
A bidirectional USB41 module running at 115200 baud with easy read/write of pages and registers would be HIGHLY welcome.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 1,253
Threads: 117
Joined: Nov 2005
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?
Quote:
With the USB41 there is absolutly no problem - but with the 41CL, I cannot get it right.
Cheers,
ÁM
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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.
Posts: 297
Threads: 25
Joined: Nov 2006
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.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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...
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Geir, that looks very much like a framing/parity issue. Make sure that the data formats on both sided match.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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.
▼
Posts: 54
Threads: 6
Joined: Sep 2010
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 :-)
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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?
▼
Posts: 54
Threads: 6
Joined: Sep 2010
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).
▼
Posts: 896
Threads: 183
Joined: Jul 2005
Success!!
Byte swapping was the key.
Thank you very much :)
Posts: 1,253
Threads: 117
Joined: Nov 2005
Quote:
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.
|