on 4/26/00 4:13 AM, Toru Nishimura at nisimura@itc.aist-nara.ac.jp wrote
something like:

>> Also, does the PROM monitor work like a TSR where it stays resident?
> 
> As far as I know, Digital PROM does not do such thing.  It's possible
> to call predefined (by TURBOchannel specification) routines, but
> essentially PROM does not function during loaded operating system
> (ULTRIX or NetBSD) is on service.

    OK, I was wondering if the PROM Executive could continue being
called/used like OpenFirmware, which AFAIK stays resident until you tell it
to go away (on MacPPC anyway).
    There must be some way in which the PROM Exec. picks out the keyboard
and mouse and references this info. Perhaps a special purpose register on
the I2C master (and in this case only) controller? That being the case,
could we not just read the values? I'm assuming the trick is knowing
if/where they are stored.
    I know you mentioned we can't send data on the bus reliably, what if we
issue just a bus interrogate command until the kernel can at least pick out
"keyboard" and then assume that the mouse is on the other address? Is that
possible to try on my local tree with -current or do you have most of your
work in a private tree? I think I'll try Michael's patch and see if that
fixes things first.
    On my MAXine, almost every time I power on the system or reboot, the KB
and mouse addresses switch to the incorrect ones. (Mouse on 0x6c and kb on
0x6a) Thus far the only way around this is to unplug the keyboard and mouse
in a certain order, or keep typing rst until they eventually switch to the
correct address; sometimes that can take 10+ tries.

    Chris


-- 
    
    "I use to be indecisive, now I'm not so sure..."