Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: vt420 gripes

  1. #1

    Default vt420 gripes

    I've got a vt420 and I love some things about it, the screen is a beautiful and crisp, the keyboard is nice, but my one gripe is that it constantly shows junk characters because I am guessing the rendering engine can't keep up. I remember reading in the manual something about it can keep up with 19200 baud, but I don't even think that is true. I know you have to skip the smooth scrolling and turn off that feature, but I connected it to the Zeta SBC I built yesterday and even at 9600 baud I can see it have issues in certain situations. It had this odd issue in Turbo Pascal where the command screen was constantly redrawing again and again until I turned off XON/XOFF. Also, even at 9600 baud, TINST when showing the terminals shows some junk characters. Maybe my unit has problems, I suppose that is always possible, but it seems to me that a dedicated terminal should be bulletproof. My other grip is that the other handshaking option which I think they call MODEM isn't RTS/CTS, but something else. I don't remember the particulars, so I could be wrong about that. Hardware handshaking worked for me in Teraterm, but not at all when I tried the MODEM option under the vt420 settings.

  2. #2
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    466

    Default

    The VT420 doesn't have inbound flow control, only outbound. It has DTR/DSR but not RTS/CTS. the MODEM option in setup basically means that you've redirected the "DSR" pin on the terminal side to the "CD" pin on the modem, because you are more interested in knowing whether the modem is connected, than in knowing whether it's powered on.

    I can kind of understand leaving RTS/CTS out. I've heard RTS/CTS were originally intended to support half-duplex lines, which were no longer common when the VT420 came out. And since RTS/CTS aren't typically passed through a full duplex modem they wouldn't help anyway (they would just move your buffering problem from the VT420 to the modem) and it makes sense to build a product that works equally well both with and without a modem. It's not exactly DEC's fault that application developers insisted on using ^S and ^Q for other things, preventing XON/XOFF flow control from working.

    Still, I do appreciate having the ability to use RTS/CTS in a direct host connection, freeing up ^S and ^Q for other uses, and I'm a bit disappointed that that's not an option with the VT420. But just because I know the constraints on when RTS/CTS is effective and when it's not doesn't mean all users do, and not having it at all probably saved a lot of tech support headaches trying to explain to a user why they could use ^S and ^Q in EMACS on a directly connected terminal, while they couldn't do so when using a modem unless it was running at 4800bps or lower.
    Last edited by kgober; February 27th, 2019 at 08:42 AM.

  3. #3

    Default

    Thanks for the informative reply! I decided to fully test the vt420 and even redirected the DTR/DSR to RTS/CTS and hooked up the logic analyzer and indeed it does what you suggest (no hardware flow control). I guess I just need to accept it is XON/XOFF only!

  4. #4

    Default

    A few more questions about this terminal:

    #1 - Can you generate any value? If it is in 8-bit mode, is there a keyboard combination that can send byte value 0-255 ?

    #2 - I was thinking more about the flow control issue. Is there such a thing as a software to hardware handshaking adapter? I could make such a thing pretty easily using an AVR where it could provide a RTS/CTS signal that is controlled by receiving ^S/^Q from the terminal. I think there is even a tiny AVR that has dual USART's so it could be a pretty simple pass through. Is this something that has been made by others already?

  5. #5
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    466

    Default

    1. yes, see page 81: http://bitsavers.org/pdf/dec/termina...inal_Nov89.pdf

    2. I suppose such a thing would be possible, I don't know if anyone has ever made it as a single-port adapter but I suppose it's likely that some terminal servers had this feature built-in. As a bonus, if you build it yourself you can make it so that if you type 2 ^S characters in a row, it will treat the second one as ^Q locally, and also pass it on as ^S to the host. Basically an escape that lets you send ^S to the host when that's what you really want. And for ^Q you can eat them when in hold mode and pass them through otherwise. This takes advantage of the VT420 flow control not sending ^S when it's already held, and not sending ^Q if it's not held, so you can make a good guess about which ones are generated by the VT420 and which ones are typed by the user.
    Last edited by kgober; July 9th, 2019 at 07:36 AM.

  6. #6

    Default

    #1 - I wish it had a decimal mode, but as long as there is a way...

    #2 - Good ideas. Doesn't the VT420 send more than one ^S even if it is already held? At the first initial buffer point, and then also when the buffer is full? I could be wrong...

  7. #7
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    466

    Default

    Actually it might not work because according to page 78 of the reference manual (http://manx-docs.org/collections/mds...m/vt420rm2.pdf), The Ctrl+Q and Ctrl+S key combinations only send their corresponding control code when XON/XOFF support is turned off. The implication being that with XON/XOFF enabled, generation of these codes from the keyboard is blocked. It's possible that you might still be able to send ^S and ^Q using Compose followed by 2 hex digits but that seems so inconvenient that even if you could you probably never would.

    The issue of the VT420 sending multiple ^S characters (at the first XOFF buffer point, at the second XOFF buffer point, and for every character received when the buffer is full) is only a problem if the host continues to send characters after the first XOFF. if you are building the adapter then you'll be in a position to prevent this from happening.

  8. #8

    Default

    I'm no help with the VT420 (but I liked the VT240), but I appreciate that you mentioned Turbo Pascal. I used it a lot in the 80's, beginning with V1.0 on a Robin.

    Pete

  9. #9

    Default

    Hi Pete - I agree - there is something special about Turbo Pascal. I started on it in high school and learned a lot with it.

  10. #10

    Default

    kgober - I tested the ^Q and ^S and you are correct, the vt420 will not send them. I thought about using some sort of escape character to be able to send them, but with only two of them it hardly seems worth it to use an escape character, so instead I'm going to give the option of translating another key to ^Q and/or translating another key to ^S. When the RS232 bridge receives the other character from the vt420, it would translate it into a ^Q or ^S and then it on to the non-XON/XOFF side. This way you could map ^W if it did not need to be used for anything to ^Q for example. Of course you have to find another value not being used, but that shouldn't be too hard since it can compose characters anyway.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •