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: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
