HP Forums

I have a problem trying to understand the operation of the 82164A (HP-IL to RS-232) module. I'm trying to use it to connect to some display device. But I have a problem.

1) I'm seeing some extra garbage (escape sequences I think) that follow a CR (ENTER) used from the HP-71B. These only show up when I use ENTER on the 71B. A similar thing happens when I use UPARROW or DNARROW arrow on the 71B. Several lines are printed out, as in the test program, these extra characters aren't sent.

This is a problem because of different behavior on two different display devices. On most display devices, and on a DOS Terminal Emulator, these extra characters are simply ignored as non-displayable. These sequences are,

1. "0x1B, 0x3C - ("ESC <")"
2. "0x1B, 0x3E ("ESC >")
3. "0x1B, 0x52" - ("ESC R")
4. And so forth

everytime an ENTER key is pressed, instead of simply ">" like what is normal on most devices and the 71B display. All that should be displayed is ">" after an ENTER press. But what shows up is "<R,CR,LF,><>>>R>". Wierd!

As you can see in the 3 screenshots, if I run an emulator, these don't show up and are not displayed, on the emulator. Also, these are not displayed on most other display devices by other manufacturers. But on ONLY one of my display devices, the 0x1B is ignored and the 0x3C is printed. I need to understand what these other characters are and why they are sent???

Anyone know why these extra characters would be sent by the 82164A module? Anyone know how to turn them off?

Images (so you know what you are looking at:

Image1: This is what most display devices look like and what I want them to look like.

Image2: The captured text, being sent over RS-232, to the display device, in ascii format. The small box, is the 0x1B character. The esc chars aren't displyaed on emulator and other displays. They are on the ONLY one of my display devices. On this one device, the 2nd byte is being displayed, as if the 1st (0x1B) isn't seen. I think that is the source of my problem.

Image3: Image 3 is simply 3 presses of the ENTER key, on the 71B. I would expect to see ONLY three sequences of 0x0D, 0x0A characters.

Click Images for Larger View

So, what I'm trying to figure out is 2 fold.

1) Why these characters are even being sent?

2) Why this other display device ignores the first char and prints the 2nd? (working that through the display mfg.) But folks here can help me with the first question.

The only question for this forum is the 1st question. I'll deal with the 2nd question with the mfg. of the display controller.

Why are these extra two-byte (esc ?) chars being sent? How to turn them off? Is this even normal? Because it's a consistent 2 byte sequence, I think we can rule out noise or some other similar cause.

Anyone here have an answer to the 1st question?

Sidenote: I'm initializing the 82164A with the following sequence:

REMOTE

OUTPUT :1; "R0, R1, P4, SS0, SBF"

LOCAL

The RS-232 is being initialized to be a DISPLAY IS device. Is this a good sequence or should I be initializing with something additional or different.

Edited: 3 June 2006, 11:24 p.m.

Followup: Please read and understand the 1st post above you you will be lost in this one. You may be anyway, but reading the first will help understand this post, which is just a continuation.

When I review the command stack, I get this kind of a display, on the one display that is acting wierd. But, this behavior isn't the fault of the display. It's because the 71B or 82164A are sending more characters than I would expect.

This is what is displayed. I will explain this below.

<>>R><R

<>>R>

<R\>PRINTCHR$(10)DDDDDDDDDDDDDR>CCCCCCCC

CCCCC

<R\>PRINTCHR$(13)DDDDDDDDDDDDDR>CCCCCCCC

CCCCC<R

<>>R>

PREFACE: I previously executed PRINTCHR$(10) and PRINTCHR$(13) to see what the effect was on the screen. These were left on the command stack and I wanted to review them. I notice a bizzare behavior on my emulator and also on this one display. When I used the ^ to review the commands, I got page scrolls not line feeds. So I wanted to investigate this, which lead to the text displayed above. To analyze this I did the following:

I entered several ENTER presses to display only input prompts (">" theoritically). All that was present on the screen was the 1st 2 lines above (the problem mentioned in the first post).

Then, I executed g CMDS (on the 71B), to see these previous commands. When I executed the first g CMDS, you see line 3 right up to the CCCCs. They aren't displayed at this point. Then I press the ^ (UPARROW) key to see the previous command. At this point, the CCCCCCCCCCCCC are displayed followed by line 5, up to the CCCCs again. Upon hitting ENTER to execute the PRINTCHR$(13) command again, I get another CCCCCCCCCCCCC<R sequence followed by a LF which accounts for the space, then the garbage again of <>>R>.

BTW, I suspect the DDDDDDDDDDDDD and CCCCCCCCCCCCC are really sequences of 0x1B, 0x44 and 0x1B, 0x43. One the Terminal Emulator, when I do this same thing (tapping the ^ UPARROW), I see essentially the same thing. I see the text scroll off the screen, as if the text is displayed a page at a time. But this one display doesn't see the 0x1B char and only interprets it as D or C. But my problems (questions) are really concerned with WHAT and WHY these extra character (esc sequences) are sent at all.

So, why are all these extra esc sequences sent by simply using the UPARROW to review the COMMAND stack? This is related to my previous post, where pressing ENTER also sends the sequences mentioned in that post. Seems that all that should be sent are 0x0A, 0x0D

Edited: 3 June 2006, 11:38 p.m.

It's because the HP 71B is trying to talk to a display, and expects the display to interpret control characters and escape sequences in the same manner as the HP 82163A or HP 92198A displays.

If you don't want the display escape sequences, use PRINTER IS rather than DISPLAY IS, and use LPRINT, LLIST, etc. to send things to the serial interface.

But what are those extra characters and why are they even necessary? Seems to me that ENTER should simply produce the 0x0A and 0x0D. What are 0x1B, 0x52 and 0x1B, 0x3C and 0x1B, 0x3D and why are they necessary? And why does the g CMDS produce 13 line feeds. Seems that even on an HP display, you wouldn't want to see that. You'd expect to see the ^ simply scroll up one line; not 13.

Why would ENTER ever produce:

0x1B, 0x3C (ESC "<")

0x1B, 0x52 (ESC "R")

0x0D, 0x0A (CR LF) (or visa versa)

0x1B, 0x3C (ESC "<")

0x1B, 0x3E (ESC ">")

0x1B, 0x3E (ESC ">")

0x1B, 0x52 (ESC "R")

0x1B, 0x3E (ESC ">")

I'm not just looking for the fix but also the understanding why this is happening? And why it even makes sense for HP, assuming it does.

Like I said, I have only one display that behaves this way. All the rest and the emulator, don't exhibit this problem. And none of them are HP displays.

Besides PRINTER IS doesn't do what I want. I also want the display to display everything that is entered, from the keyboard, on the remote display. PRINTER IS doesn't allow that.

I already have another display that isn't HP and doesn't have this problem. I think the issue is WHY and WHAT are these extra characters? and can they be turned off?

Edited: 4 June 2006, 8:48 a.m. after one or more responses were posted

Hi Mike,
Wow, a serial video terminal? Haven't seen one of those in a long time, prehistoric days.

OUTPUT :1; "R0, R1, P4, SS0, SBF"

What protocol are you using? R11? For XON-XOFF use C0, C2 (use C0 because the C2 does not clear the other bits). The default protocol on the HP82164 is not a vaild protocol. Also, is your terminal set for 8 bits?

Doug

Quote:

---

Why?

---

Because it's trying to fiddle with the curor, using the escape sequences that work on the HP-71B internal display and on the 82163A.

Quote:

---

Is this what is supposed to be sent out?

---

Yes.

Quote:

---

Is there an explanation of what these are for?

---

Yes. I'd suggest that you Read The Fine Manuals. :-)

The escape sequences are defined in the HP-71B Reference Manual on page 328, and in the 82163A manual on page 10. The one's you're reporting are:

• ESC < turns the cursor off
  
• ESC > turns the cursor on
  
• ESC Q sets the "insert cursor", a blinking left arrow
  
• ESC R sets the "replace cursor", a blinking block
  

I expect that if you repeatedly press "g I/R" on the keyboard, it will alternately send ESC Q and ESC R sequences to the display.

Quote:

---

I also want the display to display everything that is entered, from the keyboard, on the remote display. PRINTER IS doesn't allow that.

---

Then you're going to get the escape sequences. "DISPLAY IS" expects to talk to a display, and these are the escape sequences used by displays (as far as the HP-71B and HP-75 are concerned; HP wasn't a big supporter of ANSI X3.64 standard).

If it didn't send the escape sequences, you wouldn't get a dsiplay of "everything that is entered", because the line editing wouldn't be displayed correctly.

Perhaps someone would care to write an 82163A emulator? I'm busy working on better MOD file support for Nonpareil, so I don't have time to do it. Maybe someday.

Quote:

---

and can they be turned off?

---

Not AFAIK. If there's a way to do it, it would be buried in the HP-71B Software IDS.

Quote:

---

Yes. I'd suggest that you Read The Fine Manuals. :-)

---

Quote:

---

If it didn't send the escape sequences, you wouldn't get a dsiplay of "everything that is entered", because the line editing wouldn't be displayed correctly.

---

Quote:

---

Perhaps someone would care to write an 82163A emulator? I'm busy working on better MOD file support for Nonpareil, so I don't have time to do it. Maybe someday.

---

Edited: 4 June 2006, 8:46 a.m.

Quote:

---

Hi Mike, Wow, a serial video terminal? Haven't seen one of those in a long time, prehistoric days.

---

I'm working on a serial LCD display for use with the 71B. It will be 16 lines by 40 characters and have an HP-IL interface. Talk about wasting one's time. I guess it really doesn't have to be serial and I might still change that but it will still have the HP-IL interface. The serial just allows me to test this (with the 82164A), while I'm working on the interface.

Edited: 4 June 2006, 8:47 a.m.

As the previous posters have mentioned, these escape sequences embedded in the output are used to drive an external display.

In conjunction with KEYBOARD.LEX (which allows keyboard input from an HP-IL device), you can "log-on" to your HP-71B from an external machine.

By handling (and generating) escape sequenses, the external machine can (a) display HP-71B output just as it appears on the screen (or 821263 video interface) *AND* allow things like the cursors keys to work correctly (e.g. editing the current line).

All this required a lot of work, and I am grateful to the HP developers for adding this capability to the HP-71B.

I have developed a program that does all the remapping and I can send it to you, but be aware that its just a quick hack (so it may have errors), and (b) its designed for *my* environment which is NOT windows (I do not waste my time with Windows).

Having said that, this will work with any reasonable Unix or clone and if you have trouble porting it to a recent Unix system, I'll be happy to help.

**vp

PS
This is the readme file from the program (as you can see its more of a note to myself :-)

Use a cisco TERMINAL type 25 pin adaptor and a patch cord

to connect the HP-IL serial converter to the workstation.

Run the translation utility (vtover) to convert HP-71B escape

sequences to xterm-compatible sequences

Use

        kermit -l /dev/cua00 -b 9600 -c

to connect to the serial port

On the HP71B

Load the keyboard redirector KEYBOARD.LEX (??)

ASSIGNIO ":FD,:SR"

PRINTER IS :SR

DISPLAY IS :SR

KEYBOARD IS :SR

To disconnect use

OFF IO

To reset a redirection use (e.g.)

PRINTER IS *

The following prog prints floppy directories on the printer

It assumes the floppy is assigned to :FD the display is the LCD

and the printer has already been assigned with a PRINTER IS

  4 ! ------------------

  5 ! SENT CAT TO PRINTER

 10 DIM A$[100]

 50 DISP "Vol name";

 60 INPUT A$

 70 PRINT A$

 90 PRINT "   NAME    S TYPE   LEN    DATE    TIME"

100 FOR I=1 TO 300

110   A$=CAT$(I,":FD")

120   IF A$="" THEN GOTO 200

130   PRINT A$

140 NEXT I

150 !

200 PRINT "--------"

Hmmmm... keyboard remapping. That might work. So instead of getting the 16 characters that END LINE produces, map it to something that behaves the way I need. Might work ok.

I wouldn't mind taking a look at your remapping.

Edited: 4 June 2006, 11:48 p.m.

Hi, Vassilis,

I'd love a copy of your program's source code. The lack of Windows compatibility would be a point in its favor, in my opinion. 8)

Regards,
Howard

Ok the program is at: http://www.series80.org/Misc/vtover.c

When using this baby you have to understand that the shell you get
after you run it is not the same as the shell you had before you run the program! Essentially what it does is that it creates a new terminal session (in the same xterm as the old one) and runs a new shell. To verify this run the Unix command tty before running vtover and then again after you run it. You will see that your terminal port has changed.

In the image below

the path on the left hand side is what you have before running vtover while on the RHS you have the situation after running vtover (with vtover being in place of "remap", although not entirely, because there are two versions of vtover running -- one for incoming data, and another for outgoing).

The "application" in the RHS is the shell you are seeing after you run vtover and will be replaced by kermit once you run it. Then characters from the serial line (i.e. originating from the HP-71B) will be mapped by vtover before they are sent to your xterm (terminal in the RHS of the picture).

Similarly, data you type (e.g. if you press the cursor up key, you
will generate ESC [ A) will be converted to what the HP-71B expects (ESC ^K or \033\013).

I hope this makes it clear.

The program should compile cleanly on Linux (cc vtover.c), but on
OpenBSD you will need to use cc -D_OpenBSD vtover.c -lutil

**vp

Edited: 5 June 2006, 6:37 a.m.

Quote:

---

Hmmmm... keyboard remapping. That might work. So instead of getting the 16 characters that END LINE produces, map it to something that behaves the way I need. Might work ok.

---

Don't remap the keyboard of your poor HP-71B if you want to make it recognize your commands! What happens is roughly the following:

1. You type a key.
   
2. The key gets translated by the operating system to a character or control code, depending on what you have typed. Combined sequences (just as [g][4]) are properly translated at this stage.
   
3. The code is passed to the currently running application. This might be the BASIC command mode, CALC mode, a running program or whatever.
   
4. The application processes the information. If it decides that it should update the display device in some way, it does so; if not the key is ignored. The reaction is totally up to the controlling application. Just take CALC mode as an example what might happen to the characters and other keys you type in.
   
5. If the display must be updated, the application assembles the correct sequence of characters, control codes or escape sequences to make the display show the intended information. This information is then sent to the display.
   
6. The display controller (or some software in between) looks at the codes sent and makes the output look like it was meant to look. This only works, if the application talks the same "language" as the display.
   

Intercepting the output is a different matter. As I've already pointed out, the controlling application has a certain display behaviour in mind and tells this to the display controller by means of characters, control codes and escape sequences. Any display is now meant to follow these rules. If you design an external display four the HP-71B, you (your display controller) must stick to the rules and interpret the sequences correctly.

Marcus

(who has written more than one keyboard and display driver in his career.)

The way to do the remapping is on the host, not the HP71B. This is what the program I mentioned in my previous posting does.

Remapping occurs both for input and for output, so if you type a character on the workstation keyboard (say CURSOR_UP), your terminal (xterm if you use X11, or HylaTerm if you use Windows) will generate an escape sequence (e.g. "ESC [ A", where ESC is ASCII 27).

Unfortunately your HP71B will not recognise this escape sequence, as it expects something else (in this case ESC VT or ASCII 27 11). So
we need to map ESC [ A to ESC VT so that your HP71B understands the CURSOR_UP keystroke coming from the remote keyboard in the same way as the local "cursor_up" key.

Similarly your HP71B inserts various escape sequences in its output to the remote display. We have to map these escape seuqnces to something our (virtual) terminal (xterm) can understand.

My program does all this in a transparent way (you run it and you get a new shell prompt, then run kermit or any other program to access to serial line and you are set). It also adds the ability to associate strings with your keyboard function keys. These are expanded in exactly the same manner as the other (keyboard) escape sequences.

Best Regards

**vp

I will have a processor between the HP-IL and the Serial TTL output of my interface. My micro will translate from HP ESC sequences to the equivelant sequences the display will handle. The display module is quite powerful and has more capability than the HP, in terms of display control.