Video output methods for various console models

[lidnariq]

What? That's definitely using all 7 bits: (6 downto 0)

The only place I see anything less than all 7 bits is there fourth byte where only 4 of the 7 bits contain the various sync pulses.

[mikejmoffitt]

What? That's definitely using all 7 bits: (6 downto 0)

The only place I see anything less than all 7 bits is there fourth byte where only 4 of the 7 bits contain the various sync pulses.

the signal is 7 bits per component, but no games I've tested seem to actually use it (Smash Bros and Pokemon Stadium). I'd believe that most games used 5 bits per component to represent a color in a single 16-bit halfword (quarterword, with a 64-bit register size?).

[qwertymodo]

480p Component is possible if I can find a synthesizable RGB -> YCbCr component (I'm not bothering with that on my own and simulation-only models are useless).

Yeah, I'll probably just do RGB->YPbPr in analog, rather than trying to figure out RGB->YCbCr in HDL. I linked to this schematic in my earlier post: http://elm-chan.org/works/yuv2rgb/rc/rgb2yuv.png

[Joe]

The only place I see anything less than all 7 bits is there fourth byte where only 4 of the 7 bits contain the various sync pulses.

Exactly.

Are those bits really unused? I don't have the equipment to find out for myself, which is why I'm asking.

[mikejmoffitt]

The only place I see anything less than all 7 bits is there fourth byte where only 4 of the 7 bits contain the various sync pulses.

Exactly.

Are those bits really unused? I don't have the equipment to find out for myself, which is why I'm asking.

I haven't tried to look at them to see if there's any extra information being conveyed. It's possible something is there, I haven't looked. Some time maybe I'll check it out.

[qwertymodo]

I'm looking a bit more into viletim's N64 RGB board, based on his older schematic here and I'm wondering if I can omit any of the following output signals in order to free up an I/O pin that I need as an input signal:

CSYNC
HSYNC
VSYNC
CLAMP

VSYNC, I could understand as potentially needing, but is there really any use for HSYNC? Also, CSYNC I could acquire from composite video using a sync stripper, though I suppose it would be better to use this one if possible. The CLAMP signal might actually be the best option, as I can't find any info on what that's used for at all...

In any case, if I can free up a pin to use as an input, then I could implement a Pb/Pr encoder on the CPLD itself and avoid a bunch of external components. It'd output on the same R2R pins as the G and B channels and be switched with that input pin, which would greatly simplify the job of encoding the various signals to hook up to a Wii-style multi-out connector.

[Joe]

VSYNC, I could understand as potentially needing, but is there really any use for HSYNC?

Those are for situations where vertical and horizontal sync need to be separate signals. If you only have one of VSYNC or HSYNC, it's pretty much useless. You can only sync to a video signal that has both.

Also, CSYNC I could acquire from composite video using a sync stripper, though I suppose it would be better to use this one if possible.

It's better to use it from this source.

Do you know which set of sync signals you need? CSYNC is essentially a combined HSYNC and VSYNC, so if your output requires combined sync signals, you won't need HSYNC or VSYNC. On the other hand, if your output uses separate HSYNC and VSYNC, you won't need CSYNC.

The CLAMP signal might actually be the best option, as I can't find any info on what that's used for at all...

From what I've been able to find, it allows you to use simpler circuits to combine sync with green/luma. I don't think you need it when sync is separated from the rest of the video signal.

[Sik]

Yeah, also the fact that it could be getting chained to something else and you'll want the most raw signals you can get in that case (this stuff is feasible if the hardware gets reused on e.g. arcades).

[Helder]

I'm looking a bit more into viletim's N64 RGB board, based on his older schematic here and I'm wondering if I can omit any of the following output signals in order to free up an I/O pin that I need as an input signal:

CSYNC
HSYNC
VSYNC
CLAMP

VSYNC, I could understand as potentially needing, but is there really any use for HSYNC? Also, CSYNC I could acquire from composite video using a sync stripper, though I suppose it would be better to use this one if possible. The CLAMP signal might actually be the best option, as I can't find any info on what that's used for at all...

In any case, if I can free up a pin to use as an input, then I could implement a Pb/Pr encoder on the CPLD itself and avoid a bunch of external components. It'd output on the same R2R pins as the G and B channels and be switched with that input pin, which would greatly simplify the job of encoding the various signals to hook up to a Wii-style multi-out connector.

Get one of these EL1883 and you don't need the 3 syncs, just input the Composite video and get all 3 outputs.

[lidnariq]

I've used LM1881s before; the EL1883 is clearly related. (It is, in fact, a "sync stripper" as mentioned in your quoted section)

They have their limitations; several devices I've used consider the output to be insufficiently clean to sync perfectly.

[lidnariq]

Here's a silly question about N64 RGB...

If I happen to be lucky enough to have an N64 that already emits RGB (by dint of having an VDC-NUS) and I want to emit 15kHz RGBHV ... can I "just" add a 74AC161 (or anything else comparably fast) and inverter/delay on the clock input to latch /HS and /VS ?

(I'm just looking at http://members.optusnet.com.au/eviltim/ ... 64rgb.html )

[qwertymodo]

You could probably do it by feeding (50MHz clock NAND DSYNC) into the clock input of a posedge-triggered (assuming active-high output on the NAND) latch with D0 and D1 as its data inputs. No inverter or delay necessary.