Bit-banged RS170 video via $4011 for comparing chroma phase to colorburst phase
Moderator: Moderators
Bit-banged RS170 video via $4011 for comparing chroma phase to colorburst phase
(Edited the title because it doesn't actually show that it is what I said it was)
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. 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: 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.
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. 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: 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.
Re: Unequivocal proof that 2C02 colorburst is phase 8
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.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Unequivocal proof that 2C02 colorburst is phase 8
Accessibility is a value in argumentation.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: Unequivocal proof that 2C02 colorburst is phase 8
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?
Re: Unequivocal proof that 2C02 colorburst is phase 8
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."
Re: Unequivocal proof that 2C02 colorburst is phase 8
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)?
What would a corresponding program look like for PAL NES (106.5625x312) or PAL famiclones (113.667x312)?
Re: Unequivocal proof that 2C02 colorburst is phase 8
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.
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.
Re: Unequivocal proof that 2C02 colorburst is phase 8
That's what Craigslist and eBay are for...tepples wrote:Why not buy a studio monitor? Because manufacturers don't make CRT TVs anymore.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: Unequivocal proof that 2C02 colorburst is phase 8
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.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)?
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
Re: Unequivocal proof that 2C02 colorburst is phase 8
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:
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:
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).
Code: Select all
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 : : : : : :
And because of Johnson counter there is shift by 5 steps (6 positive phases and 6 negative phases). Resulting phase map is:
Code: Select all
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 : . . . . . . . . . . . .
Re: Unequivocal proof that 2C02 colorburst is phase 8
Bull.HardWareMan wrote:Not unequivocal for me. You violate raster timing and many AGC's in monitor/TV getting mad.
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.
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
Re: Unequivocal proof that 2C02 colorburst is phase 8
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: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.
Nobody talks about RF.lidnariq wrote:3- The AGC for RF modulated content is completely inapplicable to the experiment I designed here.
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: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.
Code: Select all
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?