FPGA 6561 - PAL Questions
Moderator: Moderators
- JonBrawn
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
FPGA 6561 - PAL Questions
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?
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?
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
Re: FPGA 6561 - PAL Questions
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)
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)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Re: FPGA 6561 - PAL Questions
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. )
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
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
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.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
- JonBrawn
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
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
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º
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];
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
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
- JonBrawn
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
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.
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.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
Re: FPGA 6561 - PAL Questions
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.)
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
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
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?
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?
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
Re: FPGA 6561 - PAL Questions
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)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- JonBrawn
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
If anyone out there in Denial Land could PM me an invitation to Forum64 so I can create an account, I'd be grateful.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
Re: FPGA 6561 - PAL Questions
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.
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
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
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.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
- JonBrawn
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
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.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
Re: FPGA 6561 - PAL Questions
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.
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
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: FPGA 6561 - PAL Questions
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?a4000bear wrote: ↑Sat Apr 15, 2023 7:57 am 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.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary