Milsancho

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 26 total)
  • Author
    Posts
  • in reply to: On Sony CRTs and D-sub-SCART cables #66092
    Milsancho
    Participant

      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.

       

       

       

       

      • This reply was modified 1 month, 1 week ago by Milsancho.
      • This reply was modified 1 month, 1 week ago by Milsancho.
      in reply to: On Sony CRTs and D-sub-SCART cables #65833
      Milsancho
      Participant

        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.

         

         

        in reply to: On Sony CRTs and D-sub-SCART cables #65825
        Milsancho
        Participant

          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.

           

           

           

          in reply to: The PC Engine #26166
          Milsancho
          Participant

            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.

            in reply to: N64 de-blur. #24817
            Milsancho
            Participant

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

              in reply to: N64 de-blur. #24773
              Milsancho
              Participant

                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.

                in reply to: The PC Engine #24771
                Milsancho
                Participant

                  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.

                  in reply to: 60-Hz-modded PAL PS vs. NTSC #20387
                  Milsancho
                  Participant

                    I have Shinetsu grease for my arcade stuff; do you think it’s safe using it for the drive’s lubrication too?

                    in reply to: 60-Hz-modded PAL PS vs. NTSC #20252
                    Milsancho
                    Participant

                      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!

                      in reply to: The PC Engine #18733
                      Milsancho
                      Participant

                        Theoretically, you can use an ordinary composite video RCA cable just for the audio out, can’t you (for already RGB-modded units)?

                        in reply to: The PC Engine #18730
                        Milsancho
                        Participant

                          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/

                          in reply to: The PC Engine #18598
                          Milsancho
                          Participant

                            They of course messed it up. Hopefully RGC releases a dedicated cable.

                            in reply to: The PC Engine #18215
                            Milsancho
                            Participant

                              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.

                              in reply to: The PC Engine #17927
                              Milsancho
                              Participant

                                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.

                                http://etim.net.au/av-driver/pcebars/

                                in reply to: Pixel Colour Bleeding #16166
                                Milsancho
                                Participant

                                  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.

                                Viewing 15 posts - 1 through 15 (of 26 total)