I've been thinking about this for awhile, and I'm at the point
where I'd like to pick up MIPS Assembly if this is a good idea. Basically
it seems that the current driver (dtop) is a psuedo device driver that
checks a stack for keyboard/locator data, but not an actual packet. It
merly extracts the Source address and if it's 0x6c it assumes that it's
the keyboard and if it's 0x6a it assumes that it's a locator device. Is
this accurate?
	I think it better to have an actual Access Bus driver
written in MIPS assembly. The DEC Access Bus documentation gives me the
impression that we don't even need to touch I2C, other than simply
starting and stopping the bus, and possibly when devices are hot
swapped. This would make life quite a bit simpler if we don't need to
touch I2C at the Assym. level, anyone know if that is true?

Problems with dtop presently: (according to me)

	-Uses hardcoded device addresses without detecting what's there.

	-No hot-swapping of devices.

	-The interrupt load on headed pmax systems is high and
	 heavily blocked. I notice that sfb causes 72 int/sec. When the
	 system gets busy it doesn't check the dtop buffer and data over-
	 runs the buffer. Which results in data and op-codes going to 
	 /dev/null until the dtop driver gets a chance to look for data.
	 this is most notable whilst compiling anything and moving the
	 mouse in X, though it's happened with only the keyboard on the
	 console.

	-dtop doesn't poll, it assumes that there is a packet there every
	 time it checks. In theory that doesn't seem like a very good idea
	 Granted polling isn't a good idea anyway, but there has to be a
	 better alternative to polling the buffer directly.

	-doesn't work with WSCONS

	-It's _evil_  (J/K)

Hacks that would help the current situation:

	-commiting Micheal Hitch's dtop hacks to let the driver tell when
	 a keyboard/locator is at the wrong address and swap the hardcoded
	 device entries in the driver. I still haven't tried them as they 
	 were written for ~1.4P.

	-fix A.B. so it can transmit, then we can at least force devices
	 to reinitialize to a desired address. Possibly keeping the
	 current dtop/lk code base, though with WSCONS it'll probably have
	 to be rewritten anyway. Theoretically this would let us detect
	 device attachment/removal and get devices on the right ID, but
	 still avoiding the bigger picture (IMHO).



	Anyone have any comments on this? {yes/no/you're an idiot, and
have no idea what you're talking about/it'd be nice, but.../etc.} Also,
the MIPS assym programming manual isn't very learner friendly, any
pointers to a decent learning MIPS assym for the x86 programmer, or
examples around of how to write anything for the NetBSD kernel?


	Chris