GBS 8200/8220 CFW Project

The place for all discussion on gaming hardware
SuperSpongo
Posts: 315
Joined: Sat Mar 17, 2018 2:49 pm
Location: Germany

Re: GBS 8200/8220 CFW Project

Post by SuperSpongo »

Looks really nice!
User avatar
dwards
Posts: 35
Joined: Tue Nov 19, 2013 4:17 pm

Re: GBS 8200/8220 CFW Project

Post by dwards »

Jasper wrote:I ordered them through the Formulor website, just had to slide my design in the Inkscape template they provide, the colors used in my design already match what they expect.
Depending on what laser-cutting service you use you might need to change the colors, but at least the shapes and measurements are there already.
Jasper, very cool design! I tried to upload to ponoko.com and it imported with dimensions 1.98 inches x 1.18 inches. I know this is not right, what should the dimensions be? They also accept mm as well? See how it imported below:
Spoiler
Image
Last edited by dwards on Tue Nov 05, 2019 3:48 pm, edited 1 time in total.
Jasper
Posts: 6
Joined: Fri Jun 28, 2019 9:49 pm

Re: GBS 8200/8220 CFW Project

Post by Jasper »

I re-checked the SVG files in Inkscape, and it gives me a total width of 178.299mm and height of 106.5mm, and that's how big it is in real life as well.
User avatar
NoAffinity
Posts: 1019
Joined: Mon May 07, 2018 5:27 pm
Location: Escondido, CA, USA

Re: GBS 8200/8220 CFW Project

Post by NoAffinity »

@dwards i didnt write that. :p

Very nice design jasper!

Sent from my SM-G955U using Tapatalk
User avatar
dwards
Posts: 35
Joined: Tue Nov 19, 2013 4:17 pm

Re: GBS 8200/8220 CFW Project

Post by dwards »

@NoAffinity, not sure how that happened. Fixed :)

Thank you for the measurements Jasper!
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

NoAffinity wrote: Rama:
Is there a way for gbs control to tell us what the input signal is? I poked around a bit and didnt find anything in the build i currently have flashed (a couple weeks old), and dont remember ever seeing it as a feature that was implemented. Possible to do? Anybody else interested in seeing this?
You mean the source format specs?
I do display then, albeit not very prominently.
"post preset done (preset id: 1) for 60Hz " << NTSC, otherwise I would say "EDTV" or whatever.
Use info mode to get the particular line count, as the IF and the SP see them.
Line counts are no exact science, since the sync filtering sometimes counts EQ and serration pulses, sometimes it doesn't.
And horizontal resolution doesn't exist, as you know :p
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Jasper:
Looks like you ordered the parts in Germany?
What did you pay, if I may ask? :)
Jasper
Posts: 6
Joined: Fri Jun 28, 2019 9:49 pm

Re: GBS 8200/8220 CFW Project

Post by Jasper »

rama wrote:Jasper:
Looks like you ordered the parts in Germany?
What did you pay, if I may ask? :)
Indeed, here are the price details :
Spoiler
Image
And for Germany, the shipping cost would be lower!
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Jasper:
Thanks, so the hunt continues.
I really need something *cheap* to match the cost of the hardware inside :p

benryves:
The frametime lock update is out.
I managed to get it stable on both of my main test displays.
The one that behaves like yours (has a noticable up/down motion normally) can now work with "method 1" to produce an almost stable image.
It still seems to judder ever so slightly when adjusting, but I think that's the best it's going to get.
If I didn't know what it was doing, I would miss it :p
benryves
Posts: 31
Joined: Sun Jan 27, 2019 12:32 am

Re: GBS 8200/8220 CFW Project

Post by benryves »

rama wrote:benryves:
The frametime lock update is out.
I managed to get it stable on both of my main test displays.
The one that behaves like yours (has a noticable up/down motion normally) can now work with "method 1" to produce an almost stable image.
It still seems to judder ever so slightly when adjusting, but I think that's the best it's going to get.
If I didn't know what it was doing, I would miss it :p
Brilliant, thank you very much for pushing out that update!

The new code is considerably cleaner so it's easier to experiment with. :) I've tried changing the two variables at different points (both at the same time, one before the other with a delay between, and in various places within the frame - e.g. inside or outside vblank) but can't get it to change seamlessly on my TV so I think your assertion that it's the best it's going to get holds true. As it stands the current behaviour is a considerable improvement over the previous behaviour for me, so thanks again!
Jasper
Posts: 6
Joined: Fri Jun 28, 2019 9:49 pm

Re: GBS 8200/8220 CFW Project

Post by Jasper »

rama wrote:Jasper:
Thanks, so the hunt continues.
I really need something *cheap* to match the cost of the hardware inside :p
Yes, it's a shame the price is so high for just one set, I just did a simulation and on their biggest acrylic sheet, I was able to fit 7 sets (so both top and bottom) for just under 70 euros without shipping (which is the same regardless of what and how much you buy).
Under 10 euros a set is pretty good.
Spoiler
Image
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Thanks for the bulk simulation!

I fully understand and respect the price on offer. This is simply the cost of business for these kinds of things.
For gbscontrol, I hope to find something that is cheap by virtue of either mass production, or material / workmanship costs.

There's also the posts and screws to consider, as well as a SCART socket solution.
As far as I know, only 3D prints offer all of these right now (and they're expensive also, especially with the printing time).
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Anyone that's modified their VGA to HDMI adapters for direct 3.3V power:

The modification seems to be incomplete, as I didn't know about the EEPROM that's hooked up to the HDMI port.
This EEPROM seems to be powered by the 5V input, and with my modification, it has no more Vcc of its own.
I think it still works from phantom power from the HDMI port (from the other device), but I'm not sure.
In any case, there is probably going to be some issues with my simple mod with regards to phantom current.

I would recommend you investigate yourself, or undo the modification.
If you undo it, maybe it's good enough to have a wire from the 5V GBS input to the adapter's 5V input.
This at least avoids another full length of power supply cable and associated potential differences.

Sorry for the fuss, but why the heck is there an EEPROM at 5V just enjoying the ride on the HDMI bus?! :p
benryves
Posts: 31
Joined: Sun Jan 27, 2019 12:32 am

Re: GBS 8200/8220 CFW Project

Post by benryves »

rama wrote:Sorry for the fuss, but why the heck is there an EEPROM at 5V just enjoying the ride on the HDMI bus?! :p
I was going to suggest it could be there for the EDID data but wouldn't that go in the monitor (or at the very least on the VGA side?)

I think I've cracked the twitching vertical position on my monitor following a bit of thought rather than just trying all sorts of different strategies to see if anything worked.

When vtotal++ the picture moves down, when vsst++ the picture moves up. On my display when vtotal++ and vsst++ simultaneously the picture moves down then up, so presumably it reacts to the effects of the vtotal change first. Therefore, changing vsst before vtotal might help the display to respond to both simultaneously. I first tried changing vsst, waiting a frame, then changing vtotal but that resulted in a glitch in the opposite direction (the picture moved up then down). The sweet spot would then seem to be somewhere between the two strategies, and that seems to be what works. That is, rather than:

Code: Select all

        do {
          // wait for right window for stability
        } while ((GBS::STATUS_VDS_FIELD::read() == 1) && (++timeout < 400));
        VRST_SST::write(vtotal, vsst);
do this:

Code: Select all

        while ((GBS::STATUS_VDS_FIELD::read() == 1) && (++timeout < 400));
        GBS::VDS_VS_ST::write(vsst);
        timeout = 0;
        while ((GBS::STATUS_VDS_FIELD::read() == 0) && (++timeout < 400));
        GBS::VDS_VSYNC_RST::write(vtotal);
This results in a completely stable picture on my monitor, no more glitching every few seconds. :mrgreen:

I've added a third active frametime lock mode to my version of gbs-control, here's framesync.h in its entirety:
Spoiler
framesync.h

Code: Select all

#ifndef FRAMESYNC_H_
#define FRAMESYNC_H_

// fast digitalRead()
#if defined(ESP8266)
#define digitalRead(x) ((GPIO_REG_READ(GPIO_IN_ADDRESS) >> x) & 1)
#ifndef DEBUG_IN_PIN
#define DEBUG_IN_PIN D6
#endif
#else // Arduino
   // fastest, but non portable (Uno pin 11 = PB3, Mega2560 pin 11 = PB5)
   //#define digitalRead(x) bitRead(PINB, 3)
#include "fastpin.h"
#define digitalRead(x) fastRead<x>()
// no define for DEBUG_IN_PIN
#endif

//#define FS_DEBUG

volatile uint32_t stopTime, startTime;

void ICACHE_RAM_ATTR risingEdgeISR_measure() {
  noInterrupts();
  stopTime = ESP.getCycleCount();
  detachInterrupt(DEBUG_IN_PIN);
  interrupts();
}

void ICACHE_RAM_ATTR risingEdgeISR_prepare() {
  noInterrupts();
  startTime = ESP.getCycleCount();
  detachInterrupt(DEBUG_IN_PIN);
  attachInterrupt(DEBUG_IN_PIN, risingEdgeISR_measure, RISING);
  interrupts();
}

template <class GBS, class Attrs>
class FrameSyncManager {
private:
  typedef typename GBS::STATUS_VDS_VERT_COUNT VERT_COUNT;
  typedef typename GBS::VDS_HSYNC_RST HSYNC_RST;
  typedef typename GBS::VDS_VSYNC_RST VSYNC_RST;
  typedef typename GBS::VDS_VS_ST VSST;
  typedef typename GBS::template Tie<VSYNC_RST, VSST> VRST_SST;

  static const uint8_t debugInPin = Attrs::debugInPin;
  static const int16_t syncCorrection = Attrs::syncCorrection;
  static const int32_t syncTargetPhase = Attrs::syncTargetPhase;

  static bool syncLockReady;
  static uint8_t delayLock;
  static int16_t syncLastCorrection;

  // Sample vsync start and stop times from debug pin.
  static bool vsyncOutputSample(uint32_t *start, uint32_t *stop) {
    startTime = 0; stopTime = 0;
    ESP.wdtDisable();
    attachInterrupt(DEBUG_IN_PIN, risingEdgeISR_prepare, RISING);
    // PAL50: 20ms, worst case 2 fields, sometimes needed when tuning VDS clock
    for (uint32_t i = 0; i < 1500; i++)
    {
      if (stopTime > 0) {
        break;
      }
      if ((i % 100) == 0) {
        ESP.wdtFeed();
      }
      delayMicroseconds(100);
    }
    *start = startTime;
    *stop = stopTime;
    ESP.wdtEnable(0);

    if ((*start > *stop) || *stop == 0 || *start == 0) {
      // ESP.getCycleCount() overflow oder no pulse, just fail this round
      return false;
    }

    return true;
  }

  // Sample input and output vsync periods and their phase
  // difference in microseconds
  static bool vsyncPeriodAndPhase(int32_t *periodInput, int32_t *periodOutput, int32_t *phase) {
    uint32_t inStart, inStop, outStart, outStop;
    uint32_t inPeriod, outPeriod, diff;

    // calling code needs to ensure debug bus is ready to sample vperiod

    if (!vsyncInputSample(&inStart, &inStop)) {
      return false;
    }

    GBS::TEST_BUS_SEL::write(0x2);  // 0x2 = VDS (t3t50t4) // measure VDS vblank (VB ST/SP)
    inPeriod = (inStop - inStart); //>> 1;
    if (!vsyncOutputSample(&outStart, &outStop)) {
      return false;
    }
    outPeriod = (outStop - outStart); //>> 1;


    diff = (outStart - inStart) % inPeriod;
    if (periodInput)
      *periodInput = inPeriod;
    if (periodOutput)
      *periodOutput = outPeriod;
    if (phase)
      *phase = (diff < inPeriod) ? diff : diff - inPeriod;

    return true;
  }

  static bool sampleVsyncPeriods(uint32_t *input, uint32_t *output) {
    int32_t inPeriod, outPeriod;

    if (!vsyncPeriodAndPhase(&inPeriod, &outPeriod, NULL))
      return false;

    *input = inPeriod;
    *output = outPeriod;

    return true;
  }

  // Find appropriate htotal that makes output frame time slightly more than the input.
  static bool findBestHTotal(uint32_t &bestHtotal) {
    uint16_t inHtotal = HSYNC_RST::read();
    uint32_t inPeriod, outPeriod;

    if (inHtotal == 0) { return false; } // safety
    if (!sampleVsyncPeriods(&inPeriod, &outPeriod)) { return false; }

    if (inPeriod == 0 || outPeriod == 0) { return false; } // safety

    inPeriod -= 18; // skew to smaller bestHtotal 
    // large htotal can push intermediates to 33 bits
    bestHtotal = (uint64_t)(inHtotal * (uint64_t)inPeriod) / (uint64_t)outPeriod;

    if (bestHtotal == (inHtotal + 1)) { bestHtotal -= 1; } // works well
    if (bestHtotal == (inHtotal - 1)) { bestHtotal += 1; } // check with SNES + vtotal = 1000 (1280x960)

#ifdef FS_DEBUG
    if (bestHtotal != inHtotal) {
      Serial.print(F("                     wants new htotal, oldbest: ")); Serial.print(inHtotal);
      Serial.print(F(" newbest: ")); Serial.println(bestHtotal);
      Serial.print(F("                     inPeriod: ")); Serial.print(inPeriod);
      Serial.print(F(" outPeriod: ")); Serial.println(outPeriod);
    }
#endif
    return true;
  }

public:
  // sets syncLockReady = false, which in turn starts a new findBestHtotal run in loop()
  static void reset(uint8_t frameTimeLockMethod) {
#ifdef FS_DEBUG
    Serial.print("FS reset(), with correction: ");
#endif
    if (syncLastCorrection != 0) {
#ifdef FS_DEBUG
      Serial.println("Yes");
#endif
      uint16_t vtotal = 0, vsst = 0;
      VRST_SST::read(vtotal, vsst);
      uint16_t timeout = 0;
      vtotal -= syncLastCorrection;
  
      switch (frameTimeLockMethod) {
        case 1:
        case 2:
          vsst -= syncLastCorrection; // moves VS position
          break;
        // else it is method 0: leaves VS position alone
      }
  
      switch (frameTimeLockMethod) {
        case 0:
        case 1:
          do {
            // wait for right window for stability
          } while ((GBS::STATUS_VDS_FIELD::read() == 1) && (++timeout < 400));
          VRST_SST::write(vtotal, vsst);
          break;
        case 2:
          while ((GBS::STATUS_VDS_FIELD::read() == 1) && (++timeout < 400));
          GBS::VDS_VS_ST::write(vsst);
          timeout = 0;
          while ((GBS::STATUS_VDS_FIELD::read() == 0) && (++timeout < 400));
          GBS::VDS_VSYNC_RST::write(vtotal);
          break;
      }
      
    }
#ifdef FS_DEBUG
    else {
      Serial.println("No");
    }
#endif
    syncLockReady = false;
    syncLastCorrection = 0;
    delayLock = 0;
  }

  static void resetWithoutRecalculation() {
    syncLockReady = true;
    syncLastCorrection = 0;
    delayLock = 0;
  }

  static uint16_t init() {
    uint32_t bestHTotal = 0;

    // Adjust output horizontal sync timing so that the overall
    // frame time is as close to the input as possible while still
    // being less.  Increasing the vertical frame size slightly
    // should then push the output frame time to being larger than
    // the input.
    if (!findBestHTotal(bestHTotal)) {
      return 0;
    }

    syncLockReady = true;
    delayLock = 0;
    return (uint16_t)bestHTotal;
  }

  static uint32_t getPulseTicks() {
    uint32_t inStart, inStop;
    if (!vsyncInputSample(&inStart, &inStop)) {
      return 0;
    }
    return inStop - inStart;
  }

  static bool ready(void) {
    return syncLockReady;
  }

  static int16_t getSyncLastCorrection() {
    return syncLastCorrection;
  }

  static void cleanup() {
    syncLastCorrection = 0; // the important bit
    syncLockReady = 0;
    delayLock = 0;
  }

  // Sample vsync start and stop times from debug pin.
  static bool vsyncInputSample(uint32_t *start, uint32_t *stop) {
    startTime = 0; stopTime = 0;
    ESP.wdtDisable();
    attachInterrupt(DEBUG_IN_PIN, risingEdgeISR_prepare, RISING);
    // PAL50: 20ms, worst case 2 fields, sometimes needed when tuning VDS clock
    for (uint32_t i = 0; i < 1500; i++)
    {
      if (stopTime > 0) {
        break;
      }
      if ((i % 100) == 0) {
        ESP.wdtFeed();
      }
      delayMicroseconds(100);
    }
    *start = startTime;
    *stop = stopTime;
    ESP.wdtEnable(0);

    if ((*start > *stop) || *stop == 0 || *start == 0) {
      // ESP.getCycleCount() overflow oder no pulse, just fail this round
      return false;
    }

    return true;
  }

  // Perform vsync phase locking.  This is accomplished by measuring
  // the period and phase offset of the input and output vsync
  // signals and adjusting the frame size (and thus the output vsync
  // frequency) to bring the phase offset closer to the desired
  // value.
  static bool run(uint8_t frameTimeLockMethod) {
    int32_t period;
    int32_t phase;
    int32_t target;
    int16_t correction;

    if (!syncLockReady)
      return false;

    if (delayLock < 2) {
      delayLock++;
      return true;
    }

    if (!vsyncPeriodAndPhase(&period, NULL, &phase))
      return false;

    target = (syncTargetPhase * period) / 360;

    if (phase > target)
      correction = 0;
    else
      correction = syncCorrection;

#ifdef FS_DEBUG
    Serial.print(" target: "); Serial.print(target);
    Serial.print(" phase: "); Serial.println(phase);
#endif

    if (correction == syncLastCorrection) {
      return true;
    }

    int16_t delta = correction - syncLastCorrection;
    uint16_t vtotal = 0, vsst = 0;
    uint16_t timeout = 0;
    VRST_SST::read(vtotal, vsst);
    vtotal += delta;

    switch (frameTimeLockMethod) {
      case 1:
      case 2:
        vsst += delta; // moves VS position
        break;
      // else it is method 0: leaves VS position alone
    }

    switch (frameTimeLockMethod) {
      case 0:
      case 1:
        do {
          // wait for right window for stability
        } while ((GBS::STATUS_VDS_FIELD::read() == 1) && (++timeout < 400));
        VRST_SST::write(vtotal, vsst);
        break;
      case 2:
        while ((GBS::STATUS_VDS_FIELD::read() == 1) && (++timeout < 400));
        GBS::VDS_VS_ST::write(vsst);
        timeout = 0;
        while ((GBS::STATUS_VDS_FIELD::read() == 0) && (++timeout < 400));
        GBS::VDS_VSYNC_RST::write(vtotal);
        break;
    }
    
    syncLastCorrection = correction;

#ifdef FS_DEBUG
    Serial.print("  vtotal: "); Serial.println(vtotal);
#endif

    return true;
  }
};

template <class GBS, class Attrs>
int16_t FrameSyncManager<GBS, Attrs>::syncLastCorrection;

template <class GBS, class Attrs>
uint8_t FrameSyncManager<GBS, Attrs>::delayLock;

template <class GBS, class Attrs>
bool FrameSyncManager<GBS, Attrs>::syncLockReady;
#endif
The changes to gbs-control.ino are more spread out and related to handling the extra mode number, but I think I've covered them all below:
Spoiler
In activeFrameTimeLockInitialSteps():

Code: Select all

  SerialM.print(F("Active FrameTime Lock enabled, disable if display unstable or stays blank! Method: "));
  switch (uopt->frameTimeLockMethod) {
    case 0:
      SerialM.println("0 (vtotal only)");
      break;
    case 1:
      SerialM.println("1 (vtotal with VSST)");
      break;
    case 2:
      SerialM.println("2 (vtotal after VSST)");
      break;
  }
In setup():

Code: Select all

      uopt->frameTimeLockMethod = (uint8_t)(f.read() - '0');
      if (uopt->frameTimeLockMethod > 2) uopt->frameTimeLockMethod = 0;
In handleType2Command(char argument):

Code: Select all

  case 'i':
    // toggle active frametime lock method
    FrameSync::reset(uopt->frameTimeLockMethod);

    uopt->frameTimeLockMethod = (uopt->frameTimeLockMethod + 1) % 3;
    
    saveUserPrefs();
    activeFrameTimeLockInitialSteps();
    break;
I've done some testing with my Mega Drive and Saturn, normally both of those show the jumping picture and whilst it's still apparent in modes 0 and 1 it's no longer showing up in mode 2. I also played a fair amount of Sonic the Hedgehog 2 as the fast scrolling in that normally shows the horizontal tear line quite obviously when the frame time lock isn't active but I haven't seen it yet (just in case I'd broken something else!)
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Sounds great!
I hope this will just work on my display as well.
In that case, there's no need for a third mode :)
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Yep, this method is super compatible. Great find! :)

It even fixes some issues I had with PAL sources on my PC TFT, so at least 2 very different display controller designs like it.
These were never designed for FreeSync style timing tricks, so that's kind of impressive really.

I'll commit this soon, I want to decide whether I even need 2 methods now :)

Bonus:
It works with the old 2 line adjust as well, which doesn't cause dropouts on the PC TFT.
(The PC TFT has dropouts with 1 line adjust while the FTL routine does the first few adjustments. It later becomes stable though.)
So that could be a reason to have 2 different methods, or simply always use 2 lines.
benryves
Posts: 31
Joined: Sun Jan 27, 2019 12:32 am

Re: GBS 8200/8220 CFW Project

Post by benryves »

Great to hear it's working for you on your monitors, too! I normally use a cheap "Blaupunkt"-branded TV so have also tried the changed code on my LG PC monitor and can confirm that the "mode 2" works on it too (mode 0 moves up and down slowly and mode 1 glitches up and down, so same behaviour as my main TV).

After your "Bonus:" comment I tried changing FrameSyncAttrs::syncCorrection back to 2 and the picture is still rock steady when using "mode 2" on both displays, all looks good here. :)
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Pushed this change, and made the vtotal + vsst method the default as well (method 0).
I hope I didn't mess it up when tuning the phase and lock interval parameters :p

The lock interval has been optimized so that active wait times are a little shorter on average.
Maybe the FTL routine should schedule updates itself (based on 50/60Hz frametimes).
The goal of that is to try and reduce the time the routine has to hammer the status register.
I2C comms are a little noisy, and the GBS board design routes SCL / SDA directly below all the analog pins :(
It's nothing that can be seen normally though.
benryves
Posts: 31
Joined: Sun Jan 27, 2019 12:32 am

Re: GBS 8200/8220 CFW Project

Post by benryves »

rama wrote:I hope I didn't mess it up when tuning the phase and lock interval parameters :p
All looking good here, I've switched to the current firmware version and it all seems to be working very nicely, stable picture and no horizontal tear line. Thank you!

Here's a much more technically demanding question: I'm currently using D4 to drive the status LED on the outside of my enclosure via a modification of the LEDON/LEDOFF macros (D4 picked because it let me use a three pin header for that LED and a power LED). Is that likely to conflict with anything in future, or did I miss an obvious place where the built-in LED's pin is exposed externally?
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Great.
I also tried a few more HDMI sinks that I could find, and even the HDMI to AV converter box has no trouble with active FTL now :D

ESP8266 is a little pin-starved but gbscontrol doesn't require too many of them.
If "D4" is a free GPIO on your board, then it's fine to use.
I don't currently have plans to use any more GPIO :)
User avatar
AndehX
Posts: 790
Joined: Sun Oct 18, 2015 11:37 pm

Re: GBS 8200/8220 CFW Project

Post by AndehX »

Did a quick stream earlier to test out quality (and my MSU-1 pack lol) I love how it looks with scanlines

https://www.twitch.tv/videos/506211867
User avatar
Syntax
Posts: 1774
Joined: Wed Aug 09, 2017 12:10 am
Location: Australia

Re: GBS 8200/8220 CFW Project

Post by Syntax »

If I put my CPS2 through the GBS then a HDMI converter do you think it would look as wonky as the OSSC?

GBS on the left OSSC on the right.

Image
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Syntax:
Best if you just tried it :p
The OSSC obviously struggles there around VSync. I never get results like these in my tests, but I also don't have exotic hardware to provoke it.
I'm sure I can fix it if gbscontrol produces similar results though.
Ryoandr
Posts: 269
Joined: Mon Jun 12, 2017 4:12 am

Re: GBS 8200/8220 CFW Project

Post by Ryoandr »

CPS2 worked perfectly (no skew) with GBS HDMI version, so I'm guessing it'll work fine with normal GBS with an HDMI converter. With adjusted frame rate, it also worked great with HDMI monitors.
Iraito
Posts: 122
Joined: Sat Aug 24, 2019 8:59 am

Re: GBS 8200/8220 CFW Project

Post by Iraito »

Lately i have been messing around with my capture card and HD content, by connecting the hdmi directly into the usb capture card i get some weird vertical color artifacts but by using the GBS (console---> to VGA adapter ---> to hdmi adapter---> to capture card) everything looks perfect (it seems to be working in pass-through) but the picture is slightly offset to the right leaving a small black bar on the left. Only after i try resetting a lot of times the picture center itself, now i know this is an exotic problem but is there anyway to fix this ? like an auto adjustment or something ?
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: GBS 8200/8220 CFW Project

Post by Xyga »

rama wrote:Syntax:
Best if you just tried it :p
The OSSC obviously struggles there around VSync. I never get results like these in my tests, but I also don't have exotic hardware to provoke it.
I'm sure I can fix it if gbscontrol produces similar results though.
I haven't had a GBS in a very long time (maybe 10 years) but I seem to remember it had similar issues (skew/flag) with my Dogyuun.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
Syntax
Posts: 1774
Joined: Wed Aug 09, 2017 12:10 am
Location: Australia

Re: GBS 8200/8220 CFW Project

Post by Syntax »

My point was the OSSC struggles with a CPS2 but the GBS smashed it out no worries.

OSSC was dropping sync for around 20 seconds before it picked up.

GBS-Control is pretty damn awesome.

In my picture the GBS is off center because I was too lazy to tune the screen in, I was playing Dreamcast last I think.
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: GBS 8200/8220 CFW Project

Post by rama »

Well, to be fair, I think the OSSC optimizes for standards complience first and foremost.
I try to generalize sync processing so it works with every device I encounter.
Doing that, I don't shy away from non-recommended settings for some parameters, and others I set based on experience but not knowing what they do exactly.

The OSSC also knows what it's doing, because every chip on it has proper documentation with full explanations.
For the TV5725, they throw acronyms at you left and right, and nothing in the manual makes sense :p
User avatar
Syntax
Posts: 1774
Joined: Wed Aug 09, 2017 12:10 am
Location: Australia

Re: GBS 8200/8220 CFW Project

Post by Syntax »

I should mention the GBS was doing a really funny thing with the picture but would clear up on reset, or id start with my PC engine then switch to the CPS2.

The image was smeared, very dull and rainbowy.( like a subcarrier going out of spec). Not sure what was going on there, bad clamp?
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: GBS 8200/8220 CFW Project

Post by Xyga »

Yes it does cps2 right, but cps2 is not too hard, lots of doublers and processors can manage that hardware.

Really troublesome arcade games is where multipliers and scalers are put to test the hardest, we've seen the Dogyuun case, trust me it's not isolated.

So far it really does take a heavyweight like the VP50 Pro to completely tame some of those shrews without sacrifices or side-effects (as far as I've seen)

If GBScontrol could probably be a good alternative to that, it would have to be tested with pcbs anyway, so by people who own a great variety and are interested in the project.

Good luck, because it there's one thing pcb owners/collectors most often don't care about, it's flat panels and scalers. :mrgreen:
Strikers1945guy wrote:"Do we....eat chicken balls?!"
Post Reply