JAMMA RGB and Sync Through Oscilloscope?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Post Reply
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

JAMMA RGB and Sync Through Oscilloscope?

Post by Drew Sebastino » Thu Dec 06, 2018 11:20 pm

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.

lidnariq
Posts: 9301
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by lidnariq » Thu Dec 06, 2018 11:33 pm

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):

Code: Select all

red ___.-~-~-~-.___.-~-~-~-.___
grn _____.--~--._____.--~--.___
blu ___.--~--._____.--~--._____
snc _~~~~~~~~~~~~_~~~~~~~~~~~_~
This is basically identical to any other RGBS video standard. I might be wrong about the composite sync polarity, too.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by Drew Sebastino » Thu Dec 06, 2018 11:57 pm

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.

lidnariq
Posts: 9301
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by lidnariq » Fri Dec 07, 2018 12:13 am

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.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by Drew Sebastino » Fri Dec 07, 2018 1:00 am

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.
Last edited by Drew Sebastino on Fri Dec 07, 2018 2:07 am, edited 2 times in total.

User avatar
TmEE
Posts: 745
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by TmEE » Fri Dec 07, 2018 1:49 am

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

lidnariq
Posts: 9301
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by lidnariq » Fri Dec 07, 2018 2:16 am

Drew Sebastino wrote: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?
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.
(Otherwise you'd see the bottom of the previous frame above the top of the current frame onscreen?)
Not just that, but without a sync lock the picture would "roll"
The sync signal interval should then be a fixed value across all NTSC devices?
Should, but isn't. Official RS170, horizontal sync rate is exactly 6331/63 µs. Official NTSC is exactly 635/9µs. A whole bunch of random video game consoles instead it's 6373/105µs.
Problem is, if you want something like 1080p, 60fps, the thing has to run at what, (2 million pixels x 60fps = ) about 120MHz?...
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.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by Drew Sebastino » Fri Dec 07, 2018 2:35 am

lidnariq wrote:
Problem is, if you want something like 1080p, 60fps, the thing has to run at what, (2 million pixels x 60fps = ) about 120MHz?...
In turns out that any LCD computer monitor with a VGA input already has to do exactly that.
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.

tepples
Posts: 21946
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by tepples » Fri Dec 07, 2018 7:41 am

lidnariq wrote:
The sync signal interval should then be a fixed value across all NTSC devices?
Should, but isn't. Official RS170, horizontal sync rate is exactly 6331/63 µs. Official NTSC is exactly 635/9µs. A whole bunch of random video game consoles instead it's 6373/105µs.
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

User avatar
TmEE
Posts: 745
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by TmEE » Fri Dec 07, 2018 8:10 am

tepples wrote: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
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.

tepples
Posts: 21946
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by tepples » Fri Dec 07, 2018 10:10 am

TmEE wrote:
tepples wrote: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
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.
"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.

User avatar
TmEE
Posts: 745
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: JAMMA RGB and Sync Through Oscilloscope?

Post by TmEE » Fri Dec 07, 2018 10:48 am

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

Post Reply