Re: IIgs video modes...

["Bryan Parkoff" <nospam@nospam.com>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
oMmdnR424K1hEnnYnZ2dnUVZ_tSunZ2d@comcast.com">news:oMmdnR424K1hEnnYnZ2dnUVZ_tSunZ2d@comcast.com...
> jsnospam@cimmeri.com wrote:
>> On Feb 27, 7:31 am, demp...@actrix.gen.nz (David Empson) wrote:
>>
>>>The horizontal line is the same width in SHR and other video modes,
>>>implying the same time (about 40 microseconds) for the active portion of
>>>the row, so it must have a higher frequency dot clock in order to fit
>>>320 or 640 pixels in the same space as 280 or 560 for other modes.
>>
>>
>> David, have you actually verified that they are the same width with
>> your eyeballs and a ruler?  Just curious if this is an established
>> fact now.
>
> It would be pretty obvious if you watch the monitor while switching
> modes.  Movement of the border edges would be hard to hide!
>
>>>If I remember right, the IIgs has a master clock frequency of 28.63636
>>>MHz. Deriving 8.18181 from that is reasonably OK: a divisor of 3.5, i.e.
>>>7 half cycles. It would be harder to derive 16.36363 MHz, which would
>>>require a divisor of 1.75. DPLL, perhaps?
>>
>>
>> Looking at the IIgs schematic, the VGC has both a 14M and 28M clock
>> input.   28M is generated by a dedicated oscillator nearby.   The only
>> other signals of interest are coming from a chip named SERCLK which
>> itself is driven by a 32.768khz crystal, and is powered at times by
>> the Lithium Battery.  I suppose this is a clock chip.
>>
>> This clock chip is for some reason connected to several of the VGC
>> inputs -- CLKCS, DATA, CLK, 1SEC, and 3.5DIK.   Not sure what that's
>> mean, but David mentioned 3.5 divisor above.  A bell has rung.
>
> My guess is that those data lines are just a "utility" connection in
> which some glue logic in the VGC is used to interface to the real-time
> clock/NVRAM.

Michael,

    I would advise to use Logic Analyzer like I did for DHGR, but I have not 
done with SGR yet.  I am able to count 10 ns pulse from the beginning to the 
end in one horizontal line.  Add each 10 ns pulse until it brings to a total 
63 us.  Try to exclude 560 * (10 ns * 7) and measure horizontal blanking. 
It might reveal that 560 pixels are using 8/16 instead of 7/14 to fit into 
640 pixels, but each pixel out of 560 is very tiny width to match 640 
pixels.  It looks like 1.143 pixel out of 640 to look like 560 pixels.  Rich 
claims that each 1.143 pixel looks terrible on NTSC monitor, but it looks 
fine to me because my sight is not very good as legal blind.

Bryan Parkoff