JAMMA RGB and Sync Through Oscilloscope?

This probably isn't the best place to ask this question, but does anyone know what JAMMA RGB and sync output would look like through an oscilloscope? It's something I've wondered quite a bit but haven't been able to find anywhere. I have no idea what it would look like, so sorry if these next questions are particularly stupid. Are color channel values directly tied to voltage? If so, what would be the maximum and minimum voltages outputted? Sync will obviously be different; any guess I can give as to how it will look will probably be wrong.

JAMMA is 5Vpp RGB analog video (instead of VGA's 0.7Vpp or some other older computers using 1Vpp) and 5V digital composite sync.

So via a scope (forgive my ascii art):


This is basically identical to any other RGBS video standard. I might be wrong about the composite sync polarity, too.

Any reason the time durrations when R, G, and B are 0V are not the same? I'm not sure I actually know what's going on on the graph.

My graph was a little too simplistic.

0V is both black and blanking, so the ascii art I drew would show two scanlines that were purple on the left, white in the middle, and yellow on the right.

For clarification, the sync signal signifies the start of the frame outputted from the device so the monitor can match this with when it starts drawing the picture? (Otherwise you'd see the bottom of the previous frame above the top of the current frame onscreen?) The sync signal interval should then be a fixed value across all NTSC devices?

Sounds like it would be trivial to make an analog RGB to HDMI converter; for the color chanels you just need ADCs that output 8 bit serial values and I guess resistors to lower the voltage to what the ADCs want. Problem is, if you want something like 1080p, 60fps, the thing has to run at what, (2 million pixels x 60fps = ) about 120MHz?...

Actually wait, I'm an idiot, there's no way that could be anywhere near everything because that's not accounting for any sort of dimensional difference between the pictures among about a million other things... You'll definitely need computer hardware at this point for line doubling among other things, but I wonder if you could primarily change horizontal scale by somehow adjusting ADC frequently rather than sampling at a constant rate and having the computer hardware scale it digitally later. Should look better and require less powerful hardware.

Scaling and probably need for frame rate conversion make this quite difficult. HDMI mandates exact 60Hz and there are plenty TVs and monitors that will barf periodically when that isn't the case.

This will provide most info one needs to know about the video outputs (NTSC related stuff is just minorly different but the ideas are exactly same) : http://martin.hinner.info/vga/pal.html

Both top and left. It's composite sync, combined H and V. Just like in RS170/NTSC, a falling edge (probably) signifies the start of hsync, while a lowpassed copy being low on average signifies the start of vsync.

Not just that, but without a sync lock the picture would "roll"

Should, but isn't. Official RS170, horizontal sync rate is exactly 63³¹/₆₃ µs. Official NTSC is exactly 63⁵/₉µs. A whole bunch of random video game consoles instead it's 63⁷³/₁₀₅µs.

In turns out that any LCD computer monitor with a VGA input already has to do exactly that.

In practice, what TµEE says: modern TVs throw a hissy fit if their input signal isn't perfect. But the same display in a computer monitor is more tolerant.

Oh yeah, I forget that computer monitor analog to digital conversion isn't shit unlike the majority of modern TVs where it's sampled at probably nowhere near that and just upscaled.

To translate this into numbers you might recognize from elsewhere:

RS170 (525 line monochrome pre-NTSC) hsync period: 63+31/63 microseconds
1000000/(63+31/63) = 15750 Hz
(63+31/63)*13.5 = 857+1/7 Rec. 601 pixels
(63+31/63)*315/88 = 227+2/9 chroma periods

NTSC hsync period: 63+5/9 microseconds
1000000/(63+5/9) = 15734+38/143 Hz
(63+5/9)*13.5 = 858 Rec. 601 pixels
(63+5/9)*315/88 = 227+1/2 chroma periods

Apple II, Atari 2600, etc. hsync period: 63+73/105 microseconds
Also ColecoVision, Master System, and Sega Genesis
1000000/(63+73/105) = 15699+159/209 Hz
(63+73/105)*13.5 = 859+31/35 Rec. 601 pixels
(63+73/105)*315/88 = 228 chroma periods

NES and Super NES hsync period: 63+481/945 microseconds
Also Vs. System, PlayChoice, and Nintendo Super System
N.B.: In every second field on NES and Super NES, lines in vblank are shortened totaling 2/3 of a chroma period or 186+46/189 ns
1000000/(63+481/945) = 15745+3005/3751 Hz
(63+481/945)*13.5 = 857+13/35 Rec. 601 pixels
(63+481/945)*315/88 = 227+1/3 chroma periods

Neo Geo MVS hsync period: 64 microseconds
N.B.: AES does not use this rate
1000000/64 = 15625 Hz
64*13.5 = 864 Rec. 601 pixels
64*315/88 = 229+1/11 chroma periods

Nitpick : NTSC MD/Genesis and SMS rate is exactly 53693175 / 3420 and for PAL it is 53203424 / 3420. The clock values are exact and without additional decimal points. In case of MD there are 2 other video modes where the rates differ from those plus several more in interlaced flavors.

"53693175/3420" reduces to 3579545/228 Hz, which is to be expected if chroma frequency is treated as 3579545 Hz instead of 315/88 MHz. But I suspect that "53693175 Hz" was intended to mean 15 times NTSC's 315/88 MHz chroma frequency, which was originally chosen to make the hsync frequency a divisor of the 4.5 MHz audio carrier. Either way is within the 10 Hz tolerance specified by the FCC for the chroma frequency (source: "27 MHz Crystal in the Jakks Pacific Game" by Eric Smith). So I made this calculation based on 88/315 microsecond NTSC chroma period times 228.

Intention is to be 15 * NTSC, but reality is those exact numbers.