[Coco] V.PAGE

[Robert Gault]

Chuck Youse wrote:
> 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.

You only probe once, curing the init phase of the driver. That uses an 
insignificant amount of processor time.

If you are going to create a system with multiple RS-232 cards or disk 
controllers, you will need to also create custom drivers as none of the 
current ones are designed this way.
As I said, if this is just for you then modify OS-9 to your hearts 
content. :)

Auto-probing is not dangerous if done with correct coding. Obviously one 
turns off interrupts before switching the MPI, uses the intended device, 
and resets the system as it was found when the driver gets finished. 
This is exactly what a driver must do if not the floppy controller.
Study the NitrOS-9 code for examples.