[Simh] PDP11 default terminal setting

[Johnny Billquist]

Bob...

On 2016-01-03 17:14, Bob Supnik wrote:
> The short form:
>
> I have no problem setting the default for PDP11 TTO to 7B instead of 7P,
> although I'm sure some old software will break. If this is done, though,
> I would suggest reverting the previous change to the printable character
> mask back to its original settings. The pdp11_dc.c default settings
> should also be set to 7B, because those always go through a TELNET session.

Like I said - I would prefer that simh didn't interfere unless people 
actually asked for it, but I do not have a strong preference.

> The long form:
>
> In the beginning, SimH only ran on VMS and Unix, both of which had
> excellent VT100-emulating terminal windows. At that time, all terminal
> IO was full 8b, with no masking. Things fell apart with the advent of
> the Windows port.

That word "windows" keeps popping up whenever there are problems. :-)

> To begin with, Windows interpreted characters 128-255 as unique, and not
> as variants of 0-127. So to get sensible output from systems that
> thought they were implementing KSR-33s (bit<7> forced to 1), there had
> to be a capability to mask to 7b. However, people ALSO used the terminal
> to talk to Kermit, so 8b capability was needed. This led to the
> introduction of general 7b/8b formatting.

Well, KERMIT can run just fine over a line that strips the eight bit, 
and also over lines that mess with some control characters, so it should 
still be usable. But then again, that also might need some tweaking to 
kermit settings, which people also seems to have a hard time 
understanding nowadays...

> There still were problems. Non-printing characters inserted into the
> output stream put utter crap in the Windows terminal window. That led to
> the creation of the 7P variant. This was done for the PDP11, in
> particular, because its early software tended to do fills for the early
> DEC terminals by outputting nulls, which Windows obligingly displayed as
> garbage. I can no longer pinpoint the software that caused problems,
> though, so I'm more than willing to let the user community rediscover
> the issues.

Oh, I don't have any problems pinpointing the software. It's called the 
operating system.
The RSX terminal device driver can do this for you, if asked to. And for 
some terminals, it does it by default.

.dev ti:
TT12:   [BQT]       [7,14]    3-JAN-16 20:08   1        J. BILLQUIST
         CLI   = CCL     BUF   = 80.     HFILL = 0
         LINES = 24.     TERM  = VT2xx   OWNER = none    NOPARITY
         CHAR_LENGTH = 8 PRINTER_PORT    NOPASTHRU       NOSERIAL
         LOWER   PRIV    NOHOLD  NOSLAVE NOESC   CRT     NOFORM  REMOTE
         ECHO    NOVFILL HHT     FDX     NOWRAP  NORPA   EBC     TYPEAHEAD
         NOCTRLC AVO     ANSI    DEC     EDIT    NOREGIS NOSOFT  NOBLKMOD
         HSYNC   BRO     NOABAUD TTSYNC  COLOR
         LINE_EDIT       INSERT
.help set hfill
   SET /HFILL=term:[value]

   Specifies the number of fill characters  (value) that the terminal
   driver places after a carriage return when sending output to a terminal.
   The range for value is 0 through 7.

   Term can be a logical name assigned to the terminal, or it can be the
   physical device and unit number for the terminal (ttnn:).

   When you omit value, the system displays the fill-character value
   for the specified terminal.
.help set vfill
   SET /VFILL[=term:]

   Enables the  vertical  fill characters option for the specified 
terminal.
   The option instructs the  terminal  driver to  add  four fill characters
   following each line feed.

   Term can be a logical name assigned to the terminal, or it can be the
   physical device and unit number for the terminal (ttnn:).
   When you omit =term:, the system displays all the terminals that have
   the /VFILL option enabled.

.

I'm pretty sure all DEC OSes have the same capability.
And when you say you have a specific terminal (or the OS identifies that 
for you), it sets these to "reasonable" values.

I could go on listing the defaults for different terminals, if anyone is 
interested.

In addition, a well known editor likes to grab ^S/^Q for its own use, 
meaning software flow control is no longer an option for the terminal, 
which cause that editor to also send lots of fills during some 
operation, if the terminal is at higher line speeds...

> It's important to remember that the PDP11 was introduced in 1970, with a
> Teletype as its standard terminal. The LA30 and VT50 (of late unlamented
> memory) weren't introduced until later, and the really useful terminals,
> the LA36 and VT100, later still.

Yes. And let's not forget the VT05. Not exactly a speed demon, even if 
it was a glass TTY...

> Finally, the Windows console window was always intended to emulate a
> hard copy terminal. On a multiuser PDP11 system, the console was usually
> a hard copy device, for logging. So the effort to do a VT100 emulator
> INSIDE the simulator seemed pointless, particularly because the console
> can be redirected to a TELNET application with a full VT100 emulator.

Agreed. I don't mind people having the mindset that the console is a 
printing terminal. But it should still not filter any characters normally.

Windows is the obvious special case we're talking about/dealing with. 
Either have normal defaults that makes sense assuming a normal 
environment, or if possible, explicitly detect that this is windows, and 
have it act differently there.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol