Can a HP 42S print to a HP 48G or a to PC?

The Museum of HP Calculators

HP Forum Archive 15

Can a HP 42S print to a HP 48G or a to PC?
Message #1 Posted by Marcus von Cube on 23 Apr 2005, 3:24 p.m.

I don't have an IR printer from HP but I want to send program listings or data from my HP 42S to a PC. Can my HP 48G be of any help as intermediate storage?
I'm looking for some software to capture the IR output and convert it to an ASCII file.
Has anybody written code for a PC to decode the IR stream? I'm aware of the Article "IR Printer information" on this site.

INPRT is the capturing prgm (was: Can a HP 42S print to a HP 48G or a to PC?)
Message #2 Posted by Vieira, Luiz C. (Brazil) on 23 Apr 2005, 5:01 p.m.,
in response to message #1 by Marcus von Cube

Hi, Marcus;
'inprt' was first release by HP in a SW package with the HP48S connection kit (cable + disks). There is a version that runs with the G-series, and it is available through www.hpcalc.org. After a search I found this.
Jordi Hidalgo's version is a very good choice.
Cheers.
Luiz (Brazil)

Re: INPRT is the capturing prgm (was: Can a HP 42S print to a HP 48G or a to PC?)
Message #3 Posted by Marcus von Cube on 23 Apr 2005, 6:35 p.m.,
in response to message #2 by Vieira, Luiz C. (Brazil)

Thanks for the tip, I just tried it out. It's not quite perfect yet...
1) After installation of the lib, I started the INPRT program on the HP 48.
2) I aligned the two calcs
3) I LISTed my program on the HP 42S
4) On the HP 48, I stored the resulting string in a variable
5) I transfered the variable to my PC with Transfile WIN 48
What I got is a file with an identifying tag at the beginning (added by Transfile?) and the program lines (with some garbage in between, transmission errors?). The lines are seperated by HEX(04) instead of CR/LF.
The main problem seems to be the garbage. I assume that's an alignment problem. The translation can be done with a small script (I prefer REXX but this is a personal preference.)

Re: INPRT is the capturing prgm (was: Can a HP 42S print to a HP 48G or a to PC?)
Message #4 Posted by Vieira, Luiz C. (Brazil) on 23 Apr 2005, 9:45 p.m.,
in response to message #3 by Marcus von Cube

Hi, Marcus;
there is an article writen by Jordi about the translation of some codes (remapping) that occurs when the HP42S is sending data to the printer. I don't thave the link, all I know is that it is available at HPCC.
I had some 'issues' when creating the HP42S TTF mainly because of this fact, too. I also had to replace some characters for others after transfering data from the HP42S to the HP48. As an example of what I faced when creating the TTF file, both up-arrow and down-arrow characters in the HP42S LCD are sent as '^' and 'v' to the printer (82240A or B), and you see R^ for roll-up and Rv for roll-down in the hardcopy. I am not quite sure about the reasons, but I guess it is because of the two versions of the HP82240.
Maybe you already know about this, but it is harmless to mention, right? ;-) The HP82240B accepts codes to be 'interpreted' amongst two sets of characters, ROMAN8 and ECMA94. The 'ASCII' range (32₁₀ to 127₁₀) of them both is the same, but characters from 128₁₀ to 255₁₀ match in only a few cases. Codes 144₁₀ and 145₁₀ are, respectively, up- and down-arrow in ECMA94, but they are 'µ' (micron) and 'LF' (line-feed symbol) in ROMAN8, respectivey. So, it was wise to use '^' and 'v' instead, that works the same for both printers. There are also other characters that were remapped, but I don't recall them by heart.
About alignment: I keep the HP42S about 1/3 of an inch higher than the HP48 when transmitting. I experienced some problems wehn both were leveled.
Hope this helps a bit.
Cheers.
Luiz (Brazil)

Re: INPRT is the capturing prgm (was: Can a HP 42S print to a HP 48G or a to PC?)
Message #5 Posted by James M. Prange (Michigan) on 24 Apr 2005, 12:08 a.m.,
in response to message #3 by Marcus von Cube

Quote:
3) I LISTed my program on the HP 42S
I'm not familiar with the 42S, but I do have the manual on the Museum DVD. It looks like it uses a pretty strange character set. I hope that you've read the printing topic in it.

Quote:
4) On the HP 48, I stored the resulting string in a variable
Right. You may want to recall the string to the stack, and then edit it just to get a look at what INPRT received, before any changes that transferring it to the PC may cause.

Quote:
5) I transfered the variable to my PC with Transfile WIN 48
What I got is a file with an identifying tag at the beginning (added by Transfile?)
I'm not familiar with Transfile; is it Kermit-based or Xmodem-based?
Anyway, Kermit transfers can be either "ASCII" or "Binary", determined by system flag -35 on the 48. Xmodem transfer are Binary only.
Kermit ASCII transfers start with a header similar to:
%%HP: T(3)A(R)F(.);
by itself on the first line. The decompiled, and optionally translated, form of the object follows the header starting on the next line.
the T(n) parameter may be of interest to you. It records the translation mode for non-ASCII characters, the "\" character, and the LineFeed code. See your HP 48 manual for details.
Binary transfers from the 48 series start with a header of:
HPHP48-x
where x represents the ROM version. The compiled object immediately follows the binary header. For a character string, the compiled object starts with a 5-nibble prologue, followed by a 5-nibble length field, and finally, the characters in the string.
What it boils down to for a binary transfer of a character string is: Delete the first 13 bytes in the file, and the remainder should be the original character string.

Quote:
and the program lines (with some garbage in between, transmission errors?).
I don't know. Are all of the expected program lines present and complete?

Quote:
The lines are seperated by HEX(04) instead of CR/LF.
That makes sense. The 82240 printers use that as an "alternate Line Feed"; it prints the characters in the buffer and leaves the print head at the right margin. I don't know whether it will help you, but also see the HP H2240B Infrared Printer Technical Interfacing Guide
Regards,
James

Re: INPRT is the capturing prgm (was: Can a HP 42S print to a HP 48G or a to PC?)
Message #6 Posted by Marcus von Cube on 24 Apr 2005, 8:12 a.m.,
in response to message #5 by James M. Prange (Michigan)

Thank you both for the information provided.
The garbage (and some missing lines) resulted from not levelling the two calcs correctly. I was keeping the 42 in my hands, lifting it slightly, but I may have shaken it too much so that data was lost (I got "1" as the result code on the 48).
Transfile seems to use Kermit-ASCII transfer with the %HP header. That (and the HEX(04) / EOT problem has obviously to be solved by some software.
["Transfile WIN 48" looks a little like good old Norton commander for Windows 3.x, with one panel showing a local directory and the other showing the calculator "file" system.]
Has anyboy written software to capture the IR output on a PC (e. g. with a sound card)?

Printing from 42S to PC via sound card
Message #7 Posted by Andrés C. Rodríguez (Argentina) on 24 Apr 2005, 12:04 p.m.,
in response to message #6 by Marcus von Cube

Look for an excellent article written many years ago by "Steve (Australia)" in the MoHPC Archives, or in the Articles Forum.

Re: Printing from 42S to PC via sound card
Message #8 Posted by Marcus von Cube on 24 Apr 2005, 2:11 p.m.,
in response to message #7 by Andrés C. Rodríguez (Argentina)

I guess you mean this article:
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=74
I was hoping, someone had written a program from this info.

Re: INPRT is the capturing prgm (was: Can a HP 42S print to a HP 48G or a to PC?)
Message #9 Posted by Christoph Giesselink on 25 Apr 2005, 1:31 p.m.,
in response to message #6 by Marcus von Cube

Capturing and decoding the Ir-Redeye format directly with a PC is quite hard, because Windows is no real time OS. The half bit time of the HP Redeye format is 427us. My decoder tables from a complete hardware solution with own CPU base on a measuring accuray of 52us. Decoding should/must be interrupt driven.
IMHO this accuracy can only achieved by a low level driver on the PC. A low level driver is platform dependent.
There were software solutions for DOS made end of 80'ties simulating a HP82240B printer (PrintHP in Germany). None of them work any more, because they are working in polling mode counting the CPU cycles. I made a similar software decoder for MS-DOS in the early 90'ties using the original beeper timer as time reference. This one still works under some "compatible" PC's but because it needs DOS it isn't in use any more.
For all solutions you need a special IR-receiver hardware, standard IrDA receivers don't work.
Regards,
Christoph

Capturing HP IR output with a PC
Message #10 Posted by Marcus von Cube on 25 Apr 2005, 6:41 p.m.,
in response to message #9 by Christoph Giesselink

Christoph,
if you want to do all the timing "by hand", you're lost with any of the modern operating systems.
On the other hand, it should be possible to connect an IR receiver directly to the microphone or line input of a sound card and let the card capture the "sound" generated by the light pulses. If the sample frequency is right, it should be possible to decode the resulting "wave" in software.
With the power of modern CPUs this should be easily done in real time or line by line, triggering on the delays between lines. (As long as the time critical part is done in (sound) hardware.)
That's not my idea. The artikel referred to in my first post meantions such an approach. I was hoping, someone had already done it...
Marcus

[ Return to Index | Top of Index ]

Go back to the main exhibit hall