"Hugh_Messenger.EuroPARC"@Xerox.COM (10/03/88)
Hi, I've only just subscribed to Info-Atari16, so no flames if this is an old, old question .. I'm having hassle with the VT52 emulator DA. I use a Dowty Quattro modem, talking at 2400, 7 bits, one stop bit, even parity, flow control on, full duplex. As I am currently only using it to read my email from home, I'm not using any comms packages, just the emulator. It is running on a Mega ST4. It all works just fine for a while, then the Atari seems to to chuck out a massively long string of nuls (^@'s), interspersed with everything I have typed so far in the session. Once it finishes outputting everything I have typed (including my password in legible format!) it carries on working just fine, for a few minutes, then .... you guessed it ... ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@1itscambsitshippo********yyy12,45,67nnn^@^@^@^@ [etc etc etc]. I am fairly sure that the Atari is responsible for the spurious crap, as the TX light on the modem is lit while the above is happening. Another slight annoyance is that when I log in to any Un*x systems (most often a Sun 3/140 running SunOs 3.4), the terminal type is not recognised and defaults to DM2500. set term=vt52 works OK, but surely the emulation should answer Un*x's request for terminal identification? Or is SunOs getting it wrong, after all, we all know what terrible machines Suns are :-) Any suggestions, answers, hints, gratuitous insults etc gratefully received. -- Hugh ARPA: Hippo.EuroPARC@Xerox.COM UUCP: Who knows? Something with !'s in it.
greg@bilbo (Greg Wageman) (10/06/88)
In article <881003-055901-3134@Xerox> "Hugh_Messenger.EuroPARC"@Xerox.COM writes: >Hi, Hello. >I'm having hassle with the VT52 emulator DA. My immediate impulse is to tell you to get a better program, such as the shareware "Uniterm" program. >It all works just fine for a while, then the Atari seems to to chuck out a >massively long string of nuls (^@'s), interspersed with everything I have >typed so far in the session. Once it finishes outputting everything I have >typed (including my password in legible format!) it carries on working just >fine, for a few minutes, then .... you guessed it ... >^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@1itscambsitshippo********yyy12,45,67nnn^@^@^@^@ Sounds to me like a ring buffer is being overrun, causing pointers to cross and point into memory where they shouldn't. It's a bug, you can't fix it except by dropping the baud rate to 1200 or less. >Another slight annoyance is that when I log in to any Un*x systems (most >often a Sun 3/140 running SunOs 3.4), the terminal type is not recognised >and defaults to DM2500. set term=vt52 works OK, but surely the emulation >should answer Un*x's request for terminal identification? Or is SunOs >getting it wrong, after all, we all know what terrible machines Suns are [ smiley at end of the above deleted. Just so's you know. ] No Un*x that I know of queries for terminal type, since most dumb terminals wouldn't respond anyway. The terminal type on SunOs 3.4 can be set in several ways. In the file "/etc/ttytype", there is a list of terminal ports, and the associated terminal type (taken from an entry in the "/etc/termcap" file). For example, you might see a line that says, "vt100 ttya". This would determine the default terminal type for that port. You can override this in your ".login" file using the "stty" command, with a few lines like: set t=(`tset -S -m 'dialup:?vt52' -m 'unknown:?vt52' -m 'network:?vt52'`) setenv TERM $t[1] setenv TERMCAP "$t[2]" unset t This does several things. First, if the default terminal type (from /etc/ttytype) is "dialup", "unknown", or "network" (this is undocumented, but what you get when you do "rlogin" over ethernet), the terminal type is set to "vt52". It also causes the shell variable "t" to be set to contain two strings; one is the terminal type (in this case "vt52", and the second is the /etc/termcap entry data for that terminal. Then it sets the environment variables TERM and TERMCAP to the appropriate strings, and un-sets "t". This will make programs that use termcap capabilites start up much quicker, since they get the TERMCAP string from the environment, instead of from the /etc/termcap file, which can be huge. Hope this helps. Greg Wageman ARPA: greg%sentry@spar.slb.com Schlumberger Technologies BIX: gwage 1601 Technology Drive CIS: 74016,352 San Jose, CA 95110 GEnie: GWAGEMAN (408) 437-5198 UUCP: ...!decwrl!spar!sentry!greg ------------------ Opinions expressed herein are solely the responsibility of the author.
to_stdnet@stag.UUCP (10/08/88)
From: thelake!steve@stag.UUCP (Steve Yelvington) greg%sentry@spar.slb.com (Greg Wageman) writes... > In article <881003-055901-3134@Xerox> "Hugh_Messenger.EuroPARC"@Xerox.COM > writes: > >Hi, > > Hello. > > >I'm having hassle with the VT52 emulator DA. > > My immediate impulse is to tell you to get a better program, such as > the shareware "Uniterm" program. > > >It all works just fine for a while, then the Atari seems to to chuck out a > >massively long string of nuls (^@'s), interspersed with everything I have > >typed so far in the session. Once it finishes outputting everything I have > >typed (including my password in legible format!) it carries on working just > >fine, for a few minutes, then .... you guessed it ... > >^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@1itscambsitshippo********yyy12,45,67nnn^@^@^@^@ > > Sounds to me like a ring buffer is being overrun, causing pointers to > cross and point into memory where they shouldn't. It's a bug, you > can't fix it except by dropping the baud rate to 1200 or less. If the problem is in the ST's auxiliary port ring buffer, yes, it can be fixed. Relocating the iorec is reasonably easy. (If anyone would like a code sample, send me mail.) Tom Zerucha wrote a little utility that resizes the aux buffer. Look around for a TRANS127.ARC file on your local BBSes. It includes Tom's file-transfer desk accessory, a command-line file xfer program (wxytr.ttp), and a couple of utilities including the iorec resizer, which you can toss in \auto\ and forget. All that aside, I can't imagine HOW you could overflow the buffer at anything less than 19.2kbps. Try playing with the flow-control settings. | thelake!steve@stag.UUCP / ...rosevax!pwcs!stag!thelake!steve