On 2016-06-06 19:47, Clem Cole wrote:
On Mon, Jun 6, 2016 at 12:13 PM, Mark Pizzolato <[email protected]
<mailto:[email protected]>> 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: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
