Post by Walter F.J. MüllerPost by Jonathan Harstonset cpu 70
mount db0: H:\develop\pdp11\unix\bsd2-11.dsk /rp06
with E11 v7.0, and the disk image from
https://skn.noip.me/pdp11/pdp11.html
I tried this 211BSD image. It's patch level 448.
If it truly is at 448, then you should not have the problem. I actually
did 448 on a local 11/83 with a VT420, and it was just so annoying that
I had the 7-bit parity problem when booting 2.11BSD, while everything
was fine when booting RSX on the same machine, and I did not want to go
in and change the setup in the terminal every time I booted the other
system. (And the boot roms in the 11/83 themselves also assume you have
an 8-bit clean console, so it was really 2.11BSD that was the odd duck.)
So I know that worked correctly on real hardware.
But it's really just a one line change. usr/src/sys/pdp/cons.c line 167.
And in there you'll find an or with the parity, which I just commented out.
449 and 450 changed it to be settable, as my forced non-parity was
considered a little too brutal. :-)
Post by Walter F.J. MüllerI tried e11 version 7.3 and 7.2, both under Linux.
The output up to and including "Sat Oct 31 16:00:38 PST 1981" is ok.
After that I see crap.
I've tried with SimH again. The default setting in 'classical' SimH is 7bit !
When I boot that image in SimH with tto default setting all is fine.
When I use "set tto 8b" I get the same crap that I see with e11.
The problem is obviously that there is no mechanism in e11 to set the console output into 7bit mode.
Since 211BSD fills in the parity bit, the host system sees character codes > 0177 and misinterprets them
as UTF-8 characters.
Interesting that E11 don't actually seem to do anything with the
specified mode. I guess you might be right in that it just tries to
change the characteristics of the actual line.
You could always ping John Wilson about it...
Johnny