shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Tue Nov 19, 2019 9:30 pm View unanswered posts
View active topics



Post new topic Reply to topic  [ 2514 posts ]  Go to page Previous  1 ... 80, 81, 82, 83, 84  Next
Author Message
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 04, 2019 8:17 am 



Joined: 17 Mar 2018
Posts: 63
Looks really nice!


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 04, 2019 9:45 pm 


User avatar

Joined: 19 Nov 2013
Posts: 33
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: show
Image


Last edited by dwards on Tue Nov 05, 2019 3:48 pm, edited 1 time in total.

Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 04, 2019 11:00 pm 



Joined: 28 Jun 2019
Posts: 5
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.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Nov 05, 2019 3:27 am 


User avatar

Joined: 07 May 2018
Posts: 429
Location: Escondido, CA, USA
@dwards i didnt write that. :p

Very nice design jasper!

Sent from my SM-G955U using Tapatalk


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Nov 05, 2019 3:49 pm 


User avatar

Joined: 19 Nov 2013
Posts: 33
@NoAffinity, not sure how that happened. Fixed :)

Thank you for the measurements Jasper!


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Nov 05, 2019 4:20 pm 



Joined: 08 Mar 2017
Posts: 1105
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


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Nov 05, 2019 4:59 pm 



Joined: 08 Mar 2017
Posts: 1105
Jasper:
Looks like you ordered the parts in Germany?
What did you pay, if I may ask? :)


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Nov 05, 2019 9:23 pm 



Joined: 28 Jun 2019
Posts: 5
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: show
Image


And for Germany, the shipping cost would be lower!


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Nov 05, 2019 9:40 pm 



Joined: 08 Mar 2017
Posts: 1105
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


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Wed Nov 06, 2019 6:35 am 



Joined: 27 Jan 2019
Posts: 31
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!


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Wed Nov 06, 2019 10:37 pm 



Joined: 28 Jun 2019
Posts: 5
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: show
Image


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Thu Nov 07, 2019 6:31 pm 



Joined: 08 Mar 2017
Posts: 1105
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).


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Thu Nov 07, 2019 10:52 pm 



Joined: 08 Mar 2017
Posts: 1105
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


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Thu Nov 07, 2019 11:48 pm 



Joined: 27 Jan 2019
Posts: 31
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:
        do {
          // wait for right window for stability
        } while ((GBS::STATUS_VDS_FIELD::read() == 1) && (++timeout < 400));
        VRST_SST::write(vtotal, vsst);


do this:

Code:
        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: show
framesync.h
Code:
#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: show
In activeFrameTimeLockInitialSteps():
Code:
  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:
      uopt->frameTimeLockMethod = (uint8_t)(f.read() - '0');
      if (uopt->frameTimeLockMethod > 2) uopt->frameTimeLockMethod = 0;


In handleType2Command(char argument):
Code:
  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!)


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Fri Nov 08, 2019 12:27 am 



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


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Fri Nov 08, 2019 1:10 am 



Joined: 08 Mar 2017
Posts: 1105
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.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Fri Nov 08, 2019 4:05 am 



Joined: 27 Jan 2019
Posts: 31
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. :)


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Fri Nov 08, 2019 6:18 am 



Joined: 08 Mar 2017
Posts: 1105
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.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Fri Nov 08, 2019 12:59 pm 



Joined: 27 Jan 2019
Posts: 31
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?


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Fri Nov 08, 2019 2:48 pm 



Joined: 08 Mar 2017
Posts: 1105
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 :)


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Sun Nov 10, 2019 2:05 am 



Joined: 18 Oct 2015
Posts: 730
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


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Sun Nov 10, 2019 3:41 am 


User avatar

Joined: 09 Aug 2017
Posts: 1284
Location: Australia
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


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Sun Nov 10, 2019 6:32 pm 



Joined: 08 Mar 2017
Posts: 1105
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.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 11, 2019 1:02 am 



Joined: 12 Jun 2017
Posts: 150
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.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 11, 2019 8:59 am 



Joined: 24 Aug 2019
Posts: 70
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 ?


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 11, 2019 10:43 am 


User avatar

Joined: 05 Nov 2013
Posts: 6975
Location: block
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.
_________________
mycophobia wrote:
have tyou ever played dodponpatchi


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 11, 2019 2:48 pm 


User avatar

Joined: 09 Aug 2017
Posts: 1284
Location: Australia
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.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 11, 2019 3:13 pm 



Joined: 08 Mar 2017
Posts: 1105
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


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 11, 2019 3:58 pm 


User avatar

Joined: 09 Aug 2017
Posts: 1284
Location: Australia
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?


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Nov 11, 2019 4:44 pm 


User avatar

Joined: 05 Nov 2013
Posts: 6975
Location: block
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:
_________________
mycophobia wrote:
have tyou ever played dodponpatchi


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2514 posts ]  Go to page Previous  1 ... 80, 81, 82, 83, 84  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot], ulihox, Xer Xian and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Space Pilot 3K template by Jakob Persson
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group