Thanks to everyone for their quick responses. To my surprise, Xon/Xoff was turned off on the VAX, specifically, SHOW TERM TTA0 showed No HostSync. However SET TERM/PERM/HOSTSYNC TTA0 made no difference.
I have tried setting the line speed to 2400, but that only slows down the output. It still contains the same characters, to the extent that I can tell. I will continue to experiment and I will try using a different computer so that the serial port hardware is (presumably) different. If I can't solve it, I will indeed create an issue on github as Mark suggests. Cheers Peter Allan On 5 December 2017 at 19:30, Mark Pizzolato <m...@infocomm.com> wrote: > On Tuesday, December 5, 2017 at 10:08 AM, Paul Koning wrote: > > Do you have flow control (Xon/Xoff) enabled both on the terminal and on > the > > VAX? > > > > You might try a slower speed to see if that makes a difference. It > shouldn't, > > but it might give more information. > > > > Is autobaud enabled on the line? You might turn that off and set the > speed > > and related parameters explicitly. > > These are all great suggestions. Autobaud should definitely be turned off > on > the VMS side, but I don't think that is the problem since he's able to > login > and the commands he types produce output, which merely is garbled. > > A slower speed, which is explicitly stated on the ATTACH command might > help. > sim> ATTACH DZ LINE=0,CONNECT=SER0;2400-8N1 > > I think that what you're seeing is output from the simulator overrunning > the host OS provided interface to the serial port. This came up a while > back. > The simulator serial port interface delivers data to the host OS driver one > character at a time as it is emitted by the simulator. The simulator is > notified of I/O completion when the host OS said the IO was complete. > On some operating systems, this completion notification merely indicated > that the data had made it to a kernel buffer and not actually out through > the hardware. This early completion indication then was passed back > through the simulator and more data was then emitted. Ultimately it seemed > that there was not a reliable way to know that the data has actually, not > only > made it to the hardware, but actually been transmitted. Some relatively > common serial ports have an output buffer in the hardware that will take > a number of characters to be transmitted as quickly as the host puts them > into the hardware, and then deliver it outbound after the fact. In any > case > due to the problem of not getting a precise indication from the OS driver > of > when the data actually made it out the serial port, an alternative approach > was taken. This approach attempts to time the delivery of character I/O > data to the OS driver by explicitly scheduling the I/O completion time > based > on the port specified speed. This approach presumes that the OS actually > starts to send some of the data to the serial port when it is presented and > doesn't hold off until some buffer full condition is achieved. > > If the above ATTACH suggestion doesn't work for you, please create an issue > at https://github.com/simh/simh/issues and we can try to dig into this > further. > > > > On Dec 5, 2017, at 12:56 PM, Peter Allan <petermal...@gmail.com> > wrote: > > > > > > I am trying to get a real VT420 terminal working with a simulated > micro VAX > > 3900. However, I am having problems getting text displayed on the screen > of > > the VT420. > > > ... > > > Once the microVAX has booted, if I hit Enter on the VT420, then I can > see > > that a login process starts on the simulated microVAX, but all I see on > the > > screen of the VT420 is a few garbage characters. Despite that, when I > type a > > username and a password, I do get logged into the simulated microVAX. Any > > commands that I type on the keyboard of the VT420 appears on the screen > of > > the VT420 (except the password, of course), but anything that the > microVAX is > > sending to the VT420 appears as garbage. There are recognisable > characters, > > but if I TYPE a file, even a small one, what appears seems to be every > 7th > > character from the file starting with the first character. The output of > > commands such as DIR appear to have the same problem. ... > > _______________________________________________ > > Simh mailing list > > Simh@trailing-edge.com > > http://mailman.trailing-edge.com/mailman/listinfo/simh >
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh