It is currently Thu May 23, 2019 8:40 pm

 All times are UTC - 7 hours

 Page 1 of 1 [ 12 posts ]
 Print view Previous topic | Next topic
Author Message
 Post subject: Unequivocal proof that 2C02 colorburst is phase 8Posted: Thu Jun 23, 2016 5:57 pm

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
I don't know why we keep getting these stupid arguments, but I figured out a way to prove it, trivially reproduced by anyone else with a TV with an S-video jack.

I wrote a simple program that will bit-bang a replacement luma signal using the DMC DAC. We can then use the NES's normal video signal as chroma, and we can skew the two so that the colorburst is on screen.

A simple pattern (a giant letter I with top and bottom bars) will let us do a few other tests.
Attachment:

IMG_0986_EDIT.JPG [ 92.64 KiB | Viewed 5479 times ]

Additionally, for anyone who wants to see what will happen if the color chosen is not phase 8, pressing certain key combinations on controller one when you release reset will choose other colors instead of \$08 for the background.

If you power on holding:
Sel+Up=\$01 Sel+Dn=\$02 Sel+Lt=\$03 Sel+Rt=\$04
St+Up=\$05 St+Dn=\$06 St+Lt=\$07 St+Rt=\$08
Up=\$09 Dn=\$0A Lt=\$0B Rt=\$0C
Start=\$18 Select=\$28 St+Sel=\$38
the backdrop will be the specified color. Then release all buttons to begin.

After bit-banging RS170 has started, you can use up/down/left/right to move the relative phase of the fake S-video luma relative to the 2C02-as-chroma. A and B will change the color for the backdrop.

Source:
Attachment:
File comment: (WTFPL/CC0; requires ca65)
colorburst-phase-demonstration.zip [6.5 KiB]

Many thanks to Nintendulator's pixel counters, which made this about 10 times faster and less painful than it would have been otherwise.

This should be easily adapted to the Dendy to test there, and painfully adapted for the 2A07.

Top

 Posted: Thu Jun 23, 2016 6:38 pm

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1464
There's a much easier way to prove it, at least for the RP2C02G - simulate the Visual 2C02 and examine the phase it uses when outputting colorburst.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Top

 Posted: Thu Jun 23, 2016 6:59 pm

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 965
Accessibility is a value in argumentation.

Top

 Posted: Fri Jun 24, 2016 5:04 pm

Joined: Sun May 27, 2012 8:43 pm
Posts: 1348
Wait, why can't we just use a studio monitor (like the popular Sony PVM series) and put it into HV delay, allowing the colorburst to be visible? When I have done this, the olive-colored \$08 is clearly visible on the left side. Is that not proof enough?

Top

 Posted: Fri Jun 24, 2016 5:55 pm

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
The point is that you don't need any special equipment, so that when someone comes along and says "are you sure it's not phase 7 or 9"? we can say "well, run this program and prove it to yourself."

Top

 Posted: Fri Jun 24, 2016 6:02 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21397
Location: NE Indiana, USA (NTSC)
Why not use a studio monitor? Because I don't have one. Why not buy a studio monitor? Because manufacturers don't make CRT TVs anymore.

What would a corresponding program look like for PAL NES (106.5625x312) or PAL famiclones (113.667x312)?

_________________
Pin Eight | Twitter | GitHub | Patreon

Top

 Posted: Fri Jun 24, 2016 6:33 pm

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
This 2A03+2C02 version requires a two field-long kernel to produce the hsync and vsync pulses at the right relative timing.

A version for the 6527P+6538 could use a one field-long kernel (since 341×312÷3=35464 exactly), which could be easily done by extending the active time from 3×80 scanlines to ... uh, 97×3. Probably need to subtly massage exact scanline timing to make things work.

A version for the 2A07+2C07 would require redoing almost all of it because of 9/16th remainder on cycles per scanline. (It also requires a two field-long kernel because (341×312×2÷(16÷5)=66495 exactly).

If I've understood what other people have been saying, I think that we might be able to get away with still using a solid phase #6 on PAL? Otherwise I guess we would have to add alternating scanlines of colors.

Top

 Posted: Mon Jun 27, 2016 11:17 am

Joined: Fri Sep 14, 2012 12:17 pm
Posts: 76
tepples wrote:
Why not buy a studio monitor? Because manufacturers don't make CRT TVs anymore.

That's what Craigslist and eBay are for...

Top

 Posted: Mon Jun 27, 2016 2:28 pm

Joined: Sun May 27, 2012 8:43 pm
Posts: 1348
tepples wrote:
Why not use a studio monitor? Because I don't have one. Why not buy a studio monitor? Because manufacturers don't make CRT TVs anymore.

What would a corresponding program look like for PAL NES (106.5625x312) or PAL famiclones (113.667x312)?

I was not implying everybody present had to reproduce the experiment. Surely some multitude of members possess this equipment. I didn't say CRT TV, either - a new (absurdly-priced for this purpose) studio monitor (be it LCD, LED-backlit LCD, OLED, Plasma, what have you) will still accept NTSC signals and have the aforementioned features. if not, it's not a general purpose broadcast monitor.

Top

 Posted: Sun Jul 03, 2016 12:03 am

Joined: Mon Jan 01, 2007 11:12 am
Posts: 206
Not unequivocal for me. You violate raster timing and many AGC's in monitor/TV getting mad. For example, black level restorer, that use front porch for it (where color burst placed). Now. Working on BreakNES project, we discovered this level assignment:
Code:
LEVEL : SYNC : BURST : LUMA0 : LUMA1 : LUMA2 : LUMA3 :
VCC  :      :       :       :       :       :       :
L10  :      :       :       :       :       :       :
L09  :      :       :       :       :   H   :   H   :
L08  :      :       :       :       :   .   :   L   :
L07  :      :       :       :   H   :   .   :       :
L06  :      :       :   H   :   .   :   .   :       :
L05  :      :       :   .   :   .   :   L   :       :
L04  :      :   H   :   .   :   .   :       :       :
L03  :   H  :   .   :   .   :   L   :       :       : < BLACK LEVEL
L02  :   .  :   .   :   L   :       :       :       :
L01  :   .  :   L   :       :       :       :       :
GND  :   L  :       :       :       :       :       :

Phase backward order was approved later (there is inversion in phase matrix select). Here it is:

And because of Johnson counter there is shift by 5 steps (6 positive phases and 6 negative phases). Resulting phase map is:
Code:
Color ID  : Used phase(s)
H 3 2 1 0 :  P1  P2  P3  P4  P5  P6  P7  P8  P9  P10 P11 P12
0 0 0 0 0 :   .   .   .   .   .   .   .   .   .   .   .   .
1 0 0 0 1 :   .   .   .   .   .   X   .   .   .   .   .   .
2 0 0 1 0 :   .   .   .   .   .   .   .   .   .   .   X   .
3 0 0 1 1 :   .   .   .   X   .   .   .   .   .   .   .   .
4 0 1 0 0 :   .   .   .   .   .   .   .   .   X   .   .   .
5 0 1 0 1 :   .   X   .   .   .   .   .   .   .   .   .   .
6 0 1 1 0 :   .   .   .   .   .   .   X   .   .   .   .   .
7 0 1 1 1 :   .   .   .   .   .   .   .   .   .   .   .   X
8 1 0 0 0 :   .   .   .   .   X   .   .   .   .   .   .   .
9 1 0 0 1 :   .   .   .   .   .   .   .   .   .   X   .   .
A 1 0 1 0 :   .   .   X   .   .   .   .   .   .   .   .   .
B 1 0 1 1 :   .   .   .   .   .   .   .   X   .   .   .   .
C 1 1 0 0 :   X   .   .   .   .   .   .   .   .   .   .   .
D 1 1 0 1 :   .   .   .   .   .   .   .   .   .   .   .   .
E 1 1 1 0 :   .   .   .   .   .   .   .   .   .   .   .   .
F 1 1 1 1 :   .   .   .   .   .   .   .   .   .   .   .   .

BURST signal set up only 3rd (from 0) bit of color index, that give 1xxx. This is give us two possible values: 0x8 or 0xF. But in the matrix there no 0xF phase decode, so it can be only 0x8. Also, there might be default value 0x0 in color index prefetch block. And there is 0x0 decode in matrix that switch off subcarrier frequency. Later I'll show you correct model in CPLD (I was wrong in some moments).

Top

 Posted: Sun Jul 03, 2016 12:24 am

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
HardWareMan wrote:
Not unequivocal for me. You violate raster timing and many AGC's in monitor/TV getting mad.
Bull.

1- There is absolutely no reason to believe that variation in precise hsync timing would cause a uniform chroma error across the entire screen. Scanline-to-scanline, sure, but that is not happening. Furthermore even if there were vertical chroma subsampling happening, it would still indicate that the average phase were phase 8.

2- An AGC, if even active on an S-Video input, will not care about the chroma and luma components relative to each other. That's the entire point of S-Video.

3- The AGC for RF modulated content is completely inapplicable to the experiment I designed here.

4- The 2C02 already violates RS170 and NTSC raster timing. The scanlines are too short for NTSC or too long for RS170, scanlines are not a constant length (the missing pixel), the signal is not interlaced, the field rate is too fast.

5- If you really think that all of these effects actually could possibly change the exact hue angle you see... you could plug two NTSC famiclones in at the same time, one to chroma and one to luma, and use the difference in timing between the two consoles to move the colorburst on-screen.

Top

 Posted: Sun Jul 03, 2016 2:40 am

Joined: Mon Jan 01, 2007 11:12 am
Posts: 206
lidnariq wrote:
2- An AGC, if even active on an S-Video input, will not care about the chroma and luma components relative to each other. That's the entire point of S-Video.

There is AGC in RGB matrix and amplifier right before CRT. This is where luma from your S-Video meets with chroma from decoder. Also there happens some user regulations: contrast, brigtness and saturations. That part of signal path use horizontal front porch for black level fixation for contrast and brightness adjustment possible. This AGC affect on any of video source availble in you monitor or TV. Without it you will see psychodelic picture.
lidnariq wrote:
3- The AGC for RF modulated content is completely inapplicable to the experiment I designed here.

lidnariq wrote:
4- The 2C02 already violates RS170 and NTSC raster timing. The scanlines are too short for NTSC or too long for RS170, scanlines are not a constant length (the missing pixel), the signal is not interlaced, the field rate is too fast.

I believe in only what I discovered by myself within BreakNES project. Also, all of this comply with Visual6502. I've got right palette with phase 8 in CPLD generator. Here is verilog:
Code:
module PAL_NTSC_Gen(
input       NTSC_Clk,     // 21.4772 MHz
input       PAL_Clk,      // 53.2034 MHz
output      [7:0]DAC,
output      [3:0]COUT,
output      [12:1]PHOUT
);
// For test purpose
assign COUT[3:0] = HCOUNT[7:4];
assign PHOUT[12:1] = PH[12:1];

// Registers
reg [2:0]PH_PSC;        // Phase prescaler
reg [12:1]PH;           // Color subcarrier phases
reg [3:0]PIX_PSC;       // Pixelclock prescaler
reg PIX_CLK;            // Pixelclock strobe
reg [9:0]HCOUNT;        // Horizontal counter
reg [9:0]VCOUNT;        // Vertical counter
reg HSYNC;              // Horizontal sync
reg BURST;              // Color burst
reg HSCREEN;            // Active video in scanline
reg VSYNC;              // Vertical sync
reg VSCREEN;            // Active video in frame

// Used levels
wire [7:0]L0;
wire [7:0]L1;
wire [7:0]L2;
wire [7:0]L3;
wire [7:0]L4;
wire [7:0]L5;
wire [7:0]L6;
wire [7:0]L7;
wire [7:0]L8;
wire [7:0]L9;
// NTSC
assign L0 = 8'h00;
assign L1 = 8'h10;
assign L2 = 8'h18;
assign L3 = 8'h20;
assign L4 = 8'h32;
assign L5 = 8'h36;
assign L6 = 8'h3C;
assign L7 = 8'h4E;
assign L8 = 8'h55;
assign L9 = 8'h6E;

// Luma
wire [7:0]LUMAL;
wire [7:0]LUMAH;
assign LUMAL[7:0] = (~VCOUNT[6]) ?
(~VCOUNT[5]) ? L2[7:0] : L3[7:0]
:
(~VCOUNT[5]) ? L5[7:0] : L8[7:0];
assign LUMAH[7:0] = (~VCOUNT[6]) ?
(~VCOUNT[5]) ? L6[7:0] : L7[7:0]
: L9[7:0];

// Chroma
wire [7:0]CHROMA;
assign CHROMA[7:0] =    (~HCOUNT[7]) ?
(~HCOUNT[6]) ?
(~HCOUNT[5]) ?
(~HCOUNT[4]) ?
LUMAH[7:0]
:
(PH[1]) ? LUMAH[7:0] : LUMAL[7:0]
:
(~HCOUNT[4]) ?
(PH[2]) ? LUMAH[7:0] : LUMAL[7:0]
:
(PH[3]) ? LUMAH[7:0] : LUMAL[7:0]
:
(~HCOUNT[5]) ?
(~HCOUNT[4]) ?
(PH[4]) ? LUMAH[7:0] : LUMAL[7:0]
:
(PH[5]) ? LUMAH[7:0] : LUMAL[7:0]
:
(~HCOUNT[4]) ?
(PH[6]) ? LUMAH[7:0] : LUMAL[7:0]
:
(PH[7]) ? LUMAH[7:0] : LUMAL[7:0]
:
(~HCOUNT[6]) ?
(~HCOUNT[5]) ?
(~HCOUNT[4]) ?
(PH[8]) ? LUMAH[7:0] : LUMAL[7:0]
:
(PH[9]) ? LUMAH[7:0] : LUMAL[7:0]
:
(~HCOUNT[4]) ?
(PH[10]) ? LUMAH[7:0] : LUMAL[7:0]
:
(PH[11]) ? LUMAH[7:0] : LUMAL[7:0]
:
(~HCOUNT[5]) ?
(~HCOUNT[4]) ?
(PH[12]) ? LUMAH[7:0] : LUMAL[7:0]
:
LUMAL[7:0]
:
(~HCOUNT[4]) ?
L3[7:0]
:
L3[7:0];
// Video output
assign DAC[7:0] = (VSYNC | HSYNC) ?
// This is correct composite sync
(VSYNC & HSYNC) ? L3[7:0] : L0[7:0]
:  (BURST) ?
// This is color burst
(PH[8]) ? L4[7:0] : L1[7:0]
:    (VSCREEN & HSCREEN) ?
// this is picture
CHROMA[7:0]
// Otherwise it is blank
: L3[7:0];

// Because I don't have 42,9544 MHz generator and CPLD don't allow sync always block on both edge we update only even phases at negedge.
always @(negedge NTSC_Clk) begin
{PH[11],PH[9],PH[7],PH[5],PH[3],PH[1]} <= {PH[12],PH[11],PH[9],PH[7],PH[5],PH[3]};
end
// Video generator
always @(posedge NTSC_Clk) begin
// Color subcarrier phase prescaler
if (PH_PSC[1] & !PH_PSC[0])
begin
PH_PSC[2:0] <= 3'h0; PH[12] <= !PH[12];
end else PH_PSC[2:0] <= PH_PSC[2:0] + 3'h1;
{PH[10],PH[8],PH[6],PH[4],PH[2]} <= {PH[12],PH[10],PH[8],PH[6],PH[4]};

// Pixelclock prescaler
PIX_PSC[3:0] <= PIX_PSC[3:0] + 4'h1;
PIX_CLK <= !PIX_PSC[1] & !PIX_PSC[0];

// HV COUNTERS: 341 pixels and 262 scanlines
if (PIX_CLK)
begin
if (HCOUNT[9:0] == 9'd340)
begin
HCOUNT[9:0] <= 9'd000;
if (VCOUNT[9:0] == 9'd261) VCOUNT[9:0] <= 9'd000; else VCOUNT[9:0] <= VCOUNT[9:0] + 9'd001;
end else HCOUNT[9:0] <= HCOUNT[9:0] + 9'd001;
end

// Active video in scanline
if (HCOUNT[9:0] == 9'd000) HSCREEN <= 1'b1;
if (HCOUNT[9:0] == 9'd255) HSCREEN <= 1'b0;
// Horizontal sync
if (HCOUNT[9:0] == 9'd280) HSYNC <= 1'b1;
if (HCOUNT[9:0] == 9'd305) HSYNC <= 1'b0;
// Color burst
if (HCOUNT[9:0] == 9'd309) BURST <= 1'b1;
if (HCOUNT[9:0] == 9'd325) BURST <= 1'b0;
// Vertical sync
if (VCOUNT[9:0] == 9'd244) VSYNC <= 1'b1;
if (VCOUNT[9:0] == 9'd248) VSYNC <= 1'b0;
// Active video in frame
if (VCOUNT[9:0] == 9'd000) VSCREEN <= 1'b1;
if (VCOUNT[9:0] == 9'd240) VSCREEN <= 1'b0;
end
// end
endmodule

Anyway. Do you have oscilloscope record of your PD-ROM output? Or can you provide compiled binary version for NTSC NES? I can test it on this setup:

It produce this palette:

Is it enough authentic for you?

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 1 [ 12 posts ]

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 12 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki