[Simh] Serial Console

[Johnny Billquist]

On 2012-07-04 11:00, Holger Veit wrote:
> 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!).

No. A big reason was/is that different equipment have different 
capabilities.

> 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).

Ha! And what is, pray tell, the "maximum baudrate"? It varies for the 
terminals that you use, and the interface they are connected to. Which 
means you must be able to adapt on both sides in order to have a working 
connection. The setting of baudrates are as important today as it was 30 
years ago.
The OP wanted to hook up a real DEC terminal. Now, a real DEC termnal 
have a max baudrate that very much depends on which terminal it is.
A VT220 can do 19200 bps. A VT320 I seem to remember the same. A VT420 
can do 38400. A VT520 can do 38400 as well, but I think it can actuallu 
do 115K. A real VT100 I think is limited to 9600.

On the system side, a DZ11 cannot be told to do more than 9600. A DH11 
also is limited to 9600, but also have two magic values (ExtA and ExtB). 
A DHU11 can do 19200.

I hope you start seeing the problem. Being able to set the baudrate is 
neccesary for a successful connection.

>> 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.

No? Why not? If I have my VT320, and I want to connect it to a serial 
port that goes in to the simh system, I think it makes sense that I on 
the simh console can tell the OS that TT1: should be running at 19200 
bps. I then set my VT320 to 19200 bps, and I connect it to the serial 
port, and at that point I would expect it to work. No?

> 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.

If we talk about tcp and telnet, it's a different story. There are no 
speeds, so that part can be ignored.
Also, there is always flow control, so that part needs to be handled. 
Sometimes that actually makes the emulation break.

	Johnny