[Simh] PDP-8 KL8E XON/XOFF

[Johnny Billquist]

On 2016-06-06 19:47, Clem Cole wrote:
>
> On Mon, Jun 6, 2016 at 12:13 PM, Mark Pizzolato <Mark at infocomm.com
> <mailto:Mark at infocomm.com>> wrote:
>
>     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.
>
>
> ​Agreed the problem is in simh, although Johnny's right about the
> trigger/causing being the buffering on the host OS.
>
> 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.
>
> 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.
>
> We get "bad behavior" because OS/8 thinks the char has already been
> printed because on  >>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).
>
> 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).
>
> 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.
>
> 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:
>
>  1. 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.
>  2. 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.
>
> 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.
>
> 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.

OK, I worded it badly. Yes, it is a problem in that simh will not appear 
to behave the same as the real thing, because simh is running on 
something that provides a much deeper buffer than the hardware emulated.

The problem is that I don't see any good way for simh to solve this. 
Your two options listed, Clem, are pretty much it. However, only the 
first one even have a chance, and that is the ugly solution.

Setting the output buffering is just something that you don't have 
enough control of. As I said, you actually have two levels of buffering. 
First is the host OS serial line buffer, which I don't know how much it 
will hold, but it's definitely not close to zero. It might be possible 
to control this one in software.
The second level of buffering happens on the chip, and I seriously doubt 
there is any interface that gives you any control over that one. If you 
were to reprogram the chip, you usually have several options on how it 
works, and you could run it in a way that would get you the control you 
would need for simh, but for the general use case, this would be the 
very worst performing settings. And the OS device driver just have its 
idea how it want things set up, and you'll have to just accept that one.
Which means, you can never know when the character have actually been 
transmitted.

So, timer to control the ready flag is pretty much it.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol