A520 Color Doubt

[spawnerbr]

Hi all.
I got an A520 PAL from Europe and have tried to use with my Color Conversion Box from PAL to HDMI. I use that Color Conversion Box on all computers that I have from Europe. Works perfectly with colors. Just another info, I'm from Brazil.
So, my first attempt was use the A520 PAL on my Amiga 500 NTSC. Plugged the VIDEO OUT on my Color Conversion Box and the colors goes wrong. The pics are here to show what happened.
Then I connected the A520 PAL to my Amiga 1200 PAL and using the same connection the colors comes perfect.
Now, my last attempt was connect the A520 PAL on my Amiga 1200 NTSC and got the same color problems like the Amiga 500 NTSC.
I just wanna understand why that. Is this the vsync? Thanks all.

[robinsonb5]

The A520 makes use of the /C1 clock signal on video port pin 15, and this frequency differs between PAL and NTSC Amigas - I suspect that's the reason for the difference you're seeing.

[Zetr0]

@spawnerbr

If I am not mistaken Brazil uses PAL-M with a close to NTSC (3.575611 MHz instead of 3.58MHz) colour sub carrier - I am sure rkauer will be along to confirm.

At the moment when you connect the PAL A520 to an NTSC based Amiga the colour information is skewed (as you have seen) this is due to the /C1 output on the native Video, as out fellow forumite robinsonb5 suspects.

With an NTSC Amiga it outputs 3.58Mhz to the /C1 (Colour Clock) - the A520 uses this *clock* in sample timing for the RGB Colour input from the Amiga. A PAL A520 requires a clock ( /C1 ) of 4.43361875 MHz to sample the RGB for output - with it only receiving 3.58MHz you are essentially losing 20% of the colour information per sample of RED, GREEN and BLUE.

As you can see its a bit of a mess - so what can be done about this?

You would need something in between the Amiga output and the A520 - personally I would forgo the A520, they are noisy beasts and only serve to push the machine further away from the wall off the desk. Instead have you thought about a RGB or YUV component hook up?

Does your TV support RGB/SCART or YUV ?

[mark_k]

That's a pretty bogus explanation.

The A520 doesn't sample the analogue R, G and B signals. I believe the /C1 clock present on the 23-pin video connector of PAL machines is ~3.55MHz, see http://amigadev.elowar.com/read/ADCD.../node029E.html.

But if the A520 does use the /C1 clock then the difference between PAL and NTSC machines could explain the problem. Also, because of the different clock frequencies, video timings (scanline time etc.) are shorter on an NTSC machine. Perhaps they are sufficiently out-of-spec for your PAL-to-HDMI box to cause problems?

[robinsonb5]

Originally Posted by mark_k

But if the A520 does use the /C1 clock then the difference between PAL and NTSC machines could explain the problem. Also, because of the different clock frequencies, video timings (scanline time etc.) are shorter on an NTSC machine. Perhaps they are sufficiently out-of-spec for your PAL-to-HDMI box to cause problems?

According to the Schematic found here: http://members.iinet.net.au/~davem2/...0-standard.png The A520 does use the /C1 clock but also has an internal oscillator.

The MC1377 chip requires a clock of either 3.58-ish MHz for NTSC mode, or 4.43-ish for PAL mode - these are the colour carrier frequencies for NTSC and PAL.

A PAL Amiga doesn't output 4.43MHz on /c1, though - it outputs 3.55MHz, and while I'm not sure exactly what's going on with the clock division in IC2, I think it's designed to keep the 4.43MHz clock reasonably edge-aligned with the Amiga's clock. On a PAL machine there's a 5:4 relationship between C1 (3.55) and the internal oscillator (4.43) - but on an NTSC machine C1 is 3.58MHz, which messes up that relationship. I think the colour cycling is due to an interference pattern between those two clock frequencies, causing the colour clock to drift in and out of stability.

[mark_k]

Originally Posted by robinsonb5

A PAL Amiga doesn't output 4.43MHz on /c1, though - it outputs 3.55MHz, and while I'm not sure exactly what's going on with the clock division in IC2, I think it's designed to keep the 4.43MHz clock reasonably edge-aligned with the Amiga's clock. On a PAL machine there's a 5:4 relationship between C1 (3.55) and the internal oscillator (4.43) - but on an NTSC machine C1 is 3.58MHz, which messes up that relationship. I think the colour cycling is due to an interference pattern between those two clock frequencies, causing the colour clock to drift in and out of stability.

Yes I think the flip-flops and related circuitry in the schematic are used to somehow tweak the A520's on-board 4.43MHz oscillator to be aligned with the Amiga's clock. They divide the C1 clock by 4, so the output of that is 1/5 of the PAL subcarrier frequency. My electronics skills are very rusty though.

Another possible reason for the picture problem could be the alternate long/short lines which are a feature of the NTSC signal. It's possible (on an ECS machine) to program the ECS registers to disable the long/short toggle (LOLDIS bit in BEAMCON0) but of course that won't do much good for most software. Does setting LOLDIS require you to manually program all the other video signal timings? Of course if you don't mind playing games in PAL mode you can just use a program like Degrader to set PAL mode before running a game (ECS Agnus required).

I wonder how disconnecting the C1 clock line between the Amiga and A520 would affect its output...

[spawnerbr]

Originally Posted by Zetr0

@spawnerbr
Does your TV support RGB/SCART or YUV ?

No, we don't have Scart on TVs. I have a Scaler Box to conver Scart to HDMI that I use on my Spectrum and other systems. I have a 15Khz monitor to connect from the Amiga RGB, but I'm trying another way.
I can do a DB23 to Scart too but I got this A520 in a pile of things, so just trying to have use for this.

[Hewitson]

Forget about the A520. It's the worst quality RF modulator ever designed and even in 1987 it was considered absolute rubbish.

Get yourself an RGB SCART to Component converter. I use the CSY-2100, and I highly recommend it.