<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 12:13 PM, Mark Pizzolato <span dir="ltr"><<a href="mailto:Mark@infocomm.com" target="_blank">Mark@infocomm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The fundamental issue Bill is seeing is a problem in the simh code and not the hardware or the host OS.  There may be a hardware issue, but I doubt it and if there is, the simh issue will have to be addressed first.</blockquote></div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​Agreed the problem is in simh, although Johnny's right about the trigger/causing being the buffering on the host OS.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Let's explore what is happening.    Terminal canonicalization is an OS operation.   Flow control on the other hand is something you >>would<< like to have as close to the HW as possible.  We have a real TTY here, but because of the emulation, we have a role reversal in that by the time the Flow control logic in the simulated host kicks in, it too late.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Simply put..   OS/8's terminal handler is doing the flow control.    On the original HW, there is an Full/Empty bit in the UART that signals its ok for the OS (OS/8 here) the put the next character in the output buffer.    On real HW, "emptying" the transmit buffer in the UART takes the X bits times at the appropriate baud rate - where X is determined by the 1 START bit + SIZE of CHAR + [optional PARITY] + 1 STOP BIT [optional second STOP bit].   In this case, its 11 bits at 110 baud or 10 chars per second.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font face="arial, helvetica, sans-serif">We get "bad behavior" because OS/8 thinks the char has already been printed because on </font> >>real<< HW the fastest OS/8 can ever see the Full/Empty bit is 10 cps.    But in the emulated world, the read of the transmit buffer occurs and start stop etc are removed and the data passed on to the host as a char with a write system call by simh and then "output" via the real host serial code.   As Johnny points out, this is going into the UNIX terminal output queue (and normally UNIX would be doing is on canonicalization plus any flow control). <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">So the flow control logic that OS/8 is doing is too late (the chars have already been written as far as OS/8 is concerned - they already saw Full/Empty signal it was ok to send).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The trick is some how the emulated Full/Empty state in the simulated HW (e.g the PDP/8), needs to follow the time that the host actually wrote of the character (i.e. the UNIX tty driver actually posted the char in this case) so the simulate OS (OS/8) actually behaves as expected.   That is to say, their needs to be a way for the simulator to delay setting the emulated Full/Empty bit until the character really is on its way to the real UART connected to the real UNIX hosts talking to a real ASR33.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As I see it, there are two possible ways for simh to fix the problem so the simulated OS's canonicalization and flow logic actually work as designed for the real HW:</div><div class="gmail_default"><ol><li><font face="arial, helvetica, sans-serif">have simh keep reasonably precise time in the emulated HW and not post Full/Empty in the emulated UART any faster than the X cps defined by the original HW.</font></li><li><font face="arial, helvetica, sans-serif">If simh can set the output buffering to very few say 1 maybe 2 chars, before actually writes another character to UNIX (and this not post Full/Empty) as sooner than the physical HW can output it.</font></li></ol><div><font face="arial, helvetica, sans-serif">If you can pull it off, I think the later actually will work better, because you are letting the local HW help you and not putting artificial timing into things any more than needed but it might be hard.   Sadly, when we designed the POSIX terminal interface (and yes you can blame me, I'm one 1/2 of the original author of that chapter), we took the inverse problem into account with the MIN/TIM values for reading characters coming into the tty handler.   We did worried about the output issue, as UNIX will control the buffering.   I need to think about a portable way in the application code to make that work right.  </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">That said, I think Mark's right - we need control the timing better in the simulator.   If we can do that better in the simulator in a host OS independent way, the problem should be fixed.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Clem</font></div></div></div></div>