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

The place for all discussion on gaming hardware
User avatar
invzim
Posts: 45
Joined: Tue Jul 24, 2007 8:40 am
Location: https://irkenlabs.com/
Contact:

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

Post by invzim »

Unless I fudged up the patching, no dice - getting tile corruption :(
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 »

Ha, it's too good to be true apparently. Especially considering that 3 people had the same idea literally at the same time :D

Toaplan lovers: hey look! we could simply... Fate: what were you thinking Image :mrgreen:

Yeah, I can confirm that with Dogyuun. It looks exactly the same as my previous video capture.
I guess to see a positive side of it, it's the same instead of (completely) different behavior. So the chance grows that it's not a continuum, i.e. if we nail it, we actually nail it without having to worry about arcane spillover effects that aren't immediately apparent.
If that's really the case of course remains to be seen.

TL;DR: The only thing left is to understand how these byte sequences work, or, less preferably, devising a way of efficiently testing many values. Then we've won.

@sergiopolog: do you have a Teki Paki by any chance? You could check if it works with the OSSC, it's the only PCB we don't have empirical info about so far :)
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 sorry, that one along with Ghox are the pcbs that I don't have yet for this system :cry:
User avatar
parodius
Posts: 720
Joined: Wed Jan 26, 2005 5:54 am
Location: Singapore

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

Post by parodius »

6t8k wrote:Working patch for Knuckle Bash added and added a patch for Fixeight!
@parodius: can you try the latter? :)
Just did :

Code: Select all

$ sha1sum.exe tp-026-1.fixeight
56017cc2adeb2fdfd25a992bbf31605b18581865 *tp-026-1.fixeight
Unfortunately, it seems to change nothing at all... There's no graphics glitch like on Dogyuun/Batsugun, and the sync signal is still messed up in the same way as before.

6t8k wrote: Fixeight is an interesting special case, because it uses two different checksums (at 0xc0 and 0xc4), and it traverses the loop twice, one time checking against one checksum for even bytes and one time checking against the other checksum for odd bytes (ROM EVEN ERROR vs. ROM ODD ERROR). So basically everything is the same, it's just that you have to go through the process described above twice and change both checksums accordingly.

By the way, as per parodius' reportings, changing occurences #1 and #3 in Fixeight leads to a blank screen. I could confirm that these lock up the game even before the integrity check is called, so as suspected, #2 is the occurence to change.
Thanks for the explanations. Any idea what to try next for FixEight ? 8)
My sales thread : 2020/07/20..MASTER.VER.
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 »

@parodius: my bad, somehow the impression snuck in that the #3 occurence can't be changed without provoking the black screen - however, in contrast to #1, it can! Could you re-download and re-apply? :)

---
6t8k wrote:It's certainly possible that it would've been enough to change only one specific byte within that "configuration string" to achieve this.
Yes. I've tried a few variants for Dogyuun, not yet reaching both OSSC compatibility and sound graphics at the same time however. Here are the results:
Spoiler
(byte order on disk)

[0] (tried here)
0300, 0200, 0040 <- first controller
0212, 0312, 0052 <- second controller
Results: OSSC recognizes the signal, but game has graphical glitches, as can be seen in the video capture

[1] (tried here)
0300, 0200, 0040
0310, 0210, 0050
Results: like [0]

[A] (original values, but set the next-to rightmost bit to 0 akin to "OSSC compatible" values)
0202, 0302, 0040
0212, 0312, 0050
Results: like [0]

(original values, but swapped the first two words each because in "OSSC compatible" values, the 3 comes first)
0302, 0202, 0042
0312, 0212, 0052
Results: OSSC does not recognize the signal, but game is fine (like unpatched ROM)

[C] (A and B combined)
0302, 0202, 0040
0312, 0212, 0050
Results: did not try due to above results

[D] (original values, but set rightmost bit to 1 as a "compromise" between original values and A)
0202, 0302, 0041
0212, 0312, 0051
Results: OSSC recognizes the signal, but graphical glitches are much, much worse. almost everything is missing aside from backgrounds.

[E]
0203, 0303, 0043
0213, 0313, 0053
Results: OSSC does not recognize the signal AND completely broken graphics like [D]

[F]
0202, 0302, 0043
0212, 0312, 0053
Results: like [E]

[G]
0202, 0302, 0052
0212, 0312, 0062
Results: OSSC shows NO SYNC, graphics like [A], rolling image on CRT, Vsync pulse missing, Hsync alone is fine

[H]
0202, 0302, 0040
0212, 0312, 0052
Results: like [0]


0202, 0302, FF41
0212, 0312, FF51
Results: OSSC shows NO SYNC, no image on CRT, sync signal completely missing (both V and H components)


So the rightmost byte (order on disk) seems to be responsible...
Last edited by 6t8k on Mon Feb 03, 2020 12:17 am, edited 1 time in total.
User avatar
parodius
Posts: 720
Joined: Wed Jan 26, 2005 5:54 am
Location: Singapore

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

Post by parodius »

6t8k wrote:@parodius: my bad, somehow the impression snuck in that the #3 occurence can't be changed without provoking the black screen - however, in contrast to #1, it can! Could you re-download and re-apply? :)

Code: Select all

sha1sum.exe tp-026-1.fixeight
3763350f56af46477bc30e60274cb277f47cb4a9 *tp-026-1.fixeight
No dice, still the same.
My sales thread : 2020/07/20..MASTER.VER.
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 »

parodius: Hmm.. if it's the #1 occurence we may be out of luck for the time being. :?
Someone would have to step through the instructions to find out why changing the bytes there prevents the game from booting and see if something can be done to remedy that.

The only other possibility I can think of right now would be that Fixeight could (for some strange reason) use the values that are normally fed to the second GP9001, which are always stored adjacently even for games that have only one GP9001 like Fixeight does.
I'll create a corresponding patch shortly that you can try if it's not too much trouble at this point so we can rule that possibility out.
User avatar
parodius
Posts: 720
Joined: Wed Jan 26, 2005 5:54 am
Location: Singapore

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

Post by parodius »

No trouble at all.
My sales thread : 2020/07/20..MASTER.VER.
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 »

Revised the Fixeight patch, please retry.

I'm now quite sure though that the first occurence is the relevant one..

A few observations in regards to the black screen boot failure: it seems like there is another integrity check or something.
The failure is in fact triggered when any address between 0x100..0x70EE is modified. All bytes within that range are processed and afterwards, an infinite loop waits until 0xFF appears at 0x28F001, which is memory shared with the V25 audio CPU I suppose (?). This eventually happens (not from within that loop), but when any byte within the aforementioned range is changed, 0xFD appears instead.
If I manually set that value to 0xFF via the memory viewer, the game boots with upside down graphics, in Taiwanese region, has no audio and crashes when a credit is started. Interesting.
User avatar
parodius
Posts: 720
Joined: Wed Jan 26, 2005 5:54 am
Location: Singapore

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

Post by parodius »

Code: Select all

sha1sum.exe tp-026-1.fixeight
be33802651f983ce081d203715a7e3c8ddcc9d4b *tp-026-1.fixeight
Unfortunately, I couldn't see any difference with this patch either.
My sales thread : 2020/07/20..MASTER.VER.
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, they seem to have done things differently with Fixeight for some reason..
Removed the patch until there's a way to work around the above-mentioned issue. I'm sure it's possible somehow.
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 »

Your efforts on this are awesome, keep up the good work!

That being said, would the OSSC Pro, just announced, have the ability to fix the sync on these?
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 »

The following PCBs work with a HAS > RetroTINK SCART2COMP > CRT TV (no OSSC in the chain).

Here are the results with HAS > OSSC > Sharp LCD TV. OSSC FW .85a reset settings.

Japanese Knuckle Bash:

Default: Red and Green LED on, screen black.
Line3x 320x240 default: Red and Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1250.00: Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1400.00: Green LED on, screen black.

OSSC LCD Screen:
AV1: RGBS 263p
15.60kHz 59.34Hz

--------------------------------------

Korean Knuckle Bash:

Default: Red and Green LED on, screen black.
Line3x 320x240 default: Red and Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1250.00: Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1400.00: Green LED on, screen black.

OSSC LCD Screen:
AV1: RGBS 263p
15.61kHz 59.37Hz

--------------------------------------

Snow Brothers 2:

Default: Red and Green LED on, screen black.
Line3x 320x240 default: Red and Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 501.00 - ~680.00: Green LED on, screen black.
Line3x 320x240 with H. samplerate set to ~681.00: Green LED on, Red LED comes on intermittently, with the Red LED coming on more often as the H. samplerate is set higher, screen black.
Line3x 320x240 with H. samplerate set to 703.00: Red and Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1250.00: Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1400.00: Green LED on, screen black.

OSSC LCD Screen:
AV1: RGBS 263p
15.61kHz 59.37Hz

--------------------------------------

Fixeight: I KNEW I WASN'T CRAZY!!! MY FIXEIGHT WORKS ON DEFAULT SETTINGS!

Default: Red and Green LED on, screen black.
Line3x Generic default: Green LED on, game works but top edge (left if screen rotate, player 1 side) has slight distortion. Very slight, almost not noticeable.
Line3x 320x240 default: Red and Green LED on, screen black, I can hear the game intermittenly, TV says incompatible resolution.
Line3x 320x240 with H. samplerate set to 750.00: Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1250.00: Green LED on, screen black, I can hear the game, TV says incompatible resolution.
Line3x 320x240 with H. samplerate set to 1400.00: Green LED on, screen black, I can hear the game, TV says incompatible resolution.

OSSC LCD Screen:
AV1: RGBS 263p
15.62kHz 59.41Hz
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 »

XtraSmiley wrote:Fixeight:
[...]
Line3x Generic default: Green LED on, game works but top edge (left if screen rotate, player 1 side) has slight distortion. Very slight, almost not noticeable.
Thanks for the tests, that Fixeight result was unexpected! Well, it fits the mould of it having additional idiosyncracies I guess. Would be interesting to have a look at the sync waveform, but I don't have the PCB at this time..
XtraSmiley wrote:would the OSSC Pro, just announced, have the ability to fix the sync on these?
Since it'll have a Si5351C configurable clock generator, I assume we'll at least be able to achieve results akin to what you can see in the "before" photos that parodius posted.

However, considering that the Framemeister can digest these PCBs with odd sync just fine without any artifacts in the resulting image, and that I can't tell what crucial component the OSSC Pro would be lacking in comparison to the Framemeister, I see no reason why the Pro wouldn't be able to completely cancel out the problem in principle (also refer to this post). Whether the Pro will be able to compensate for it automatically or if it'll make more sense to readjust some parameters manually remains to be seen. marqs can probably give a better assessment though (feel free to correct me). :)


Either way I'd still like to finalize these patches. As for Fixeight, I've got something going, but before I release the patch I want to see if I can optimize it.
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 »

New Fixeight patch, parodius, the stage is yours :)

It changes two additional bytes compared to all previous patches in order to appease another integrity check performed by the NEC V25 that would otherwise prevent the game from booting.
These bytes are in the 0x40100..0x470ee range. As I want to avoid changing the gameplay behavior in any way, I set a corresponding memory watchpoint and credit-fed my way through the game (while cycling through the different characters along the way for what it's worth) to see if the game accesses that range - it didn't. A simple smoke test like this might not mean much, but as far as I can tell, that specific range is only accessed by the various integrity checks when the game boots.


Yesterday I listened to this interesting conversation with Artemio and SmokeMonster about some technical aspects of video game preservation and the MiSTer project. The GP9001 needs to be delidded and analyzed already!
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 »

So at this stage, V-V works but Batsugun does not?
A camel is a horse designed by a committee
User avatar
parodius
Posts: 720
Joined: Wed Jan 26, 2005 5:54 am
Location: Singapore

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

Post by parodius »

6t8k wrote:New Fixeight patch, parodius, the stage is yours :)

It changes two additional bytes compared to all previous patches in order to appease another integrity check performed by the NEC V25 that would otherwise prevent the game from booting.
These bytes are in the 0x40100..0x470ee range. As I want to avoid changing the gameplay behavior in any way, I set a corresponding memory watchpoint and credit-fed my way through the game (while cycling through the different characters along the way for what it's worth) to see if the game accesses that range - it didn't. A simple smoke test like this might not mean much, but as far as I can tell, that specific range is only accessed by the various integrity checks when the game boots.
Hats off, it works !
I couldn't spot any graphical glitches during attract mode.
Excellent reverse engineering/hacking work, man.
Spoiler
ImageImage
My sales thread : 2020/07/20..MASTER.VER.
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 »

Awesome work man!!!!!

I suggest updating the first post with the new info, and adding third column with working/not working patches.

Amazing..!
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 »

Glad it works!

thchardcore: Dogyuun and Batsugun don't have a working patch yet because they each have two GP9001 chips which makes it more complicated. At this time it's a bit like a combination lock, and for each try an EPROM has to be burnt anew.

XtraSmiley: For now I think it'd be best to simply link to the post with the patches. Separation of concerns.
User avatar
Harrumph
Posts: 368
Joined: Tue Jan 19, 2016 10:06 pm
Location: Sweden

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

Post by Harrumph »

XtraSmiley wrote: Line3x 320x240 with H. samplerate set to 1250.00: Green LED on, screen black.
Line3x 320x240 with H. samplerate set to 1400.00: Green LED on, screen black.
Bit off tangent here, but just to save you some time in future testing, those settings will never produce a valid signal.

I saw 6t8k recommended using 320x240 opt with high sample rates earlier in the thread, but I think that’s a red herring. The resulting output total frame is just wildly off-spec, and actually exceeds max pixel clock of OSSC: 3*1250*4/3= 5000; 5000*263*3*59.4= 234 MHz!
Don’t know how ossc handles it, maybe it just doesn’t increase actual h.samplerate once pixelrate limit is reach.

If you wanna test for compatibility, simply generic mode is enough.
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 »

^ Well aware, we were not expecting to suddenly get a viable image this way!

My idea was that, for people who don't have a scope, comparing the specific artifacts in the image I coaxed out this way could be used to identify if other PCBs suffer from the very same problem while excluding other possibilities. I don't think it's useless in that regard.
You're right though that checking if it works in generic mode with default samplerate is enough for compatibility itself, as I said earlier. Besides, many displays, especially TVs, presumably won't display the off-spec signal anyway, so that analysis is not always 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 »

I checked whether the patching approach in fact changes the overall gameplay speed, not only the vertical refresh rate, as previously established. It does, and the difference corresponds exactly to the change in vertical refresh rate. I did this by recording 1h of footage through the Framemeister of both the original and the patched vfive ROM (0300 0200 0040) and comparing both videos.

It would be nice if it were possible to correct that difference by changing some of the other bytes. To scout that, I first changed only the first two words (resulting in 0300 0200 0042), leading to the following outcome:
• signal not recognized by the OSSC (as expected)
• Vsync period and p1-5 exactly like the original, unpatched ROM
• gameplay speed exactly like the original, unpatched ROM

In another experiment, I only changed the last byte (resulting in 0202 0302 0041). 41 to vary things a bit, since we know that 40 works and already have enough data for that.
• signal recognized by the OSSC (as expected)
• Vsync period and p1-5 exactly like the patched ROM (0300 0200 0040)
• gameplay speed exactly like the patched ROM (0300 0200 0040)
• surprise: many (all?) sprites, like the player ship, enemies and shots, are completely missing

I also tried a few more values for Dogyuun and added the results to the list here.
Feel free to mention if you spot a pattern and/or have an idea for what value(s) to try next.

Conclusions:
➤ So the last word (=2 bytes) must make the relevant difference. Not sure what the others do. So far I was unable to discern any effect, at least neither sync signal wise, nor gameplay wise.
➤ Compensating the difference in gameplay speed seems impossible via this method. All findings indicate that the difference is directly caused by the absence/presence of the 5μs long sync quirk
➤ "Wrong" values can already confuse games that only have one GP9001 VDP. Before, I attributed the fact that Dogyuun/Batsugun glitch out with 40/41 to a "desync" of both VDPs, but it may be more than that.
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 »

Still holding out hope Batsugun can be fixed.
A camel is a horse designed by a committee
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 »

I may learn to program just to finish what was started here. Would be awesome if Batsugun and even Dogyuun (as much as I dislike it) worked so this could be closed out for good.

6t8k - Do you mind if I cross-post/link to this topic on arcade projects? I am hoping an interested party might be able to assist.

I would like to make an initial donation of $100 to anyone willing to give this another shot. If you succeed, I will happily donate another $100 for your time and effort.
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 »

Sure, go ahead crossposting it :)

By now I've come to the perception that delidding and photographing the GP9001 under a microscope to reveal its logic is the best solution by far.

Following that, we'll know for sure whether it's possible at all to develop a patch in this vein for Batsugun and Dogyuun, what exactly these values do and therefore which ones we need to use. This will have to be done anyway at some point for projects like the MiSTer and MAME. We can then further hope for an elucidation on why the GP9001 spits out a weird sync signal in the first place. Maybe it's a sort of crutch for facilitating correct teamwork between the two chips.

So I think that efforts would best be concentrated on this end going forward (but I don't want to deter you from anything). One needs the right tools for that, but I'm sure the community will manage to pull it off eventually, with the help of the right people :)

For example, it was not before the end of 2016 that a specialized chip which holds the sound on Vimana, Teki Paki, and Fire Shark PCBs, was analyzed. Only since then did MAME have proper audio emulation for these games!
That project was concerned with extracting data instead of logic, which in part requires different steps, but I think it's a cool example of why stuff like this is so important.
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:Sure, go ahead crossposting it :)

By now I've come to the perception that delidding and photographing the GP9001 under a microscope to reveal its logic is the best solution by far.

Following that, we'll know for sure whether it's possible at all to develop a patch in this vein for Batsugun and Dogyuun, what exactly these values do and therefore which ones we need to use. This will have to be done anyway at some point for projects like the MiSTer and MAME. We can then further hope for an elucidation on why the GP9001 spits out a weird sync signal in the first place. Maybe it's a sort of crutch for facilitating correct teamwork between the two chips.

So I think that efforts would best be concentrated on this end going forward (but I don't want to deter you from anything). One needs the right tools for that, but I'm sure the community will manage to pull it off eventually, with the help of the right people :)

For example, it was not before the end of 2016 that a specialized chip which holds the sound on Vimana, Teki Paki, and Fire Shark PCBs, was analyzed. Only since then did MAME have proper audio emulation for these games!
That project was concerned with extracting data instead of logic, which in part requires different steps, but I think it's a cool example of why stuff like this is so important.
This was a super interesting read. I'll keep my eyes open for a cheap donor to donate for sacrifice. Thanks for sharing this.
A camel is a horse designed by a committee
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 »

I'm willing to contribute cash to a GP9001 decap and documentation effort by someone with a proven track record in such endeavors. Not only would that be useful for implementing sync fixes, it would also open the door to FPGA replacements.
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 don't have a direct contact, but I know some people who could potentially get something going or know others who could.

In 2012, Dr Decapitator (now aka. caps0ff, who also did the Toaplan-related chips mentioned above), managed to dump a set of SNES DSPs, which are a crucial component of certain game cartridges, for byuu et al., the author of bsnes (article).

Coincidentally, byuu (now called Near) is currently trying to get the two SNES PPU (= Picture Processing Unit) chips scanned.
The magnification factor of the existing scans by John McMaster is not high enough to trace all the details.

Supposing the SNES PPU effort could pick up pace medium-term, I wonder if there are some synergy effects that could be leveraged?

I cross-posted this over at arcade-projects.


P.S.
Will not be updating this thread myself with news/findings from arcade-projects or decapping efforts, respectively., so as to not inflate the scope of this thread. I think it's not really relevant here as long as there's no progress with a Dogyuun/Batsugun patch (which could still be achieved by different means).

P.P.S.
shmupsrocks, by now you can remove the [assumed] remark in the opening post for everything except Teki Paki :)


P.P.P.S.
thchardcore wrote:and even Dogyuun (as much as I dislike it)
Image
shmupsrocks
Posts: 597
Joined: Mon Aug 13, 2018 3:53 pm

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

Post by shmupsrocks »

First post updated. :)
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 »

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.
Post Reply