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. 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.
To properly emulate the device, you should have simh indicate that the
transmitter is ready when the physical hardware have transmitted the
character.
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?
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.
Johnny
- 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: [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
--
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
