What's new
In regards to Mark of the Wolves proto and final version, I messaged rewrite to bring this his to attention. He suggested this to be posted here to clear up what's what with the proto and final version. Here is a copy and paste of said message.

Hey rewrite. Seen that one guy ask about MOTW if it's the prototype version or the final in your multi interest check thread. Was going to comment, but didn't want to come off as if I'm putting your efforts down. Anyway so there is a prototype version of this game, which is used in the 161 in 1. The final version wont run on the 161 in 1, as far as I know, because it uses a custom mapper which the cpld does not support. This version is without endings when you beat it, and also surfers from a bug which freezes the game when preforming a certain move. Also the title screen is a bit different, among other small changes.

Now some claim the 138 in 1 version is the final. I have this cart and tested it. The freezing bug has been patched, and the title screen resembles that of the final. The endings are still not there though unfortunately. Rom hackers way back in the day probably patched the proto to be closer to the final, but at the time no emulators supported the custom mapper so the final version was not playable. You can get this version from an old neoragex romset, and currently is the best available version to use to my knowledge.

I believe the final version with decrypted Vroms would take extensive asm disassembly and editing to get running on the 161 in 1 unfortunately. I've brought it up a couple times in the main 161 in 1 mod thread, but no one has commented on it. ack did however suggest in a chat that if we can get someone with a real flash cart, we could test modifications out before flashing a 161 in 1.

The rom set for the hacked updated version of neoragex 5.2a, has fully decrypted Vroms and is the final version, but I think it may still be using the new mapper. I'm not 100% sure. It will likely run on the 161 in 1 if it isn't.

If someone has access to, preferably a DarkSoft flash cart, then testing could be done to get the final version running on the 161 in 1. Too much work to be soldering and reprograming each chip to test. Please leave a message if you have one and would like to help. Terraonion's flash cart may work in testing as well, but not 100% sure.
 
Fgto79 has kindly offered to help do testing on his AES DarkSoft Multi cart. He tested the neoragex 5.2a rom set of Garou but get's the fallowing error upon booting.

Untitled.png


It's probably because it still uses the mapper mode 4, but not sure yet. I used the tool by aluzed to compile the set in Darksoft format.

https://github.com/aluzed/MiSTer-Ne...eogeo-rom-generator-for-mister-fpga-by-aluzed

The CRC32 hash is different for the Crom0 when using the python script that Darksoft made a thread about converting rom sets. Will test the Crom0 generated from the python script next when Fgto79 can test later tomorrow.
 
Last edited:
Not really a question of reverse engineering, since the neo-sma asic used for bankswitching the P rom was documented a while ago by hpman.
Compared to the other 3 neo-sma games Garou never had a release on a different pcb (BK1), so you're stuck dealing with a 8MB P rom plus the neo-sma dump file that is part of the P rom.
 
I just wanted the title to be relatively clear as to what's going on, and to get conversations in two different threads into one single one while getting a few eyes on it for testing since @darknezz19 said they needed someone for it.

The term may be not be accurate but it was a close enough approximation and got the job done. :)
 
@leonk has a video of Sam Sho 5 Perfect running on the 161 on Twitter, so seems this may have already been worked out?
 
@leonk has a video of Sam Sho 5 Perfect running on the 161 on Twitter, so seems this may have already been worked out?
Yeah the fix for the roms was brought up in the project thread a day or two ago. I simply didn't think to look for it when I'd made my carts.
 
I have the 138 in 1, it has the endings, no gibberish text as the 161 in 1 and the correct Hokutomaru scarf color in the select screen.
But It has Grant's infinite so it's not the final version for sure.
 
Interesting. Played my 138 in 1 a couple weeks ago and it had no endings. I wonder if there are two entries in the game list, maybe one is like a hack. Are you using the dip mod for game selection or the unmodded daughterboard?

Edit: just tried the variant Garou MotW Plus+and it didn't have endings either. Are you maybe playing on aes mode? Maybe there are more versions of the 138 in 1.
 
Last edited:
Interesting. Played my 138 in 1 a couple weeks ago and it had no endings. I wonder if there are two entries in the game list, maybe one is like a hack. Are you using the dip mod for game selection or the unmodded daughterboard?

Edit: just tried the variant Garou MotW Plus+and it didn't have endings either. Are you maybe playing on aes mode? Maybe there are more versions of the 138 in 1.
Yes, I was playing in AES mode. Is it only in MVS mode that it has no endings?

Here's a page with the differences between the proto and the final version:
https://rq87.flyingomelette.com/RQ/PP/MOTW/1.html

The version in 138 in 1 has some of the stuff of the proto patched and some left unpatched.
 
Misos is right, MOTW on the 138 in 1 does have endings when played in AES mode. Good enough for now. I'll Try the NeoRageX proto version and see if does as well as I think that's the romset they used.
 
Couldn't find any set that has the version the 138 has. Found a patch on wayback machine that patches the proms to that version though. Looks like it's the same version. There are still a few glitches, like on Tizoc's stage, but is the closest we will get without support for 512KB Srom. Notable differences are selecting Hotaru with C button, her portrait is black and not green. When you defeat a character, their icon is greyed out. Need to apply patch to the original proto roms.

Original Proto CRC32 Proms
P1 C72F0C16
P2 BF8DE565

Patched CRC32 Proms
P1 3F41581E
P2 CF4B3903

The rom in Vortex's pack is the original proto dump that crashes when doing Kim Dong Hwan's top down special. Same with the Darksoft packs found on achieve.org. So the patch will work on the CRC of these Proms.

Edit: There are also proms from a winkawaks garoubl set that is close to this patch posted with the aforementioned fixes. It doesn't address the fix when selecting Kim Jae Hoon's outfit with C. In this set his gi turns blue, and the palette glitches around his eye. For this reason I believe the patch posted is the latest version known that attempts to address the differences in the proto.

CRC32 for winkawaks garoubl
P1 FD446D59
P2 3FB10A84

If anyone has the skills and interest to fix the background glitch in Tizoc's stage, please do.

Edit2: I found some more references to patches on wayback machine, but download links wouldn't work unfortunately.

https://web.archive.org/web/2009060....snk-neofighters.com/patches/hacks/garou.html

https://web.archive.org/web/20050527062635/http://www.micmano.net/Utilitaires_et_Patch.htm

That last one has a reference to a p1rom that patches to crc32 321365f5 and it's dated from 2005. This is probably a newer patch but I couldn't find a download. Anyone know if it's possible to bruteforce the changes to come up with that CRC32?

On a side note someone told me that if you set the Neo Geo's region to Japan, Tizoc's stage doesn't have that glitch and I have confirmed this.
 

Attachments

  • ptw00409.zip
    35.9 KB · Views: 57
Last edited:
I've been reading a lot about how the fix layer and the 68k work. Should be able to patch the prom to have it repeat addresses in the first 128kb range of the srom, in the parts where it addresses the other 3 banks. The first 128KB of the Srom has enough blank tiles and kanji tiles to edit it and make the game display properly in the USA or Europe Region setting. Mame has a nice built in debugger, but needs a custom neo geo driver to get the 8mb neoragex prom to load properly.

I've tried for a whole day to get it to work, but failed in the end. There are other neo geo sets in mame that address a single 8mb prom, svcboot and kof10th. I tried to overwrite the file names and adjust the m1 s1 rom regions and sizes in neogeo.cpp. Then compiled but just get a red or blue cross hatch screen. I tried to edit the Garou Bootleg entry with rom region and sizes of the neoragex set, but got the same thing. I tried a version of HBmame that has a some sets with a 8mb prom and changed the files from the neorage set to the hbmame set. This got the game to boot for whatever reason, but then immediately whet to a bios crash screen. I'm pretty sure both neoragex and mame prom files are in the same 16bit formats. They have areas that are the same in the upper header region when looking at the hex.

I'm at a loss here unfortunately. Can anyone please help getting the nrx set to load into mame so we can debug it.
 
So it turns out mame has all the debug data unencrypted already when using the final version rom set.

Couldn't figure out how the bank switching works. I fallowed this and was able to edit the Vram in these regions, but had no visible effect.

https://wiki.neogeodev.org/index.php?title=Fix_bankswitching

I then decided to comment out the srom bank switching in neogeo_spr.cpp. This showed the fix layer as if only the first 128kb are being read of the srom. Minimal fix layer corruption. Really only the power bars, combo counter, and the round win icons will need to be addressed. I'm going to try to burn this set and see if it behaves the same on the 161 in 1 cart.
 
Making progress. Combo, reversal topdown, ect works. Life bars and special gauge redid. Just have to do the icon for the S/P above the power gauge and the win icons. It all fits in 128kb so far without having to overwrite the neo geo into splash screen. Still haven't tried it on a 161 in 1 yet, but if there is still a bank switching issue I'll have to figure it out.

garou.jpg


Got stuck on the S/P tiles. The hex doesn't show up in the Prom like it did for the life and power bars. I think because of their animation it's in a function or routine. I'll try to mess with it some more but if anyone who is handy with assembly could help please PM me.
 
Back
Top