[Coco] This tickles me....

[Chuck Youse]

On Fri, 2008-10-24 at 23:00 -0400, Gene Heskett wrote:

> 
> V.PAGE?  Yes its used, by the memory manager, and the windowing system IIRC.  
> I believe I also used it in myram. (my ramdisk, in 3rd party tree)  Since 
> myram still works under 3.2.8, I have to assume it is still valid, and not 
> open for grabs.
> 

Hm, I don't see myram.  I also see no references in the kernel, other
than in IOMan, where V.PAGE is explicitly cleared in the static device
data area right before INIT is called on any device driver.  (Just
because I don't see any more references doesn't mean it's not used - it
just means its not referenced as V.PAGE - i.e., disassembly that never
got its constants cleaned up or offsets from other fields are used,
etc.)

Seeing as V.PAGE is supposed to be used as the address extension field -
for systems that place I/O registers behind address translation rather
than in front - it's meaningless on a Coco unless you have a multi-pak
(which has its own address-translation hardware to map different slots
into FF40-FF5F).  I'm curious why the memory manager gets its fingers
into that.  I can see why the window manager might want make use of this
field, but that shouldn't affect non-Window devices (it certainly
doesn't pay attention to what's in the descriptor; it's always HW.PAGE,
window devices or not, under Level 2).

It would seem the only reason why the kernel even needs to reference
this field is to determine which instance of a device driver to invoke.
I.e., two devices at FF40 with V.PAGE=0 would be e.g., two drives on the
same disk controller, a third drive at FF40 with V.PAGE=1 would be a
different instance of the same driver.  It's clear that this was
Microware's intent, and it's also clear that it was unused on the Coco.
for some reason no one used the translation ability of the multi-pak and
instead did address decoding on each board..

Anyway, if you could provide further information it would be
interesting.

Thanks,
C.