[Simh] pdp11 - console input with high bit set

[Paul Moore]

I am trying to run an RK11 diagnostic and am stuck.

The diagnostic asks the user how many drives to test and I can get the input to work

Looking at the code, it is looking for digits and then cr.

But it is actually looking for #215, which is 0x8d. Which is CR with the high bit set. (It also looks for #377 del with HB set)

So what happens is that it just keeps reprompting

I don't see how that character ever gets into the system. I did 'set tti 8b' but it made no difference. I can post the relevant code if needed.

[Ethan Dicks]

Johnny, I don't know what that means for simh

On an xterm session, there may not be a way to do it. If you were
running simh from a dumb terminal on a serial port, you could set your
terminal to do 7E1 (even parity), and possibly a matching "stty
parenb -parodd" , but the arg 'parenb' appears not to be valid from a
window session.

Sent: Friday, July 24, 2020 1:37:27 AM
You need to have your terminal set to MARK parity.

Post by Paul Moore
I am trying to run an RK11 diagnostic and am stuck.
Looking at the code, it is looking for digits and then cr.
But it is actually looking for #215, which is 0x8d. Which is CR with
the high bit set. (It also looks for #377 del with HB set)
So what happens is that it just keeps reprompting
I don’t see how that character ever gets into the system. I did ‘set tti
8b’ but it made no difference. I can post the relevant code if needed.

Does "set tti 7p" work for this?

-ethan

[Paul Koning]

Not helped by not knowing what KSR really means.

Keyboard send receive. A model 33 teletype without paper tape.
ASR was the model with paper tape, Automatic send receive.
DEC used teletype's that generated mark parity. From the manuals keyboards were
available to generate other parity. A reasonable amount of old code for
PDP-8's assumed mark parity. Later code ignores the upper bit.
I thought the high bit setting would be turned off if you used set tti 7b or
8b but never verified.

7b, yes. But that only helps with software that sets the top bit on output, as some old Unices do. It doesn't help with the problem Paul M raised, which is software that insists on mark parity input.

The right answer would be a tweak to the console emulation in SIMH pdp11. I wonder if this was done for PDP8 and not PDP11 because it was known to be needed on the one but people hadn't run into it for the other.

paul

[Ethan Dicks]

Anyway, I think the 'right' answer for simh is to ask the user to use a serial
emulation program that can generate any of: 8-bit no parity, 7-bit no parity,
or 7-bits of data plus an 8th parity bit with any of the 4 parity options: odd,
even, mark (aways 1) or space (always 0). Seems to me, simh should
bring 8 bits into the simulated serial port and let the SW running on the
system decide what it's going to do with it.

About 15 years ago, I encountered a terminal emulation problem running
Emacs on TOPS-20 on klh10 (which I needed to edit network
configuration files). In the end, I connected a real DEC terminal via
hardware serial port, set the port up with getty, logged into Linux
over the terminal, then ran simh there. Emacs ran perfectly on the
real terminal.

This is not a good solution for Windows, but it works great for UNIX
and UNIX-like OSes that let you log in from somewhere other than the
keyboard and screen.

-ethan

[Clem Cole]

How often you got parity errors was a function of modem generation and
line quality - acoustic couplers from your house in the country were good
for frequent parity - and mult-bit - errors.

Amen ... I remember those days - calling to a GE 635 with an acoustic
coupler [and an ASR33] running DTSS in '67.

Current loops - especially when optically coupled - were actually quite
good.

That was always my impression. I remember seeing optically coupled 20 ma
links in a couple of factories style (press rooms) for this reason at the
Pittsburgh Press and the Philadelphia Inquirer. They ran that way until
the MI folks replaced that whole thing with optical networking gear
??Protean maybe/I think?? when we replaced it all in a project the early
1980s [I was part of the original design, but not the deployment. I just
remember going to the site to see what was there].

Extending RS232 beyond the 25 ft spec could get problematic.

McNamara has a wonderful piece - "How far, how fast" which he capped at
9.6K baud. I kind of chuckle today as current gear goes at speeds like
115.2K and the scroll menu on the 'serial' apps displays as fast as
926.6K. But 115.K is pretty much now the standard out of the console
serial port from things that use "Cisco Pinning" of an RJ45 with RS-232E
signaling (like my new Ubiquiti GW/FW).

Yes, 3,000 ft was quite possible. But sensitive to environment.

UCB's Berk-Net --- 2 wire plus a common ground, 9.6K lines across UC
Berkeley's campus, building to building. No optical isolation either - so
we occasionally blew out the 488/489 drivers in the Able DMAX's that they
connected. Hey, it worked amazing well before the first Ethernet was
installed.

Like anything, it helps to read, understand, and conform to the
specifications...

Amen.
Clem

[Paul Moore]

I have hacked the TTUF_KSR flag here

uptr->buf = sim_tt_inpcvt (c, TT_GET_MODE (uptr->flags)|TTUF_KSR);

in pdp11_stddev.c
and this works, (its what the pdp8 console has) but obviously this isn’t the correct solution, but it gets me unblocked.


-----Original Message-----
From: Simh <simh-***@trailing-edge.com> On Behalf Of Mark Pizzolato - Info Comm
Sent: Friday, July 24, 2020 4:34 PM
To: Paul Koning <***@comcast.net>; David Gesswein <***@pdp8online.com>
Cc: ***@trailing-edge.com
Subject: Re: [Simh] pdp11 - console input with high bit set

Post by Paul Koning

Not helped by not knowing what KSR really means.

Keyboard send receive. A model 33 teletype without paper tape.
ASR was the model with paper tape, Automatic send receive.
DEC used teletype's that generated mark parity. From the manuals
keyboards were available to generate other parity. A reasonable
amount of old code for PDP-8's assumed mark parity. Later code
ignores the upper

bit.

I thought the high bit setting would be turned off if you used set
tti 7b or 8b but never verified.

7b, yes. But that only helps with software that sets the top bit on
output, as some old Unices do. It doesn't help with the problem Paul
M raised, which is software that insists on mark parity input.
The right answer would be a tweak to the console emulation in SIMH pdp11.
I wonder if this was done for PDP8 and not PDP11 because it was known
to be needed on the one but people hadn't run into it for the other.

The console emulation in simh actually has functionality to present input data
with different character sizes and/or parity. Leveraging this functionality is
missing from the PDP11 console devices. I will fix this over the next day or so.

- Mark

_______________________________________________
Simh mailing list
***@trailing-edge.com
https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimh&amp;data=02%7C01%7C%7C935ca02c54034f116c7808d8302a1ed2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637312304757205527&amp;sdata=cgIBzSKW0Cs9wyEEBN9eXcYf%2BN%2FpfjD51UB2urM4AGU%3D&amp;reserved=0

[Mark Pizzolato - Info Comm]

I thought the high bit setting would be turned off if you used set
tti 7b or 8b but never verified.

Which obviously won't help if the software running inside simh then
expects MARK parity...

Correct. That was for software that doesn't want mark parity.
Probably should had quoted this from the posting.

So basically pdp8 is always doing KSR. I assume that I don’t want that
for pdp11.

pdp8_doc.doc 2.4.3 KL8E Terminal Input says it will not force mark parity if
you specify 7P, 7B, or 8B.
The rest of the context.
I am running it in the windows console.
I can see that setting TTU_KSR on the mode flags passed to sim_tt_impcvt
will do the job. The pdp-8 console hard code this bit on
else uptr->buf = sim_tt_inpcvt (c, TT_GET_MODE (uptr->flags) | TTUF_KSR);
the is also a KSR mode switch
MTAB tti_mod[] = {
{ TT_MODE, TT_MODE_KSR, "KSR", "KSR", &tty_set_mode },
But this only forces UC (sim_console.h)
#define TT_MODE_KSR (TT_MODE_UC)

Absolutely true AND the TTUF_KSR flag passed to sim_tt_inpcvt is only interpreted
when in upper case mode. The latest code has a KSR mode for TTI which is upper
case with Mark parity. Additionally, there are options to provide SPACE, MARK, EVEN
and ODD parity for any of the 7 bit character input modes.

Your above change isn't needed anymore, but also won't hurt anything (unless somehow
you want Upper Case only and a parity option other than MARK). It is best left off.

- Mark

[Johnny Billquist]

Post by Ethan Dicks

Johnny, I don't know what that means for simh

On an xterm session, there may not be a way to do it. If you were
running simh from a dumb terminal on a serial port, you could set your
terminal to do 7E1 (even parity), and possibly a matching "stty
parenb -parodd" , but the arg 'parenb' appears not to be valid from a
window session.

7E1 obviously will not work when the software is expecting MARK parity.
stty settings might work, but I would generally assume that simh would
remove such things so that it can instead be applied inside the
simulation, if wanted.

Of course, right now my mind is drawing a blank, but I'm trying to
remember if 7N2 could actually be a trick. But I can't remember if the
stop bits equals mark or space.

But if you have a reasonable terminal, it should be able to also
properly do MARK parity as well.

Johnny

Post by Ethan Dicks

Sent: Friday, July 24, 2020 1:37:27 AM
You need to have your terminal set to MARK parity.

Post by Paul Moore
I am trying to run an RK11 diagnostic and am stuck.
Looking at the code, it is looking for digits and then cr.
But it is actually looking for #215, which is 0x8d. Which is CR with
the high bit set. (It also looks for #377 del with HB set)
So what happens is that it just keeps reprompting
I don’t see how that character ever gets into the system. I did ‘set tti
8b’ but it made no difference. I can post the relevant code if needed.

Does "set tti 7p" work for this?
-ethan

[Timothe Litt]

Actually, even parity was more common in the early daze of DEC async. 
MARK always sets the high bit - even sets it only to make the total
number of 1s even.

Quick test: Given that #215 is CR - If the code is looking for #212 for
LF, it's mark.  If it's looking for #012, it's even.

Note also that the digits can also be used - e.g. '0' => 060 - is even,
while 260 would be Mark (or Odd).

Generating the expected format is a function of the terminal emulator.

You need to have your terminal set to MARK parity.
  Johnny

Post by Paul Moore
I am trying to run an RK11 diagnostic and am stuck.
The diagnostic asks the user how many drives to test and I can get the input to work
Looking at the code, it is looking for digits and then cr.
But it is actually looking for  #215, which is 0x8d. Which is CR with
the high bit set. (It also looks for #377 del with HB set)
So what happens is that it just keeps reprompting
I don’t see how that character ever gets into the system. I did ‘set
tti 8b’ but it made no difference. I can post the relevant code if
needed.
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Johnny Billquist]

I would have to disagree with that. All older PDP-8 software is
definitely using MARK parity, not EVEN. Both on input and output.
(Sortof annoying if you aren't expecting it.)

The ASR33, as configured by DEC, was normally also set up with MARK
parity, which is probably the reason all software expected it.

Actually, older PDP-11 software is also expecting MARK parity. Lots of
the older diagnostics, for example.

I wouldn't know about older PDP-10 software, but it would be a little
surprising if they did things differently than PDP-8 and PDP-11.

Johnny

Post by Timothe Litt
Actually, even parity was more common in the early daze of DEC async.
MARK always sets the high bit - even sets it only to make the total
number of 1s even.
Quick test: Given that #215 is CR - If the code is looking for #212 for
LF, it's mark.  If it's looking for #012, it's even.
Note also that the digits can also be used - e.g. '0' => 060 - is even,
while 260 would be Mark (or Odd).
Generating the expected format is a function of the terminal emulator.

You need to have your terminal set to MARK parity.
  Johnny

Post by Paul Moore
I am trying to run an RK11 diagnostic and am stuck.
The diagnostic asks the user how many drives to test and I can get the input to work
Looking at the code, it is looking for digits and then cr.
But it is actually looking for  #215, which is 0x8d. Which is CR with
the high bit set. (It also looks for #377 del with HB set)
So what happens is that it just keeps reprompting
I don’t see how that character ever gets into the system. I did ‘set
tti 8b’ but it made no difference. I can post the relevant code if
needed.
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[David Gesswein]

PDP-8 has set tti ksr to handle this. Looks like the PDP-11 doesn't.
You could implement the same code in PDP-11. Looks like trying to send
arbitrary 8 bit data through terminal windows doen't work for most of them.

Post by Paul Moore
I am trying to run an RK11 diagnostic and am stuck.
The diagnostic asks the user how many drives to test and I can get the input to work
Looking at the code, it is looking for digits and then cr.
But it is actually looking for #215, which is 0x8d. Which is CR with the high bit set. (It also looks for #377 del with HB set)
So what happens is that it just keeps reprompting
I don't see how that character ever gets into the system. I did 'set tti 8b' but it made no difference. I can post the relevant code if needed.
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Johnny Billquist]

Technically, this is not something about simh at all.
However, it is possible to do a workaround inside simh. But unless it is
already implemented (in which case I would expect there to be some
command or setting for it), you might need to modify the simh code to
work around the problem.

But bottom line is that the software you are running are expecting bytes
received over the serial port to have MARK parity, so you need to ensure
that you actually send data with MARK parity.

The workaround would be to fake that the data received on the serial
port have MARK parity by explicitly turning on the high bit on all
received characters.

Johnny

Johnny, I don't know what that means for simh
Get Outlook for Android <https://aka.ms/ghei36>
------------------------------------------------------------------------
*Sent:* Friday, July 24, 2020 1:37:27 AM
*Subject:* Re: [Simh] pdp11 - console input with high bit set
You need to have your terminal set to MARK parity.
   Johnny

Post by Paul Moore
I am trying to run an RK11 diagnostic and am stuck.
The diagnostic asks the user how many drives to test and I can get the input to work
Looking at the code, it is looking for digits and then cr.
But it is actually looking for  #215, which is 0x8d. Which is CR with
the high bit set. (It also looks for #377 del with HB set)
So what happens is that it just keeps reprompting
I don’t see how that character ever gets into the system. I did ‘set tti
8b’ but it made no difference. I can post the relevant code if needed.
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

--
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
pdp is alive!                     ||  tryin' to stay hip" - B. Idol