[Simh] Serial Console

[Holger Veit]

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 <psvsimh at psv.nu> 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