On Tue, 12 Dec 2000, Simon Burge wrote:

> Chris Tribo wrote:
> 
> > 	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?
> 
> I've never really looked at the dtop bus thing (and probably wont until
> I get the right keyboard/mouse for my maxine), but I'm a bit confused as

	I have a spare keyboard and mostly working mouse (the #1 button is
flaky).

> to why you think using assembly language is a good idea for this?  If
> we're using C for things like gigabit network and ultra-wide fast SCSI
> disk drivers, surely it's good enough for a serial protocol...

	Yes, but we are not running Gigabit or UltraWide our pmaxen
with a 12.5MHz bus, and it needs to work on a 20MHz CPU. I'm all for
making things easier but a.) It doesn't work right now b.) it doesn't work
with WSCONS, and c.) This code is running all the time, every few ticks,
wouldn't asym reduce context switching, CPU time, and make it interrupt
and recover more gracefully?
	There's a p-code driver up at
http://www.ping.be/~ping0751/i2cfaq/i2cpseud.htm
	It could be pretty easilly dropped into our existing C setup, or
coded with asym. 


	Disclamer: I have no idea what I'm talking about

	

	Chris