On Thu, 14 Mar 2002, Chris Tribo wrote:

> On Thu, 14 Mar 2002, Andrew Doran wrote:
> 
> <snip>
> > With the wscons drivers it's possible to hard-wire the definitions into the
> > kernel configuration, but if it's indeterminte then that's not too useful.
> 
> 	It is indeterminite, very rarely they will go to the correct
> addresses. The only way I can get it to go where I want it is to unplug
> the cords in a certain order and rst's over and over until the chance
> reset to the "right" addresses

  I've experience the opposite on my 5000/25:  most of the time the
keyboard and mouse would be assigned the expected device ID, but once in a
rare while they would be switched.  If I halt the system, it will usually
revert back to the expected settings.  There's a PROM test that can be
used to check the device assignements, but I don't recall what they are at
the moment.

> > Does this reversal ever happen "on the fly" - e.g. while you're typing into
> > an xterm? Either way it should be easy enough to solve; ACCESS.bus devices

  I've never had them change in the middle of anything.  I've only seen
them change when halting or rebooting.

> documents I have to RTF/PDF/PS and send them to you let me know. The last
> word I heard on AB development as that nothing new could happen until the
> bus could transmit. Which hasn't been figured out yet I don't think. I

  The bus can transmit - I've been able to send data out, but I have
problems getting the response back.  I think the problem may be that data
starts coming back in before the entire transmit is completed, and data
gets lost.  I've thought about reworking the driver so that the transmit
routine can also process input while it's sending data.  I haven't been
able to work on it for a while, since the only monitor I had at home which
worked with the 5000/25 died violently.  Then there's also a little
problem of being too busy doing too many other things and not having the
time do work on all the little NetBSD projects I'd like to be working on.

  Another thing I was trying was to check the data in one of the device
handlers for invalid codes and swap the keyboard/mouse handlers.  I think
that the other device handler didn't have any easily detected invalid
values, and losing data due to lost interrupts can confuse the checks as
well.

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA