Does BSD 2.11 support 8N1 serial terminal hookups?

[David Conners]

I picked up an IBM 3151 for a very decent price recently and have it attached to my PiDP-11 via a serial-USB converter. SIMH owns the serial port so AFAIK all the communication configuration is done via the /etc/gettytab entry for the terminal.

I have it all working with a 7E1 configuration just fine, but have started experimenting with the alternate graphics characters that the terminal supports.

The IBM documentation states that if 8 bit mode I can just set the high bit of the character to access the alternate characters which seems more convenient than the only method I have currently working (switching the character set to the graphics characters, sending the graphics characters, switching back).

Later versions of gettytab seem to support a "np" (No Parity) setting but the man page for the 2.11 BSD gettytab has no mention of it and does not seem to recognize the setting when I try adding it in.

I'm assuming that means that I am out of luck if I want to do 8N1 comms with the serial terminal under BSD 2.11, but hey I was never an admin on one of these boxes back in the day (only a CS student at the time these were around) so figured I'd ask.

Not a big deal, more an opportunity to learn.

Cheers

David

[Johnny Billquist]

(another repost...)

Not sure why you just look at gettytab.

In stty, you have the pass8 option, and you can also set the line to
just not have parity as well.

Just check the man-page for stty...

And yes, 2.11BSD do support 8-bit clean communication. Until something
like 25 patches ago, it didn't work on the console specifically, but all
other lines. But it was fixed for the console there too.

Johnny

On 2023-04-05 19:09, David Conners wrote:
[...]

> Later versions of gettytab seem to support a "np" (No Parity) setting
> but the man page for the 2.11 BSD gettytab has no mention of it and does
> not seem to recognize the setting when I try adding it in.
>
> I'm assuming that means that I am out of luck if I want to do 8N1 comms
> with the serial terminal under BSD 2.11, but hey I was never an admin on
> one of these boxes back in the day (only a CS student at the time these
> were around) so figured I'd ask.
>
> Not a big deal, more an opportunity to learn.

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

[David Conners]

Thanks Johnny

I guess it was naive to assume that gettytab would have all of the options for configuring communications.

I did a bunch of testing using your stty recommendation and I have been unable to get 8-bit clean output under BSD even with the aid of stty.

Using stty with the pass8 option *does* enable the terminal to be configured as 8N1 and function.

- In pass8 mode I get 8-bit clean input

- In pass8 mode sending 8-bit characters to the terminal results in the high bit being stripped.

My simple test was to put the terminal into line drawing mode (which enables sending extended characters from the terminal) and enabling local echo (so I could see how the terminal was rendering the character I typed).

Using readchar() I dumped the input of typing the '┬' character. This resulted in:

1. the local echo showing '┬'

2. the host sending back 'w' 

3. readchar() returning 247

To further eliminate there being some weird display mode issue I stopped simh, used the linux host to set the tty to pass8 mode and wrote the 247 character directly to the tty and was able to see '┬' displayed on the terminal. The linux version of stty includes a cs8 setting (that is included in pass8) that sets the character size to 8, that is not available in the BSD 2.11 stty AFAICT.

The man page for stty under BSD states that pass8 affects input and does not mention output. The parity settings (odd and even) also state that they affect input and seem to be overridden by the pass8 setting in any case.

I tried litout but that did not seem to impact the high bit output (and messed up carriage returns). I've not been able to determine any other stty settings that might impact the 8-bit ness of the output.

Cheers

David

[Johnny Billquist]

David - first of all, this might be something with simh. What does your
config for simh look like?

And yeah, gettytab should probably get updated.

Also did a bit of testing using telnet. I created a file with some
characters with the high bit set.

simh:/home/bqt> od -c test
0000000 344 366 345 \n
0000004
simh:/home/bqt> cat test
äöå
simh:/home/bqt> stty -pass8
simh:/home/bqt> cat test
dve
simh:/home/bqt>


I hope that comes across right, as the first cat test gives outputs
which are correct. So clearly pass8 affects also output.


Anyway, I can play a bit more with simulated serial ports, including the
console later. But clearly I can get 8 bit clean input and output in
2.11BSD. However, with telnet, I need to set it to binary mode,
otherwise telnet is also stripping characters, no matter what I do on
the 2.11BSD side.

Johnny


On 2023-04-12 18:28, David Conners wrote:
> Thanks Johnny
>

[...]

[Warner Losh]

On Wed, Apr 12, 2023 at 10:42 AM Johnny Billquist <b...@softjar.se> wrote:

However, with telnet, I need to set it to binary mode,
otherwise telnet is also stripping characters, no matter what I do on
the 2.11BSD side.

Telnet is a 7 bit protocol... binary mode is weird too, since it kinda forces 'raw'

mode which both sides might not always agree on depending on which telnet

client you use. There are different flavors that tried to give an 8-bit clean connection,

but they interfered with telnet's inband signalling (hence the disconnect).

Warner 

[David Conners]

The relevant section from the boot.ini I believe is

; set one DZ11 8 line async mux

; accessible via telnet to 127.0.0.1:4000...4007

set dz enabled

set dz lines=8

set dz 8b

;attach -am dz 4000

attach dz 4000

attach dz -V line=1,connect=/dev/ttyUSB0

;

sho dz

I don't know SIMH well enough to know if there are other places I need to be looking.

The boot.ini originally had set dz 7b but changing it did not seem to make any difference.

Cheers

David

---

From: pid...@googlegroups.com <pid...@googlegroups.com> on behalf of Johnny Billquist <b...@softjar.se>
Sent: Wednesday, April 12, 2023 9:42 AM
To: pid...@googlegroups.com <pid...@googlegroups.com>
Subject: Re: [PiDP-11] Does BSD 2.11 support 8N1 serial terminal hookups?

 

--
You received this message because you are subscribed to a topic in the Google Groups "[PiDP-11]" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-11/yuIL2oD6OGc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6f67faa8-6ac9-04d6-1964-46f355d3ecad%40softjar.se.

[Mark Pizzolato]

simh telnet connections are ALWAYS negotiated as 8 bit clean and 8 bits of data moves from simulator to telnet client without regard to setting of 7B or 7B in the DZ device or the simulated OS use of the port.  The 8 bits of data (possibly containing parity if the simulated OS is doing that) move back and forth between the simulated OS and the client application.

[Johnny Billquist]

No. telnet is definitely not a 7-bit protocol. And there is no
interference with the inband signalling.

Yes, by default telnet uses 7-bit mode. But the only character reserved
in the telnet protocol is 255, which is used to prefix all signalling.
And if you actually want to transfer a 255 as data, it will be encoded
as 255 255. So there are absolutely no problems as such anywhere in here.
The 7-bit default is basically because back then, it was normal, and you
also have (had) some systems which actually only used 7 bits.

Johnny

[Johnny Billquist]

Well, I suspect you are on the console, which is not a dz.

And it's actually controlled by two devices. TTI and TTO.

The version of simh I'm running is a bit old, and something funny is
going on in there. I'll investigate more.

But anyway, setting TTI and TTO to 8b should make them clean. But I can
get output of characters with the 8th bit set, but they get stripped on
input on the console.

But I think we're getting too many things in the mix here.

From my side I can confirm:

. it is possible to get 8-bit clean 2.11BSD on a telnet session, both in
and out.
. it is possible to get 8-bit clean 2.11BSD on the console, both in and out.
. it is possible to get 8-bit clean 2.11BSD on a dz, but only input.
Output seems to disappear somewhere or something funny.


Johnny

On 2023-04-12 20:03, David Conners wrote:
> The relevant section from the boot.ini I believe is
>
> ; set one DZ11 8 line async mux
> ; accessible via telnet to 127.0.0.1:4000...4007
> set dz enabled
> set dz lines=8
> set dz 8b
> ;attach -am dz 4000
> attach dz 4000
> attach dz -V line=1,connect=/dev/ttyUSB0
> ;
> sho dz
>
> I don't know SIMH well enough to know if there are other places I need
> to be looking.
>
> The boot.ini originally had set dz 7b but changing it did not seem to
> make any difference.
>
> Cheers
>
> David
>
>

> ------------------------------------------------------------------------
> *From:* pid...@googlegroups.com <pid...@googlegroups.com> on behalf of
> Johnny Billquist <b...@softjar.se>
> *Sent:* Wednesday, April 12, 2023 9:42 AM
> *To:* pid...@googlegroups.com <pid...@googlegroups.com>
> *Subject:* Re: [PiDP-11] Does BSD 2.11 support 8N1 serial terminal hookups?

> <https://groups.google.com/d/topic/pidp-11/yuIL2oD6OGc/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to
> pidp-11+u...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/6f67faa8-6ac9-04d6-1964-46f355d3ecad%40softjar.se <https://groups.google.com/d/msgid/pidp-11/6f67faa8-6ac9-04d6-1964-46f355d3ecad%40softjar.se>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/LV2PR19MB576583FC7F1FF703FE752176A39B9%40LV2PR19MB5765.namprd19.prod.outlook.com <https://groups.google.com/d/msgid/pidp-11/LV2PR19MB576583FC7F1FF703FE752176A39B9%40LV2PR19MB5765.namprd19.prod.outlook.com?utm_medium=email&utm_source=footer>.

[David Conners]

I'm definitely not on the console.

The serial terminal is connected to the host device /dev/ttyUSB0 which is linked into the dz as per the boot.ini and shows up as /dev/tty01 in BSD

your experience on dz matches mine (8 bit clean on input only).

Cheers

David

[Johnny Billquist]

Hi

On 2023-04-12 21:17, David Conners wrote:
> I'm definitely not on the console.

Ok. Sorry for making that assumption.

> The serial terminal is connected to the host device /dev/ttyUSB0 which
> is linked into the dz as per the boot.ini and shows up as /dev/tty01 inBSD
>
> your experience on dz matches mine (8 bit clean on input only).

Yeah. In a way, it would seem you might actually have had more success
if it was on the console.

This really seems to be something broken in simh. I even turned out
various debugging, and no output to the dz happens at all for characters
with the high bit set. So it would seem they get dropped in some more
core part of simh. Looking around a bit, but haven't found any smoking
gun so far.

I have this simple file that I showed before. If I do stty -pass8, the
characters are output as expected, but with the high bit stripped.
If I do stty pass8 before cat:ting the file, *nothing* comes out, and
it's almost as if simh stalls the terminal line for some time. Takes
quite a few seconds before I get the shell prompt again.

Mark, this seems such an easy thing to reproduce. Could you try it.

My file looks like this:

simh:/home/bqt> od -c test
0000000 344 366 345 \n
0000004
simh:/home/bqt>

And if I cat it on a dz line (connected to a telnet port), I get "edv"
if I don't have pass8, but get nothing if I do have pass8.

I should be getting "äöå" if I have latin-1 charset.

Hmm... Is there some clever utf-8 parsing going on in there??? Obviously
there shouldn't be. The bytes should be written to the DZ registers, and
that's the end of it, but it appears not to happen.

Johnny

[Johnny Billquist]

Ha! I think I might have figured it out.
And the problem is not simh if I'm right, but actually the dz driver in
2.11BSD.
Investigating a bit more, but there might be a new patch coming up for
2.11BSD for this...

[Johnny Billquist]

Bingo! Bug found and fixed. New patch for 2.11BSD will come. This is
specifically just the dz driver in 2.11BSD, which drops all characters
with the high bit set on output, and cause a timeout delay for each such
character. No idea why the code was that way. No other driver have this...

Johnny

[Johnny Billquist]

I've created a patch for this problem now, and send to Steven for
distribution.

In the process, I also added "np" to gettytab, to make life easier in
the future, and fixed a bug in login that made some flags not actually
take effect at login from gettytab.

I'll post when the new patch is out for people to download.

Johnny

[Johnny Billquist]

Aaaand the patch is out. #480. To be found in the usual places. Apply
it, and any other patches you might not have applied, and then things
should work as expected.

[David Conners]

Thanks Clem.

I took a quick pass through the tty*.c code in sys and see some high order bit masking going on but have not unraveled it far enough to see if it conditional or universal.

After some more research I decided to just go down the path of dealing with the 7-bit escape sequence approach, as that seems more portable (e.g., if I ever pickup a more period appropriate serial terminal), and am now happily coding like I'm in 2^nd year comp sci again.

Cheers

David

---

From: Clem Cole <cl...@ccc.com>
Sent: Wednesday, April 5, 2023 12:25 PM
To: David Conners <da...@conners.com>
Cc: [PiDP-11] <pid...@googlegroups.com>
Subject: Re: [PiDP-11] Does BSD 2.11 support 8N1 serial terminal hookups?

 

An interesting question -- the tty driver will support 8-bits in RAW mode as V6 and V7 did that, but I think you want something different.  LITOUT (literal output - no translation) was added to the 4.1 BSD tty driver, but it may have been even earlier with BSD 3.0 or 4.0 (look at the online sources in TUHS.org or disk1 of Kirk's collection).  PASS8 (8-bit input) was a 4.3 BSD addition - IIRC LITOUT was output only.  A big issue is the DH, DZ and KL drivers themselves - I would not be surprised that they AND off the high bit with 0177 on input unless RAW is set.  I'm fairly sure that the V7 tty driver does that.   Take a look at the sources and grep through the drivers and sys/*tty.c looking for 0177 -- i.e. the idiom will be some assignment with an expression in the form: c &= 0177. 

However, it may be that getty if the problem here... IIRC getty defaults to 7b even parity, unless "op" is set -- I thought there was an "ap" for any parity but I don't remember.  And I have not messed with 2BSD in years - Warner Losh and the folks on the TUHS mailing list for a definitive answer.  Since anything past the original 2 BSD was originally Keith pulling kernel features from Vax-based 4X BSD and making them work on the 11, certainly by 2.10 BSD LITOUT support is there so 2.11BSD should have it.     The question is if that is good enough for you and how to convince getty to set it up. 

Best wishes, hope this is helpful.

Clem

ᐧ

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/f97d0396-bd87-43c8-8cc8-e3becedb3d7cn%40googlegroups.com.

[Johnny Billquist]

Not sure why you just look at gettytab.

In stty, you have the pass8 option, and you can also set the line to
just not have parity as well.

Just check the man-page for stty...

And yes, 2.11BSD do support 8-bit clean communication. Until something
like 25 patches ago, it didn't work on the console specifically, but all
other lines. But it was fixed for the console there too.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/f97d0396-bd87-43c8-8cc8-e3becedb3d7cn%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/f97d0396-bd87-43c8-8cc8-e3becedb3d7cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

David - first of all, this might be something with simh. What does your
config for simh look like?

And yeah, gettytab should probably get updated.

Also did a bit of testing using telnet. I created a file with some

characters with the high bit set.

simh:/home/bqt> od -c test
0000000 344 366 345 \n
0000004

simh:/home/bqt> cat test
äöå
simh:/home/bqt> stty -pass8
simh:/home/bqt> cat test
dve
simh:/home/bqt>


I hope that comes across right, as the first cat test gives outputs
which are correct. So clearly pass8 affects also output.


Anyway, I can play a bit more with simulated serial ports, including the
console later. But clearly I can get 8 bit clean input and output in
2.11BSD. However, with telnet, I need to set it to binary mode,
otherwise telnet is also stripping characters, no matter what I do on
the 2.11BSD side.

Johnny

On 2023-04-12 18:28, David Conners wrote:
> Thanks Johnny
>
> I guess it was naive to assume that gettytab would have all of the
> options for configuring communications.
>
> I did a bunch of testing using your stty recommendation and I have been
> unable to get 8-bit clean output under BSD even with the aid of stty.
>
> Using stty with the pass8 option *does* enable the terminal to be
> configured as 8N1 and function.
> - In pass8 mode I get 8-bit clean input
> - In pass8 mode sending 8-bit characters to the terminal results in the
> high bit being stripped.
>
> My simple test was to put the terminal into line drawing mode (which
> enables sending extended characters from the terminal) and enabling
> local echo (so I could see how the terminal was rendering the character
> I typed).
>
> Using readchar() I dumped the input of typing the '┬' character. This
> resulted in:
>
> 1. the local echo showing '┬'
> 2. the host sending back 'w'
> 3. readchar() returning 247
>
> To further eliminate there being some weird display mode issue I stopped
> simh, used the linux host to set the tty to pass8 mode and wrote the 247

> character directly to the tty and was able to see '┬' displayedon the

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/2c8e572a-4b2a-45c3-b2c6-5ea1adf7e1a0n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/2c8e572a-4b2a-45c3-b2c6-5ea1adf7e1a0n%40googlegroups.com?utm_medium=email&utm_source=footer>.