[Simh] SIMH console settings for escape sequence support

[Mark Pizzolato]

On Saturday, January 2, 2016 at 3:28 AM, Johnny Billquist wrote:
> On 2016-01-01 23:08, Mark Pizzolato wrote:
> > On Friday, January 1, 2016 at 1:02 PM, Johnny Billquist wrote:
> >> Um. What does 7B and 7P stand for here? They are not "normal"
> >> designation for 7 bits with some parity... The letters I know of are
> >> N - None, S
> >> - Space, M - Mark, O - Odd, E - Even.
> >>
> >> And if you are using anything that manage to print something visible
> >> when outputting a NUL, that sounds like something broken somewhere
> else.
> >>
> >> Sounds like the current simh code is trying to cover up when people
> >> have an error somewhere else in their setup?
> >
> > Actually, no.  Some simulated systems have very particular
> > expectations of the terminal devices which are connected to the
> > system.  They'll output 7bits of data with a parity bit.  In general
> > the parity bit isn't useful for essentially any modern system running
> > the simulator so 7P and 7B allow the parity bit to be stripped off
> > before the data is delivered to the local session.  Besides parity
> > bits, as Dave Bryan points out some of these simulated systems presume
> > they're talking to ASR Model 33 teletype terminals.  When talking to
> > these slow mechanical devices the simulated system often will insert
> > NUL or RUBOUT or other characters into the output character stream as
> > non-printing delays to accommodate the slow mechanical behavior of the
> > terminal when it may be repositioning the print head.  If you happen
> > to be running a simulator with a real Model 33 teletype terminal then
> > you would want to run the console port in 8B mode so all of the generated
> characters and parity bits get to the terminal, otherwise most folks will want a
> filtered mode.
> 
> I would like to point out that this is in no way ASR-33 specific. Using NUL
> fillers for delays was needed on *lots* of terminals, including even a VT100
> when running at higher speeds and doing some operations (like a linefeed).
> 
> So NUL characters was used a lot of the time. And there are also lots of other
> control characters defined in ASCII. And programs sometimes use them. And
> they have defined behaviors. 

The details of the filtering behavior are very configurable.

> And simh deciding to filter them all out is
> basically wrong. If you have a specific environment, in which you are not
> actually using a proper ASCII conformant terminal, then fine, have some way
> for simh to accommodate such brokenness. But don't assume it, and don't
> enforce it, and don't break everyone else because of it.

Since the behavior is configurable, simh isn't deciding or forcing anything on 
the user.  If you want every bit without any filtering configure the port/mux 
to 8B.

Meanwhile, having the output data filtered allows the "User visible" data to 
interact with SEND/EXPECT commands that may be defined in the simh 
environment in meaningful ways without having to be burdened with the 
potentially variable filler/invisible characters that may have been injected 
into the output data in somewhat arbitrary places.

- Mark