Device Driver For Developers and Hackers

[Craig Johnson]

I have been playing for some time with the idea of building my own combo
board so that I could expand my system using the cheap RAM SIMMs that are
available, get another couple of serial ports, and gain some experience
toward constructing some more ambitious expansion cards.  I've had the
design worked out for some time now, but one thing that was holding me
back was determining what the magic ID code is that is contained in the
tiny ROM on the combo board (I intend to let the software believe that my
combo board is a real AT&T combo board).  A couple of days ago I finally
was able to borrow a real combo board and examine it.

Since the ID ROM was soldered-in, rather than unsolder it and try to read
it in a PROM programmer, I decided to see if I could get at its contents
through software.  My first attempt was to try gaining access through
/dev/mem (which I'd never played with before).  Unfortunately, /dev/mem
appears to only let you get to physical memory locations that are decoded
in "user" mode.  Most/all the I/O in the Unix PC is only accessible in
privileged "supervisor" mode (used by the kernel).

So I decided to try a loadable device driver instead.  Starting with Mike
"Ford" Ditto's vidram driver, it was a small effort to modify it to allow
access to any physical address in the machine.  The driver I created is
accessed through a device called /dev/io.  It is a character device.  You
simply open the device, seek to the address you want to read, and then
read a stream of bytes -- as many as you want.  It works beautifully.
There was the ID ROM sitting from 0xc3fff0 to 0xc3ffff.  I also read the
8530's registers just for fun.  I have not tried using it to write to I/O
yet, but it should work ok provided byte I/O is acceptable.  Modifications
would be need before you could use this to write to word-wide registers.

So gang, is there anyone out there hacking on the guts of this machine
that feels like this driver would help them?  Let me know if you're
interested and if warranted I'll post it in a few days.

I'm looking forward to getting the device driver document from Thad so I
can learn some about block devices next.  I've been wondering if the
vidram driver wouldn't work a lot better as a block device.  Then the
screen could be accessed with bcopy or maybe even with the DMA hardware.
By the way, can anyone tell me the purpose of the subyte() and fubyte()
calls in the vidram driver?  They appear to simply move a byte at a time
in/out of the "u" user structure.  Why can't the data in the user
structure be accessed directly like the other elements of the structure?
----
	Craig V. Johnson		...!fluke!vince
	John Fluke Mfg. Co.			or
	Everett, WA			vince at tc.fluke.com
----