FPGA 6561 - PAL Questions

[JonBrawn]

I'm looking into what I must do to support PAL on the 6561 FPGA. I'm going to be assuming PAL G / I parameters for the video are:

25 frames/second
50 fields/second
625 scan lines/frame
312.5 scan lines/field
288/576 visible lines per field/frame
.576ms vert sync length
4.43361875 MHz colour subcarrier.
64µs line duration
1.55-2.05µs front porch
4.5-4.9µs sync pulse length
5.5-5.9µs back porch length
9-11 cycle colour burst, alternating +/- 45º, starting 2.02-2.48µs into back porch
51.85-52.35µs active video
Sync is 0.000V
Blank is 0.285V
Black is 0.339V
White is 1.000V
Bright is 1.073V (this is full brightness + full saturated colour)
5-5-5 vertical sync structure
The R-Y component ("V") alternates phase from line to line - which I assume means a 180º phase shift - this means a different sine wave table for odd and even lines.

Given what I already have, this is all nice and easy to code up.

Things I'm going to have to find out before I can have a first stab at this, though:

Starting with an easy one:
- Does the 6561 always interlace or never interlace?

Now, what looks like a couple of tough ones:
- What phase shifts correspond to the 16 colours?
- What luma amplitudes correspond to each colour?
But if somebody has good RGB values for the 16 PAL VIC20 colours, I can calculate these.

And one that'd almost certainly a sit down with an oscilloscope and a notepad:
- What are the two chroma modulation amplitude values?

And one to be solved using empirical methods:
- Does the -45º colour burst correspond to the 0º phase shifted R-Y or the 180º phase shifted R-Y?

[groepaz]

PAL VIC has no interlace mode.

For the Color Angles and Amplitudes, check https://sourceforge.net/p/vice-emu/code ... ic-color.c (You might want to contact "Tobias" on Forum64 for the raw measurements)

[mathop]

There is some research data here (partly German)

The PAL colour generation is a bit problematic because the even and odd lines have different angles/amplitudes for each of the colours. This is probably due to the way the colours are generated on the chip.

In theory all dark colours (2-8) should have roughly 2*L amplitude and all light colours (9-15) should have L amplitude, where L is the amplitude of the colour burst signal. But again this does not really work in practice.

On the 6561 a line is not 64µs, rather 4*71/fsc, where fsc is the colour burst frequency. So slightly above 64µs. This means that the colour carrier is actually phase-locked to the horizontal sync, which is also a bit nonstandard. (Well, quite illegal I would say. )

[JonBrawn]

On the 6561 a line is not 64µs, rather 4*71/fsc, where fsc is the colour burst frequency. So slightly above 64µs.

It's only out by 0.09%, which if it were independent of everything else wouldn't be an issue in the slightest, I'm sure. How you avoid the carrier being in lock with the horizontal line frequency when you've only got one incoming clock I'm not really sure. You could probably do something about it if you had an awesome PLL on your FPGA, but I don't.

[JonBrawn]

In theory all dark colours (2-8) should have roughly 2*L amplitude and all light colours (9-15) should have L amplitude, where L is the amplitude of the colour burst signal. But again this does not really work in practice.

You're all going to hate my NTSC colour tables. Note that I am definitely not claiming that these are technically accurate to the 6560-101 at all. They are just values I picked to make my life easy. I expect that many of the details in here are going to horrify you, in particular having only five luma levels.

Here's my luma table - only five distinct values:

Code: Select all

   always @(*) begin                                                            
      case (colour)                                                             
         `BLACK:     luma_value <= `LUMA_0;                                     
         `WHITE:     luma_value <= `LUMA_100;                                   
         `RED:       luma_value <= `LUMA_25;                                    
         `CYAN:      luma_value <= `LUMA_75;                                    
         `PURPLE:    luma_value <= `LUMA_50;                                    
         `GREEN:     luma_value <= `LUMA_50;                                    
         `BLUE:      luma_value <= `LUMA_25;                                    
         `YELLOW:    luma_value <= `LUMA_75;                                    
         `ORANGE:    luma_value <= `LUMA_50;                                    
         `LT_ORANGE: luma_value <= `LUMA_75;                                    
         `LT_RED:    luma_value <= `LUMA_50;                                    
         `LT_CYAN:   luma_value <= `LUMA_100;                                   
         `LT_PURPLE: luma_value <= `LUMA_75;                                    
         `LT_GREEN:  luma_value <= `LUMA_75;                                    
         `LT_BLUE:   luma_value <= `LUMA_50;                                    
         `LT_YELLOW: luma_value <= `LUMA_100;                                   
      endcase                                                                   
   end

And my chroma angles:

Code: Select all

   wire [6:0] angle_blue   = {angle_000,3'b000};
   wire [6:0] angle_purple = {angle_045,3'b000};
   wire [6:0] angle_red    = {angle_112,3'b000}; // 112.5º
   wire [6:0] angle_orange = {angle_135,3'b000};
   wire [6:0] angle_yellow = {angle_180,3'b000};
   wire [6:0] angle_green  = {angle_225,3'b000};
   wire [6:0] angle_cyan   = {angle_292,3'b000}; // 292.5º

And my chroma amplitudes. 'hi' and 'lo' refer to the amplitude of the chroma signal. hi_sine and lo_sine are 8 entry tables of sine wave values with a DC offset. 'angle_<colour>' isn't a constant, it is an index into the sine table that increments and wraps at the end of the sine table.

Code: Select all

   // High intensity colours:                                                   
   wire [7:0] hi_blue   = hi_sine[angle_blue+:8];                               
   wire [7:0] hi_purple = hi_sine[angle_purple+:8];                             
   wire [7:0] hi_red    = hi_sine[angle_red+:8];                                
   wire [7:0] hi_orange = hi_sine[angle_orange+:8];                             
   wire [7:0] hi_yellow = hi_sine[angle_yellow+:8];                             
   wire [7:0] hi_green  = hi_sine[angle_green+:8];                              
   wire [7:0] hi_cyan   = hi_sine[angle_cyan+:8];                               
                                                                                
   // Low intensity colours:                                                    
   wire [7:0] lo_blue   = lo_sine[angle_blue+:8];                               
   wire [7:0] lo_purple = lo_sine[angle_purple+:8];                             
   wire [7:0] lo_red    = lo_sine[angle_red+:8];                                
   wire [7:0] lo_orange = lo_sine[angle_orange+:8];                             
   wire [7:0] lo_yellow = lo_sine[angle_yellow+:8];                             
   wire [7:0] lo_green  = lo_sine[angle_green+:8];                              
   wire [7:0] lo_cyan   = lo_sine[angle_cyan+:8];

And the final chroma palette looks like this:

Code: Select all

   // Black and White have no chroma component.                                 
   always @(*) begin                                                            
      case (colour)                                                             
         `BLACK:     chroma_value <= `DC;                                       
         `WHITE:     chroma_value <= `DC;                                       
         `RED:       chroma_value <= hi_red;                                    
         `CYAN:      chroma_value <= hi_cyan;                                   
         `PURPLE:    chroma_value <= hi_purple;                                 
         `GREEN:     chroma_value <= hi_green;                                  
         `BLUE:      chroma_value <= hi_blue;                                   
         `YELLOW:    chroma_value <= hi_yellow;                                 
         `ORANGE:    chroma_value <= hi_orange;                                 
         `LT_ORANGE: chroma_value <= lo_orange;                                 
         `LT_RED:    chroma_value <= lo_red;                                    
         `LT_CYAN:   chroma_value <= lo_cyan;                                   
         `LT_PURPLE: chroma_value <= lo_purple;                                 
         `LT_GREEN:  chroma_value <= lo_green;                                  
         `LT_BLUE:   chroma_value <= lo_blue;                                   
         `LT_YELLOW: chroma_value <= lo_yellow;                                 
      endcase                                                                   
   end

So these are all simplified and pushed around to be as easy to generate as possible - there is a huge variation in hue, saturation and brightness between the three 6560s I have, making it a difficult target to get "right". When I get home I'll do some captures and y'all can judge for yourselves how bad it looks (again, I'm not claiming I'm "right").

[JonBrawn]

I have three 6560 chips - lovingly named "Red", "Green" and "Blue" - not because of any particular colour cast they have or anything like that, but because each one has a dot of that color stuck to it so I can identify them, for example, "Green" has a faulty random noise generator.

In this picture, each panel of four screenshots is in the following order:

Red Green
Blue FPGA

As you can see, the colours I've generated are truly lovely but wrong. In general, they're all too saturated, and cyan and purple are just plain wrong. I'll try winding down the saturation a notch and I'll steal Mike & Tokra's values for cyan and purple. This might involve a complete re-vamp of how the chroma signal is generated.

[mathop]

Re cyan being off:
I seem to recall that older 6560 variations generate a different cyan that is more blue-looking. E.g. this is what my NTSC VIC20 looks like

My PAL VIC20 looks like this

apparently the cyan on later 6560 models should look more like the lower picture. (I'll try to locate a source for this.)

[JonBrawn]

Well, I thought I'd use the VICE Vic-20 colour palette for NTSC - except I don't understand the encoding in the structure.

Take the two colours, Cyan and Green.

First, there are some defines:
#define ANGLE_RED 112.5f
#define ANGLE_GRN -112.5f
#define ANGLE_BLU 0.0f
#define ANGLE_ORN -45.0f

Then the struct entries for cyan and green look like this:

{ LUMA3 , ANGLE_RED, -1, "Cyan" },
{ LUMA5 , ANGLE_GRN + 45.0f, 1, "Green" },

Expanding things a bit that's
cyan = 112.5º, but it has a '-1' in the table, so it's the negative phase of that, so we add 180º and get 292.5º
green = -112.5 + 45 = -67.5º, it has a '+1' in the table, so no phase change, so let's convert it into a positive angle, 360 - 67.5 = 292.5º

Clearly, cyan and green are not the same colour, so what am I doing wrong?

[groepaz]

As said before, contact that "Tobias" guy from Forum64 - he has the numbers in a nice table, and they arent in this weird form that VICE expects. I just randomly added or subtracted 180° or 360° or whatever until the VICE color generator produced the expected result - no idea why exactly it requires the numbers like this (and the guy who wrote that code is MIA)

[JonBrawn]

If anyone out there in Denial Land could PM me an invitation to Forum64 so I can create an account, I'd be grateful.

[tokra]

I don't think you need an invitation, just register here:

https://www.forum64.de/wcf/index.php?sc ... ster=1&l=2

Should be in english. Otherwise you can switch langages at the top left.

Most people on the Forum will be fine if you PM them in english, I guess. To be safe, you could add a deepl.com translation.

[JonBrawn]

I don't think you need an invitation, just register here:

You are correct - I saw the box for the invitation link and I ran away, as I didn't have an invitation link. Turns out you don't need that, just a bit of C64 knowledge.

[JonBrawn]

I bit the bullet and created a spreadsheet to convert RGB888 palettes into {Luma, Chroma Amplitude and Chroma Angle} tuples. It only took three evenings of staring at the maths and wishing trig worked the way I wanted it to.

[a4000bear]

As already mentioned the PAL 6561 does not support interlace. I have always wondered why Commodore removed it from the PAL 6561. I wonder what would the consequences of including it in an FPGA version would be. I think it would be fun to have it available, assuming it doesn't break anything.

PAL does not have 'setup' like NTSC has, so the blanking level and black level are both the same at 0.3V.

I have several PAL VIC-20s, and an oscilloscope, so if you need any measurements, let me know and I could make them for you.

[JonBrawn]

As already mentioned the PAL 6561 does not support interlace. I have always wondered why Commodore removed it from the PAL 6561. I wonder what would the consequences of including it in an FPGA version would be. I think it would be fun to have it available, assuming it doesn't break anything.

Tokra, Mike - if I added Interlace to the PAL FPGA, do you think you'd be able to put together a demo that shows it off?