[Coco] V.PAGE

[Chuck Youse]

On Sun, 2008-07-20 at 23:03 -0400, Robert Gault wrote:
> Chuck Youse wrote:
> > This byte in the device descriptor appears to be unused (or at least,
> > not useful) on Coco OS-9 (both levels 1 and 2).  While it's set in the
> > device descriptor, it appears to be cleared in the device static storage
> > area (rather than copied from the descriptor) before the call to the
> > driver's INIT routine during I$Attach (in both Level 1 and Level 2
> > IOMAN).
> > 
> > I'd like to re-use this byte as the multi-pak slot indicator, as I can't
> > see that that's in the device descriptor anywhere else and appears to be
> > hard-coded into the respective device drivers.
> > 
> > Am I going to make something explode if I try to repurpose this byte?
> > 
> > C.
> >
> 
> Nothing should explode but you may not want to hard code the slot. A 
> more flexible scheme would be to use a driver data byte for each device 
> installed in the MPI. It would be the responsibility of the device 
> during its init phase to store the current value of the MPI I/O byte, 
> search for itself scanning through the slots, and saving the found slot.
> Each time the device (driver) runs, it swaps MPI slots as needed.

Thanks for the response.  And interesting idea - but - there are three
problems I can see with this scheme:

1. auto-probing is dangerous business - not every device can be detected
safely, which may lead to interference with or crashing other devices ..

2. What if there are multiple instances of a card in the multi-pak
(e.g., more than one RS-232 card)?

3. Architecturally, OS-9 doesn't do any auto-probing of this sort; port
addresses, drive geometries, etc. are all hard-coded into the device
descriptors.  These save the system a lot of guesswork, and the
associated code/speed.  MPI slot is just another of these values (and
V.PAGE seems the right place to me, as slot selection is in fact a form
of address extension). So probing just doesn't match the rest of the
system architecture that well.

C.