inmbolmie / 5250_usb_converter Goto Github PK

If e.g. your terminal is at address 3, you start the program that defaults to address 0 and you issue a command different than 'setactiveterminal', the program aborts as an terminal identifier will be accessed that doesn't exist.
Also, 'setactiveterminal' should verify that the requested terminal ID is indeed existing.

The current behavior prevents the program to be run as a proper daemon, e.g. via a systemd unit.
Obvious possibilities are:

• An AF_UNIX socket
• An AF_INET{,6} socket - probably bound to localhost be default

scancodeDictionaries['122KEY_EN'] includes:

        # TEXT EDIT MODE KEYS BLOCK MAPPINGS
        # KEYS FROM TOP TO BOTTOM AND FROM LEFT TO RIGHT
        ...
        0x6c: [chr(0x1b), chr(0x1b), chr(0x1b), '', ''], #
        0x57: [chr(0x1B), chr(0x1B), chr(0x1B), '', ''], #
        # 0x6c

The entries shown are the last two, for the Insert and Delete keys respectively. From 5250_Information_Display_System_to_S36_S38_AS400_System_Units_Product_Attachment_Information_198910.pdf page 185 figure 103, it can be seen that those are key numbers 81 and 86 respectively. From page 189 it can be seen that those keys generate the same scan code, and if Alt is not held, based on the "ALT Key Up Note" column and the notes on page 186 it can be seen that the keys can be differentiated based on the shift state.

In the code above, the 0x6c row was presumably intended for the Insert key and the 0x57 key was presumably intended for the Delete key, but the latter scan code appears in the SHIFT_PRESS list, so presumably that entry in the table is ignored. The following # 0x6c comment is probably related to the fact that in a scan code dump the Delete key generated both 0x57 and 0x6c scan codes (due to the shift key not being held at the time).

As further evidence, on a 3476, when I replace the 0x6c entry with:

        0x6c: ["i", "d", chr(0x1b), '', ''], #

pressing Insert generates an i character and pressing Delete generates a d character, regardless of whether I'm holding shift.

Given that those keys don't currently do anything useful, and can't really be made to right now because the VT52 terminfo entry doesn't provide any suitable entries whose character sequences could be generated, it's probably not worth fixing this right now.

For the record, I think the correct terminfo capabilities are kich1 for Insert and kdch1 for Delete.

The initial symptom I encountered was that in GNU Emacs 24.3.1 running on CentOS 7.9, pressing the Backspace key (with the 122KEY_EN scancode table, but I think they're all the same in this regard) caused Emacs to show "C-h (Type ? for further options)-" which is a help prompt that on a modern system you'd obtain by pressing Ctrl-H.

An initial workaround for that issue which worked was to run M-x normal-erase-is-backspace-mode RET (where M-x probably has to be entered as ESC x with all current scancode tables).

Running infocmp -L vt52 shows that the terminfo entry suggests that generating character 8 is correct, as its output includes key_backspace=^H.

However, this post suggests that at least for older Unix variants, what is set via stty is more important than what is in the terminal database, and from testing this seems to be true. stty -a shows erase = ^?, indicating that the delete character is actually what the backspace key should generate. That is what xterm and rxvt-unicode generate - even xterm -ti vt52 -tn vt52, or at least that's what showkey --ascii reveals.

It seems that 5250_terminal.py could set up the terminal appropriately itself without the need to run stty by calling termios.tcsetattr(). This seemed to work to indicate that backspace will generate character 8, when run from a method invoked by Interceptor._init_fd():

attrs = termios.tcgetattr(self.master_fd)
attrs[CC][termios.VERASE] = 0x08
termios.tcsetattr(self.master_fd, termios.TCSANOW, attrs)

I think the best solution would be if each dictionary in scancodeDictionaries:

1. had an entry like 'BACKSPACE_CHAR': chr(0x08) which Interceptor could use to determine what to set attrs[CC][termios.VERASE] to; and
2. set the character to be generated by the scan code for the backspace key - or any key the user wanted to act like backspace - to some new constant which was defined in such a way that it couldn't be mistaken for a string when processing the dictionary entry, e.g.:

# @enum.unique
class KeyAction(enum.Enum):
    BACKSPACE = 0
...
scancodeDictionaries = {
...
        0x3D: [KeyAction.BACKSPACE, KeyAction.BACKSPACE, '', ''],  # BS

and then when generating input to the PTY based on a key press, if an entry is set to that special value, the BACKSPACE_CHAR set in the dictionary is sent.

I'll try to address this soon but am in the middle of too many other things.

Hi! Firstly, thanks for the project, I'd never have been able to get the 3477 working at all without it! I got a PCB printed & am running it off of a teensy 4.0. All seems to be working well save for the update speed of the display, which seems much slower than the example video shown (especially noticeable with cmatrix, far more stuttering and seemingly redrawing entire lines. I can provide a video if that helps).

My question is, do you have any advice on how to go about debugging this? Would the teensy's code or the python script be the bottleneck, or is the 3477's emulation just slower in general? (though setting the slower polling rate seemed to just make it worse). I've some experience with writing for a teensy (a 3.1) and python, so I may be able to take a crack at making my 3477 more usable but I'm not sure where to start.

If there's any debug info I can provide that'd be useful, let me know!

This happens with an IBM 3196-B10 and a factory Twinax cable and validated correct hardware termination setting.
The terminal appears to behave normally in test mode (pressing space while powering on).
After starting 5250_terminal.py and powering on the terminal, the bash prompt comes up reliably and accepts input.
Though, after a short number of key-presses and according output on the screen, communication gets stuck and nothing further is displayed on the screen.
debug logs are attached, which I examined, but don't really know what to look for.
debug.log
write.log
read.log

Hi @inmbolmie!

A 3197 recently landed in my hands. This is a color, two-session terminal.
There is a twinax T-piece connected to the terminal, to that a normal twinax cable, that is plugged into the USB box.
I've made sure an unmodified firmware is flashed on the Teensy.
The controller is at /dev/ttyACM0. Terminal addresses are 0 and 1.
The commandline I run is: python3 5250_terminal.py -t /dev/ttyACM0 -i -c 0:5250_DE:1 1:5250_DE:1
When I switch the terminal on, I just get a blinking cursor in the upper right corner, nothing else.
Here is the debug log file, read.log and write.log are empty.
debug.log
What else can I check?

I tried using VT52_to_5250.BS() directly from some Python code and found that it didn't behave as I expected. It seems that I can reproduce it this way:

1. Start 5250_terminal.py
2. In the terminal, type a few random characters
3. Hit the backspace key to clear the random characters, it behaves normally
4. Run the command export TERM=dumb via the terminal
5. Type say asdf, see asdf█
6. Hit the backspace key, see asd █ - note that the cursor hasn't moved
7. Type x, see asd x█
8. Hit Ctrl-L to redraw the line, now see asdx█ instead
9. Hit backspace a few more times, it keeps deleting characters as expected, but always leaves the cursor one position to the right

Note that it seems that with the standard TERM=vt52, bash (at least version 4.2 on CentOS 7) doesn't output a backspace character in response to backspace being pressed.

There seem to be two problems here if I understand correctly:

1. BS() sends a WRITE_DATA_LOAD_CURSOR command to overwrite the character being deleted, which results in the terminal moving the cursor back to where it started.
2. BS() doesn't move the cursor back to the just-deleted character, but it also doesn't update self.cursorX and self.cursorY to reflect that WRITE_DATA_LOAD_CURSOR moved the cursor.

I presume that there should be an additional LOAD_CURSOR_REGISTER command sent to move the cursor again after WRITE_DATA_LOAD_CURSOR.

I'm happy to file a pull request including this fix myself if you think that what I propose is correct, but I'm not actually sure what the correct handling for receiving ASCII character 0x08 is - it doesn't seem to be a VT52 control character based on a quick read of the Wikipedia article.

Usual terminal behavior is to ask the user to authenticate themselves before getting a shell, which makes sense generally.

This code doesn't actually show any indicator on a 3476 when caps lock is enabled:

                self.indicatorsByte = self.indicatorsByte | 0x10
                self.transmitCommand(WRITE_DATA_LOAD_CURSOR_INDICATORS,
                                     self.destinationAddr,
                                     [self.indicatorsByte])
            else:
                self.indicatorsByte = self.indicatorsByte & 0xEF
                self.transmitCommand(WRITE_DATA_LOAD_CURSOR_INDICATORS,
                                     self.destinationAddr,
                                     [self.indicatorsByte])

Based on https://bitsavers.org/pdf/ibm/5250_5251/5250_Information_Display_System_to_S36_S38_AS400_System_Units_Product_Attachment_Information_198910.pdf section 2.4.16.1 "Discrete Indicators Data Word" (p65) and my understanding of the bit ordering from experimenting with the txindicatorsbyte command, this is toggling the "Katakana shift" bit. Using a mask of 0x20 instead would turn on the "Keyboard shift" bit which causes a ⇧ to appear on the 3476's status line. From looking at photos online I gather that 5251s have an indicator for that too (although I can't be sure since I didn't see any in English, or at least any that were in focus!), so I assume it's probably supported by all 5250-like terminals, whereas I'm assuming the katakana shift bit might not be supported by many?

For what it's worth, https://bitsavers.org/pdf/ibm/5250_5251/SY31-0461-0_5251_Display_Station_Model_11_Maintenance_Information_Dec77.pdf p4-9 says that indicator "indicates that the display station is in upper (numeric) keyboard shift" so I'm not sure what it's actually meant for.

5250_Information_Display_System_to_S36_S38_AS400_System_Units_Product_Attachment_Information_198910.pdf sections 15 and 16 show that the 3476 and 3477 respectively both support additional indicators written using a separate command, and that set includes an actual "Caps Lock" indicator (which shows up as an "A"), but some work would obviously need to be done to detect the station type before trying to using that one, or it would need to be a configuration option.