Re: [Simh] pdp11 - console input with high bit set

[Rich Alderson]

> From: Johnny Billquist 
> Date: Sat, 25 Jul 2020 00:58:08 +0200

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

Hi, Johnny,

On the PDP-10, the rule was "Be strict in what you send, and generous in what
you accept." The standard was to send 7E1, and anything which could be made
7-bit on input was good (so 8N1 was popular).

Rich

Rich Alderson
ex LCM+L
s...@alderson.users.panix.com
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Timothe Litt]

On 25-Jul-20 13:47, Paul Koning wrote:
>>  But by the mid to late 70s, i.e. with the glass TTY it started to fall from 
>> favor.   I don't know why, but I would suspect this was because dedicated 
>> lines started to supplant telephone circuit-based connections and single-bit 
>> error detect was not useful.  It did not happen that often.
> It could be that glass TTYs were computer peripherals, and typically close to 
> the computer or connected by a modem that was pretty clean.  The older 
> devices tended to be on current loops, possibly quite long ones with 
> debatable signal quality.

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.

By the 80s modems got much smarter.  While the 103 was pure bit-by-bit
FSK, in addition to coding improvements, later modem protocols (e.g.USR
HST in 186, then V.42) provide error correction (including
retransmission).   In between, V.34 does a lot of work in the initial
handshake to adapt to line characteristics.

So the error rate became essentially zero (though latency could be
unbounded).

Except in some weird cases (I won't mention which computer rooms had
modems several hundred feet from the computer's interfaces...), the
modem - host and modem - TTY would be within the RS232 limit of 25 ft.

OTOTH, parity in hardware was cheap - though software often didn't
handle parity errors very effectively.  Software used (IBM) or moved to
8-bit characters as I8n came along.  So unless parity was used in HW, or
you had a non-byte architecture (e.g. the PDP-10 which treats "bytes"
between 1 and 36 bits equally), it was inconvenient.

In any case, while the short modem - DTE interface was still a
vulnerability, once you have an error-corrected path, "parity was for
farmers."

Current loops - especially when optically coupled - were actually quite
good.  Extending RS232 beyond the 25 ft spec could get problematic. 
Yes, 3,000 ft was quite possible.  But sensitive to environment.  I had
a number of notable cases where customers complained about long line
(RS233) issues - and switching to current loop modems (typically > 20ma)
resolved them.  Hint: you don't want to run long RS232 lines around
elevator machine rooms, or industrial factory floors, or ...

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


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

Re: [Simh] pdp11 - console input with high bit set

[Paul Koning]

> On Jul 24, 2020, at 5:57 PM, Clem Cole  wrote:
> 
> ...
>>  If you set your UART for 8 bits with parity, it would send 11 bits total: 
>> start, 8 data, parity, stop.
> Yep ...  you are correct that is exactly how the hardware works. mei culpa.   
> Although, if we are going to get specific.   There could also optionally be 2 
> stop bits.  As I said, the Model 33 used 2 but either 5-bit gear used either 
> 1 or 1.5.  I think I remember with 5-bit plus parity the A version generated 
> 1.5 stop bits when the chip was programmed for 2 and the original sent a full 
> 2 bits.
> 
> You are right that I should have been more specific but in all fairness, I 
> don't know of a DEC OS that supported that setup.  But I'm sure it was 
> possible and probably for people running PDP-11's as communications 
> 'front-ends' it was done.  The fact is if you ran 8 bits back in the day, it 
> was usually without parity.  Instead, some other protection was done in a 
> higher level protocol to protect and/or correct for transmission errors.

It's true that parity is a bit silly because it only does error detection on an 
unstructured data stream, which isn't all that helpful.  But it was fairly 
common practice at one time.  For example, the popular Friden Flexowriter 
machines -- somewhat like a TTY model 35 but even more reliable -- use a 7 bit 
character code that is better thought of as 6 bit characters with odd parity.

I don't know about others, but RSTS definitely supports setting parity on 8-bit 
data.  Since the devices (like DH11 and DHU11) support it, that's just a matter 
of the software implementing an API and telling the driver to set the proper 
bits:

$ set ter kb6/perm/parity=even

> 
> If I remember McNamara's book he had a whole chapter on errors and suggested 
> that parity was popular (almost always used) in early devices, like the 5-bit 
> Baudot based equipment like Teletypes model 28 and Friden Flexowriter, and of 
> course as you pointed out the infamous 7-bit Model 33 and 37.

Not 5 bit devices, none of those codes have parity.  Neither do 6 bit devices 
(typesetters).

>  But by the mid to late 70s, i.e. with the glass TTY it started to fall from 
> favor.   I don't know why, but I would suspect this was because dedicated 
> lines started to supplant telephone circuit-based connections and single-bit 
> error detect was not useful.  It did not happen that often.

It could be that glass TTYs were computer peripherals, and typically close to 
the computer or connected by a modem that was pretty clean.  The older devices 
tended to be on current loops, possibly quite long ones with debatable signal 
quality.

>> I've even run into 10-bit UARTs (on PLATO terminals).  But that's not DEC 
>> stuff.
> 
> Not surprised, CDC did some very strange things with characters ;-) 

True, but not this.  CDC had nothing to do with that design, it came from the U 
of Illinois.  7 bit characters, the high order bits were to indentify one of 
several data streams (keyboard, touch panel, echo response, external device).

The amazing thing is that they managed to get standard chips to speak these 
weird signalling schemes, in the later 8080-based PPT (PLATO V terminal).  10 
bit async one way, 21 bit sync the other way, both done with an 8251 USART.

paul

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

Re: [Simh] pdp11 - console input with high bit set

[Mark Pizzolato - Info Comm]

On Friday, July 24, 2020 at 5:42 PM, David Gesswein wrote:
> On Sat, Jul 25, 2020 at 01:22:38AM +0200, Johnny Billquist wrote:
> > >
> > > 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", _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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[David Gesswein]

On Sat, Jul 25, 2020 at 01:22:38AM +0200, Johnny Billquist wrote:
> > 
> > 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", _set_mode },

But this only forces UC (sim_console.h)

#define  TT_MODE_KSR(TT_MODE_UC)

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

Re: [Simh] pdp11 - console input with high bit set

[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  On Behalf Of Mark Pizzolato - Info 
Comm
Sent: Friday, July 24, 2020 4:34 PM
To: Paul Koning ; David Gesswein 
Cc: Simh@trailing-edge.com
Subject: Re: [Simh] pdp11 - console input with high bit set

On Friday, July 24, 2020 at 11:36 AM, Paul Koning wrote:
> > On Jul 24, 2020, at 2:28 PM, David Gesswein  wrote:
> >
> > On Fri, Jul 24, 2020 at 06:12:17PM +, Paul Moore wrote:
> >> 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
Simh@trailing-edge.com
https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimhdata=02%7C01%7C%7C935ca02c54034f116c7808d8302a1ed2%7C84df9e7fe9f640afb435%7C1%7C0%7C637312304757205527sdata=cgIBzSKW0Cs9wyEEBN9eXcYf%2BN%2FpfjD51UB2urM4AGU%3Dreserved=0
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Mark Pizzolato - Info Comm]

On Friday, July 24, 2020 at 11:36 AM, Paul Koning wrote:
> > On Jul 24, 2020, at 2:28 PM, David Gesswein  wrote:
> >
> > On Fri, Jul 24, 2020 at 06:12:17PM +, Paul Moore wrote:
> >> 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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Johnny Billquist]

On 2020-07-24 20:28, David Gesswein wrote:

On Fri, Jul 24, 2020 at 06:12:17PM +, Paul Moore wrote:

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.


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


  Johnny

--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Johnny Billquist]

On 2020-07-24 19:53, Ethan Dicks wrote:

On Fri, Jul 24, 2020 at 1:13 PM Paul Moore  wrote:

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




From: Johnny Billquist 
Sent: Friday, July 24, 2020 1:37:27 AM
To: Paul Moore ; Simh@trailing-edge.com 


You need to have your terminal set to MARK parity.

On 2020-07-24 01:56, Paul Moore wrote:

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



--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[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

On 2020-07-24 19:26, Timothe Litt wrote:
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.

On 24-Jul-20 04:37, Johnny Billquist wrote:

You need to have your terminal set to MARK parity.

  Johnny

On 2020-07-24 01:56, Paul Moore wrote:

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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh





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



--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[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

On 2020-07-24 19:12, Paul Moore wrote:

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

Get Outlook for Android <https://aka.ms/ghei36>


*From:* Johnny Billquist 
*Sent:* Friday, July 24, 2020 1:37:27 AM
*To:* Paul Moore ; Simh@trailing-edge.com 


*Subject:* Re: [Simh] pdp11 - console input with high bit set
You need to have your terminal set to MARK parity.

    Johnny

On 2020-07-24 01:56, Paul Moore wrote:

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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh



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


--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Clem Cole]

On Fri, Jul 24, 2020 at 4:18 PM Paul Koning  wrote:

> Parity is something that comes in addition to the data.  DEC UARTS (and
> many others, I think)
>
Appendix D of McNamara's book, *a.k.a.* the 40-pin WD1402 and 1402A :-)  I
once knew it well and at one time had an official WD manual for it (I may
still in a filing cabinet)  I believe the chip was added to IEEE's hall of
fame.  In those days, but I've long forgotten the difference between the
original and the "A" version, I think it had to do with the second stop bit
getting being the wrong size when 2 stop bits were defined. IIRC: Getting
the framing right was a common issue with a number of early UARTs
cause shorter chars (5 bits) used 1.5 stop bits, not a full 2.   Sadly
there was a time when I could probably have quoted stuff from that and the
EIA RS-232 >>B<< specs, much less my copy of his now, dog eared book.



> would let you set the data length (5, 6, 7, 8 bits) and the parity setting
> (none, even, odd).  So what you called "8 bits including parity" is
> technically "7 bits with parity".
>
absolutely.  The WD chip could not do space or mark parity.  It was either
none or even/odd.  There were two pins on the chip, one that said to use it
or not, and the other if in used which of the two types.

Which comes back to the OP's question is why I think Tim's comment is the
correct one, you don't want 'mark' parity, if you need parity I would think
that you want to set it to 'even' (see Table D-1 on page 288 of the book)
since I don't think the UART in the KL11 could generate anything but these
three options.




>  If you set your UART for 8 bits with parity, it would send 11 bits total:
> start, 8 data, parity, stop.
>
Yep ...  you are correct that is exactly how the hardware works. mei
culpa.   Although, if we are going to get specific.   There could also
optionally be 2 stop bits.  As I said, the Model 33 used 2 but either 5-bit
gear used either 1 or 1.5.  I think I remember with 5-bit plus parity the A
version generated 1.5 stop bits when the chip was programmed for 2 and the
original sent a full 2 bits.

You are right that I should have been more specific but in all fairness, I
don't know of a DEC OS that supported that setup.  But I'm sure it was
possible and probably for people running PDP-11's as communications
'front-ends' it was done.  The fact is if you ran 8 bits back in the day,
it was usually without parity.  Instead, some other protection was done in
a higher level protocol to protect and/or correct for transmission errors.

If I remember McNamara's book he had a whole chapter on errors and
suggested that parity was popular (almost always used) in early devices,
like the 5-bit Baudot based equipment like Teletypes model 28 and Friden
Flexowriter, and of course as you pointed out the infamous 7-bit Model 33
and 37.  But by the mid to late 70s, i.e. with the glass TTY it started to
fall from favor.   I don't know why, but I would suspect this was because
dedicated lines started to supplant telephone circuit-based connections and
single-bit error detect was not useful.  It did not happen that often.



>
> I've even run into 10-bit UARTs (on PLATO terminals).  But that's not DEC
> stuff.
>
Not surprised, CDC did some very strange things with characters ;-)

Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Paul Koning]

> On Jul 24, 2020, at 3:15 PM, Clem Cole  wrote:
> 
> 
> 
> On Fri, Jul 24, 2020 at 2:37 PM Paul Koning  > wrote:
> The right answer would be a tweak to the console emulation in SIMH pdp11.  
> Mumble... Paul - I'm not so sure.  While DEC used MARK a lot, there were 
> places that used EVEN parity a lot also on PDP-11's (Lord how, I hated 20 mA 
> current loop ;-) at least by the time of widespread RS-232C interfaces it was 
> glass ttys and usually a full 8-bit data path.   7-bit with odd/even is 
> defined this way:
> 
>  bits of data
> (count of 1-bits) 8 bits including parity
> even  odd
> 000   0   1000
> 1010001   3   1101000101010001
> 1101001   4   0110100111101001
> 111   7   0111
> FWIW:  I'm on a Mac and I run a program called 'Serial' that can do that; but 
>  I thought most of the programs that simulate a serial connection for the 
> different PC/Windows system have similar options.  Certainly that was true 
> when I did it with DOS.

I use minicom, and yes, it can do all those things.  But that wasn't the case I 
was thinking about.  I thought the issue isn't so much the case where you have 
a terminal emulator program talking to a serial port, but rather the case of 
your command window in which you invoke simh (pdp11) and you're then talking to 
the console terminal.  I would rather not have to change the settings on my 
regular shell to deal with oddball stuff expected by some application, I figure 
that's the application's job.

> 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.
> 
> I'm curious to hear what Bob thinks?  

Parity is something that comes in addition to the data.  DEC UARTS (and many 
others, I think) would let you set the data length (5, 6, 7, 8 bits) and the 
parity setting (none, even, odd).  So what you called "8 bits including parity" 
is technically "7 bits with parity".  If you set your UART for 8 bits with 
parity, it would send 11 bits total: start, 8 data, parity, stop.

I've even run into 10-bit UARTs (on PLATO terminals).  But that's not DEC stuff.

paul

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

Re: [Simh] pdp11 - console input with high bit set

[Ethan Dicks]

On Fri, Jul 24, 2020 at 3:16 PM Clem Cole  wrote:
> 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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Clem Cole]

On Fri, Jul 24, 2020 at 2:37 PM Paul Koning  wrote:

> The right answer would be a tweak to the console emulation in SIMH pdp11.

Mumble... Paul - I'm not so sure.  While DEC used MARK a lot, there were
places that used EVEN parity a lot also on PDP-11's (Lord how, I hated 20
mA current loop ;-) at least by the time of widespread RS-232C interfaces
it was glass ttys and usually a full 8-bit data path.   7-bit with odd/even
is defined this way:

 bits of data
(count of 1-bits)8 bits including parity
evenodd
000 0 *0*000 *1*000
1010001 3 *1*1010001 *0*1010001
1101001 4 *0*1101001 *1*1101001
111 7 *1*111 *0*111FWIW:  I'm on a Mac and I run a program
called 'Serial' that can do that; but  I thought most of the programs that
simulate a serial connection for the different PC/Windows system have
similar options.  Certainly that was true when I did it with DOS.

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.

I'm curious to hear what Bob thinks?
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Paul Koning]

> On Jul 24, 2020, at 2:28 PM, David Gesswein  wrote:
> 
> On Fri, Jul 24, 2020 at 06:12:17PM +, Paul Moore wrote:
>> 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


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

Re: [Simh] pdp11 - console input with high bit set

[David Gesswein]

On Fri, Jul 24, 2020 at 06:12:17PM +, Paul Moore wrote:
> 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.

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

Re: [Simh] pdp11 - console input with high bit set

[Paul Moore]

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", _set_mode },

But this only forces UC (sim_console.h)

#define  TT_MODE_KSR(TT_MODE_UC)

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

I tried naively adding the same mode flag but of course that did nothing since 
is not a mode it’s a modifier of a mode (an 'ored' in flag) so I am not sure 
what to do. I mean I can hack that flag into a temp build but it seems like 
this is a useful thing to have

Not helped by not knowing what KSR really means.

-Original Message-
From: Ethan Dicks  
Sent: Friday, July 24, 2020 10:53 AM
To: Paul Moore 
Cc: Simh@trailing-edge.com; Johnny Billquist 
Subject: Re: [Simh] pdp11 - console input with high bit set

On Fri, Jul 24, 2020 at 1:13 PM Paul Moore  wrote:
> 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.

> From: Johnny Billquist 
> Sent: Friday, July 24, 2020 1:37:27 AM
> To: Paul Moore ; Simh@trailing-edge.com 
> 
>
> You need to have your terminal set to MARK parity.
>
> On 2020-07-24 01:56, Paul Moore wrote:
> > 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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Ethan Dicks]

On Fri, Jul 24, 2020 at 1:13 PM Paul Moore  wrote:
> 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.

> From: Johnny Billquist 
> Sent: Friday, July 24, 2020 1:37:27 AM
> To: Paul Moore ; Simh@trailing-edge.com 
> 
>
> You need to have your terminal set to MARK parity.
>
> On 2020-07-24 01:56, Paul Moore wrote:
> > 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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

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

On 24-Jul-20 04:37, Johnny Billquist wrote:
> You need to have your terminal set to MARK parity.
>
>   Johnny
>
> On 2020-07-24 01:56, Paul Moore wrote:
>> 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
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Paul Moore]

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

Get Outlook for Android<https://aka.ms/ghei36>


From: Johnny Billquist 
Sent: Friday, July 24, 2020 1:37:27 AM
To: Paul Moore ; Simh@trailing-edge.com 

Subject: Re: [Simh] pdp11 - console input with high bit set

You need to have your terminal set to MARK parity.

   Johnny

On 2020-07-24 01:56, Paul Moore wrote:
> 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
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>

--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set]

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


On Thu, Jul 23, 2020 at 11:56:24PM +, Paul Moore wrote:
> 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
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

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

Re: [Simh] pdp11 - console input with high bit set

[Johnny Billquist]

You need to have your terminal set to MARK parity.

  Johnny

On 2020-07-24 01:56, Paul Moore wrote:

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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh



--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh