On 14 jan, 02:15, baz...{at}gmail.com wrote:
> There are actually two parts to the process: one is handled directly
> in hardware, the second is a software process.
>
> 1. Hardware
> Logic on the SecondSight card is triggered whenever a write is
> performed to any of the Apple's video memory ranges (text/lores,
> hires, gs-hires). When such a write is detected, the value is mirrored
> to the same memory range on the SecondSight card. An interrupt is also
> generated to the SS's onboard CPU and (part of) the address that was
> written to is latched in a register.
>
> 1.1 More Hardware
> The SS tracks what video mode the Apple is in by the same process as
> above, watching for writes to the video mode registers.
>
> 2. Software
> Upon processing of the interrupt, software on the onboard CPU reads
> the address and based on what video mode the card is in, and updates
> the SS VGA video buffer accordingly. Since we do not actually get the
> full 16-bit address, there are a few cases where we have to make
> educated guesses as to which video address we actually meant. In GS
> superhires mode this means we update 4 bytes for every write, if I
> recall.
>
> Jawaid
>

Thank you Jawaid and I am glad to see you here. That is a clear
explanation of how the SS works.

>
> On Jan 11, 8:45 pm, "geoff"

>
> > It looks like the graphics memory which the Second Sight shadows has to=
 exist
> > in the Mega 2 memory (hence the card needs to work in a slot with the M=
2BA0
> > pin). =A0Unless somebody understands the GS hardware better than I do, =
I don't
> > think the Second Sight can read memory from the fast RAM IIgs banks--wh=
ich is
> > what it looks like you are proposing).

You understood correctly what I was proposing but it appears the SS
does not behave like that.

> > My impression is that a software solution is the only way to implement =
a
> > higher desktop resolution.

As usual, Inside Mac of Color Quickdraw is worth reading especially
the Graphics Driver part which separates the display process into
separate layers: one for the graphic port, one for the display port.
Once again, a neat documentation from Apple.

> > Wouldn't a 640x400x2 be easier to implement and faster to get out the d=
oor
> > (since that is the native 640 mode QDII)? =A0This will show which softw=
are will
> > work with a higher resolution and which ones won't. =A0I see 8bit and m=
aybe
> > 24bit color support be added in a second phase.
>

Quickdraw II (and its standard routines) is the core toolset but a
complete desktop application requires the following toolsets to be
updated: Window Manager, Menu Manager, Control Manager, some other
toolsets and the one I especially like: the Midi toolset as it
modifies the QD II Cursor routines to perform MidiInputPoll calls.

If you want to keep compatibility with the original modes (320*200*16
and 640*200*4), you must add other modes =3D> update the toolsets
accordingly =3D> modify the ToolTable resource file to handle the new
types =3D> update the ToolLocator toolset. And please, do not forget the
display driver which outputs data to the video board ;-)

That is why I hoped the SS would be smart enough to read data from
other places than the display RAM of the IIgs. Too bad!

When I wrote Cogito II: The Return a long time ago for the SS, I used
to 400 bytes long table which told the graphics driver which lines
needed to be updated to the SS RAM. If we had the ability to read the
IIgs RAM that would have become useless.

Ahem! What I see from the toolsets is that the _GetMasterSCB IS the
main call! Now, I understand why Facelift disappeared!

antoine
--- SBBSecho 2.12-Win32