HP Forums
Can a HP 42S print to a HP 48G or a to PC? - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: Can a HP 42S print to a HP 48G or a to PC? (/thread-72202.html)



Can a HP 42S print to a HP 48G or a to PC? - Marcus von Cube - 04-23-2005

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?) - Vieira, Luiz C. (Brazil) - 04-23-2005

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?) - Marcus von Cube - 04-23-2005

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?) - Vieira, Luiz C. (Brazil) - 04-23-2005

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 (3210 to 12710) of them both is the same, but characters from 12810 to 25510 match in only a few cases. Codes 14410 and 14510 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?) - James M. Prange (Michigan) - 04-24-2005

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?) - Marcus von Cube - 04-24-2005

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 - Andrés C. Rodríguez (Argentina) - 04-24-2005

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 - Marcus von Cube - 04-24-2005

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?) - Christoph Giesselink - 04-25-2005

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 - Marcus von Cube - 04-25-2005

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