> * when there is no device responding to the read cycles, and the bus
> (hardware, usually, or software for weird implementations where it's
> normally done in hardware) arranges for an all-1s result.
> 
> ISA I/O accesses (and maybe memory accesses) _do_ fall into that
> category, i.e. a read of a non-existant device is supposed to return
> all-bits-set.

This is what I was looking for  ;-)  and having read isareg.h, it appears
that the addresses I'm attempting to read are beyond IO_ISAEND (0x3ff),
which would explain the result.

> I dnnno what kinda chip your working on, or how its registers are
> layed out, but it sounds to me like they don't necessarily end up
> where you think they're going to end up.

It's the Acer Labs M1543 chip that does all the i/o stuff in my CATS
machine, and I'm working from the Acer docs.  Also, the register locations
that the docs state, appear to be standard across IEEE1284 devices, as
they're wired in to the FreeBSD ppbus stuff, which is what I'm working
with.

I suppose the question now is:

Given that the registers that I want are (according to dev/isa/isareg.h)
beyond the end of the standard ISA address space, how do I access them?

> > The code that give this is:
> > 
> > 	ppc->ppc_sc = malloc(sizeof(struct ppc_softc),M_DEVBUF,M_NOWAIT);
> 
> I'm not sure i want to understand what you're doing here....  (it
> seems ... unlikely to be the right thing.)

I knew somebody would say that  ;-)  The code needs some temporary space
to store stuff like iot & ioh whilst it does the rest of the probe and the
ppc_softc has roughly the right elements...it's free()'d after the
bus_space_unmap() a little later on.

> FWIW, you probably want two separate mappings for the two
> non-contiguous register sets.  on ports which do (proper, hell, ANY!)
> bus space accounting, this code will fall over fairly well.

I was wondering about this - It didn't seem "right" to have a gap, but I
couldn't find an obvious example in the tree which had more than one
region mapped.

By fall over, I presume you mean there'll be a panic at some point?
Rather than returning a duff value?

> Are you sure that the extended registers are:
> 	* enabled by the hardware (i.e. the port's not running in
> 	  'stupid' mode or something), and

AFAICT from the acer docs, the ECR register is always there, and is what
is needed to engaged ECP mode.  Unless anyone knows otherwise?  (I have to
confess to not having read every page of the document - it's a big
chip...)

> 	* the system places them in the place you're expecting?

This is something that the Acer docs (obviously) don't comment on and I
can't find anything in the tree or elsewhere to explain where they would
turn up.  It might make sense that they don't appear where I'm expecting,
given what I read in isareg.h.  Does anyone know where they would appear?

Thanks,

David.