GBS 8200/8220 CFW Project

[Iraito]

I will totally check that and see to a fix as soon as i can.

[maxtherabbit]

The console may have this mod applied:



Back then (and even today still), many modders / guides leave out the part of lifting pin 157.
This shortcuts the NTSC/PAL selector driver in the GPU, which besides destroying the driver, probably also causes signal quality issues that could explain the problems here.

The next thing to check (replace) is the output coupling capacitor (220uF electrolytic, called C551 on many later models).
It has a tendency to go bad, and delivering a dark CVBS picture and obviously bad sync.

That would certainly explain it, since there's nothing intrinsic to a MM3 chip that could affect video in any way

[rama]

There's a new option on the devel tab called IF Auto Offset.
It'd be great if you could test this a little.
The option is currently just a toggle switch. The effect is lost when a new preset is loaded or the scaler is reset.

I had this always enabled previously, but in some situations, it would cause flicker in reds and blues (it works on UV color space).
I don't get these problems now, but it's probably still happening somewhere, and I need to find out what to do about it.

The effect is simple:
The Input Formatter looks at each line (optionally each frame) from the ADC and automatically adjusts the offsets, so the 3 channels are balanced.
It is a great basis to adjust colors to, to deliver the best possible color mixing that's true to the source.

[Iraito]

It was the damn mod chip...

The pin was untouched and there was no bridge, the cabling was a mess of this copper cables too. I lifted the pin, did the bridge and redid the cabling of the modchip, the picture is 100% stable and without any imperfection; what a night.

I will test the IF autoset tomorrow.

[rama]

Well, that's great that this issue is fixed!

Did you actually want the PAL encoding mod though?
Lifting pin 157 and bridging the encoder input to ground forces the encoder to use the PAL subcarrier clock at all times, even with NTSC titles.
The mod is used to get color for CVBS when playing NTSC games on a PAL console. It has no effect on an RGB picture (or none that I know of).

That said, even if you didn't actually want it, it shouldn't hurt either way.

[Iraito]

It looks perfect and stable, i'm fine with PAL60.

[Ryoandr]

Tested IF auto offset briefly, and I couldn't see anything wrong, nor spot any difference on and off to be honest.
Here is a video of it, first 2 attract loops have IF disabled, then the 2 following loops have IF enabled. Recorded in 720p60, and did not correct the aspect ratio flag so you can see more horizontal details.
https://www.youtube.com/watch?v=_yHRTLryXZA

If you think youtube compression gets in the way I can link you the original file.

One thing tho, how do you treat neogeo horizontal res ? Because, while used hres varies from game to game (majority being 304, a good number being 320, and some rare have less than 304 ; neogeo jingle screen is always 304 I think), the frame is still 320, so I usually have to do some shrinking and some hsleft adjust (which isn't saved) because green border appears.
Note that it's really minor nitpicking at this point, a few clicks for fixing isn't the end of the world

[Iraito]

I tested it too, it looks identical and gives me no issue whatsoever.

[rama]

I can spot the difference in the color mixing

Okay, I'm mainly interested in hearing whether or not it works without obvious glitches, and here it looks fine.
The capture is pretty nice, too.
Too bad my work TFT has the worst color performance possible.
I hope the capture shows the all white screens as mostly white for you :p

About the Neo Geo horizontal resolution, I don't know nor care about it, as with any other scaler.
The information of how many pixels are in a line is simply lost after the signal leaves the console.
The Neo Geo has that far off spec vertical refresh, right?
I assume what's happening is that the HTotal routine needs to adjust too far, moving invalid data into the view frame.
I'm always working on that, so it should be fixed some day or another :p

[Ryoandr]

It's MVS that is quite far at 59.19, home AES has a slightly different main crystal that makes refresh 59.60.

[rama]

59.6 is unusual but should not be an issue for the auto adjust.
So I guess the problem is with the size adjustment / shrinking.
Are you modifying the scaling factor for that?
I don't really recommend changing horizontal scaling, if it can be avoided.
It's preferable to just move the picture, cutting off pixels to the left and right for magnification and keeping the image centered with boarders for minification.

[Ryoandr]

320 games get quite cut left and right, so yeah I do have to do some horizontal shrink.

[rama]

Weird.
I managed to support the very wide maximum active video of a PS2, and I can't imagine a system using even more than that.
Not really sure what's going on there, but it's probably somehow related to the system being so close to arcade hardware.

[maxtherabbit]

iirc the front and back porches on MVS are pretty disproportionate, that could be throwing something off

[Ryoandr]

some things I've found searching around
http://raster.effect.free.fr/15khz/mode ... _15khz.png

and also found a theory that 384 htotal is a little short for reliably display a 320 frame. MD uses 420 comparatively for its 320 mode.

[rama]

Hm, that looks pretty standard, if tight. The h-active to h-blank pixels have the right proportions.
I would go with ratios like that when creating output presets, and I try to support this kind of ratio source in full.

So there's some other detail. I kind of suspect that it's the sampling clock I chose for 263 line @ 60 / "NTSC".
This is the part of not knowing what the source pixel count is.
My approach is to try and sample as many times as possible, while:
- producing an output stream that can be processed within the hardware limitations (FIFO length)
- selecting an H-PLL clock that aligns well with popular source resolutions
- making sure that clock is stable on poorer GBS designs
- making sure that the resulting stream scales well to a "slot" on the output formatter / VDS
- etc pp, more details :p

And here I think the Neo Geo does something unusual that doesn't work well with that approach.
I don't know what it is, and I think I really need the actual system to find it out.
Until then, please keep trying tricks to work around the issues you get! :p

[donluca]

Are we talking Neo Geo MVS (arcade board) or AES (home console)?

[Iraito]

Since i'm still waiting for the PSU, i tried something that usually audiophiles do to eliminate noise, i took a battery, created a usb to round connector and powered the GBS directly with the battery, i still get the moire effect. Shouldn't that be impossible ?

[rama]

Need to see some good pictures.

[Iraito]

https://streamable.com/4a2ta

[rama]

Nice example of this!
This is chroma dot crawl, from sending CVBS down a cable for sync.
The high frequency chroma radiates into the RGB lines whenever shielding isn't sufficient or on connectors.
You can't fix this on the GBS, as it happens before reaching the inputs.

But you can fix this by either using CSync from the source (mod on the PSX, for example), or by using Luma for sync.
Another solution is to find a high quality cable.

[Iraito]

I'm happy to hear that, can you give me a link for the modding\solutions ? i can mod the cable\console if needed.

[rama]

Just done looking it up again. It's all in this thread :p

For 7502 (9002 and 7002 should be similar. If the trace layout looks the same, it probably is the same)
viewtopic.php?p=1341006#p1341006

For 1002
viewtopic.php?p=1338447#p1338447

[Iraito]

Excellent! it doesn't look too hard, thank you

I also remember you telling me something about PAL consoles and sync on luma, is this something i can try before modding the console ?

[rama]

For Luma sync you need to modify either the cable on the console end, or mod the console.
If you do the console, I'd go with CSync directly. (But of course any mod disables CVBS, in case you want that later.)

The CSync mod is maybe a little hard, due to the tiny components.
No issue if you have experience, but if you're unsure, there are simpler modifications.

[Iraito]

I have quite a decent amount of experience with soldering etc. this mod looks as hard as the saturn switch without the pin lift, if i need to i can pull it off.

How should i modify the cable on the console end ?

[rama]

I don't recommend this. The console end plugs aren't made to be opened and reconfigured.
But if you want to, just remove the CVBS cable from its pin and solder it to the PSX Luma pin.
Sometimes there's no pin installed for signals the cable doesn't use.
You have to move the entire CVBS pin over to the Luma position then.

It's much easier to do a console mod

[maxtherabbit]

I don't recommend this. The console end plugs aren't made to be opened and reconfigured.
But if you want to, just remove the CVBS cable from its pin and solder it to the PSX Luma pin.
Sometimes there's no pin installed for signals the cable doesn't use.
You have to move the entire CVBS pin over to the Luma position then.

It's much easier to do a console mod

+1

if you don't want to delete CVBS, just buy a different RGB cable with sync on luma - get a nice 75ohm coax one and it will be an upgrade anyway

[rama]

And + 1 to that.

The dot crawl from the current cable looks like the cable should be upgraded in any case.
I know things are kind of expensive, but quality cables simply aren't mass produced anymore (sadly).

[rama]

.. Which is another reason I'd like to look into Component cables more.
I think they're quite a bit easier to DIY, with just 3 signals instead of 4.
It "just" needs to have CSync added onto the green line, where it would fall onto the blanking area anyway.
Something like a diode could be all that's required, maybe.

I can then modify the YUV input to treat the signal as RGsB, and we would additionally benefit from the nicer stock YUV signal path on each GBS.

Just an idea atm :p