Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: NTSC TV progressive modelines roll, interlaced modelines random v position  (Read 1727 times)

0 Members and 1 Guest are viewing this topic.

rogerxyz

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:September 13, 2021, 03:42:08 pm
  • I want to build my own arcade controls!
Hello there! Apologies for the newbishness. My first time with crt_emudriver and I'm very excited. I know this is so close to working perfectly but I could use some pointers. There's not much info on these forums about V hold or vertical rolling. On 240p modes, my image rolls upwards continuously; on interlaced modes, the vertical position of line 0 is random every time the mode is entered.

First, what I'm working with:
ATI R9 200
CRT_emudriver 2.0 beta 15
DVI-I -> HD15 breakout box -> RGBS -> component transcoder -> YPbPr -> JVC D-Series
CSYNC enabled, taken from HSYNC pin 13
NTSC range, tried a few variations with no luck
Transcoder is a build of dekkit's https://github.com/dekkit/RGB-to-Component-Transcoder
I have tried this with the LM1881 sync separator as designed, as well as (currently) removed, jumpering C_IN of U3 to C_OUT of U3 (see https://github.com/dekkit/RGB-to-Component-Transcoder/blob/master/VA03a/Schematic_Dek's%20RGB%20to%20Component%20Transcoder_2021-03-08.png schematic). U3 is removed from the PCB as well, just saying where the bypass is. In the physical board I've jumpered where pin 2 of the LM1881 would be to the leg of R12.
Identical results with and without the sync separator.
To eliminate other issues, I can confirm that the same transcoder worked as designed with my RGB-modded Famicom and PC Engines (both use sync on composite).

I've tried all combinations of sync polarities, only -/- (default) appears correct.

For the rolling modelines, I can adjust the speed and direction of the roll in discrete steps with the v pulse, however a stable middle would be between two steps; it's always going to roll in one direction or another.

For the vertical offset modelines, I can adjust the V Center in arcade OSD but to no avail, since the position of line 0 is not stable, it will shift the next time the CRT displays the modeline.

I have tried some other CRT ranges like custom and 15khz default, which are generally worse with more extreme rolling. My thinking is that NTSC is the most conservative and constrained range and thus the baseline I want to get working first.

As far as eliminating the TV as a potential cause, I am getting the same effect when plugging into my Sony Trinitron TV; also I can run other component sources on the JVC with no issue (Genesis with HD Retrovision cable for example).

I hope that someone with better knowledge of NTSC and CRT_emudriver can hear "V hold" or "V rolling" and aha! point to a specific thing I should be investigating... It's quite likely the issue is with csync and my transcoder. I can take some readings of DC levels, I'm not sure what range I should be shooting for in this application though.

Thanks everyone! And amazing work on crt_emudriver and groovymame, I'm beyond excited to get this working!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7178
  • Last login:October 10, 2021, 07:55:06 am
  • Quote me with care
If you're enabling c-sync on VMMaker, make sure to recreate the modes after c-sync is set.

Check this:

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

rogerxyz

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:September 13, 2021, 03:42:08 pm
  • I want to build my own arcade controls!
Thank you Calamity and amazing work on crt_emudriver!

Ah, I wish the issue was that simple. I have recreated the modes any number of times, rebooted, changed the monitor ranges, etc. Always regenerating and installing the modelines immediately afterward. One thing I haven't really tried is disabling and reenabling csync or reinstalling the driver. However this is on a clean install of Windows 10 where I had never installed ATI drivers.

You can see the two issues: rolling on 240p, random vertical placement on interlaced modes, here https://imgur.com/a/mEaDOxq

Zebidee

  • Trade Count: (+6)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1970
  • Last login:Today at 07:47:48 am
Hi Roger. That dekkit build is actually an earlier version of the GreenAntz transcoder. The dekkit version is based on a circuit I breadboarded several years ago, and my design was derived from some designs that floated around the Sega forums long before that. GreenAntz evolved when dekkit and I started collaborating directly.

Back to you, the issue is with the vertical sync. There are two main culprits. One is that CRT-EMU produces XNOR composite sync with glitches around the vertical sync pulse, and this can confuse some TVs. Another is that this old design's sync integration into Y/luma (R12) doesn't have any sync tip clamping so the ground or reference black level can float, and not at the recommended ~0.286vpp level. Again, this can confuse some TVs.

If you have access to an oscilloscope, plug in some colour bars test signals and hook it up to the Y signal output to confirm.

We've addressed these issues with the later GreenAntz designs which include a XNOR sync logic combining circuit that has a filter, so less glitches than raw CRT-EMU composite sync (it either makes it's own composite sync from H+V inputs, or takes composite sync input and tweaks/filters that). We also addressed the sync tip clamping I mentioned before, and tidied up the mixing into luma so that there is less degradation of luma signal amplitude.

As for the LM1881, we only use that for SCART versions now.
Check out my completed projects!


rogerxyz

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:September 13, 2021, 03:42:08 pm
  • I want to build my own arcade controls!
Wow! Thank you for the awesome response. Yep, this sounds beyond a doubt to be the culprit.

I would do some more digging but I'm limited to a software scope whose time resolution isn't going to cut it for analyzing video :D I can definitely check p-p voltages and stuff. But... I'm pretty sure you are right so there's not much value confirming it.

Out of curiosity: wouldn't feeding combined sync directly from the graphics adapter into say an RGB-modded consumer CRT TV have the same issues? I would think some folks out there use it that way, but maybe it's really best to use an arcade monitor or professional monitor OR a dedicated sync combiner...

I'll certainly post an update if I make any progress, but I'd call this an "accepted answer" or something :D Thank you again!

buttersoft

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1214
  • Last login:Yesterday at 05:55:35 pm
  • Is running at 15kHz
Phew, i was hoping Zeb would chime in. No need for my backyard suggestions now :)

Zebidee

  • Trade Count: (+6)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1970
  • Last login:Today at 07:47:48 am
Wow! Thank you for the awesome response. Yep, this sounds beyond a doubt to be the culprit.

I would do some more digging but I'm limited to a software scope whose time resolution isn't going to cut it for analyzing video :D I can definitely check p-p voltages and stuff. But... I'm pretty sure you are right so there's not much value confirming it.

Out of curiosity: wouldn't feeding combined sync directly from the graphics adapter into say an RGB-modded consumer CRT TV have the same issues? I would think some folks out there use it that way, but maybe it's really best to use an arcade monitor or professional monitor OR a dedicated sync combiner...

I'll certainly post an update if I make any progress, but I'd call this an "accepted answer" or something :D Thank you again!

Couple of things I missed mentioning - the dekkit design is really for consoles, and is why it has worked for you so far with them. Dekkit always built mainly for consoles and me for PC/arcade. However, PC video cards output sync voltage at much higher levels (TTL, up to 5vpp) than consoles. As you've alluded, this is part of your problem. If building the dekkit-type transcoder for PC use, with the lm1881 back in, then a 680R to 1k resistor in series on your sync before your 75R terminator and 0.1uf cap to the lm1881 input should do the trick. I didn't immediately notice it missing from the schematic. The LM1881 is only rated for signal inputs up to 2vpp iirc, so you should bring down PC sync input levels.

I may have seemed like I was deprecating the LM1881 before, but it is actually useful here as it provides some sync "cleaning" and reforming (it won't make csync for you), input clamping, and signal amplifcation to consistent levels (Vcc less ~0.4v) regardless of input. So I suggest you use it. If putting the lm1881 back in, note that you don't need C9 (0.1uf) or R11 (680k) at all. They don't actually do anything useful for this build. Keep C16.

If you don't put the lm1881 back in, it is trickier. You might see OK results with a smaller value of around 100-500 ohms instead. I would maybe get rid of the 75R termination resistor too. Needs may vary with your input source. Thinking as I type, try 500R or 1k pot in series on your sync input, and see if you can get a value that works for you. You can change it for a fixed value later.

These results should be OK for most TVs, and will probably still look great to you, but aren't quite to standard. While the TV might still sync in, you'll still be losing some colour and contrast because luma signal will be degraded from interaction with the sync input. If you adjust sync to ideal levels, the luma loses definition and amplitude. So you dial it back. It is really a balancing of bads, which isn't good.

To get better results you need to go to the next level from there, which means making a basic signal clamp where sync and luma combine to: lock in the black levels to ground, set your output signal impedance properly, help siphon away AC sine interference from your TV (because at this point your circuit will be connected to the TV!) and prevent your luma from losing amplitude ("backwash") as the signal is pushed back and forth over R12.

Let me know how far you want to go down the rabbit hole.

Software-based oscilloscope should work OK I imagine - give it a go if you have one! I've been using a cheap but reliable PC/USB Owon scope myself.
Check out my completed projects!


rogerxyz

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:September 13, 2021, 03:42:08 pm
  • I want to build my own arcade controls!
Zebidee! Sorry I just saw this incredible follow up. Iím absolutely going to try your suggestions out this weekend. I am not surprised to hear the voltage ranges are out of bounds, but didnít know what I was doing enough to debug it. And it makes sense to keep the LM1881 in (I have some extras), looking at the data sheet it didnít seem like it would have done any harm, removed it mostly in the process of eliminating variables 😅

Sounds like extremely minor tweaks, Iíll follow up with my results! Canít wait for the weekend now heh. This is really above and beyond, btw, truly thanks!
« Last Edit: August 06, 2021, 02:11:29 am by rogerxyz »

rogerxyz

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:September 13, 2021, 03:42:08 pm
  • I want to build my own arcade controls!
Guess what, you were absolutely right! Replacing the LM1881 and using a 1K resistor on the sync line before anything else got me to a place where I could use most of the standard modes from the generic_15 range, with the exception of some of the lowest refresh rates (<52hz). That is so exciting!

As you cautioned there is significant crosstalk(?) between luma and sync, so things start to get wonky when the screen is very dark in some modes, and there's some minor noise visible in the darkest parts of the image otherwise. But all totally ignorable, this gets me from zero to one, and is more than sufficient for me for the time being!

Holy hell this is awesome. Things are finally starting to look like they should. I was previously limited to 480i over S-video integrated into an older graphics card. Vive la difference.

dekkit

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 4
  • Last login:September 17, 2021, 12:49:07 pm
  • I want to build my own arcade controls!
Late to the party on this one (havent been on this forum for a a while!), but very glad to see you got the results you wanted!

Looking good!

Note: as zeb noted above, the open design/ schematic is kinda like the 'base' model which combines and formalises a bunch of research, plus many of the ideas floating around the web,  initial pcb design and prototyping,  testing, etc.

The greenantz versions (with vga/ scart sockets) are much more refined with added sync and power regulation.  For most folks,  its just plug and play.


rogerxyz

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:September 13, 2021, 03:42:08 pm
  • I want to build my own arcade controls!
Hey Dek!

Just wanted to say, I really appreciate you sharing your designs! Your build was really straightforward compared to the alternative of trying to work from the original Ace schematics floating around old forums :)

As I noted, I made several already and I'm really enjoying them! (I'm the guy who was asking about the colourspace of the Genesis on your issue tracker.) I've put in an order with Zebidee for a GreenAntz and look forward to trying that out too. Awesome that you two teamed up and refined the design even further :D

It's pretty amazing that with the holy trinity of crt_emudriver, groovymame, and a good component transcoder, you can basically use a garden variety consumer TV and PC and build a pretty convincing arcade cab... what a time to be alive!!!  :cheers:
« Last Edit: August 06, 2021, 11:34:53 pm by rogerxyz »

Zebidee

  • Trade Count: (+6)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1970
  • Last login:Today at 07:47:48 am
It's pretty amazing that with the holy trinity of crt_emudriver, groovymame, and a good component transcoder, you can basically use a garden variety consumer TV and PC and build a pretty convincing arcade cab... what a time to be alive!!!  :cheers:

You got it right there Roger! I also like that there is a strong "circular economy" aspect to the project. It encourages people to repair, reuse, repurpose and recycle old tech that otherwise might be deemed "junk", helping to keep CRTs out of landfill while making people happy.  Saving the planet, one TV at a time!
Check out my completed projects!