On 2016-01-04 21:05, Paul Koning wrote:
On Jan 4, 2016, at 2:53 PM, Mark Pizzolato <m...@infocomm.com> wrote:
...
I vaguely remember that something else depends on how it is currently
implemented. The wait delay was added to accommodate the fact that something
didn't expect immediate response. A delay of 1 is essentially the same as no
delay.
It is hard to imagine that the OS driver would expect that the device would
complete some operation in one instruction time. This would tend to fail as
newer models of CPU were implemented which used the same peripheral hardware,
no?
All I can say is that it does work on real hardware.
The manual says that the bit is "self-clearing". That isn't the same words as the more
common "write only" but it implies roughly the same thing. The driver definitely does
not expect the whole master clear process to complete in a few instruction times; it patiently
waits for RUN to become set. But it DOES expect that MCLR does not read back as set, not even very
quickly after it was set by the driver.
So maybe the thing to do is have the process master clear action be started at
the CSR write rather than delayed (while other CSR operations can remain
delayed) so that at least the clear_master_clear part is done right away.
What about just always returning that bit as zero when read? Seems that
should be good enough. Or is something else also expected to happen that
don't? Just masking out the master clear means you can keep the delay
for the rest as it is, or did I miss something more?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh