Hi Mark,

in message <Pine.NEB.3.96.971018225100.7955A-100000@riscbsd3.client.
nc.com>
          you <mark@client.nc.com> wrote:

> I would not consider this reverse engineering etc but I would not
expect
> that to be able to provide enough information to write a driver.

I was afraid you'd say that.

> The problem arises when you try and find this information. The
obvious way
> is to look at the module code and see what it does but this would be
> reverse engineering in my book and is a no-no.

Definitely.


> An alternative (and I don't know if this would be considered reverse
> engineering, I suspect some may) is to use something that displays
the

I wouldn't say so. I mean if you have a look at the podule and read
something like FAS216 on one of the ICs, this can never be reverse-
engineering! And IMHO, you're doing the same, just electronically.

> contents of podule space. Various controller chips can often easily
be
> found, for example various SCSI chips report there ID's in certain
> registers after reset (info can be obtained from the chip data
sheet).
> However a lot of boards will have custom register is programmable
logic
> e.g. for interrupt / DMA control and the location and behaviour of
these
> can not normally be deduced from looking the the podule's memory
map.
> 
> This means that you need the cooperation of the hardware
manufacturers in
> order to write drivers if the details are not publically available.

Too bad. :-(((
Maybe I should just sell my Cumana controller, I'm fed up with the
hassle
of getting hold of a current version of csc.o again and again just
because
Cumana are unreasonable enough to put some stupid address offsets
under NDA
and not withdraw it now that they have several competitors.
But then it's working nicely with RISC OS and you keep hearing about
problems with other controllers.

So long, Markus