Serial port problems (in SIMH?)

[Anton Lavrentiev]

Hi all,

So I have my PiDP-11 complete with RS232 ports and two terminals, a real VT320 and a TeraTerm on a PC connected via a COM port.  Wohoo!

When I was playing with connections, I was booting up RSX11M (SW=1), and then once it was up and running, was using Ctrl-E in SIMH console to add serial lines with like so:

att dz line=1,nomodem,connect=/dev/ttyUSB0

att dz line=2,nomodem,connect=/dev/ttyUSB1

cont

and everything was working perfectly: I would be able to log in those terminals (baudrate 9600) and use the system.  Both appear to function very similarly, as to the rate of output.

So it was time to put these statements into the boot.ini file (so that I would not have to type them every time).  That's where the problem number one is:

Once these two "attach" statements were in (right before the last line, "boot rq"), both terminals would appear e-x-t-r-e-m-e-l-y slow with output when system was booted up.  It wasn't the look and feel of 9600 but rather 2400 at best (even though the actual baud rate wasn't changed).

I removed the statements from boot.ini and did again via Ctrl-E and prompt, and I got the speed back.  Now the question is, why?  I believe that's somehow SIMH's, but I may be wrong...  Anybody else experienced this?

Another problem is strongly pointing to SIMH, too:  Like I mentioned before, when struggling with power supply issues (another thread), I noticed that running two long directory listings in RSX11M+ would sometimes garble the output.  I attributed that to bad signal levels due to poor power supply, but now I think differently, and that's why:

1.  I do not have power issues anymore with new power supply, and signals levels are checked good (they were borderline good with old power supply as well, TBH);

2. I still have these broken outputs when running two terminals attached to RS232 lines in parallel ("dir" of the system directory);

3. There is never a garbage character in the output -- but merely looks like missing new-lines or line-feeds.

4. When output breaks it _always_ happens in the two terminals simultaneously;

5. I used different USB/TTL UART converters in the two RS232 lines, and also combined/individual MAX232 signal shifters for both, the result was the same;

6. It does not seem to be an operating system issue because I'm sure it would have been reported by now :-) and also because if I use a serial console (Pi's UART lines and /dev/ttyS0 as RSX11M+ console), the same long output (the long dir listing) that goes into there does not get corrupted (even when run in parallel to the other two listings, which always mess up).

I'm very inclined to think that there's a race condition issue somewhere in SIMH because it always breaks simultaneously in both serial lines ("connect"ed specially) and always as a line boundary thing (which probably also causes some kind of a flush condition, internally).  I'm a software guy and have a strong feeling for that now that I've played with it.

Hopefully, someone from the SIMH team is also here on the list, and can take a look?  I'm using nothing more than stock software as it is provided per PiDP11 instructions (on a Pi 3B+), and the RSX11M+ OS image per the same.

Thanks,

Anton

[Oscar Vermeulen]

Anton,

On Thu, 24 Oct 2019 at 05:34, Anton Lavrentiev <anton.la...@gmail.com> wrote:

I removed the statements from boot.ini and did again via Ctrl-E and prompt, and I got the speed back.  Now the question is, why?  I believe that's somehow SIMH's, but I may be wrong...  Anybody else experienced this?

Hmm... the one thing that differs between manually adding the configs and doing them in the boot.ini is that the boot.ini will execute them when the system (the Pi!) bootss up, before you are logged in.

Maybe that is the cause for the slowness. The check: rather than boot the PDP-11 straight into RSX when you boot up (by having the SR switches set), boot up in Idled, then reboot the PDP-11 into RSX from the boot menu of different operating systems.

--> Do you then still have this issue?

Another problem is strongly pointing to SIMH, too

Simh is pretty mature. Chances are it is my way of using it in the PiDP-11 that is to blame.

One more exploration would be to get the regular simh from github, leave the PiDP-11 (CTRL-E, exit) and run regular simh instead

--> Do you then still have this issue?

 

:  Like I mentioned before, when struggling with power supply issues (another thread), I noticed that running two long directory listings in RSX11M+ would sometimes garble the output.  I attributed that to bad signal levels due to poor power supply, but now I think differently, and that's why:

3. There is never a garbage character in the output -- but merely looks like missing new-lines or line-feeds.

I've noticed this a few times on my PiDP-8 (but it's pretty much the same for this purpose). I blamed it on the terminal not being able to keep up with the data flow at 9600bps. Because RTS/CTS are not implemented on the cheaper RS-232-USB converter cables, just RX/TX. It never bothered me enough to look in to it - it only happened with very long DIR outputs. My suspicion is indeed this would be solved with a converter cable that does have RTS/CTS. But maybe there's another insight here? That both terminals do this at the same time is cause for suspicion.

I'm very inclined to think that there's a race condition issue somewhere in SIMH because it always breaks simultaneously in both serial lines ("connect"ed specially) and always as a line boundary thing (which probably also causes some kind of a flush condition, internally).  I'm a software guy and have a strong feeling for that now that I've played with it.

It might be. Speaking from recollection (thus not 100% solid), simh has its own serial port buffer and then Linux adds another buffer too. I remember hacking out both buffers for a Teletype, so that it would clatter its print head in sync with the flashing lights on the front panel ;)

Simh has its own mail group (google simh mailing list), but I think you should try to reproduce the behaviour with regular simh before asking there. As the simh developers would want that before they delve into the issue anyway.

Kind regards,

Oscar.

[Terry Kennedy]

On Wednesday, October 23, 2019 at 11:34:05 PM UTC-4, Anton Lavrentiev wrote:

I'm very inclined to think that there's a race condition issue somewhere in SIMH because it always breaks simultaneously in both serial lines ("connect"ed specially) and always as a line boundary thing (which probably also causes some kind of a flush condition, internally).  I'm a software guy and have a strong feeling for that now that I've played with it.

Hopefully, someone from the SIMH team is also here on the list, and can take a look?  I'm using nothing more than stock software as it is provided per PiDP11 instructions (on a Pi 3B+), and the RSX11M+ OS image per the same.

I haven't seen anything like that on the limited testing I did with 4 serial terminals on RSTS/E. This is the code I'm using in the simh startup script:

; Set up the USB-to-serial ports on the RPi
set vh lines=16
set vh dhu
set vh nomodem
set vh enable
; Note that these are "shuffled" so the cabling matches the panel
attach vh line=0,connect=/dev/ttyUSB3
attach vh line=1,connect=/dev/ttyUSB1
attach vh line=2,connect=/dev/ttyUSB0
attach vh line=3,connect=/dev/ttyUSB2

This of course requires an OS new enough to support the DHU11 multiplexor. You could use another multiplexor type - if you do that I'd recommend DH11 over DZ11, and DZ11 over DL11.

Another important item is the particular USB-to-serial chip on your adapters. These vary widely in quality and some are even counterfeit. The ones I'm using are CH341 based, with USB hardware ID 1A86:7523.

While many of these chips support partial modem control, the complete adapters generally provide only TXD and RXD. There isn't any provision on the PiDP11 for converting other signals to RS232 anyway, unless you "steal" the converters for the other channels. If full modem control is needed, it would probably be better to design a custom paddleboard for the back of the DB25 connector with all of the level shifters on board, rather than using the ones on the PiDP11 mainboard. Another issue will be ensuring that these signals get passed correctly to the emulated PDP-11 and not acted upon by either the Pi's Raspbian OS or SIMH. I discovered that RSTS/E's autobaud functionality "sort of" works with the adapters I'm using - it can autobaud properly at a few speeds, but not at most speeds.

There is probably some XXDP diagnostic for terminals that you could run to generate continuous output on one (or possibly more) ports. That would eliminate the OS as a potential source of trouble. The XXDP multiplexor diagnostic will likely fail as simh generally omits most of the maintenance-only functions.

[Johnny Billquist]

On 2019-10-25 03:01, Terry Kennedy wrote:
> On Wednesday, October 23, 2019 at 11:34:05 PM UTC-4, Anton Lavrentiev wrote:
>
> I'm very inclined to think that there's a race condition issue
> somewhere in SIMH because it always breaks simultaneously in both
> serial lines ("connect"ed specially) and always as a line boundary
> thing (which probably also causes some kind of a flush condition,
> internally).  I'm a software guy and have a strong feeling for that
> now that I've played with it.
>
> Hopefully, someone from the SIMH team is also here on the list, and
> can take a look?  I'm using nothing more than stock software as it
> is provided per PiDP11 instructions (on a Pi 3B+), and the RSX11M+
> OS image per the same.
>
>
> I haven't seen anything like that on the limited testing I did with 4
> serial terminals on RSTS/E.

In general I haven't seen any issues either, and doubt that simh is to
blame.

> This of course requires an OS new enough to support the DHU11
> multiplexor. You could use another multiplexor type - if you do that I'd
> recommend DH11 over DZ11, and DZ11 over DL11.

As far as I know, simh don't emulate DH11.
But other than that, I agree that DHU11 or DH11 is much preferred over a
DZ11 or a DL11.

> Another important item is the particular USB-to-serial chip on your
> adapters. These vary widely in quality and some are even counterfeit.
> The ones I'm using are CH341 based, with USB hardware ID 1A86:7523.
>
> While many of these chips support partial modem control, the complete
> adapters generally provide only TXD and RXD. There isn't any provision
> on the PiDP11 for converting other signals to RS232 anyway, unless you
> "steal" the converters for the other channels. If full modem control is
> needed, it would probably be better to design a custom paddleboard for
> the back of the DB25 connector with all of the level shifters on board,
> rather than using the ones on the PiDP11 mainboard. Another issue will
> be ensuring that these signals get passed correctly to the emulated
> PDP-11 and not acted upon by either the Pi's Raspbian OS or SIMH. I
> discovered that RSTS/E's autobaud functionality "sort of" works with the
> adapters I'm using - it can autobaud properly at a few speeds, but not
> at most speeds.

In general, I would strongly recommend against trying to use modem
signalling as a way of flow control.
DEC never did it, nor supported it, and depending on OS, this might fail
you miserably.
RSX, for instance, will time out I/O after a little while. And that will
happen if you use hardware flow control. So stopping output this way
will cause effects you probably did not intend.

DEC used XON/XOFF flow control in general, and I would recommend people
to stay with that here.

As far as things like autbaud functionality goes, it is even more tricky.
RSX, for instance, has a table of what characters are generated by the
hardware for a CR when transmitted at different speeds to a couple of
known receive speeds on the PDP-11 side, and that table differs
depending on what controller you have (a DH11 don't generate the same
data as a DZ11).
Under simh, this will all be a total gamble, as this is obviously very
dependent on specifics of the hardware.

I don't know how RSTS/E does it.

> There is probably some XXDP diagnostic for terminals that you could run
> to generate continuous output on one (or possibly more) ports. That
> would eliminate the OS as a potential source of trouble. The XXDP
> multiplexor diagnostic will likely fail as simh generally omits most of
> the maintenance-only functions.

No doubt, XXDP
>
> --
> 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/f37bd8e5-60f9-459e-946d-235690670278%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/f37bd8e5-60f9-459e-946d-235690670278%40googlegroups.com?utm_medium=email&utm_source=footer>.


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

D'oh. Managed to hit send too early...

On 2019-10-25 03:18, Johnny Billquist wrote:
> On 2019-10-25 03:01, Terry Kennedy wrote:
>> On Wednesday, October 23, 2019 at 11:34:05 PM UTC-4, Anton Lavrentiev

[...]

>> There is probably some XXDP diagnostic for terminals that you could
>> run to generate continuous output on one (or possibly more) ports.
>> That would eliminate the OS as a potential source of trouble. The XXDP
>> multiplexor diagnostic will likely fail as simh generally omits most
>> of the maintenance-only functions.
>
> No doubt, XXDP

No doubt XXDP will fail. But it sounds like you might be asking for DEC
X11 (assuming I remember the name right), which is a software package
along XXDP used to just exercise your hardware. (And it has nothing to
do with the windowing system...)

Johnny

[Anton Lavrentiev]

To broken output:

I tried two different USB/TTL UART adapters with exactly the same
result. Also if the bad signals were to blame, there would have been
garbled characters on the screen, but there are NONE!
Only occasional line-feeds / carriage returns are misplaced / missing.
And again, if the adapter was bad, it would have happened only in one
terminal or the other. But like I noted, it ALWAYS happens
simultaneously in both, that is, _when_ it happens. The last thing to
note, again, is that it does not happen in the console, which can be
also connected via UART TTL/USB (in the other direction) in addition
to running in a xterm window. There's no VH in RSX11M+, and I suppose
the simh code may be different than DZ.

> --
> 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/f37bd8e5-60f9-459e-946d-235690670278%40googlegroups.com.

[Johnny Billquist]

On 2019-10-25 05:24, Anton Lavrentiev wrote:
> To broken output:
>
> I tried two different USB/TTL UART adapters with exactly the same
> result. Also if the bad signals were to blame, there would have been
> garbled characters on the screen, but there are NONE!

I don't think it's a hardware problem.

> Only occasional line-feeds / carriage returns are misplaced / missing.
> And again, if the adapter was bad, it would have happened only in one
> terminal or the other. But like I noted, it ALWAYS happens
> simultaneously in both, that is, _when_ it happens. The last thing to
> note, again, is that it does not happen in the console, which can be
> also connected via UART TTL/USB (in the other direction) in addition
> to running in a xterm window. There's no VH in RSX11M+, and I suppose
> the simh code may be different than DZ.

VH? No terminal driver is named VH in RSX. All terminal drivers are
subtypes under the TT driver. If you dig under the hood, you'll find
that the driver controlling the DHU11 is called TTYHV, and in CON it is
shown as YV.

As for what the problem might be in the end, who knows. As Oscar
suggested, it might be something in the changing around for the PiDP-11.
It could also be a flow control problem, in which case there are
multiple places where the problem might be...

Johnny

>
> On Thu, Oct 24, 2019 at 9:01 PM Terry Kennedy <terry-...@glaver.org> wrote:
>>
>> On Wednesday, October 23, 2019 at 11:34:05 PM UTC-4, Anton Lavrentiev wrote:
>>>
>>> I'm very inclined to think that there's a race condition issue somewhere in SIMH because it always breaks simultaneously in both serial lines ("connect"ed specially) and always as a line boundary thing (which probably also causes some kind of a flush condition, internally). I'm a software guy and have a strong feeling for that now that I've played with it.
>>>
>>> Hopefully, someone from the SIMH team is also here on the list, and can take a look? I'm using nothing more than stock software as it is provided per PiDP11 instructions (on a Pi 3B+), and the RSX11M+ OS image per the same.
>>
>>
>> I haven't seen anything like that on the limited testing I did with 4 serial terminals on RSTS/E. This is the code I'm using in the simh startup script:
>>
>> ; Set up the USB-to-serial ports on the RPi
>> set vh lines=16
>> set vh dhu
>> set vh nomodem
>> set vh enable
>> ; Note that these are "shuffled" so the cabling matches the panel
>> attach vh line=0,connect=/dev/ttyUSB3
>> attach vh line=1,connect=/dev/ttyUSB1
>> attach vh line=2,connect=/dev/ttyUSB0
>> attach vh line=3,connect=/dev/ttyUSB2
>>
>> This of course requires an OS new enough to support the DHU11 multiplexor. You could use another multiplexor type - if you do that I'd recommend DH11 over DZ11, and DZ11 over DL11.
>>
>> Another important item is the particular USB-to-serial chip on your adapters. These vary widely in quality and some are even counterfeit. The ones I'm using are CH341 based, with USB hardware ID 1A86:7523.
>>
>> While many of these chips support partial modem control, the complete adapters generally provide only TXD and RXD. There isn't any provision on the PiDP11 for converting other signals to RS232 anyway, unless you "steal" the converters for the other channels. If full modem control is needed, it would probably be better to design a custom paddleboard for the back of the DB25 connector with all of the level shifters on board, rather than using the ones on the PiDP11 mainboard. Another issue will be ensuring that these signals get passed correctly to the emulated PDP-11 and not acted upon by either the Pi's Raspbian OS or SIMH. I discovered that RSTS/E's autobaud functionality "sort of" works with the adapters I'm using - it can autobaud properly at a few speeds, but not at most speeds.
>>
>> There is probably some XXDP diagnostic for terminals that you could run to generate continuous output on one (or possibly more) ports. That would eliminate the OS as a potential source of trouble. The XXDP multiplexor diagnostic will likely fail as simh generally omits most of the maintenance-only functions.
>>
>> --
>> 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/f37bd8e5-60f9-459e-946d-235690670278%40googlegroups.com.
>

[Oscar Vermeulen]

On Fri, 25 Oct 2019 at 06:44, Johnny Billquist <b...@softjar.se> wrote:

As for what the problem might be in the end, who knows. As Oscar
suggested, it might be something in the changing around for the PiDP-11.
It could also be a flow control problem, in which case there are
multiple places where the problem might be...

I think XOn/XOff should fix the dropped characters. Johnny is right, there were no RTS/CTS harware lines in the Real Machine either, so XOn/XOffis the proper flow control to use.

The fact that you see no garbled characters, only dropped characters, and only when outputting a large volume of test to the display, hints at the serial terminal not being able to keep up with the output. XOn/XOff deals with that. A good test to see if this is the correct hypothesis, would be to use a lower baudrate so the terminal has no trouble keeping up. My vt-220s have 4800bps rather than 9600bps as their default setting BTW!

Kind regards,

Oscar.

[Anton Lavrentiev]

The real (vt320) terminal is set to use the xon/xoff control, while the teraterm window doesn't have that option, but: it's able to cope with 115200 baud easily when connected as a serial console (Pi's), so I don't think it ever chokes up at 9600. Yet both have broken output when working as DZ terminals.

BTW, I downloaded and built simh from git. And the attach command given either in boot.ini or manually (via ctrl-e) does not affect the output rate on the terminals. So there must be something with the pre-built binary that is in the package.  Or it has been fixed in simh by now, and the package has an older version, obviously.  As for "maturity" of the simh code, I found a bug right after the download and build -- it's unrelated to the problem at hand -- and reported it back to the simh team. They ack'ed the issue and are working on a fix.  So, anything can be.

--
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/CAJAwMc1fqGgh7fR-rQUr50GpipoE9f%2B32xmftx-vu0KYu9CoJg%40mail.gmail.com.

[Anton Lavrentiev]

> VH? No terminal driver is named VH in > RSX. All terminal drivers are 
> subtypes under the TT driver. 

I meant in simh!

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/697cbd3f-dfbc-c362-95c4-65d3b6e63a65%40softjar.se.

[Anton Lavrentiev]

What do I need to rebuild the pdp11 simh binary for Pi with
blinkedlight support? I'd try building it from scratch (with possibly
debugging info enabled) so that I could see where the delay might be
coming from (stemmed from the "attach" command first). I checked that
my Pi has the strace tool so it'd be a good starting point besides the
source-code-level debugging (coming next, if needed).

[Oscar Vermeulen]

Anton,

On Fri, 25 Oct 2019 at 21:40, Anton Lavrentiev <anton.la...@gmail.com> wrote:

What do I need to rebuild the pdp11 simh binary for Pi with
blinkedlight support?

You mean take the latest simh update off github and add the BlinkenBone additions to it? That is very much nontrivial - you might want to check the dedicated BlinkenBone Google Group where Jörg Hoppe roams. Jörg is the author of the original BlinkenBone, I only added support for the PiDP hardware and some trivial things like the reboot-from-the-front-panel feature.

Kind regards,

Oscar

[Johnny Billquist]

It would be very nice with a new version of simh in there, as there are
other improvements that would could benefit from. A bit unfortunate that
the whole blinkenbone additions have been made in such a way that it's
complicated to update simh.

Whenever a new version of simh gets in there, let me know and I'll test
the networking stuff and hopefully we can give a simpler configuration
for people who use WiFi and would like to use DECnet as well as TCP/IP.

Johnny

[Anton Lavrentiev]

Oscar, not to brag but trust me, when it comes to software (unlike hardware) I can do non-trivial things, it's part if my job description :-) Just need to know where the source code is. Thanks for the pointer! I'll keep you posted

[Upi Tamminen]

I did a merge a while back for those interested. I haven't updated it since, though...

https://github.com/desaster/simh-realcons-pdp11

[Oscar Vermeulen]

Anton,

Oh, I trust you ;) Check with Jörg, it would be good to have a process for bringing in simh updates, rather than have it as a manual chore.

Kind regards,

Oscar.

[Mike Katz]

It would be awesome if the blinkenbone additions were included in the mainline simh with an ifdef to include them or not.  This might help with new features/bug fixes in simh do not break blinkenbone.

That's my 2 cents plain.

--
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/CAJAwMc0oQE45rspKMwxrX-vzdm5AoQKgoup3LSdWjtGqgM_abw%40mail.gmail.com.

[Oscar Vermeulen]

Mike,

It would be convenient for PiDP users, but a headache for Mark Pizzolato and his simh contributors (who correctly prefer to focus on the actual machine emulation)... some script on our side would be more feasible.

Kind regards,

Oscar.

[Mike Katz]

Oscar,

I understand, but if blinkenbone is at the very least a branch off of the main simh the likely hood of a change to simh breaking blinkenbone is greatly reduced.

And it makes regression testing easier.

I'm sorry, that's the software development manager in me talking :-D

             Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAJAwMc2G%2BB6QgZPUhz8FzHzxRV2FcX-tMqb0XFVBqW0mQdhpwQ%40mail.gmail.com.

[Johnny Billquist]

On 2019-10-25 23:51, Mike Katz wrote:
> It would be awesome if the blinkenbone additions were included in the
> mainline simh with an ifdef to include them or not.  This might help
> with new features/bug fixes in simh do not break blinkenbone.

Not happening.

They way blienkbone was done is just ass backward, and not something
that will ever come into simh itself.

However, Mark Pizzalo was working on an API on the simh side to do these
kind of things, which would make it an easy thing to integrate, but it
would require rewriting of the blinkenbone code to make use of it.

Johnny

>
> That's my 2 cents plain.
>
> On 10/25/2019 4:48 PM, Oscar Vermeulen wrote:
>> Anton,
>>
>> Oh, I trust you ;) Check with Jörg, it would be good to have a process
>> for bringing in simh updates, rather than have it as a manual chore.
>>
>> Kind regards,
>>
>> Oscar.
>>
>>
>> --
>> 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/CAJAwMc0oQE45rspKMwxrX-vzdm5AoQKgoup3LSdWjtGqgM_abw%40mail.gmail.com

>> <https://groups.google.com/d/msgid/pidp-11/CAJAwMc0oQE45rspKMwxrX-vzdm5AoQKgoup3LSdWjtGqgM_abw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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/cb420c06-03bf-8247-940f-8d6ff6beec12%40gmail.com
> <https://groups.google.com/d/msgid/pidp-11/cb420c06-03bf-8247-940f-8d6ff6beec12%40gmail.com?utm_medium=email&utm_source=footer>.

[Anton Lavrentiev]

Oh my... I've taken a deeper look at all that, and saw that it's done
as just an ad-hoc modification of the simh code, so _almost_
impossible to maintain in that way and form...

> 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/850932f7-4501-d4e4-932c-a603cb934ddf%40softjar.se.

[Mike Katz]

That's a shame.

I'm up to my neck in my home projects on top of the projects my wife
tells me I should be working on :-D

When I am a bit more caught up (Oscar you are first on my list!), with
the help of some of you (Oscar, Anton, Johnny) maybe we can work with
the SIMH group to work out a better blinkenbone interface solution.

Hey, as long as we have our dreams we will live forever.

[Neal G.]

What is the RSX11 CON command to load the DHU11 (YV) driver and place it online? I didn't see it in this thread.

[Johnny Billquist]

On 2019-11-23 22:36, Neal G. wrote:
> What is the RSX11 CON command to load the DHU11 (YV) driver and place it online? I didn't see it in this thread.

You can't. The terminal driver is complex enough that it don't allow
dynamic loading and unloading of different backends. It is built at
SYSGEN time with all the backends you might want to have, and that's it.
There is no separate driver for each type of hardware, they are all
dealt with by the same device driver.

Johnny

[Johnny Billquist]

On 2019-11-23 22:46, Johnny Billquist wrote:
> On 2019-11-23 22:36, Neal G. wrote:
>> What is the RSX11 CON command to load the DHU11 (YV) driver and place
>> it online? I didn't see it in this thread.
>
> You can't. The terminal driver is complex enough that it don't allow
> dynamic loading and unloading of different backends. It is built at
> SYSGEN time with all the backends you might want to have, and that's it.
> There is no separate driver for each type of hardware, they are all
> dealt with by the same device driver.

That said, though, CON do allow you to change configuration stuff for
each different controller you did build. So CSR address and vector can
be changed with CON.

And by the way, loading a device driver is not done with CON at all. LOA
and UNL is the tasks that are responsible for those things...

[Anton Lavrentiev]

Hi all,

Just wanted to let you know that the broken output in serial termials is seen all the same when running a freshly built simh out of its git repo (without the realcons support, obviously), and with telnet connections just as well!  Moreover, simh built on a completely unrelated platform (I used Cygwin) exhibits all the same problems (could only try telnet there as there's only one real COM port on that Windows PC).  Anyhow, I'm very much convinced by now that the problem is within simh.  Bug report is here: https://github.com/simh/simh/issues/782

I only wonder how nobody else had noticed anything like that on this group before...

Cheers

--
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/afdcdf29-492f-5721-93de-ced7dba5458e%40softjar.se.

[Neal G.]

On Sunday, December 15, 2019 at 1:46:00 PM UTC-6, Anton Lavrentiev wrote:

I only wonder how nobody else had noticed anything like that on this group before...

 

Anton, thanks for looking into this in detail. I rechecked with a Linux build of SimH 4.0 that I had pulled from github a few months ago. With multiple telnet connections to the DZ device, simultaneously and continuously sending a stream of characters, many errors do occur.

The problem seems related to the overall throughput; if I slow the four concurrent connections to 2400baud very few errors occur.

I think the problem has generally gone unnoticed because there are so many layers involved that an occasional error could be the result of any of a number of other factors. Also, I imagine most of us either use just one or two connections to the DZ interface, or those who do have many connections use them interactively not sending or receiving a large blocks of data.

If it is of interest, though I did not specifically check for data errors, my impression is that the DHU11 (SimH VH device) exhibits the same problem.

[Anton Lavrentiev]

Neal, thank you so much for re-confirming!  As per how the bug manifests itself, I'm most convinced it is sort of a race condition (which is why it lessens with lower baudrates).

Also, the multi-line terminal devices are all implemented in SimH through a generic terminal multiplexer; so the bug must be in there -- that's how the various devices might be affected.

--

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/927cda02-c44c-4a19-92b9-96da915c62d6%40googlegroups.com.