[Simh] Pasting into the console

[Mark Pizzolato - Info Comm]

On Thursday, March 26, 2015 at 4:59 PM, Rhialto wrote:
> A while ago when I was struggling^Wplaying with installing RSX on simh-
> pdp11, I noticed that pasting bits of text into the console didn't really work.
> Which was quite annoying since now I had to re-type all those csr and vector
> numbers by hand.
> 
> When trying a bit more systematically, I found that in pretty much most
> cases, only 1 in every 2 pasted characters was echoed.
> 
> With some added logging I discovered that all characters were however read
> out properly on the "inside" of TTI, in tti_rd() in pdp11_stddev.c.
> Presumably by the standalone BRU system that I used for testing.
> 
> However, there I noticed a polling time-out of tti_unit.wait. On a whim, I
> tried to increase that ("examine tti state" showed a value of 100) ("deposit tti
> time 200"). And suddenly, pasting worked just fine. (150 didn't work).
> 
> I'm not exactly sure why this helps, since seemingly all characters arrived fine
> through the TTI input buffer, but I'm happy to use it.
> 
> I already noticed there are differences in time functions between Linux and
> NetBSD (which I use as host). For instance, simh refuses to allow the cpu idle
> settings, based on some timing test it does. I suppose that somehow this
> plays a role here too, somehow.
> 
> Maybe something similar causes the VH lines to drop characters after about
> 60 or so. That is the maximum packet size that works for Kermit when
> receiving. I will look again at that later.

These issues may indeed be related, and increasing the TTI WAIT time will help to mitigate it.

Someone once observed that pasting into the VAX simulator console didn't work well and, generally easily lost data.  At the time, I looked into that and observed that the logic which reads the input data (in tti_svc) would always read data without regard to whether the prior input data had actually been digested by the simulated system yet.  I changed this logic to only read new input if the prior character had been already digested by the simulated system OR if 500ms had elapsed since the last input character was read (this timeout allows a simulation to be interrupted with ^E when a simulated system is in a tight loop not processing interrupts).

Once I made this change, the user's pasting problem went away.  I just added the same logic to the PDP11 TTI's device.

However, it seems that since you logged data delivered through tti_rd() and all data was logged, the data loss you were seeing wasn't here, AND increasing the TTI WAIT time helping suggests that the data loss is happening in the OS's TTY driver input buffer.

On the VAX simulator (running VMS), the console input no longer has issues when pasting single lines of input, but when pasting relatively large amounts of data, the data can still be delivered to the OS faster than the user application can read it from the OS's type ahead buffer.  When this happens, chunks of data are lost (not single characters).  SYSGEN on VMS can be used to increase the size of the driver's type ahead buffer from the default of 78 to much bigger values (5000+) and this problem can be significantly mitigated and serial communication programs (Kermit, UUCP, etc.) can be well behaved and not loose data.

I have no idea how to influence the size of the type ahead buffer used by RSX or any other operating system. :-(

You might want to give the latest code a try and see if it helps, otherwise the increased TTI WAIT time seems to be the best accommodation.

- Mark