I'd concider a DEC-server 900, or possibly a DEC-server 90,
communicating over TCP/IP. Use that for a console connection from your
VT-xxx to the SIM-H console port.
That would give a connection with "total DEC devotion", most surely
working properly also.
Some yerars ago, I found a program for M$ W-?? (like 2000 or XP, can't
remember) that presented itself to be a TCP/IP server using COM-port for
I/O, this worked "a bit" but not right 100%, though I can't say exactely
what link of a long communications chain that really lost those final
%... I can check program name etc tomorrow if some-one wants to have it.
I used it for a LAP-top running VPN over public Internet, into a
corporate network where a VAX was running DEC TCP/IP and DECnet, and I
wanted to use a proper VT-320 terminal with full keyboard for off-site
access (ie from a distant site that wasn't directely connected).
On 2012-07-03 13:38, Mark Benson wrote:
On 3 Jul 2012, at 12:03, Johnny Billquist <[email protected]> wrote:
On 2012-07-03 11:49, Mark Benson wrote:
Simple question: Can SimH's CONSOLE output be directed to a Serial port
(i.e. via /dev/ttyS0)?
If so how does it handle waiting for a terminal connection?
If not, is there a reason why?
I think I looked into this a few years ago, and found that it can't. There is
no absolute reason why it would not be able to, but exactly how you control a
physical serial port differs between OSes, so I suspect it would be hard to
write generic.
Ah, that makes sense, yes, different OSs use different device names
etc. even within common UNIX methods. This wouldn't be such a big
hurdle if the onus was on the user to provide the full device path
though. That, of course, doesn't help with Windows or VMS but it might
widen it's UNIX campatibility?
However, I think that under Unix, if you just log in on a serial port and start
simh, you'd be more or less there already?
No, you see what I would like to do is connect a VT terminal directly
to SimH to use either as the OP console or to provide a real VT access
for the DZV11 emulation. This is all about cutting out multiple layers
if terminal emulation to get real VT interaction direct to the
emulator.
The reason is I have noticed that over Telnet VMS is pretty robust but
only offers a 'cut down' cinnection to remain compatible. Conversely,
GNU screen working directly as the console convinces VMS that it's a
real VT then it pukes when you run something like EVE or
TCPIP$CONFIG.COM because VMS is assuming the terminal can handle
features that screen cannot. There are also other things like
softloaded fonts etc that only real VT terminals handle properly that
break ir don't work in screen or telnet.
It'd be nice to hook the VT510 up and use that instead... wasjyst a thought.
As for terminal emulators... I've heard much fine words upon that one
that was included with DEC Pathworks. I used it back in those days (the
PC/AT was a fast computer;-), but I can't say I have a running copy
these days, sadly enough.
This one communicated using DEC-net (can't even remember if LAT
alos...), I guess it wont make TCP/IP even if it would be installed on
the same PC...
All my best,
Göran
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
