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

[invzim]

Very nice work! The effect of the code by nature must be to change the sync stuff, so I guess the question is if it changes anything else.

I may be able to to have a look at the waveforms of both versions on my bench, just have to borrow batsugun again

[6t8k]

Here are the IPS patches. Use your favorite patcher, like Lunar IPS or Flips to apply them.

All patches listed below have been verified as working on genuine hardware.
The small ROM manipulation that fixes the sync signal quirk is harder to mount for Dogyuun and Batsugun; so far there are no patches for these.

I am not liable for any potential damage, use on your own responsibility!

Spoiler

R= MAME ident & filename & sha1 before & sha1 after & download R= fixeight & tp-026-1 & 0bbea6f111b818bc9b9b2060af4fe900f37cf7f9 & 9fe9870861a64eb236fac45c2d2e291adc8aea19 & [url=https://6t8k.de/static/patches/tp-026-1.ips]download[/url] R= grindstm & 01.bin & 1c2d66b432d190d0fb6ac7ca0ec0687aea3ccbf4 & 4bc294c10a13ec54767d840d51bd1ce50220d019 & [url=https://6t8k.de/static/patches/01.bin.ips]download[/url] R= grindstma & tp027-01.rom & 824dde274c8bef8a87c54d8ccdda7f0feb8d11e1 & 53448dda050f1de60fc87d629b09cbb707bafac1 & [url=https://6t8k.de/static/patches/tp027-01.rom.ips]download[/url] R= kbash & tp023_01.bin & 46f2df30fa92c80ba5a37f75e756424e15534784 & 57991b26a208d9d7cec795e820ce8ec7e7aba3ee & [url=https://6t8k.de/static/patches/tp023_01.bin.ips]download[/url] R= snowbro2 & pro-4 & ad46c605a38565d0148daac301be4e4b72302fe7 & b26860c529bb185061e7a3ee159c817aa3da428c & [url=https://6t8k.de/static/patches/pro-4.ips]download[/url] R= vfive & tp027_01.bin & 794255d0a809cda9170f5bac473df9d7f0efdac8 & 107edf24f668ad59705195782e6998dd5b8a9be9 & [url=https://6t8k.de/static/patches/tp027_01.bin.ips]download[/url]

Don't mix up the filenames for vfive and grindstma (tp027_01.bin and tp027-01.rom, respectively). I didn't name them

History:
Jan 11, 2019: removed patches for dogyuun and kbash for the time being; as they were, they provoked a ROM error
Jan 13, 2019: add working patch for kbash and add patch for fixeight, remove patches for batsugun and batsugunsp for the time being, for the reason read this post: click
Jan 14, 2019: revise patch for Fixeight
Jan 16, 2019: removed the fixeight patch for the time being; it's a bit harder to make it work for this game than it is for others, read the following posts for the reasons
Jan 22, 2019: add new fixeight patch that avoids another integrity check which would otherwise prevent the game from booting
Nov 11, 2020: all patches available so far have been verified as working on genuine hardware, reference: > click <

[6t8k]

invzim: Thanks! As rama said, I'm pretty certain gameplay itself is not affected by this modification (without guarantee). The only thing I could think of would be that the video refresh rate could change slightly. Maybe these values "only" contain timing information used for video signal generation?

But as far as I know, all Toaplan V2 PCBs have the same refresh rate anyway, don't they? If they do, this concern wouldn't apply since the patches just inject values from other V2 PCBs.
For what it's worth, the OSSC displayed the same frequency before and after. I should measure that with the scope later.

Edit, updated overview. shmupsrocks, can you put that in the first post again?

Spoiler

R= Year & Game & OSSC compatible without patch? R= 1991 & Teki Paki & O [assumed] R= 1991 & Ghox & O [assumed] R= 1992 & Pipi [and] Bibis / Whoopee!! & O R= 1992 & Tatsujin Oh / Truxton II & O R= 1992 & Dogyuun & X R= 1992 & Fixeight & X R= 1993 & V-V / Grind Stormer & X R= 1993 & Batsugun / Batsugun Special & X R= 1993 & Knuckle Bash & X R= 1993 & Mahou Daisakusen / Sorcer Striker & O R= 1994 & Otenki Paradise / Snow Bros. 2 & X [assumed] R= 1994 & Shippu Mahou Daisakusen / Kingdom Grand Prix & O [assumed] R= 1996 & Battle Garegga & O R= 1998 & Armed Police Batrider & O R= 1999 & Battle Bakraid & O

If you list the games ordered by release date like that, you can see a pattern. They introduced the change responsible for the sync glitch with Dogyuun (apparently, both Dogyuun and Tatsujin Oh were released October 1992, so not sure which or if one was "first").
Raizing on the other hand perhaps used a different code base that did not produce the bug. Or they noticed and fixed it.

[XtraSmiley]

Wow, AMAZING!

I have to dig out my EPROM burner and figure out how to do this!

I haven't had a chance to test Fixeight yet, but I also have Ghox, didn't realize that one wasn't confirmed. I guess I have some work to do this week!

Again, great job!

With this definitive info, is there anyway now Marqs can me the OSSC work without patching the ROMs?

[thchardcore]

You are basically my personal hero at this stage . I have looking over at my boards dying to play them on my line doubled setup for awhile now. Honestly, this is so cool and simple relative to hardware hacking/creation of additional hardware. I really appreciate all the time and effort spent on this. Can't emphasize this point enough!

[parodius]

Spoiler

R= Year & Game & OSSC compatible without patch? R= 1991 & Teki Paki & O [assumed] R= 1991 & Ghox & O [assumed] R= 1992 & Pipi [and] Bibis / Whoopee!! & O R= 1992 & Tatsujin Oh / Truxton II & O R= 1992 & Dogyuun & X R= 1992 & Fixeight & X R= 1993 & V-V / Grind Stormer & X R= 1993 & Batsugun / Batsugun Special & X R= 1993 & Knuckle Bash & X R= 1993 & Mahou Daisakusen / Sorcer Striker & O R= 1994 & Otenki Paradise / Snow Bros. 2 & X [assumed] R= 1994 & Shippu Mahou Daisakusen / Kingdom Grand Prix & O [assumed] R= 1996 & Battle Garegga & O R= 1998 & Armed Police Batrider & O R= 1999 & Battle Bakraid & O

Confirmed on my setup that the following PCBs do exhibit the issue with OSSC :

• Dogyuun
• Fixeight
• V-V
• Otenki Paradise

and that Shippu Mahou Daisakusen & Ghox do not.

I have yet to try the patched roms.

[ShootTheCore]

Fantastic discovery! These games are one of the only things I keep my Framemeister around for. Although I am loathe to modify my boards....have to think about it and weigh the pros and cons...

[thchardcore]

You are just burning a EEPROM and swapping it. The game ROM is socketed and can be undone in 2 minutes.

Looking forward to a Fixeight patch when someone has the ability to test.

[ShootTheCore]

I don’t remember the Toaplan 2 boards using socketed ROMs from the factory but I may be misremembering. I’ll have to look at my boards in the morning and refresh my memory.

If they are indeed socketed then I agree with you on the chip swap being trivial. That’s what I get for posting on the forums at 2:00AM.

[marqs]

This is great news! Patching is definitely more convenient than having additional HW for working around the issue. I have Knucke Bash now reserved to me (will take a while to arrive, though) so I'll plan on trying both the patch method and cps2_digiav with vanilla ROM.

[parodius]

Patched V-V first, same successful results as reported by 6t8k.

A big thank you to 6t8k for discovering this hack by the way !

Here are some before/after shots on one of my 31khz arcade CRTs via Retro Scaler A1 :

Spoiler

(ignore the slightly different tint, this is due to different lighting conditions)

[Harrumph]

Amazing detective work, great job!

[parodius]

Snow Bros 2 before/after :

Spoiler

Dogyuun has decided to play hard-to-get though, it gives an 'EP-ROM ERROR' with the patched rom (same in MAME) :

Spoiler

Fixeight...
At first, I tried to patch the 3 locations at the same time. My PCB booted to a blank screen. Tried in MAME, same thing.
Then I tried patching each location individually : locations 1 & 3 gave the same blank screen, location 2 gave a 'ROM EVEN ERROR' in MAME. Haven't tried those on the actual PCB as it's probably useless for the moment.

Spoiler

(MAME)

Sooooo... Dogyuun and Fixeight seem to verify a checksum somewhere in the ROM (or maybe in an EP-ROM for Dogyuun) which doesn't match anymore due to the modifications.

[6t8k]

parodius: Thanks for all that additional info, very happy to see it works for Snow Bros. 2 too! I should have tried all of these in MAME first
Removed the patches for Dogyuun and Knuckle Bash for the time being (kbash produces a ROM error too). The Batsugun patch works in MAME.

Having empirical info for everything now except Teki Paki that also confirms the predictions along the way, it looks like we're definitely on the right track.

It occured to me that this byte sequence we're changing most likely also plays a role in how the two GP9001s are coupled, for the games that have two, especially considering that the different sequence was introduced with Dogyuun, the first game to feature two GP9001s. After that, they just kept it, even with games that have just one GP9001. Another hint that changing this for games with one GP9001 might be completely fine, possibly even "design-compliant", quasi. If this thought at least goes in the right direction, mikejmoffitt's earlier suggestion was sort of correct already, that the sync glitch could arise from the way two GP9001s are coupled.

For this reason, I think it'd be quite interesting to see how Batsugun reacts to the patch on real hardware, maybe it'll throw off the two GP9001s and we have to think of something else. @invzim: you're going to test this, right?

I'm very sure there is a way to make the ROM integrity check accept the patch for Dogyuun, Knuckle Bash and Fixeight. We might have to use different values for Dogyuun though, if the Batsugun attempt reveals that the current patch breaks stuff (for reasons described above).

[...] so I'll plan on trying both the patch method and cps2_digiav with vanilla ROM.

Superb!

With this definitive info, is there anyway now Marqs can me the OSSC work without patching the ROMs?

As discussed on the previous pages, the OSSC may never work with unpatched ROMs. :/ These patches don't change the original reason why the OSSC doesn't recognize some of these games.
Imagine it like the patched V-V's sync signal looking like a Tatsujin Oh's sync signal from the OSSC's perspective.

If ROM patching is to be avoided, there's still the cps2_digiav way marqs is pursuing (as quoted above). This would require soldering some wires to the PCB though.

[invzim]

Tested Batsugun with patched firmware, and it works great! I want to publish a page with zipped roms with credit to 6t8k if that's ok.

Now for the tests, had to really dig around to find my in-line BNC breakout probe board.

The only thing that looks different is that the negative width of the sync is 260.80us on the patched, while 265.84us on the non-patched (measured with a 100mhz sample clock on the A1) + confirmed by scope.

Frame measured 16.83ms on both versions, but if you add a little precision the vertical refresh naturally changes from 59.392 to to 59.410 (measured on the A1), scope confirms with 59.39 and 59.41.

The math adds up, and AFAIK the only difference is that the vsync portion is now a proper multiple of the other lines.

I haven't played this game a lot patched or non-patched, but will hand it back to the person I borrowed it from with the patched ROM and I'm sure he will report if anything seems off.

Scope grabs:
http://kirurg.org/webimg/2020-01-11-MSO ... -vsync.png
http://kirurg.org/webimg/2020-01-11-MSO ... -width.png
http://kirurg.org/webimg/2020-01-11-MSO ... -width.png
http://kirurg.org/webimg/2020-01-11-MSO ... -vsync.png

Some math I hope I get right for those who cry changed framerate, it's about one frame difference PR HOUR - and it actually fixes what can only be considered a bug.

[maxtherabbit]

However, you can clearly see some relatively nasty distortions between the HSync pulses. What I've observed is that these get stronger with higher signal levels of the three color lines

that doesn't sound like a "quirk" to me, it sounds like a design deficiency that should be addressed

looks like you addressed it

[6t8k]

Tested Batsugun with patched firmware, and it works great!

That means what's left is to circumvent that integrity check for Dogyuun, Fixeight and Knuckle Bash and it should work for them too

Sure, go ahead providing the patched ROMs (I think providing patches is always more elegant, for legal reasons and stuff, but it's an additional hoop users have to go through)

Thanks for all that research, now is that vertical refresh difference actually speeding up the game a little or not and it just happens to be the screen refresh literally? I imagine that would be hard to measure, but maybe that question can be asserted by knowledge of some hardware details. But even if that would be the case, I can't imagine anyone seriously caring, considering how minuscle it is. After all, shmups are usually not speedrun (speedrun circles are usually very particular about differences like these because they can actually matter, so maybe it could matter for Knuckle Bash or Snow Bros. 2. Granted though, one frame difference PR HOUR, that would be very nitpicky. That is longer than World of Longplays' whole playthroughs of both games combined, which are not speedruns.)

[6t8k]

I measured the difference in Vsync period (vertical refresh rate) for V-V before and after the patch:

Spoiler

Before patch, first Vsync falling edge:


Before patch, second Vsync falling edge:


After patch, first Vsync falling edge:


After patch, second Vsync falling edge:

@invzim, there might've been a trivial mixup, the difference is actually a little larger:

V-V before patch
8.25600400ms - (-8.58103000ms) = 16.837034ms

V-V after patch
9.53599600ms - (-7.29599200ms) = 16.831988ms

16.837034ms - 16.831988ms = 5.046μs difference per frame

16837μs / 5.046μs = 3336.70234 frames
3336.70234 frames * 16.837034ms = 56180.171ms = 56.18 seconds of continuous gameplay until one frame difference is reached*

1000000μs / 5.046μs = 198176.773682 frames
198176.773682 frames * 16.837034ms = 3336709.0765ms = 55.612 minutes of continuous gameplay until one second difference is reached*

* The patched version being the faster one. But I don't know yet if that really has an impact on actual gameplay speed or if it merely changes the vertical refresh rate.

---

That means what's left is to circumvent that integrity check for Dogyuun, Fixeight and Knuckle Bash and it should work for them too

So I've reached out to THA MAN in regards to this sort of stuff! Excited if he'll help us
I certainly don't trust myself with doing this currently, and/or it would simply take way too long / yield suboptimal results.

We only want to patch one ROM at max, and the check is actually a sensible thing (after a few decades, EPROMs can suffer from bit rot), so it should stay ideally.
That should be achievable if the checksum is stored on the program ROM, then we could simply change it to reflect our change in the program ROM.
Otherwise, maybe it could be intercepted and our checksum be injected instead.
But that's just some deliberation of mine of which I don't know how firm it is settled in the realm of possibility. Let's see how it goes.

[shmupsrocks]

Edit, updated overview. shmupsrocks, can you put that in the first post again?

No problem, updated.

[rtw]

ROM checks are normally trivial byte checksums.

I took a look at Dogyuun and I was able to work around the check with some trivial patching but the moment I hit 2 patches the error appeared. The algorithm might also be using word checksums or a combination.

The best fix would be to fire this up in the MAME debugger and determine where the checksum value is stored and modify the binary with the "new" checksum.

[6t8k]

Yeah, the checking algorithm might be simpler than I thought (I have never done something like this myself before).

I have to say I was never really able get much use out of the MAME debugger, as I can't make out much of the logic that is happening by looking at the assembly (or it'd just take ages and ages).
I've put days into stepping through instructions for some other hobby projects not yielding any useful findings (some succeeded via other means). That's of course just my inexperience though, and I might try again. Maybe I should try loading the ROM into IDA Pro instead.

Maybe there's an easier way though by just modifying some bytes within the padding space until the check succeeds.

@shmupsrocks: thanks!

[6t8k]

Alright, got it. I have to say my concerns were unfounded. Thanks to trap15 and rtw for the initial clue(s)
The only additional change will be the checksum itself.

Expect the three remaining patches and a quick explanation later today.

[invzim]

For completeness, I burned the Batsugun SP patched rom, and it works like it should

[6t8k]

Working patch for Knuckle Bash added and added a patch for Fixeight!
@parodius: can you try the latter?

It occured to me that this byte sequence we're changing most likely also plays a role in how the two GP9001s are coupled, for the games that have two, especially considering that the different sequence was introduced with Dogyuun, the first game to feature two GP9001s. After that, they just kept it, even with games that have just one GP9001. Another hint that changing this for games with one GP9001 might be completely fine, possibly even "design-compliant", quasi. If this thought at least goes in the right direction, mikejmoffitt's earlier suggestion was sort of correct already, that the sync glitch could arise from the way two GP9001s are coupled.

For this reason, I think it'd be quite interesting to see how Batsugun reacts to the patch on real hardware, maybe it'll throw off the two GP9001s and we have to think of something else.

So since the integrity check is happy with our change now, I had the means to test Dogyuun. Turns out, what I had written about above seems very much true. That byte sequence must be fine-tuned in regards to the interplay of the two GP9001 chips, and our change thows that off, producing glitched out and missing graphics. This does not happen when loading the patched ROM into MAME because the GP9001 is only coarsely approximated there.

➤ Video capture of the problem

The coupling of the GP9001 chips being the assumed cause, this should only happen for games that have two GP9001 chips, like Batsugun and Dogyuun, all other games should be unaffected. I have removed the Batsugun patch for the time being until we have a correctly working version. If you still need it for testing purposes, shoot me a PM.

@invzim: are you sure Batsugun/Batsugun Special looks fine? Can you look out for glitches/cut-off graphics like in the video capture above?

I think what that means for us is, that instead of outright replacing the byte string with the one from compatible games, we should try to modify the original byte sequence minimally until the sync quirk goes away. Maybe this is possible while also allowing for correct GP9001 interaction. Furthermore, it was brought to my attention that with a careful selection of values, it could be possible to match (or at least closely approximate) the vertical refresh rate of the unpatched games -- again, the latter aspect is only a problem if gameplay itself is sped up, not just the screen refresh rate, I should measure this to confirm. So, I'll certainly look into this.

The only concern I have is that testing this could be quite laborious, having to UV-erase, burn, swap an EPROM, and measuring the sync signal each time. I have read that there are devices known as "EPROM simulators" or similar, where you just connect a cable to the socket on the PCB and "fill" a virtual EPROM directly via your PC this way. That could speed up testing significantly, but at this point I'm not sure how easy or hard it is to obtain such a relatively obscure (?) device. Somebody knows more? Maybe this is also possible with a Raspberry Pi or something?

Otherwise, if we don't manage to gain sufficient intuition about what to change in the byte sequence, maybe we could split up the effort in some way.

---

Short write-up of how the integrity check works and my approach:

Spoiler

First, we try to find the checking routine. The check does not encompass the whole code, so we can do that by modifying bytes in the ROM akin to a binary search pattern to be more efficient. If we have found a region where modifying a specific address does not evoke an integrity check failure, but a few bytes lower it does, we set a broad watchpoint for that region. Since the integrity check loops through all words, that watchpoint will be hit near the end of the loop execution.

We can then see that all words are add up and put into D2. After the loop, we can see that a value is loaded from 0xc0, and the content of D2 is subtracted from that. The value at 0xc0 is the checksum! For the integrity check to succeed, the result has to be 0.

This means that the value of D2 after the loop and before the subtraction is the value we have to use in place of the original checksum for any given patch: checksum - D2 = X; checksum - X = new_checksum

All games I looked into have their checksum at address 0xc0, so to find the loop for a given game (in order to get the value of D2), we can just set a watchpoint for 0xc0.

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.

[invzim]

@invzim: are you sure Batsugun/Batsugun Special looks fine? Can you look out for glitches/cut-off graphics like in the video capture above?

Indeed, there is a glitch - didn't spot it in attract mode. Pardon crappy video of LCD
https://www.icloud.com/photos/#0bIJcIb7 ... coJsWvCGCA

The score bar is too far right, and there is some subtle pixel noise I can't see in mame.

[6t8k]

Thanks, yeah, that looks very similar to what is plaguing Doyguun, minus that pixel noise pattern - not only is the HUD shifted, one graphics layer is also cut off prematurely at the bottom as you can see when the ship takes off (left side of the screen in your video).

I think we'll have to carefully change the original byte sequence step by step and see what we can achieve this way.

Edit: oh, and, another idea: of course, the second GP9001 also has a byte sequence that configures it. Maybe it would be easier to adjust that in order to reply to the change affecting the first GP9001, making the coupling coherent again (I only changed the first sequence so far).
While that wouldn't quite tackle the refresh rate aspect (if that's a problem at all; see above), having more options is always nice.

[invzim]

Thanks, yeah, that looks very similar to what is plaguing Doyguun, minus that pixel noise pattern - not only is the HUD shifted, one graphics layer is also cut off prematurely at the bottom as you can see when the ship takes off (left side of the screen in your video).

I think we'll have to carefully change the original byte sequence step by step and see what we can achieve this way.

Edit: oh, and, another idea: of course, the second GP9001 also has a byte sequence that configures it. Maybe it would be easier to adjust that in order to reply to the change affecting the first GP9001 (I only changed the first sequence so far).
While that wouldn't quite tackle the refresh rate aspect (if that's a problem at all; see above), having more options is always nice.

Yeah, that struck me as I was looking at it right now

Mame says:
0202, 0203, 4200 <- first controller
1202, 1203, 5200 <- second controller

It writes the same thing to both controllers except one bit - we could try to write the same "correct" values to both, but keep the bit for the second controller.

[6t8k]

Great find! I will try that at the latest tomorrow

With byte order on disk, it'd be the following then:

0300 0200 0040
0310 0210 0050

[Nebula]

Interesting read and awesome work 6t8k, congrats!. I have almost every toaplan v2 game pcb so I could make any test if you need it (as long as work and family allow it to me )

Anyway, bad news regarding your last posts about Dogyuun and Batsugun patches...
Apart of that potential solution by tweeking a bit the original register values, maybe it could be possible to patch the second GP9001 register values to make it "in sync" with the first GP9001 while it uses the patched values, isn't it?
yeah, it would be (lot) harder to find the correct values for the second GP9001 unit to be in sync without the proper knowledge of its internal operation, but that came to my mind as we (you) found the proper values to make first GP9001 "working fine", half of the work is done. let's go on and find them for the second one

Sorry if it sounds stupid...


EDIT: you guys are fast and discover it while I'm writing this...

[invzim]

Great find! I will try that at the latest tomorrow

With byte order on disk, it'd be the following then:

0300 0200 0040
0310 0210 0050

That's what I found too, fudged a 10 with a 01 and ran out of blank eproms - that feeling
Erasing now..