mTCP icon indicating copy to clipboard operation
mTCP copied to clipboard
verified publisher icon jhpyle

Mouse support causes crashes, slow drawing, CP437 support doesn't seem to work

Open ajrossnz opened this issue 3 years ago • 11 comments

Hi, Please see my video of the issues I am talking about. I am using mTCP on a 286/6MHz (https://youtu.be/6BkOegB1mIw).

  1. I experience system lockups when using the mouse. Only in mTCP, mouse otherwise works fine.
  2. Using normal MTCP runs without delays, however draw speed using this fork seems to be pretty slow, i.e. draws up BBSes at the speed of something like 38400-57600bps. Note that this is not connection based, as if I run normal MTCP, the speed is fine. It may be something to do with the computation time for UTF-8 translation?
  3. When I connect to an ANSI BBS, my usual (on an old IBM PC like this) would be to use CP437, even though I know this client boasts the ability to do UTF8 translation. The target BBS is CP437. However, it also gives the option to display UTF8. If I select CP437, I get garbage on the screen (much like selecting UTF8 used to when I used the old MTCP), only by selecting UTF8 do I get appropriate characters.

Great work so far, keep it up!

ajrossnz avatar Jun 12 '22 09:06 ajrossnz

Thanks for this info. I can't see the video because it is private but you could share it with [email protected].

  1. Does the mouse work at all when you are running this fork of mTCP? I.e. can you see the mouse cursor move, and then at some point later there is a crash? Or does it just crash whenever the mouse driver is installed? If this is answered by the video, then never mind, I'll just wait until I can see the video.

  2. I would expect draw speed to be slower than regular mTCP because there is more code that needs to run in the main loop for the additional features like mouse, graphics, printer, extended keyboard, and unicode. But I am surprised a slowdown is noticeable on a 286. The slowness might be related to the mouse malfunctioning; I would be curious to know if the slowness is reduced if your mouse driver is not installed. I will try using the mouse a lot to see if I can reproduce the system crashes. It could be related to the 286 environment, which would suck because I don't have a 286 for testing.

  3. If the BBS sends a character greater than 127, like 219 for a solid rectangle, then my code will assume it is the start of a unicode sequence, so there will be garbage on the screen if the BBS doesn't follow up with the second character of the unicode sequence. So with this version of mTCP, you will get garbage on the screen if you connect to a BBS that sends "extended ASCII" characters. I could add a keystroke for toggling unicode translation, although that might make problem number 2 a little bit worse.

jhpyle avatar Jun 12 '22 13:06 jhpyle

It might have just been private for a few hours when you got the link, it's definitely public now as people are commenting on it (it's a public review on my channel).

https://youtu.be/6BkOegB1mIw

  1. As you can see in the video, you can use the mouse for a random amount of time then it crashes.

  2. It is slow regardless of whether the mouse driver being loaded or not.

  3. Ok.

Cheers Alistair

Alistair Ross

On Mon, 13 Jun 2022, 01:05 Jonathan Pyle, @.***> wrote:

Thanks for this info. I can't see the video because it is private but you could share it with @.***

Does the mouse work at all when you are running this fork of mTCP? I.e. can you see the mouse cursor move, and then at some point later there is a crash? Or does it just crash whenever the mouse driver is installed? If this is answered by the video, then never mind, I'll just wait until I can see the video. 2.

I would expect draw speed to be slower than regular mTCP because there is more code that needs to run in the main loop for the additional features like mouse, graphics, printer, extended keyboard, and unicode. But I am surprised a slowdown is noticeable on a 286. The slowness might be related to the mouse malfunctioning; I would be curious to know if the slowness is reduced if your mouse driver is not installed. I will try using the mouse a lot to see if I can reproduce the system crashes. It could be related to the 286 environment, which would suck because I don't have a 286 for testing. 3.

If the BBS sends a character greater than 127, like 219 for a solid rectangle, then my code will assume it is the start of a unicode sequence, so there will be garbage on the screen if the BBS doesn't follow up with the second character of the unicode sequence. So with this version of mTCP, you will get garbage on the screen if you connect to a BBS that sends "extended ASCII" characters. I could add a keystroke for toggling unicode translation, although that might make problem number 2 a little bit worse.

— Reply to this email directly, view it on GitHub https://github.com/jhpyle/mTCP/issues/5#issuecomment-1153161433, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQ6JGP2NAFD3K4QGNW4Q4DVOXN77ANCNFSM5YRO7JXQ . You are receiving this because you authored the thread.Message ID: @.***>

ajrossnz avatar Jun 14 '22 05:06 ajrossnz

I published a new version that may work better. This incorporates the changes in Brutman's new version of mTCP. I may have fixed the crashing you saw when using the mouse.

The mouse support has two modes: 1) there is a standard mode, which you see when you telnet to a Raspberry Pi, for example, where you can select text and press both mouse buttons simultaneously to "paste"; 2) there is an xterm mode, where mouse clicks and drags are transmitted as escape sequences to an application.

Your BBS uses the second mode; it sends an escape sequence telling the terminal to send mouse actions as escape sequences. Whether your BBS does anything with that input, I don't know. Hopefully with the changes I made, the application will not hang. But this also means that mouse copy and paste will not work inside your BBS, unless your BBS implements that based on the escape sequences it receives.

In the latest version I also tried to make things faster, although I would not be surprised if you saw no difference. Note that choosing UTF-8 over Code Page 437 means that for pages that are heavy on non-ASCII characters, approximately three times as many bytes need to be transmitted to draw the page, so the network itself may account for a lot of the slowdown.

jhpyle avatar Jul 04 '22 23:07 jhpyle

Hi Jonathan, Thanks so much for your update. Was really great to see you making the patches to your fork, and in such a quick turnaround from Michael Brutman's official release! I finally had a chance to sit down and evaluate the update.

The good news is:

  1. The mouse pretty much seems fixed!
  2. It is a lot faster now! Although still noticeably slower than the official version, however do note point 3.
  3. I am still having to use UTF8 only, it does not seem to register CP437 as the original bug.

Please see my review video here: https://youtu.be/xQjPBdmEg-Y

ajrossnz avatar Jul 11 '22 08:07 ajrossnz

Point number 3 is not a bug. It not possible for a terminal emulator to support both UTF-8 and extended ASCII at the same time. I could add a feature where the user could toggle between UTF-8 mode and extended ASCII mode, but the downsides of that would be: 1) it would be toggled by a key combination, so there would be one fewer key combination that could pass through to the application; 2) it would make the main loop slower by adding additional conditional jumps based on the mode.

jhpyle avatar Jul 11 '22 11:07 jhpyle

Thanks for your feedback. Is there perhaps a way to force Telnet into either UTF8 or CP437 mode then, via a command line switch? This would negate the extra overhead of a toggle keypress that slows down the main loop and remove the key combination issue you mention. Basically, if I'm on an old retro computer, the chances of me wanting UTF8 is almost zero, so my default would be to prefer CP437, it seems that (in my experience), there is no way to force it to use CP437.

ajrossnz avatar Jul 15 '22 08:07 ajrossnz

I could add a configuration option for disabling UTF-8 conversion. It would still slow down the main loop, but perhaps not by much.

jhpyle avatar Jul 15 '22 11:07 jhpyle

There is now a separate binary telnetnu.exe for non-Unicode mode.

jhpyle avatar Aug 14 '22 22:08 jhpyle

There is now a separate binary telnetnu.exe for non-Unicode mode.

Awesome, thanks so much. A few issues I'm noting with the update:

  1. Backspace doesn't work: In telnetnu.exe, it just flat out doesn't backspace. Something is being sent to the terminal I think (maybe a DEL?), but not backspace.

  2. I used to be able to be able to change the behaviour of backspace with the Alt+B combination. I note that I can't do this at all, on both versions of the binary. The Alt+N for newline behaviour still works, however.

  3. There seems to be heavy latency or something just isn't right with updates in telnetnu.exe. The best way to experience this is using MRC chat on a BBS (eg, mine). When you send a message by pressing return, it should then echo to the main chat window. Unfortunately, whilst the message is sent, the window isn't being refreshed. This behaviour isn't the same with telnet.exe. If I force a screen refresh by hitting say, Alt+Enter or something like that, it will refresh the screen, but it is an odd issue that I saw with older versions of Michael Brutman's telnet.

ajrossnz avatar Aug 20 '22 00:08 ajrossnz

Thanks for the reports.

Due to a typo, the Alt-B key wasn't being processed. Sorry about that. That is fixed now in the latest version. I think this should fix issues 1 and 2 but let me know if it doesn't. Also note that you can set TELNET_SENDBSASDEL in your MTCP.CFG file to whatever your backspace preference is and then you won't need to use Alt-B.

I'll try to reproduce issue number 3. I had tested your BBS with TELNETNU.EXE and it seemed to work ok, but I didn't try sending any messages.

I noticed something unusual with your BBS, which might be an issue with ANSI escape sequence processing (it could even be related to issue 3, possibly). When your BBS asks me to type something into a field, the first character I type is ignored. I don't get that when using telnet from an xterm. I don't know if you've ever seen that.

jhpyle avatar Aug 20 '22 14:08 jhpyle

Did you test out issue number 3 using Michael Brutman's 7/1/2022 version of telnet.exe? I am curious if the same issue appears with that version.

The issue where the first character in a field is ignored happens with the password field, although not with the username field. I investigated it by turning on trace messages and I didn't see anything unusual. When the password field is drawn I see the ANSI escape sequences for positioning the cursor, changing the color, adding spaces for the password. All of the ANSI sequences are correct and complete. Then when I type the first character, the TCP library sends a single byte. But no bytes are thereafter received, as they were when I typed characters into the username field. I would have thought the server would echo something back.

This issue also happens with Michael Brutman's telnet. But it doesn't happen with telnet on my Linux box. So I suspect the issue might be something at a lower level, at the level of the TCP socket or Telnet messages.

jhpyle avatar Aug 21 '22 14:08 jhpyle