GBS 8200/8220 CFW Project
-
- Posts: 320
- Joined: Sat Mar 17, 2018 2:49 pm
- Location: Germany
Re: GBS 8200/8220 CFW Project
Looks really nice!
Re: GBS 8200/8220 CFW Project
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: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.
Spoiler
Last edited by dwards on Tue Nov 05, 2019 3:48 pm, edited 1 time in total.
Re: GBS 8200/8220 CFW Project
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.
-
NoAffinity
- Posts: 1033
- Joined: Mon May 07, 2018 5:27 pm
- Location: Escondido, CA, USA
Re: GBS 8200/8220 CFW Project
@dwards i didnt write that. :p
Very nice design jasper!
Sent from my SM-G955U using Tapatalk
Very nice design jasper!
Sent from my SM-G955U using Tapatalk
Re: GBS 8200/8220 CFW Project
@NoAffinity, not sure how that happened. Fixed
Thank you for the measurements Jasper!
Thank you for the measurements Jasper!
Re: GBS 8200/8220 CFW Project
You mean the source format specs?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?
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
Re: GBS 8200/8220 CFW Project
Jasper:
Looks like you ordered the parts in Germany?
What did you pay, if I may ask?
Looks like you ordered the parts in Germany?
What did you pay, if I may ask?
Re: GBS 8200/8220 CFW Project
Indeed, here are the price details :rama wrote:Jasper:
Looks like you ordered the parts in Germany?
What did you pay, if I may ask?
Spoiler
Re: GBS 8200/8220 CFW Project
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
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
Re: GBS 8200/8220 CFW Project
Brilliant, thank you very much for pushing out that update!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
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!
Re: GBS 8200/8220 CFW Project
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).rama wrote:Jasper:
Thanks, so the hunt continues.
I really need something *cheap* to match the cost of the hardware inside :p
Under 10 euros a set is pretty good.
Spoiler
Re: GBS 8200/8220 CFW Project
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).
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).
Re: GBS 8200/8220 CFW Project
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
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
Re: GBS 8200/8220 CFW Project
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?)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 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);
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);
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
Spoiler
In activeFrameTimeLockInitialSteps():
In setup():
In handleType2Command(char argument):
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;
}
Code: Select all
uopt->frameTimeLockMethod = (uint8_t)(f.read() - '0');
if (uopt->frameTimeLockMethod > 2) uopt->frameTimeLockMethod = 0;
Code: Select all
case 'i':
// toggle active frametime lock method
FrameSync::reset(uopt->frameTimeLockMethod);
uopt->frameTimeLockMethod = (uopt->frameTimeLockMethod + 1) % 3;
saveUserPrefs();
activeFrameTimeLockInitialSteps();
break;
Re: GBS 8200/8220 CFW Project
Sounds great!
I hope this will just work on my display as well.
In that case, there's no need for a third mode
I hope this will just work on my display as well.
In that case, there's no need for a third mode
Re: GBS 8200/8220 CFW Project
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.
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.
Re: GBS 8200/8220 CFW Project
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.
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.
Re: GBS 8200/8220 CFW Project
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.
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.
Re: GBS 8200/8220 CFW Project
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!rama wrote:I hope I didn't mess it up when tuning the phase and lock interval parameters :p
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?
Re: GBS 8200/8220 CFW Project
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
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
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
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
Re: GBS 8200/8220 CFW Project
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
https://www.twitch.tv/videos/506211867
Re: GBS 8200/8220 CFW Project
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.
GBS on the left OSSC on the right.
Re: GBS 8200/8220 CFW Project
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.
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.
Re: GBS 8200/8220 CFW Project
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.
Re: GBS 8200/8220 CFW Project
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 ?
Re: GBS 8200/8220 CFW Project
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.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.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
Re: GBS 8200/8220 CFW Project
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.
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.
Re: GBS 8200/8220 CFW Project
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
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
Re: GBS 8200/8220 CFW Project
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?
The image was smeared, very dull and rainbowy.( like a subcarrier going out of spec). Not sure what was going on there, bad clamp?
Re: GBS 8200/8220 CFW Project
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.
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.
Strikers1945guy wrote:"Do we....eat chicken balls?!"