Milsancho
Forum Replies Created
-
AuthorPosts
-
Yep. I was confused about ‘CVBS-as-sync RGB’ because of the terminology used, I guess. Somehow I didn’t expect R-G-B being carried over two simultaneous ways, and didn’t know that the difference between CVBS signal and ‘CVBS RGB’ was just that. I think the explanations I had read placed too much emphasis on the sync signal and never mentioned that R-G-B are doubled. That, and ‘C-sync’ (which should be ‘clean/raw sync’ instead for better clarity – CVBS is technically also ‘C-sync’, you know.
I think such a thing would be pretty much impossible since there’s no composite video signal left, it’s been stripped out, literally all there is is sync so where would you get the composite video from? I suppose you could transcode it on the fly from RGBS, but since we’re only talking about a handful of peculiar TVs here I doubt that anyone would want to make such a device.
Yeah, ever since I asked, some stuff is more clear to me. I’ve been advised to try with an RGB-to-CVBS encoder, but making sure it features RGB passthrough. At least one person made them in the US, but sadly not anymore. Other current Chinese samples may help or may not, nobody knows as indeed not many people have faced the issue or bothered enough. At any rate, it’d require custom cables and the chain would be weird.
Fortunately, I’ve also learned that this FE2 chassis do have a setting to basically recover reds’ integrity – ‘TT34’ when entering service menu. It’s not absolutely perfect, but almost. The TV has now a really nice picture, even if colour saturation and brightness should be tweaked a bit when going from a C-sync/sync on luma source to a CVBS RGB source. Moreover, some people claim to have found an ultimate solution for this particular problem:
Well, I have finally found the definitive solution to this problem without the need for any hardware modification, the problem was a pulse in the horizontal syncronism too high, this in some TVs generates a flattened color scale, can be corrected by lowering the “H Pulse” field in the hdmi_timings, it is possible that by lowering it timings with frequencies below 60Hz, they will suffer vertical desynchronization, so the “V sync” would also have to be lowered.
https://github.com/mortaca/RGB-Pi/issues/12
As I don’t know how much reduction should be that though (not an RGB Pi user myself, and the author isn’t sharing too many details), I’m going to order a cable with 280 ohm resistors for pins 7, 11, and 15, which a guy says worked flawlessly for him as well. So well, just wish me luck, even though I’m quite happy with how the colours are right now.
Also, could you confirm that sync-on-CVBS RGB uses pin 20 also for R-G-B and leaves pins 15, 11 and 7 withou any use?
I’ll address this myself, though it’s still a guess – sync-on-CVBS RGB does “use” pin 20 for R-G-B as well as combined sync, but also uses pins 15, 11 and 7 for R/G/B, otherwise it would display a composite video signal. So colors are carried over in two simultaneous ways with this RGB mode.
If anyone here happens to have any idea who could I ask to make a RGBHV/RGBS to CVBS-as-sync RGB adapter or even just to discuss which circuit could be used for that, please let me know. I thought it would be more common than it is as the opposite is a well-documented process, and it’d be a real shame if this TV set could only be used for consoles.
Yeah, you can read some people having color issues with this Sony chassis (FE2) yet never it’s properly diagnosed. I’m still to find it fully documented, at least. So I’m not really sure which are the intolerances exactly.
I’ve tested it with two different units though, both behaving the same:
· Japanese Sega Saturn with C-sync TTL cable: severely wrong colors, kind of greenish
· Japanese Sega Saturn with sync on CVBS RGB cable: accurate colors
· PAL PS2 slim with sync-on-luma cable from RGC: only red is darkened
· PAL PS2 slim with unexpensive RGB cable (I assume sync on CVBS): accurate colors
· Japanese DC with two different RGB cables (they were unexpensive so I assumed as well they were sync on CVBS): red is darkened, unsure if the rest are really fine
· RGBHV D-sub to RGBS SCART with a resistor to join syncs: only red is darkened
All these cables were already tested on different TV sets with no major issues detected.
Likely the major color issues I get with the SS C-sync cable are due to it not having attenuated electrical signals for consumer TVs, but inferring that this TV chassis only tolerates sync on CVBS is the only answer I can think of. I’m far from being an expert anyway, so maybe I’m missing something.
Do you know of a device which safely turns either RGBHV or RGBS into sync-on-CVBS RGB?
Also, could you confirm that sync-on-CVBS RGB uses pin 20 also for R-G-B and leaves pins 15, 11 and 7 withou any use?
(I’m a bit surprised that sync-on-CVBS RGB is so widely ignored by European cable makers, despite knowing that digital devices usually don’t support it.)
Thank you.
I had the 2018 revision. Sold it because it was really unbearable at least with my system and got tired of so many games with issues, but especially due to Terraonion’s customer support and unreliable attitude. No clue how “rev. B” (2019) performs.
Have now a spare Mega Drive 2/SSDS3 Packapunch RGB cable, like new (since I never had a proper chance to use it) and with audio breakout, in case there’s interest, by the way.
Ah, is that so? Mario 64, Mario Story and Tsumi to Batsu also do?
So for 240p 2D-only games such as Bangai-O or Ogre Battle 64 there’s a blur filter too unless you’ve modded your console!?
(Weird, that there isn’t a list/DB yet of N64 games which differentiates 240p/480i games!)
May I ask — does the stock NTSC N64 output 240p? If so, is there any game that supports it? Always thought that 480i was the only way and that many 2D games were double-scanned due to that.
Hi,
Guess what, I get noticeable diagonal “banding” with my SSDS3 and a Packapunch cable. I wonder if there’s anyone who really lucked out with his since it’s something you won’t notice if there isn’t a flat dark-ish color on screen, so I woudn’t expect too many reports. In other words, it’s a bad-design issue and yet, they won’t acknowledge it so that some work is put into finding and fixing its causes. I don’t know if it’s known at this point, but surprisingly pausing/unpausing the game affects the diagonal banding. Very noticeable in Ankoku Densetsu’s first stage’s sky, for example, but also in many others. Not sure if it’s related to the audio since it usually stops when paused.
Not only that — I get a bit of graphic noise too. My system is RGB-modded and, supposedly, jailbar-fixed. Nevertheless, I get severe jailbars in many situations when using the console’s RGB out. It must be a cheap cable, so I was wondering if it’s worth buying a PCE Packapunch in order to mitigate the jailbars (so that I don’t have to use the SSDS3’s video output and therefore, get rid of the diagonal banding) or if the jailbars (there’s a vertical white line at the left side which is very prominent, even) will be the same no matter the cable?
Also, I’d like to read about your own experience with the PCE’s video and the SSDS3.
I have Shinetsu grease for my arcade stuff; do you think it’s safe using it for the drive’s lubrication too?
Thanks. Learn something new everyday… Does it equally affect the PS One as well, then? Not sure if you read this line in the post lnked above:
The sticking point is that consoles earlier than, I think, the PSone won’t run the other mode with the correct subcarrier frequency (So PAL timings on NTSC will be off, and vice versa).
And a bit OT, but any suggestion to get a good, original KSM-440BAM disc drive these days. I don’t even know if there’s a way to tell apart original units from cheap clones, but all of them seem to come from China no matter what and look the same!
Theoretically, you can use an ordinary composite video RCA cable just for the audio out, can’t you (for already RGB-modded units)?
Read that yours arrived and you’ve been testing it. Can you confirm you can use a regular, cheap MD2 RCA/composite video cable with the device? (Interested only in the stereo audio output with it.)
Also, relevant link/announcement:
http://www.neosdstore.com/news/index.php/2018/01/24/super-sd-system-3-rgb-shipment-statement/
They of course messed it up. Hopefully RGC releases a dedicated cable.
So it seems the developers have finally cleared up how’s the device’s video output:
Well, there is an error there in the manual. There is a 22 ohm (or 21, I can’t remenber) resistor to attenuate the output on a proper MD2 cable.
https://shmups.system11.org/viewtopic.php?p=1292915#p1292915
Do you think by that that RGC’s C-sync MD2 cables will do without brightness issues (nor TTL-level ones either; the developers’ idea is that RGB TVs or scan converters should use the sync-on-composite-video modality.)? Too bad they didn’t study a bit better the video thing beforehand. Or that they actually cared. If there’s already a hardware revision planned due to stuff like this, many customers will be upset for a reason.
Also did I, couldn’t resist. Seems RGC will have an option for 75 Ω, so one less thing to worry about. I’m worried about the “jailbars” issue, nevertheless. apparently, you can find it whichever the console you get. Not too used with this system, myself. It seems to exist a universal fix already, but it’s not possible for me to do.
You’re not saying which Trinitron model, but anyways, try to find the “HWD RED”, “HWD GREEN”, “HWD BLUE” options; they’re usually together with geometry options, though I’m not sure on NTSC models. Lower the RED value a bit and check it out. Over-driven colors (together with the focus) will normally need adjustments only possible by opening up the set, but you may alleviate a bit the problem with the service menu options.
-
AuthorPosts