Subject: Re: Video sync problems
To: Markus Baeurle <emw4maba@gp.fht-esslingen.de>
From: Kjetil B. Thomassen <kjetil@thomassen.priv.no>
List: port-arm32
Date: 11/04/1998 21:33:40
In <URL:news:local.netbsd.port-arm32> on Wed 04 Nov, Markus Baeurle wrote:
> 
> I'm wondering if RiscBSD is treating the separate/common sync issue
> differently than RISC OS.

Probably.

> For the Risc PC I looked up the pin assignment in the Welcome Guide
> (IIRC). It says that you should feed back HSync from pin 13 to pin 11
> (Monitor ID 0) to tell the computer to output CSync on the VSync line (pin
> 14). I did so and it works well for RISC OS, no difference to a connection
> on the D-Sub input.

This also tells RISC OS that your monitor is only able to use 15kHz modes.
At least that is what the TRM claims.

> But in RiscBSD, the screen rotates through vertically because the monitor
> can't lock on the vertical sync! Even if I turn the vhold adjuster on
> the monitor, the screen still won't lock. My self-compiled kernel has the
> same mode compiled in that I'm using in RISC OS. And I tried an install
> kernel too - same result.
> 
> Questions:
> How is the switching between separate and common sync done by the Risc PC?
> I would assume it's hardware but I`m not so sure because there is a bit in
> the VIDC control register to control this. (I only have a datasheet for
> the old VIDC but I don't think it was dropped in the VIDC20.)

I can check that if you like, as I have the VIDC20 data sheet.
I just asks ARM for it.

> Maybe RISC OS checks pin 11 of the VGA connector and sets the bit in the
> VIDC control register accordingly? Would seem like a strange way to me,
> though. Can somebody with a tech manual please look where pin 11 on the
> VGA connector is going?

It is going to a non-inverting line buffer that is on the databus
pin 0. This is toggled on and off by the same signal that gets the
mouse buttons on the data bus.

So, yes, this is definitely something that is done in software. From
the schematics I would guess that the buffer is enabled, and then the
values are read from the data bus.

> If so, maybe RiscBSD doesn't do this?

Again, probably not.

> What would be a good place to set this bit from the RiscBSD kernel? I
> could hardwire this in my custom kernels.

I am sorry, but this is outside of my domain.

> I hope somebody can help me.

You could also buy or make a boks to generate composite sync directly
from the video output. I found a couple of these on the Net. At least
one of them are able to draw the power from the video port.

Kjetil B.
mailto:kjetil@thomassen.priv.no
http://home.eunet.no/~kjetilbt/