Am 03.07.2012 20:16, schrieb Johnny Billquist:
On 2012-07-03 19:46, Jan-Benedict Glaw wrote:
On Tue, 2012-07-03 18:58:15 +0200, Peter Svensson <[email protected]> wrote:
On Tue, 3 Jul 2012, Jan-Benedict Glaw wrote:
What about other solutions? I haven't used the simulated DZ up to now,
but if I get it, it maps the serial ports to (telnet'able) IP/Port
network sockets, right?
If so, why not simply write a little program to configure the serial
port and splice it to the network socket? Or a small script using
`stty' and `nc'?
Baud rate changes, modem control lines and so on. Break handling.
Okay, you won't really get modem control lines. Baud rate changes
won't work, too, but were they *really* used in the wild? I doubt it.
Baud rate changes were used a lot. Atleast on DEC systems. But even more
importantly, if you don't implement it, you will have to make a decision
somewhere as to what speed to use, and the terminal have to adapt to
that. This might not always be possible.
Surely, they were be used. But why? For the same reason we nowadays use
DHCP, USB, BONJOUR and other technology - harshly spoken, the users were
and are idiots who cannot figure out the right setting if more than two
alternatives were provided: this damn terminal does not work
out of the box (yes, it was constructed to be connectable to more than a
single machine!).
Emulators and a glass terminals are nowadays no longer in the hands
of end users; and I have yet to find someone who does not set the
maximum baudrate that will work for a given terminal/emulator
connection, other than for the nostalgical demonstration "see how slow
computing was those days" (and even in this case: in contrast to the
real iron, the emulator can be, in principle, artificially throttled
to give a "realistic feeling" if one actually wants that).
Auto baud detection. Not at all uncommon... And having different speeds
on some terminals, for whatever reason... Depends on how you generate
the system. The speeds of the terminal ports are set by the OS at boot
time.
Besides being an API matter - somehow the OS must itself set the
appropriate (emulated) hardware bits, and the emulator could react to
such changes - there is hardly any reason that the emulator actually
needs to react in the same way the hardware would do.
The fall of mankind was already done with a telnet interface to
an emulated terminal multiplexer - TCP/IP has no concept of baudrates,
so the emulator has to take measures anyway in order not to flood the OS
with data it expects to arrive at lower rates.
And break handling? Right, important for a console. But for eg. simply
using a glass terminal or a modem for PPP or something like that, that
probably won't be much of a problem.
Depends on what software you are running. Software can detect and deal
with breaks. If you can't send them, you might be limiting yourself.
On consoles. What was the key to press when SIMH runs in a cygwin shell,
COMMAND.COM, xterm, through a terminal emulator?
--
Holger
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
