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

The place for all discussion on gaming hardware
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 »

marqs wrote:Finally received my Knuckle Bash board and can confirm the issue. Didn't get a stable sync out of OSSC while OSSC Pro prototype managed to keep sync but with skew on top 20% of the picture. I suppose the only way to handle these boards via digitization would be using external sampling clock and frame synchronization. I'll be looking into cps2_digiav integration sometime soon.
Cool!

So it's the ISL51002 by itself that already manages to elicit the skewed picture and you didn't use the Si5351C yet? Is the rest of the image clear? This looks promising.
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 »

marqs wrote:Finally received my Knuckle Bash board and can confirm the issue. Didn't get a stable sync out of OSSC while OSSC Pro prototype managed to keep sync but with skew on top 20% of the picture. I suppose the only way to handle these boards via digitization would be using external sampling clock and frame synchronization. I'll be looking into cps2_digiav integration sometime soon.
Awesome, but you're speaking French to me, does this mean you may have a solution for OSSC Pro?
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:So it's the ISL51002 by itself that already manages to elicit the skewed picture and you didn't use the Si5351C yet? Is the rest of the image clear? This looks promising.
The clock from ISL51002's DPLL goes to Si5351C which means that both PLLs are able to stay in lock. The output clock is not still ideal due to the sync irregularity, and my other monitor only accepts the signal up to 720p. The image itself is perfectly clear and stable, even in the skewed part.
XtraSmiley wrote:
marqs wrote:Finally received my Knuckle Bash board and can confirm the issue. Didn't get a stable sync out of OSSC while OSSC Pro prototype managed to keep sync but with skew on top 20% of the picture. I suppose the only way to handle these boards via
digitization would be using external sampling clock and frame synchronization. I'll be looking into cps2_digiav integration sometime soon.
Awesome, but you're speaking French to me, does this mean you may have a solution for OSSC Pro?
External sampling clock is possible with Pro, but the output is then not framelocked.
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 »

marqs: thinking aloud for a moment for my understanding.(guided again by this seminal issue):

With external sampling clock, you're referring to using the ISL51002's EXTCLK_IN pin and feeding it with a signal generated by the Si5351C (not by something external to the Pro), is that right as a first approximation? If we start tapping into the arcade PCB's video clock and do the rest via OSSC (Pro), we're not that far from cps2_digiav and might as well just go that route (which we'll already explore anyway), right? So that's just why I'm assuming the above, since there'd be more to gain for most users in refining the usual OSSC Pro<-Jamma RGBS scenario.

So for that, my mental model currently is a subtle custom logic, bootstrapped by ISL51002 sync processing/DPLL output, driving the Si5351C, that can then generate a suitable clock despite Toaplan V2's sync quirk – specifically by compensating for the first malformed line somehow. To do this, we'd most certainly need to go non-framelocked, resulting in the need for the picture to be buffered, in turn resulting in some nontrivial lag penalty and/or possibly some tearing/stuttering.

I'm still missing a few puzzle pieces to understand why exactly this would be the consequence; possibly it's just because the aforementioned "subtle logic" would not be able to keep up otherwise. Not sure if it could be possible to generate a suitable clock once and then stick with it, or something to this extent, to avoid the need for buffering, perhaps it is. As for the circumstances under which such a specific mode would be activated, I'm still imagining this as an open question currently; as the quirk is quite idiosyncratic it could possibly be auto-detected (I'm suspecting the Framemeister is doing this), or user-set for best safety.

If any of this is iffy (schematics aren't even up yet), feel free to correct/amend.
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:With external sampling clock, you're referring to using the ISL51002's EXTCLK_IN pin and feeding it with a signal generated by the Si5351C (not by something external to the Pro), is that right as a first approximation?
Yes, the sampling clock in this scenario would come from Si5351C which generates it from a fixed-frequency clock source.
6t8k wrote:So for that, my mental model currently is a subtle custom logic, bootstrapped by ISL51002 sync processing/DPLL output, driving the Si5351C, that can then generate a suitable clock despite Toaplan V2's sync quirk – specifically by compensating for the first malformed line somehow. To do this, we'd most certainly need to go non-framelocked, resulting in the need for the picture to be buffered, in turn resulting in some nontrivial lag penalty and/or possibly some tearing/stuttering.
Output pixel clock is then also generated similarly by Si5351C, and its frequency and H/V timings are selected so that the resulting refresh rate is as close to Toaplan V2's output as possible to minimize frame drop/duplication. This way neither sampling or output clock stability is affected by the sync glitch.
6t8k wrote:Not sure if it could be possible to generate a suitable clock once and then stick with it, or something to this extent, to avoid the need for buffering, perhaps it is. As for the circumstances under which such a specific mode would be activated, I'm still imagining this as an open question currently; as the quirk is quite idiosyncratic it could possibly be auto-detected (I'm suspecting the Framemeister is doing this), or user-set for best safety.
Ideally the output clock should track the input refresh rate, but that's not simple when the clock is not derived from hsync. I think the digitizer IC in Framemeister uses similar async sampling and frame synchronization as discussed here - its output is skew-free but the refresh rate was 59.7Hz in my test (auto sync mode) so it's definitely not framelocked either.
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 »

Thank you, this was very reassuring. Now I'm certain it's going to work!

Yes, the Framemeister was never capable of framelocked operation ^^" I should've worded that better; with that last bit I wanted to refer to all of the above.

I'm suspecting the Framemeister is not constantly deliberately correcting for sync problems like Toaplan V2, only when it detects problems in sampling the signal without applying that step. I assume that this would otherwise be detrimental for all other sources. So I'm imagining that this would perhaps likewise be an optional, small layer/detour on the Pro's processing pipeline (regardless if set in action automatically or not), assuming the presupposition is appropriate.
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 »

A preliminary port of cps2_digiav firmware is now running on Knuckle Bash PCB. Installation of the mod board was relatively simple and it now provides a stable output from 240p to 1920x1440, proving the concept works. To get the firmware support other Toaplan V2 boards too, I'd need to know the number of VCLK (13.5MHz) cycles per frame. For example, that's 263*864+68=227300 for Knuckle Bash and I suppose it's a common number (262*864 maybe?) for all the non-problematic boards.
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 »

Top notch, measurements following soon :)
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 »

Firmware and documentation for the Toaplan2 port are now available here.
User avatar
ShootTheCore
Posts: 52
Joined: Wed Jan 18, 2017 12:20 am

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

Post by ShootTheCore »

Awesome and exciting to be able to add digital HDMI to the Toaplan 2 boards!

Will this work feed back into making the OSSC Pro compatible with unmodded T2 boards through a SuperGun? Or is modding each board individually inevitable?
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 »

marqs wrote:Firmware and documentation for the Toaplan2 port are now available here.
Hi Marqs - So if I install one of these on Toaplan V2 board, would I be able to output at 640x480 with scanlines and send to a VGA CRT (via HDMI to VGA adapter)?
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 »

@marqs:
V-V (OSSC-incompatible):
16837034ns Vsync period / (1/0.0135ns VCLK period) = 227299.959 VCLK cycles ≙ 263*864+68.

Dogyuun (OSSC-incompatible):
16836885ns Vsync period / (1/0.0135ns VCLK period) = 227297.9475 VCLK cycles ≙ 263*864+68.

Tatsujin Oh (OSSC-compatible):
16831952ns Vsync period / (1/0.0135ns VCLK period) = 227231.352 VCLK cycles ≙ 263*864.

Mahou Daisakusen (OSSC-compatible)
16831968ns Vsync period / (1/0.0135ns VCLK period) = 227231.568 VCLK cycles ≙ 263*864.

That's all Toaplan V2 PCBs I can test. I verified all have exactly 13.5Mhz VCLK frequency.
Tally: 227300 - 227232 = 68 VCLK cycles ≙ 5046ns sync quirk / (1/0.0135ns VCLK period) = 68.121 VCLK cycles

I think it should be a safe bet to assume that all incompatible games have 227300 and all compatible ones 227232.

@ShootTheCore: Even disregarding cps2_digiav, there's a good chance the Pro will be compatible with unmodified boards, since it'll have an external programmable clock generator and will be able to buffer whole frames. With these two ingredients, the sync irregularity could be ironed out eventually.

@thchardcore: that should be no problem.
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 »

ShootTheCore wrote:Will this work feed back into making the OSSC Pro compatible with unmodded T2 boards through a SuperGun? Or is modding each board individually inevitable?
OSSC Pro has multiple ways to handle these kind sources with irregular sync. The best option still involves tapping VCLK from the board to GPIO connector. With other methods it may not be possible to achieve framelock even though otherwise everything should work fine.
thchardcore wrote:So if I install one of these on Toaplan V2 board, would I be able to output at 640x480 with scanlines and send to a VGA CRT (via HDMI to VGA adapter)?
Yes, that's what 480p_CRT mode is for. Scanlines are not yet implemented on the linked fw, though, but will be later.
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 »

@marqs: with CPS2, this is relatively convenient and hidden away, but how did you attach the add-on board in this case? :)
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:@marqs: with CPS2, this is relatively convenient and hidden away, but how did you attach the add-on board in this case? :)
That shown in the installation guide.
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 »

Duh ;) Thanks!

Will report back here when I get the chance to try this out :)
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:I think it should be a safe bet to assume that all incompatible games have 227300 and all compatible ones 227232.
The firmware is now updated to support both, hopefully it covers all Toaplan V2 boards.
User avatar
Nebula
Posts: 31
Joined: Fri Nov 18, 2016 7:15 pm
Location: Asturias,Spain

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

Post by Nebula »

6t8k wrote:@marqs:
V-V (OSSC-incompatible):
16837034ns Vsync period / (1/0.0135ns VCLK period) = 227299.959 VCLK cycles ≙ 263*864+68.

Dogyuun (OSSC-incompatible):
16836885ns Vsync period / (1/0.0135ns VCLK period) = 227297.9475 VCLK cycles ≙ 263*864+68.

Tatsujin Oh (OSSC-compatible):
16831952ns Vsync period / (1/0.0135ns VCLK period) = 227231.352 VCLK cycles ≙ 263*864.

Mahou Daisakusen (OSSC-compatible)
16831968ns Vsync period / (1/0.0135ns VCLK period) = 227231.568 VCLK cycles ≙ 263*864.

That's all Toaplan V2 PCBs I can test. I verified all have exactly 13.5Mhz VCLK frequency.
Tally: 227300 - 227232 = 68 VCLK cycles ≙ 5046ns sync quirk / (1/0.0135ns VCLK period) = 68.121 VCLK cycles

I think it should be a safe bet to assume that all incompatible games have 227300 and all compatible ones 227232.
Sorry if these sound as dumb questions but according to MAME driver, Toaplan V2 hardware has a total video size of 262 scanlines and 432 “pixels” per line. Then:

- Why is it considered that there are twice (864) "pixels" per line? Maybe the clock used to trigger the latches in the output RAMDAC (they are always a pair of 74LS273) is down to a half of its frequency? (6.75MHz)
- Why are “263” lines per frame instead of 262?

Perhaps the video specifications in MAME are not fully accurate...

Just want to know how exactly Toaplan pcbs are working in the video output stage :)
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 »

No, good questions!
sergiopolog wrote:- Why is it considered that there are twice (864) "pixels" per line? Maybe the clock used to trigger the latches in the output RAMDAC (they are always a pair of 74LS273) is down to a half of its frequency? (6.75MHz)
The 13.5MHz clock I measured is pin 218 from GP9001 ("GCUCLK" according to Knuckle Bash schematics), and as as you correctly say, only half the frequency reaches DAC stage (pin 11 of each 74LS273), where it is called "DCLK". So there are not actually 864 "pixels" per line, but 432 :)

One can nicely see that this is correct if one takes the game's test pattern as a reference (V-V in this case)..
Spoiler
Image
..and juxtaposes that with the look of a scanline on the oscilloscope:
Spoiler
Image
Channel 1 is green video, channel 2 is GCUCLK, channel 3 is Csync.
What we see here is: a little bit of green, no green, a little bit of green, no green, then 100% for: 148ns, 296ns (x3), followed in shorter succession by another 100% for 148ns.
This is the end of a scanline that we can see within the upper half of the CRT photo.

The CRT is not correctly calibrated, but if we inspect the white grid's horizontal bars, we can see that these extend across two scanlines. This being a test pattern, we can assume that the vertical bars are supposed to be just as wide. There are no pixels in analog video, we are looking at their analog representations. Nevertheless, because the red square ends amidst a vertical bar, we can reason that the thin white portion after that is supposed to have the width of the smallest unit of the game's internal resolution: one pixel.
If we now zoom in on the "pixel", we can see that, fittingly, 148ns is 2x GCUCLK period (two falling clock edges while green video is active):
Spoiler
Image
Taking a screenshot in MAME and activating a pixel grid when viewing the image confirms this.

864 is the number of needed samples per line; tapping DCLK for reference clock could also work in principle, but to reconstruct the digital signal with an ADC, the sampling rate has to be at least x2 the pixel clock (Nyquist rate), otherwise you lose information, so you'd have to multiply DCLK again. Conveniently - for the same reason, in fact - 13.5MHz is also what Rec. 601 standardized to sample 480i with. I'd guess that, to keep things simple, this is why cps2_digiav takes GCUCLK instead (please correct me if I'm wrong marqs).
sergiopolog wrote:- Why are “263” lines per frame instead of 262?
You can either drop half of a scanline or add another half to get from the initially standardized 480i to 240p (the latter being a clever "hack" of the former), so due to that (and because this necessarily lies within Vblank anyway), it does not really matter whether a 263th line is present or not. Thanks again to rama who brought that article to my attention earlier. :)

I'm quite sure 263 would be technically correct for Toaplan V2, 262 would contradict measurements across 4 games (which I've each double-checked). To arrive at 262 lines, I'd have needed to measure 16768000ns Vsync period for an OSSC-compatible game, meaning ~63952ns less, while all measurements lie within a 150ns window (normalized for sync quirk), so that's by no means a realistic error margin. But I haven't studied the MAME source enough to be able to say whether the difference matters there.
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 »

DCLK is gated by HSYNC (ref. GCU sheet on Knuckle Bash schematic) which makes it problematic to use in mode detection. I initially tried to use it as C2 clock since capture on FPGA would be straightforward (i.e. every rising edge), but then figured out you could not reliably detect hsync using that clock and also it would've probably been impossible to differentiate boards with varying sync characteristics. I then switched to using video clock (VCLK / GCUCLK) as FPGA capture clock which resolves these issues - RGB signal is captured as digital so sampling theory / reconstruction rules are not relevant here.
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 »

I see, thanks a lot for clearing that up marqs!

Edit: That's actually pretty cool that you can simply tap the RGB signal digitally there. The whole time I thought these resistor inputs represent the 3 5bpc colors in the analog realm, but did not really understand how this works. Examined these resistors on the scope now and read up on resistor ladders, it is actually surprisingly simple. Needless to say why suddenly do ADC, when the lossless way of constructing the digital image is of course the cps2_digiav's unique feature. Whoops :P Anyhow, as long as something is learned along the way, all is well.

By the way, did you get the chance to try the patch method with Knucke Bash (thus far still untested on real hardware)?
User avatar
Nebula
Posts: 31
Joined: Fri Nov 18, 2016 7:15 pm
Location: Asturias,Spain

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

Post by Nebula »

6t8k wrote:No, good questions!
Wow, thanks a lot for your detailed explanations. Now is totally clear for me. That "one-pixel-wide" example you took from the V-V crosshatch is perfect to understand the period of the D-CLK and GCUCLK.
6t8k wrote:You can either drop half of a scanline or add another half to get from the initially standardized 480i to 240p (the latter being a clever "hack" of the former), so due to that (and because this necessarily lies within Vblank anyway), it does not really matter whether a 263th line is present or not.
That also makes sense, and thank you for bringing the interesting read from that CSYNC article from hdretrovision.

What I still don't understand is why you say that adding the 263th line is a clever solution. If that line falls in the Vertical blanking time, what's the difference/benefit from it instead of removing it at all and left 262 lines?
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:By the way, did you get the chance to try the patch method with Knucke Bash (thus far still untested on real hardware)?
Not yet. I have a compatible OTP EPROM but it'll take a while until I'll get to the workshop which has a suitable programmer.
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 »

sergiopolog wrote:What I still don't understand is why you say that adding the 263th line is a clever solution. If that line falls in the Vertical blanking time, what's the difference/benefit from it instead of removing it at all and left 262 lines?
I was referring to (the way to get from 480i to) 240p as a clever solution – whether you as a game/console developer do that by outputting 262 or 263 total lines per frame doesn't matter. Of course it makes a small effective difference when said signal is displayed or digitized, but nowhere should that carry weight, I think. Other than that since I'm not really sure what you're left wondering about, → PM. :)
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 »

I have access to a Teki Paki now and confirmed that the sync quirk is absent, making it work with the OSSC without modification.

@shmupsrocks: could you update the table in the first post one last time? :)

Number of VCLK/GCUCLK cycles per frame:
16832022ns Vsync period / (1/0.0135ns VCLK period) = 227232.297 VCLK cycles ≙ 263*864


I also have a cps2_digiav and relevant parts on the way, so I'll be looking into trying this out with an OSSC-compatible game soon.

Edit (Jun 28, 2020):
cps2_digiav installation on Dogyuun
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 »

So it looks like Furrtek has decapped and imaged the GP9001 :D

Image
[1] [2]

Pour la science! Image
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 »

That's awesome news!

I realize that will help for emulation/MiSTer, but will it help us in this thread in some way?
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 »

Of practical value, with regards to this thread's issue, it could help the creation of program ROM patches for Batsugun and Dogyuun that don't affect the in-game graphics. Or conversely, lead to the discovery that this is not possible.

Nevertheless, for people who want to play the games that have broken sync, and/or don't want to patch their program ROM, by now there will be a decent number of options:

• Use an OSSC Pro
• Play the ports to modern consoles by M2 (incurs inevitable input latency penalty/might not be a complete substitute to some as opposed to original HW)
• Install a cps2_digiav (already possible)

I'm still interested in learning more about the chip's inner workings, however. What is the root cause of the sync anomaly? How does that initialization vector work that gets written to the 0x0e register when the game boots? How do two GP9001 chips interact with each other?

It may also become possible to develop a replica that can be put in place of the original IC. This could be aiding in preserving the original HW's working order, and in the course the opportunity could perhaps be used to iron out the uneven sync via small tweaks, so that a patch is not necessary.

In case a patch for Batsugun/Dogyuun becomes feasible, you'll be able to read about it here, but all further poking is only tangentially related to this thread, so I'll leave it open for now if or how much of that I'll post here myself.
Last edited by 6t8k on Fri Jul 03, 2020 4:30 pm, edited 1 time in total.
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 »

Awesome update.
A camel is a horse designed by a committee
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: I'm still interested in learning more about the chip's inner workings, however. What is the root cause of the sync anomaly? How does that initialization vector work that gets written to the 0x0e register when the game boots? How do two GP9001 chips interact with each other?

In case a patch for Batsugun/Dogyuun becomes feasible, you'll be able to read about it here, but all further poking is only tangentially related to this thread, so I'll leave it open for now if or how much of that I'll post here myself.
So, I just got a cool new game. Dogyuun. I excitedly opened the box and hooked up my OSSC to my new LG C9 OLED TV... nothing.

THEN, I remembered this thread. I was so focused on Fixeight and Knucklebash, I forgot the game that started this thread...DOGYUUN!!!!!!!

Damn. OK, so I can't even get a simple sync, even with a h.samplerate moved up.

A. Any progress on a patch?
B. So OSSC Pro will definitely fix this problem, right?
Post Reply