Threaded Mode | Linear Mode

cahlucas · 05-16-2020, 08:28 PM

Hi all,
While programming an application, I noticed that there are HP50g calculators that do not print the full 24 characters per line on the infrared printer, using the PR1 command. For my application it is nice if the full 24 characters per line are used. If I run the self-test on the printer, there is no problem, i.e. 24 characters are printed per line. Resetting the printer has also done nothing, the problem is with the calculator. Are there any settings in the calculator that I have overlooked? How can I get the full 24 characters on the printer, regardless of the calculator used? I hope to hear from someone soon. Thanks in advance! Sincerely, Karel.

BobVA · 05-16-2020, 09:54 PM

First you may want to check the setting of the DELAY variable. The default is 1.8 and if it's set much below that the printer can drop characters.

(DELAY is on the PRINT menu on the 48, but I'm not sure where it is on the 50, so you might have to look that up.)

cahlucas · 05-16-2020, 10:22 PM

(05-16-2020 09:54 PM)BobVA Wrote: First you may want to check the setting of the DELAY variable. The default is 1.8 and if it's set much below that the printer can drop characters.

(DELAY is on the PRINT menu on the 48, but I'm not sure where it is on the 50, so you might have to look that up.)

It is not the DELAY setting, I checked it, its 1,8.

Joe Horn · 05-16-2020, 10:33 PM

(05-16-2020 08:28 PM)cahlucas Wrote: Hi all,
While programming an application, I noticed that there are HP50g calculators that do not print the full 24 characters per line on the infrared printer, using the PR1 command.

Please give us an example of what you are printing, how you are printing it, and what exactly gets printed. Otherwise we're just guessing what problem you're seeing.

BobVA · 05-17-2020, 01:16 AM

(05-16-2020 10:22 PM)cahlucas Wrote: It is not the DELAY setting, I checked it, its 1,8.

As Joe said, if you can post the code that does the printing and the PRTPAR variable, that might generate some suggestions.

DavidM · 05-17-2020, 01:29 AM

The IR output of the 50g is very weak compared to some of the other models that can print to the HP82240B. I find that I get best results by putting the calculator and the printer very close together (within a couple cm of each other), and also being careful to align the arrow on the 50g with the receiver on the printer.

Sometimes I've also noticed ambient lighting interfering with the process as well, so I sometimes cover the area near the IR receiver to reduce the possibility of interference.

It would be good to see examples of what you're experiencing to get a better idea of possible solutions.

Allen · (This post was last modified: 05-17-2020 12:45 PM by Allen.)

Tested using my 50g and 82240B printer with a short program to print character arrays, I would sometimes see the last character dropped or a bit-flip in the first character, but reprinting usually fixed the error. Distance between 50g and printer was <1cm on a partially lit desk near a window on a fully overcast morning.

'PCH'
<< CHR DUP DUP + + DUP + DUP + DUP + PR1 >>

55 [PCH] ->
"777777777777777777777777"
(printer humming)

cahlucas · 05-17-2020, 02:56 PM

Hi all,
Thank you for all your input so far. After some experimentation with sysRPL, the problem remains. When I debug the program everything works fine, however, when I run the program, strings that normally stay within 24 characters are sometimes printed on 2 lines. The DELAY parameter in PRTPAR is hereby set to 3.6. The program formats the strings to be printed and places them on the stack, along with a bint indicating the number, to create a meta object. These strings are then printed via a DO loop, see the code below. With NOSY I did some research on the userRPL command PR1. I thought it was best to use the pointer PTR 4C0D0 for printing. I hope to hear from you again soon. Sincerely, Karel.

Code:

ZERO_DO

BINT4

#>CHR

>T$

PTR 4C0D0

LOOP

Allen · 05-17-2020, 04:07 PM

from Les Secrets de la HP48G/GX b by J.M. Ferrard (pg. 240) isbn: 2908791102 the entry point for PR1 is #318FEh

have you tried that?

cahlucas · 05-17-2020, 04:16 PM

(05-17-2020 04:07 PM)Allen Wrote: from Les Secrets de la HP48G/GX b by J.M. Ferrard (pg. 240) isbn: 2908791102 the entry point for PR1 is #318FEh

have you tried that?

Dear Allen,
The program runs on a HP50g, not a HP48G/GX. If you search a littlebit deeper in the ROM of the HP50g, you will find the ROM pointer I have given. Sincerely, Karel.

Allen · 05-17-2020, 04:24 PM

Ah, you are right, I am in need of more coffee this morning. I was reading one of the books this past week, and as soon as I saw sysRPL, my mind went immediately to the 48g/gx series, even though just yesterday I was testing the same with a 50g.

you have not replied to Joseph's request regarding a print out?

DavidM · 05-17-2020, 06:02 PM

(05-17-2020 02:56 PM)cahlucas Wrote: With NOSY I did some research on the userRPL command PR1. I thought it was best to use the pointer PTR 4C0D0 for printing.

Hmmm...

If PR1 functionality is what you are wanting, it seems like PTR 2F127 would be a better choice (or possibly FPTR 1 2CE, which is what gets called by the above).

PTR 4C0D0 appears to be an undocumented print command called "PRINTxNLF". I'm not entirely sure what that does, but I'm wondering if the "NLF" stands for "no line feed" or "new line feed". Either way, I'd try using a different solution for the print step to see if that works better.

Note that the above applies to a v2.15 50g. Other ROM versions may vary.

Allen · 05-17-2020, 08:02 PM

(05-17-2020 06:02 PM)DavidM Wrote: ... an undocumented print command called "PRINTxNLF"...

Ah, you raise a good point. I wish cahlucas was a little more up front, like "I'm having strange print behavior [using an undocumented ROM PTR print command] with HP50g and HP82240B" when asking for help.

I could have spared myself some time testing and printing using UserRPL PR1 mentioned in the first post. I feel duped into volunteering my time to help someone who is misleading us about the problem.

cahlucas · (This post was last modified: 05-18-2020 09:05 PM by cahlucas.)

(05-16-2020 10:33 PM)Joe Horn Wrote:
(05-16-2020 08:28 PM)cahlucas Wrote: Hi all,
While programming an application, I noticed that there are HP50g calculators that do not print the full 24 characters per line on the infrared printer, using the PR1 command.

Please give us an example of what you are printing, how you are printing it, and what exactly gets printed. Otherwise we're just guessing what problem you're seeing.

Dear Mr. Horn,
The data that needs to be printed is digital numbers, like # 1A6F4D28, but if the user wants to, in HEX, DEC, OCT, or BIN mode. The output is formatted for HEX mode in bytes like this"1A 6F 4D 28", this for easy reading. In OCT mode it is like this: "3 2 3 3 6 4 6 4 5 0", and in BIN mode: "1 1010 0110 1111 0100 1101 0010 1000". The last output is then formatted as 4 nibbles in a row. The program has the abbility to show and print several binary numers that are present on the stack up to level 32. At the moment the error concerns printing in OCT mode, and the heading, see example below. The error in the heading occurs somtimes also in DEC mode. Printing in HEX, DEC and BIN is is otherwise good. I hope to have informed you sufficiently. Sincerely, Karel.

Code:

[i]Intended output:[/i]

Stack level 6 (OCT):

         1 1 0 6 4 2 5 4 7 4

       2 2 0 0 4 4 3 2 1 2 6

[i]Printed output:[/i]

Stack level

6 (OCT):

    1 1 0 6

4 2 5 4 7 4

  2 2 0 0 4

4 3 2 1 2 6

cahlucas · 05-18-2020, 09:32 PM

(05-17-2020 06:02 PM)DavidM Wrote:
(05-17-2020 02:56 PM)cahlucas Wrote: With NOSY I did some research on the userRPL command PR1. I thought it was best to use the pointer PTR 4C0D0 for printing.

Hmmm...

If PR1 functionality is what you are wanting, it seems like PTR 2F127 would be a better choice (or possibly FPTR 1 2CE, which is what gets called by the above).

PTR 4C0D0 appears to be an undocumented print command called "PRINTxNLF". I'm not entirely sure what that does, but I'm wondering if the "NLF" stands for "no line feed" or "new line feed". Either way, I'd try using a different solution for the print step to see if that works better.

Note that the above applies to a v2.15 50g. Other ROM versions may vary.

Dear DavidM,
I used the pointer PTR 2F127 first, and I got the errors mentioned there. The command PRINTxNLF mentioned by you has the address # 2F362h on my HP50g and FPTR 1 2CE turns out to be the same as PTR 2F127. Pointer 2F362 does not improve. My HP50g has the same software version: v2.15. Sincerely, Karel.

cahlucas · 05-18-2020, 09:42 PM

(05-17-2020 08:02 PM)Allen Wrote:
(05-17-2020 06:02 PM)DavidM Wrote: ... an undocumented print command called "PRINTxNLF"...

Ah, you raise a good point. I wish cahlucas was a little more up front, like "I'm having strange print behavior [using an undocumented ROM PTR print command] with HP50g and HP82240B" when asking for help.

I could have spared myself some time testing and printing using UserRPL PR1 mentioned in the first post. I feel duped into volunteering my time to help someone who is misleading us about the problem.

Dear Allen,
I apologize for the inconvenience, it was not my intention to mislead You. The problem occurs in both userRPL and sysRPL. I hope you will continue to make your contributions. Sincerely, Karel.

DavidM · 05-18-2020, 11:27 PM

(05-18-2020 09:32 PM)cahlucas Wrote: Dear DavidM,
I used the pointer PTR 2F127 first, and I got the errors mentioned there. The command PRINTxNLF mentioned by you has the address # 2F362h on my HP50g and FPTR 1 2CE turns out to be the same as PTR 2F127. Pointer 2F362 does not improve. My HP50g has the same software version: v2.15. Sincerely, Karel.

PTR 2F362 and PTR 4C0D0 both point to the same flash-based subroutine at FPTR 1 509, which is the code for PRINTxNLF.

PTR 2F127 (the SysRPL-happy version of PR1) jumps to FPTR 1 2CE. The PTR version takes up less space, with negligible extra time required. Time isn't really an issue here anyway, since you actually need some extra time for the printing.

Looking at your description, I'm wondering if there's possibly a logic error in the code that is shortening the lines. Are the extra spaces in the output being counted properly in the code that is adding linefeeds? Just a thought.

cahlucas · 05-19-2020, 05:52 PM

(05-18-2020 11:27 PM)DavidM Wrote: Looking at your description, I'm wondering if there's possibly a logic error in the code that is shortening the lines. Are the extra spaces in the output being counted properly in the code that is adding linefeeds? Just a thought.

Dear DavidM,
The strings to be printed are never longer than 23 characters. This should fit on one line on the printer that is 24 characters long. Depending on the binary mode and algorithm, the following commands are used: APPEND_SPACE or "CHR_Space >H$". So I cannot find any error in the code. As I mentioned, there were no errors with debugging, which do occur when I run the program. Look at the output I have given in the answer to Mr Horn. Sincerely, Karel.

DavidM · 05-20-2020, 04:28 AM

(05-19-2020 05:52 PM)cahlucas Wrote: The strings to be printed are never longer than 23 characters. ...

What happens if you run the following code?

Code:

::

   CK0NOLASTWD

   "ABCDEFGHIJKLMNOPQRSTUVWX"

   BINT4 #>CHR >T$

   BINT8 ZERO_DO

      DUP PTR 4C0D0

   LOOP

   DROP

;

Are any lines split, or do you simply see "A..X" printed in sequence on 8 separate lines?

Using my 50g/82240B, I see the lines all intact with no splits/omissions/additions. I tried this using a larger value for the loop count (15), and also with DELAY at 1.05 and 3.6. All tests showed the same results (full 24-character lines with no splits).

Are you able to provide a short sample of code that shows the problem? Is there some pattern of characters which makes a difference?

cahlucas · (This post was last modified: 05-20-2020 09:27 PM by cahlucas.)

(05-20-2020 04:28 AM)DavidM Wrote:
(05-19-2020 05:52 PM)cahlucas Wrote: The strings to be printed are never longer than 23 characters. ...

What happens if you run the following code?

Code:

:: CK0NOLASTWD "ABCDEFGHIJKLMNOPQRSTUVWX" BINT4 #>CHR >T$ BINT8 ZERO_DO DUP PTR 4C0D0 LOOP DROP ;

Are any lines split, or do you simply see "A..X" printed in sequence on 8 separate lines?

Using my 50g/82240B, I see the lines all intact with no splits/omissions/additions. I tried this using a larger value for the loop count (15), and also with DELAY at 1.05 and 3.6. All tests showed the same results (full 24-character lines with no splits).

Are you able to provide a short sample of code that shows the problem? Is there some pattern of characters which makes a difference?

Dear DavidM,
Only the first line of the first 8 is split between the J and the K, the rest is OK. I have given the most important code before, I have listed the patterns to be printed below. As I mentioned earlier, printing in OCT mode is particularly problematic. The given patterns are of course an example. As indicated earlier, the heading is problematic especially in OCT mode, and sometimes also in DEC mode, see the example I gave earlier. I hope that I have informed you sufficiently. Sincerely, Karel.

Code:

HEX:

Input:   "12 34 56 78 90 12 34 56"

Output:   12 34 56 78 90 12 34 56

DEC:

Input:  "1311768467284833366"

Output:  1311768467284833366

OCT:

Input:      "1 1 0 6 4 2 5 4 7 4"

          "2 2 0 0 4 4 3 2 1 2 6"

Output:      1 1 0 6

         4 2 5 4 7 4

           2 2 0 0 4

         4 3 2 1 2 6

BIN:

Input:         "1 0010 0011 0100"

            "0101 0110 0111 1000"

            "1001 0000 0001 0010"

            "0011 0100 0101 0110"

Output:         1 0010 0011 0100

             0101 0110 0111 1000

             1001 0000 0001 0010

             0011 0100 0101 0110