[Info-vax] Some questions on software for VMS 7.3 VAX

[Johnny Billquist]

On 2016-01-15 15:03, John E. Malmberg wrote:
> On 1/15/2016 5:00 AM, hb wrote:
>> On 01/15/2016 10:31 AM, lists at openmailbox.org wrote:
>>
>>>> This is based on the emacs21_2.zip from the 8.0 freeware cd. There
>>>> are a
>>>> couple of changes to let emacs make a computer slow. It looks like that
>>>> code was never built or tested on VAXes. Also, this VAX is a simh and I
>>>> use the console, OPA0:, set to a reasonable baud rate. I can't get
>>>> it to
>>>> work when logged in via telnet to port 60123, which is a simh DZ
>>>> device,
>>>> aka TTA0:. The process hangs in LEF with two busy channels to TTA0:. I
>>>> have/had other problems with that device: "-SYSTEM-W-DATAOVERUN, data
>>>> overrun" when I type very fast, aka do a cut and paste. So, it's not
>>>> yet
>>>> production quality, but for hobbyists ...
>>>
>>> If it overruns it's not ready for hobbyists either. Very little is worse
>>> than an editor that doesn't work or screws up your code.
>>
>> Maybe I didn't make it clear, to me this is a simh problem, not an Emacs
>> problem. The overrun shows in DCL. I didn't try to debug the hang in
>> Emacs.
>
> It is entirely possible that the SYSTEM-W-DATAOVERUN can be reproduced
> with a physical VAX of the same speed or slower rating as the SimH system.

Yes. Throwing lots of data at a (simulated) serial port will cause loss 
of data. The OS normally will not be able to empty the buffers fast 
enough. Not at all related to Emacs, or whatever. It's a problem between 
the hardware and device driver+OS.

This is why flow control exists. However, on simulated systems, flow 
control works even worse. DEC normally use software flow control (ie. 
XON/XOFF), and that is not managed by emulated serial lines, meaning you 
essentially have no flow control at all. If the OS buffers start filling 
up, and you don't respect the XOFF the OS sends, data will be lost. Same 
as it always was.

It's also not an easy problem to solve in the emulator.

> The DZ device family does not have buffering and will not work reliably
> for high speed input.

Right. DZ is a horrible device.

> Using them for high-speed output is self-limiting.  They will chew up so
> much CPU that it will throttle the output, and anything else you are
> attempting to do.

Yes.

> It is also possible to bugcheck a physical VAX by sending data to
> multiple DZ interfaces too fast at the same time.  I have seen it happen
> multiple times.  The only fix is to change to using a better serial
> controller.

That, on the other had, would be a bug in the code. There is no reason 
the OS should bugcheck because a serial line controller is going wild.

> A DZ interface is basically good enough for human typing speed.  If you
> are trying anything faster over it, you are rolling the dice.

Well, it can take a little more than that, but not much more, and it of 
course also depends on which CPU we're talking about.

> Which is why trying to use the serial console of a VAX for anything
> other than system maintenance very bad idea, since that is almost always
> a DZ port.

Actually never. DZ ports cannot be used as the console port. Old VAXen 
with Unibuses have the serial port specially connected as its own device 
hooked into the CPU. Does not pass through the Unibus at all.
The same is true for old, small Qbus machines. Console is special.
And of course, anything newer than Unibus/Qbus do not have a DZ 
controller to start with.

But the actual serial console interface is pretty much just as stupid as 
a DZ controller anyway, but at least it is only one serial line, and not 
8, which is what a DZ11 have...

	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