Getting the L/F-symbol into a string ?

[mcc]

Hi,

is there a way to get the "L/F" (linefeed) symbol into a string without actually "executing" the linefeed?

Cheers!
Meino

[Thomas Okken]

Indeed there is; it's character 138. This is not in the ALPHA menu, so you have to do 138 XTOA.

[whuyse]

? But it is under PUNC, 2nd page.
Werner

[firai]

? But it is under PUNC, 2nd page.
Werner

I think the question was for programs, in which case I understand that the LF character from the alpha menu executes a line feed when the string is viewed through AVIEW. Otherwise presumably the poster would have found LF in the alpha menu as well?

[whuyse]

As usual, I should learn that when Thomas posts something, I had better think twice...
Indeed, the 138 XTOA char does not show a linefeed when AVIEW'd, while char 10 (the one from the ALPHA menu) does.
Both characters show the same glyph btw.

Cheers, Werner

[mcc]

Hi,

thanks a lot - that helps!

Interesting, that 138 ist exactly 10 (the "normal L/F") 128 (half of 256/8bit) +

Cheers!
Meino

[Thomas Okken]

I don't know if this is an intentional feature or just a consequence of how character codes are mapped to characters. The top half of the code space, codes 128-255, mirrors the bottom half, except for codes 128 and 129, which are used to construct the X: and Y: labels, and for code 138, which looks the same as code 10 in strings but does not perform a line feed in AVIEW and PRA. Which makes me wonder, what about ESC, code 27? Does code 27 initiate an actual escape sequence when sent to an 82240 using PRA, and if so, what about code 155?

Free42 doesn't emulate escape sequences at all so testing this would require an actual 82240, being driven by an actual HP-42S, or maybe a DM42.

[rprosperi]

I don't know if this is an intentional feature or just a consequence of how character codes are mapped to characters. The top half of the code space, codes 128-255, mirrors the bottom half, except for codes 128 and 129, which are used to construct the X: and Y: labels, and for code 138, which looks the same as code 10 in strings but does not perform a line feed in AVIEW and PRA. Which makes me wonder, what about ESC, code 27? Does code 27 initiate an actual escape sequence when sent to an 82240 using PRA, and if so, what about code 155?

Free42 doesn't emulate escape sequences at all so testing this would require an actual 82240, being driven by an actual HP-42S, or maybe a DM42.

I've not followed the details above, but have the required tools - give me a small program fragment and I'm happy to give it a try and confirm what they do.

[Thomas Okken]

I've not followed the details above, but have the required tools - give me a small program fragment and I'm happy to give it a try and confirm what they do.

Great! Could you try this?

Code: Select all

00 { 82-Byte Prgm }
01▸LBL "PTEST"
02 CLX
03 STO 00
04▸LBL 00
05 "LINE"
06 10
07 RCL+ 00
08 XTOA
09 ├"FEED"
10 PRA
11 "PLAIN "
12 27
13 RCL+ 00
14 XTOA
15 253
16 XTOA
17 ├"WIDE"
18 R↓
19 XTOA
20 252
21 XTOA
22 PRA
23 RCL 00
24 128
25 XOR
26 STO 00
27 X≠0?
28 GTO 00
29 END

In Emu42 with the 82240B emulator, it behaves as I expected, that is, codes 10 and 27 work as actual line feed and escape characters when printed, while 138 and 155 do not. My guess is that it will work the same with the real 42S and 82240B, but there may be differences with the DM42 depending on what kind of character massaging it performs, if any.

[rprosperi]

Thanks Thomas.

Results are nearly identical; note that the LF character is printed slightly differently:
DM42: as the small "L F" characters vertically separated
HP-42S: as the greater than or equal to (small angle pointing to the right above horiz. line at the bottom

As for the bottom line, I'm not sure if this is what you expected, but they are the same.

PTEST Results sm.jpg (181.58 KiB) Viewed 2884 times