[Simh] SIMH console settings for escape sequence support

[Johnny Billquist]

On 2016-01-01 22:16, J. David Bryan wrote:
> On Friday, January 1, 2016 at 22:02, Johnny Billquist wrote:
>
>> Um. What does 7B and 7P stand for here?
>
>  From the "Writing a Simulator for the SIMH System" manual:
>
>     SIMH provides routines to convert ASCII input characters to the
>     format expected VM, and to convert VM-supplied ASCII characters to
>     C-standard format.  [...]  The supported modes are:
>
>       TTUF_MODE_8B: 8b mode; no conversion.
>
>       TTUF_MODE_7B: 7b mode; the high-order bit is masked off.
>
>       TTUF_MODE_7P: 7b printable mode; the high-order bit is masked off.
>       In addition, on output, if the character is not printable, -1 is
>       returned.
>
>       TTUF_MODE_UC: 7b upper case mode; the high-order bit is masked off.
>       In addition, lower case is converted to upper case. If the character
>       is not printable, -1 is returned.
>
>     The set of printable control characters is contained in the global
>     bit-vector variable sim_tt_pchar. Each bit represents the character
>     corresponding to the bit number (e.g., bit 0 represents NUL, bit 1
>     represents SOH, etc.). If a bit is set, the corresponding control
>     character is considered printable. It initially contains the following
>     characters: BEL, BS, HT, LF, and CR.
>
> So "7B" designates the set of 7-bit characters, and "7P" designates the set
> of 7-bit characters considered printable.

Aha. Thanks.

>> And if you are using anything that manage to print something visible
>> when outputting a NUL, that sounds like something broken somewhere
>> else.
>
> Tell it to Microsoft.  ;-)  Putting a Windows console window into "raw"
> mode, as the simulator does when it's running, prints control characters as
> graphic symbols.  That interferes with programs running under simulation
> that expect echoed control characters to be non-printing.

I'd say that such a "terminal" should not be used then. A basic 
requirement that it supports ASCII should be reasonable. That thing 
obviously do not do ASCII. I don't mind there being support for such a 
broken thing, but why have it as default. If someone use such a broken 
then, then they should adjust things to whatever brokenness is in their 
environment. But no need to break things for people who actually have 
proper equipment.

	Johnny

>
>                                        -- Dave
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>

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