On 2022-07-20 21:32, Walter F.J. Müller wrote:
> On Wednesday, July 20, 2022 at 3:41:28 PM UTC+2,
j...@mdfs.net wrote:
>> I use:
>> set cpu 70
>> mount db0: H:\develop\pdp11\unix\bsd2-11.dsk /rp06
>> boot db0:
>>
>> 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. :-)
> I 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