[Simh] PDP-8 KL8E XON/XOFF

[Mark Pizzolato]

On Monday, June 6, 2016 at 9:46 AM, Johnny Billquist wrote:
> On 2016-06-06 18:13, Mark Pizzolato wrote:
> > Hi Johnny,
> >
> > 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.
> 
> I don't see how you mean that, Mark.
> The PDP-8 will transfer one byte to the serial port. As soon as that byte have
> been transmitted, the serial port will once more indicate that it is free.
> 
> I would assume that simh gets the byte from the emulated hardware, and
> the pass it on to the physical device. But simh is not controlling the physical
> hardware. It is using the host OS device driver, which in turn is using the
> actual hardware. So any write, from the simh point of view, will complete
> directly, as the host OS driver will be buffering data, and is interrupt driven.

Actually the current simh framework code will buffer a number of output 
characters before sending the buffer to the host OS.  If when it attempts to 
send the buffer of data to the device and the device is still busy sending 
prior data, it will continue to buffer more data.  As Bill says, this works just 
fine if the line speed is sufficiently fast (via serial or across the network via 
a telnet connection) but it certainly IS NOT (at this time) trying to simulate
data delivery at the programmatically specified line speed. 

> So how can simh know when the byte actually have been sent? This host OS
> do not provide this information.
> And the host OS device driver in turn, will just do a write of the byte to the
> physical controller as soon as it is allowed to. And after that, the physical
> controller only signals when it can accept another character, which is not the
> same thing as the character actually have been transmitted, as there can be a
> buffer at that level too, so even the host OS do not know when a character
> have actually been transmitted.

Like I said, there definitely is a problem in the simh layer.  Once that is fixed 
some of the other ones you mention here may indeed also be a factor.

> To properly emulate the device, you should have simh indicate that the
> transmitter is ready when the physical hardware have transmitted the
> character.

The best goal will be to let the simulator know when the host OS has said
the write has completed.

> As I can's even see how simh could do this, as it all depends on the host OS,
> and physical hardware, how can it be a problem in simh?

Simh is currently buffering before sending.

> Or are you just suggesting that you'll add a timer in simh, and the transmitter
> idle flag will just blindly be set after that time, and this time would then be
> based what emulated bit rate you set?
> Which potentially will not work right, as the physical bit rate might not
> actually match what you set in the emulator. And furthermore, you now
> introduce timing issues between how the physical hardware works, and a
> calculated time of it.

There will be a combination of NOT buffering in the simh layer AND timing I/O 
completion indication in the simulator so that it reflects a good approximation of 
the serial port bit rate.  This strategy has already been demonstrated to work 
well for input character processing.  This is why pasting a whole text file's contents 
into a simulator telnet session now works for many devices.

- Mark


> > - Mark
> >
> > On Monday, June 6, 2016 at 9:01 AM, Johnny Billquist wrote:
> >> On 2016-06-06 17:44, William Wuttke wrote:
> >>> Hi Mark,
> >>>
> >>> Looking at the sources, the latest date on most of the files is Dec 15,
> 2015.
> >>>
> >>> The serial port is actually 2 GPIO pins on the Broadcom SOC chip,
> >>> levels
> >> translated to RS-232 via a MAX3232.
> >>>
> >>> The Raspberry Pi is a model 1 B+.
> >>>
> >>> I looked at the sources online, and I saw the work done on the
> >>> serial port
> >> speed on the input side, but nothing on the output side.
> >>>
> >>> The deal is that unless you are using ancient hardware connected to
> >> simh/PDP-8, you wouldn’t notice any problem.
> >>>
> >>> I wanted to post to this mailing list first to get some ideas before
> >>> I create an
> >> issue.
> >>
> >> Your problem is that the serial port on your raspberry is buffering
> >> for you. Either in the hardware, or else in the device driver.
> >>
> >> The PDP-8 should not output data at the bps rate of the serial port.
> >> A real machine don't do that. However, a real KL8E or KL8JA only have
> >> a one character buffer. You need simh to simulate this then. but how
> >> to do that might be very difficult, since this buffering is happening
> >> on the hardware, or device driver in the OS for the serial port, and
> >> is not something simh have real control over, or deep access to.
> >>
> >> 	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
> >> _______________________________________________
> >> Simh mailing list
> >> Simh at trailing-edge.com
> >> http://mailman.trailing-edge.com/mailman/listinfo/simh
> 
> 
> --
> 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