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

Reply via email to