Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

The place for all discussion on gaming hardware
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

Well, your measurements already completely shed any doubt that both HSync flanks are skewed by a large amount.
There isn't much you can do with this condition.
If the H-PLL could lock to the new position within VBlank, you may get some kind of a picture, at best :/

If you want to try this route:
While watching the image quality / stability, lower the H-PLL charge pump current + gain until
you either start getting it working, or totally loose any lock.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Yeah, it might be a desperate endeavour I'm afraid :?

Will try your suggestion and a few other things in a bit.
With gain you mean VCO gain, right? (everything in the "H-PLL Control" register)

The TVP registers "HSYNC Output Width", "HSYNC Output Start" and "VSYNC Alignment" come to mind as well.
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

Yep, the keywords are H-PLL, VCO, together with gain and charge pump current (or icp).
This basically controls the H-PLL bandwith.

The output parameters shouldn't affect this problem, but it won't hurt to test them.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Alright, some progress :)

Starting with 0xf8, decreasing the H-PLL control register in steps of 8 did not lead to any notable improvements by itself.
I then proceeded to fiddle with H.samplerate again; it does make it worse after 1250, so I didn't go much further than that previously. But to my surprise, there's another "good" region roughly between 1380 and 1420.
1409 is the sweetspot in my setup, it's a notable improvement over the previous result which used 1250, I'm sure the exact value could differ depending on the PCB and supergun however.

Unfortunately, the image was not at all stable, cutting off constantly. I looped through the H-PLL control register again and found one value which manages to stabilize it: 0xc8.
I also looped through HSOUTSTART, HSOUTWIDTH and VSOUTALIGN (0x0..0xff), which had no notable effect.

With H.backporch at 10 and sampling phase at 168 deg, this is the new result.
It looks like the shimmering (when the game scrolls) could be evened out via sampling phase, but it cannot.
The pixel dither while being much weaker is still there, as are the "waves" at the upper edge, so it still doesn't look particularly edifying..
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

Would you try 0x60 or so?
With C8 you have maximum gain and almost minimum ICP.
The waves you get are from the weak charge pump current, by the way, but you'll have to go with anything that allows the H-PLL to lock after the VSync desaster.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

0x60 leads to an image being shown only for a split second, every few seconds (for H.samplerates 1409/1250/431) - if you blink you could miss it.
For the last post, I already went through all possible values; none facilitate a stable image for samplerates other than 1250, except 0xc8. Most even lead to the red LED being lit and my monitor quitting with "no signal".
For 1250, there are a few more values that produce a stable image.
(all H.samplerates are to be read as sweetspots at the center of a small range of "better" values)

You're right that charge pump current and gain affect the "waves". 0x50 for example completely straightens the image and the waves are gone, but the image is again missing in action most of the time. Goes without saying that that's worse than the waves.
Here's a still frame from a video showing that the waves are completely gone:
Spoiler
Image
I've found that 0xc8 even manages to deliver an intermittent image for H.samplerate=439 (which I did not achieve before) which looks even better than the 1409 linked in the post above (probably how it would look, barring the waves, had the game a good sync signal like e.g. Tatsujin Oh). If only there was a way to stabilize it...
Spoiler
Image
It's unpredictable when the image appears, so I couldn't manage to show the same scene as I did up until now. For the same reason, it's sharper in reality than here, as the camera didn't have time to adjust to the sudden flash.


Some random unsorted thoughts:
I've been thinking about a circuit that would buffer sync and the colors for a certain amount of time in the μs magnitude, i.e. implement a look-ahead from the viewpoint of the sink. That would give it the time to correct certain malformations a sync signal can have. You would select yourself which problem should be accounted for, meaning you would select between something like (Passthru, Taito F3, Master System, ToaplanV2, and so forth). The size of the buffer would have to vary depending on the sync problem that is to be corrected. I cannot imagine that this would require a particularly complex logic. For ToaplanV2, my impression is that it's already quite obvious what would have to be done.

I think it would be best designed as a standalone device such that the number of source x sink combinations it could cover is maximized. A counter argument would be to simply use a buffered scaler that's known to be compatible, but seeing that these could simply not be available (anymore) or be too expensive, I think an (open source!) standalone device would be the logical conclusion. This could get rid of so much pain we have in the analog video realm (especially for arcade). Paired with a voltage level control circuit, it would even moreso become a sorely needed accessory. Unfortunately, I lack the background to design such a device or even evaluate the idea of it competently. I've seen rudiments of it, but nothing that's dedicated to this problem and solves it comprehensively.

Is it outrageous? Is it soaked in misconceptions? :P
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

One potential route with OSSC would be hooking video / DAC clock from the PCB to EXT_CLK pin of TVP7002. That would fix sampling, but then clock & sync generation via FPGA would get more complicated. Depending on how many pixels are on the normal lines and on the short one, a suitable output mode and FPGA PLL setting might be found. Then again, the process involves some HW modification and firmware customization so it wouldn't be an universal solution.

Sync and RGB could be buffered and reprocessed by external circuitry, but I'm afraid that making it both robust and universal (and inexpensive) would be quite a challenge.
thchardcore
Posts: 481
Joined: Wed Jun 22, 2005 9:20 am
Location: Liberal cesspool

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by thchardcore »

6t8k wrote:0x60 leads to an image being shown only for a split second, every few seconds (for H.samplerates 1409/1250/431) - if you blink you could miss it.
For the last post, I already went through all possible values; none facilitate a stable image for samplerates other than 1250, except 0xc8. Most even lead to the red LED being lit and my monitor quitting with "no signal".
For 1250, there are a few more values that produce a stable image.
(all H.samplerates are to be read as sweetspots at the center of a small range of "better" values)

You're right that charge pump current and gain affect the "waves". 0x50 for example completely straightens the image and the waves are gone, but the image is again missing in action most of the time. Goes without saying that that's worse than the waves.
Here's a still frame from a video showing that the waves are completely gone:
Spoiler
Image
I've found that 0xc8 even manages to deliver an intermittent image for H.samplerate=439 (which I did not achieve before) which looks even better than the 1409 linked in the post above (probably how it would look, barring the waves, had the game a good sync signal like e.g. Tatsujin Oh). If only there was a way to stabilize it...
Spoiler
Image
It's unpredictable when the image appears, so I couldn't manage to show the same scene as I did up until now. For the same reason, it's sharper in reality than here, as the camera didn't have time to adjust to the sudden flash.


Some random unsorted thoughts:
I've been thinking about a circuit that would buffer sync and the colors for a certain amount of time in the μs magnitude, i.e. implement a look-ahead from the viewpoint of the sink. That would give it the time to correct certain malformations a sync signal can have. You would select yourself which problem should be accounted for, meaning you would select between something like (Passthru, Taito F3, Master System, ToaplanV2, and so forth). The size of the buffer would have to vary depending on the sync problem that is to be corrected. I cannot imagine that this would require a particularly complex logic. For ToaplanV2, my impression is that it's already quite obvious what would have to be done.

I think it would be best designed as a standalone device such that the number of source x sink combinations it could cover is maximized. A counter argument would be to simply use a buffered scaler that's known to be compatible, but seeing that these could simply not be available (anymore) or be too expensive, I think an (open source!) standalone device would be the logical conclusion. This could get rid of so much pain we have in the analog video realm (especially for arcade). Paired with a voltage level control circuit, it would even moreso become a sorely needed accessory. Unfortunately, I lack the background to design such a device or even evaluate the idea of it competently. I've seen rudiments of it, but nothing that's dedicated to this problem and solves it comprehensively.

Is it outrageous? Is it soaked in misconceptions? :P
There is a man designing a scaler called the A1. He apparently is making an arcade based line doubler focused on compatibility. I am curious to what extent he considered these boards.
A camel is a horse designed by a committee
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

^ Ah, was not aware of that project - this must be it, right? https://irkenlabs.com/retro-scaler-a1/introduction

First few thoughts:
• It does not output digital video, or am I just overlooking it?
• As a fully fledged scaler, it would kind of replace the OSSC and the like. I was more thinking of something more specialized that would enable us to get more out of our existing devices.

Nonetheless interesting and will keep track of it, so thanks for the mention!
marqs wrote:One potential route with OSSC would be hooking video / DAC clock from the PCB to EXT_CLK pin of TVP7002. That would fix sampling, but then clock & sync generation via FPGA would get more complicated. Depending on how many pixels are on the normal lines and on the short one, a suitable output mode and FPGA PLL setting might be found. Then again, the process involves some HW modification and firmware customization so it wouldn't be an universal solution.

Sync and RGB could be buffered and reprocessed by external circuitry, but I'm afraid that making it both robust and universal (and inexpensive) would be quite a challenge.
Thank you for the suggestion - that would be one enterprising option (and maybe solution) for sure!

Well i'm aware a device catering to the above idea probably wouldn't be very cheap - to demand it being robust, universal and inexpensive in the same breath would sound a bit arrogating for sure. I was more expressing a wish for a sustainable solution, the price/performance ratio of which doesn't get (that much) worse over time, when supply gets scarce. I'm sure this could be obviated depending on the approach (compare e.g. OSSC and Framemeister) :)



As for a pure software OSSC solution, since we're seeing diminishing returns now, and it feels like a satisfying result will stay out of reach, I think I might now reduce efforts on this end. Unless there are some new groundbreaking ideas, I'd like to focus on more promising hardware solutions now (although I feel like I can't contribute as much to that myself). Assuring that I went into the analysis in an open-ended way, notwithstanding that it was kind of foreseen, this would be a perfectly acceptable (albeit sobering) result.
At least we've been documenting pretty obscure yet potentially useful stuff for years to come :P

I've already exhausted all settings that are accessible via OSD (in combination with the TVP registers that I've checked until now).
As for the registers, I feel like I went through the low hanging fruit by now. Are there any more that could be worth a try?
Maybe the H-PLL Feedback Divider or VBLK Field-related registers?
mikejmoffitt wrote:I do have a Ghox on loan and can try it.
Feel free to go ahead (in before you have to return it!)
Last edited by 6t8k on Wed Nov 27, 2019 7:14 pm, edited 2 times in total.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by Xyga »

Dunno, reverse-engineer the XRGB-2's AFC and see if that can fit somewhere in an improved version lol.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

The inherent problem with an universal solution (which doesn't extract signals outside of standard JAMMA/AV connector) is that sampling clock is generated from hsync. With such skews/irregularities, the same clock is no good for generating stable output pixel clock. You have to then generate pixel clock independently and either a) keep it framelocked to avoid latency (not easy, but possible) b) take the easy route and use triple buffering. The first option needs dynamically adjustable clock generator but little memory while the second one needs some memory but only simple clock circuitry.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by Xyga »

Well the XRGB-2 sure is pretty unique even if outdated. Still personally I like universal and generic solutions, I understand they're harder to do right tho.

PS: how about a sync plug-in in OSSC v2 ? :mrgreen:
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

Xyga wrote:Well the XRGB-2 sure is pretty unique even if outdated. Still personally I like universal and generic solutions, I understand they're harder to do right tho.
Has anyone tried connecting these boards via XRGB-2 -> OSSC chain to a monitor that has very little tolerance to TMDS clock variation (e.g. does not accept SNES without de-jitter mod)? The point is to get some insight whether XRGB-2's output sync has jitter that is just attennuated (could be good enough for many displays) or if sync is fully regenerated.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by Xyga »

Er...no never tried that, not sure I have the required display here but I will check tomorrow anyway.
I'm afraid all those I have here are pretty tolerant in that area.
IIRC the Sony W6 was a bitch so maybe I could try with it (it's at my old people's place now tho so later)
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by Xyga »

So I've tried, with both the XRGB-2 and th DISPL...

All I could do is passthrough the XRGB-2, resulting in the whole picture to be wobbly, and I can't use the AFC anymore to correct the flagging or I lose the picture.

¯\(°_o)/¯
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by mikejmoffitt »

I do have to ask... why does the MS9 not have these problems? The usual throwaway answer is "oh it's a CRT of course" but that doesn't really mean anything. It still has to detect a valid sync edge and act upon it; being a CRT doesn't magically imply a functioning filter.

What does the MS9 do for sync processing and edge detection?
Image
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

It's probably simply that it doesn't rely on a PLL for clock recovery and / or general sync processing.
The CRT will simply use even a skewed HSync such as this.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

And I (stubbornly) went through the remaining, above-mentioned TVP registers, to no avail, now concluding for the time being.
marqs wrote:The inherent problem with an universal solution (which doesn't extract signals outside of standard JAMMA/AV connector) is that sampling clock is generated from hsync. With such skews/irregularities, the same clock is no good for generating stable output pixel clock. You have to then generate pixel clock independently and either a) keep it framelocked to avoid latency (not easy, but possible) b) take the easy route and use triple buffering. The first option needs dynamically adjustable clock generator but little memory while the second one needs some memory but only simple clock circuitry.
While the Framemeister would be a type b solution, a type a solution would be the cps2_digiav, if I'm not mistaken.

So would you support the idea that instead of specifically trying to rectify sync on the fly, going with one of the these two approaches would be more sound?
While nothing can recover information that isn't there in the signal, I was assuming something akin to a fixed (per-source) correction matrix could perhaps do the job, as ideal (design intended) video/hardware parameters are, or can be known.
But thinking over it, with all the quirks of the analog and the plethora of different source device (sub-)revisions that could have different characteristics, I'm probably underestimating it.
rama
Posts: 1373
Joined: Wed Mar 08, 2017 3:15 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by rama »

If you're really lucky, the timer generator on the arcade board is configurable.
This would go well with the fact that other games using the same chipset don't have the problem.
Are there schematics / pinouts to guess pin functions from? :p
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

If possible, that would be cool indeed.

We briefly addressed this route here.
I left with the question whether it is at least controllable by the game ROMs themselves; it seems implicated, but there could of course be more to it.
It's kinda stretching my abilities to look further into it, at least I would need much more time etc.

As for schematics, of what I know the Knucke Bash ones linked earlier are what comes closest .
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by Xyga »

rama wrote:It's probably simply that it doesn't rely on a PLL for clock recovery and / or general sync processing.
The CRT will simply use even a skewed HSync such as this.
Sorry if I'm being redundant here, but I remember seeing the phenomenon happen on a CRT too, that was a cabinet and the owner had to adjust directly on the chassis (don't remember the cabinet details sorry)
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

6t8k wrote:While the Framemeister would be a type b solution, a type a solution would be the cps2_digiav, if I'm not mistaken.
I think Framemeister could be both depending on its framelock setting. As for cps2_digiav, it's not exactly option a as it uses board's video clock instead of an unrelated clock source.
6t8k wrote:So would you support the idea that instead of specifically trying to rectify sync on the fly, going with one of the these two approaches would be more sound?
Simple sync rectification will only help with certain displays at best as you can see from Xyga's test results - the sync would need to be generated from scratch with video data aligned to it for best compatibility. Even if the sync generation could be made with relatively simple HW, the video alignment part would need ADC+DAC which would increase cost and complexity possibly beyond what makes sense for a box-in-between type of device. That's why I think the functionality would be best integrated on either end (arcade PCB or scaler) when possible.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

^ Again thanks for the valuable insight (about cps2_digiav, I somehow managed to lose sight of that aspect again).

Note to myself in the future: check which PCBs have a "vertical line counter" circuit just like Knuckle Bash does. I have an idea.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by marqs »

Tried to scout the listed PCBs but could only find Teki Paki at decent price, and it's yet not known whether that has deranged sync or not. I'll keep an eye on these for a while but if that doesn't work out, then I might consider doing cps2_digiav install for someone else's board.
thchardcore
Posts: 481
Joined: Wed Jun 22, 2005 9:20 am
Location: Liberal cesspool

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by thchardcore »

Thank you for the update and would be happy to donate towards this cause.
A camel is a horse designed by a committee
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Exciting!

shmupsrocks, could you maybe add the list at the bottom of this post to your initial post? Seems it would get a bit buried otherwise.
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by mikejmoffitt »

Finally got access to my capture hardware again... so maybe I can actually get data now.
Image
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by 6t8k »

Found this in the MAME source the other day.

What's notable is that all games known to have the sync problem (up until now), write the same values to the 0Eh scroll register of the first GP9001 (0202, 0203, 4200).
This could indicate that Knucke Bash and Snow Bros. 2, which we don't have empirical info about so far, would be bad as well.

Of the games known to be working, Truxton 2 and Pipi & Bibis are listed. Both write the same values, which are different from the above, "OSSC incompatible" ones.
shmupsrocks
Posts: 597
Joined: Mon Aug 13, 2018 3:53 pm

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by shmupsrocks »

6t8k wrote:shmupsrocks, could you maybe add the list at the bottom of this post to your initial post? Seems it would get a bit buried otherwise.
Good idea, done.
XtraSmiley
Posts: 622
Joined: Fri Apr 20, 2018 9:22 am
Location: Washigton DC

Re: Dogyuun, Batsugun, Fixeight, V-V incompatible with OSSC

Post by XtraSmiley »

6t8k wrote:Found this in the MAME source the other day.

What's notable is that all games known to have the sync problem (up until now), write the same values to the 0Eh scroll register of the first GP9001 (0202, 0203, 4200).
This could indicate that Knucke Bash and Snow Bros. 2, which we don't have empirical info about so far, would be bad as well.

Of the games known to be working, Truxton 2 and Pipi & Bibis are listed. Both write the same values, which are different from the above, "OSSC incompatible" ones.
I have two Knuckle Bash PCBs (Japanes and Korean) and a Snow Bros. 2 on the way from overseas. I'd be happy to test, but I'd need some info on what you're looking for exactly. As I posted before, I think my Outzone works with my HAS to an OSSC... but maybe I was crazy before.
Post Reply