Thanks to Bill and Lennart for the right answer:
> The former.  It creates an IO handle in which you can use offsets
> from 0 to the length of the region.  So those 0s should be 0s.

Which means the PAS will be even more of a pain than I suspected, since its
register addresses are 078B, 0B88, 0B89, 0B8A, 0B8B, 0F8A, 138B, 1388, 1389,
138A, 178B, 178A, 1B88, 1B89, 2789, 738B, 778B, 7789, 8388, 8389, 838A, 838B, 
9A01, BF8A, BF88, EF8B, F388, F389, F38A, F788, F789, FB8A, FF88, FF8B, 
and 0x61, 0x42, 0x43 for PC speaker control and 0x41 for system warm boot
detection.  Well, at least a *few* of those i/o ports are clumped together.

This is obviously a board designed by hardware engineers who hate software
engineers.

(By the way, my recent patch for pas.c included a bogon:  I call bus_space_map
for 0x388 to reserve the device address, but it turns out the PAS doesn't have
a register at that address; the PAS uses an amazing kludge for offset
addressing where (apparently) the board knows its register addresses as values
to XOR with a base address (normally 0x388), but doesn't happen to have a
register at 0 ^ 0x388...)

Well, I thought it would be cleaner to write a named function for each control
register, now I have the motivation to do so.  I just hope there isn't a
small limit on the number of mapped bus_space regions available...

Thanks all!