Hi Kjetil!

In message <Marcel-1.46-1104213340-0b0+YEw@kjetilbt.eunet.no> you wrote:

> > (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.

That's also in the welcome guide, but I don't think this is correct as I can
use all my modes although I have made the link.

> > 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.

That would be great. I need to know which bit it is for the VIDC20.
I'm pretty sure something has changed because the old VIDC only has two bits
to set the number of bits per pixel so they must have extended these.
The number of bits this is shifted in the RiscBSD source code tells me the
same.

> 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.

Seems like a weird way to me. Well, maybe they have a reason to do it this
way that I can't think of.

> > If so, maybe RiscBSD doesn't do this?
> 
> Again, probably not.

It definitely does it differently. Well, actually it doesn't do any of this
checking at all.
For now I'm using a solution Jasper Wallace (IIRC, I don't have the mail
here.) proposed to me, which is to completely disable any mode changing in
the kernel so the RISC OS mode is used which also preserves the csync setting.
You do this by commenting out the line "WriteWord ( VIDC_BASE, reg | value );"
in vidc.c (see the rest of the path below), currently at line 151.
Thanks for suggesting this, Jasper!
It's not an ideal solution though because I'm losing the cursor. Well, in
fact it is blinking in the middle of the screen quite happily, but not at the
prompt where it belongs.

> > 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 have found it now, it's in /sys/arch/arm32/vidc/console/vidcconsole.c.
The register is called VIDC_CONREG.

> > 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.

I tried that with the PC with disappointing results. The picture quality was
quite bad with all kinds of distortion that even got worse with every access
to the HD or CDROM! Maybe my mistake was to use an OR and not an XOR gate.
Anyway, I find it much easier to hack the RiscBSD kernel as I'm compiling
these myself anyway.
-- 
So long, Markus

PGP key available on request or from
my homepage at http://www.gp.fht-esslingen.de/students/emw4maba