nesdev.org

SNgamer wrote:so, it's me again.
First off, the new host app is very well done (i know it does not belong in this thread, but i had to say this :D).

Now i have tested my 12mb HiLoRom board with some other games, but i can't get some of them to work...
I tested super metroid, which at first did not work and i found out that it checks for the size of the sram available onboard. as there is 32kb installed for LoRom games, i manually grounded A14 and A13 in order to have 8kb of sram. i checked again if the game starts, but blackscreen like before...
I also tried dezaemon (with normal 32kb sram setup on the board), which also ended in black screen and castlevania dracula x too...
i also tried star ocean, which fills all the 12mb space of the board, but here again, blackscreen (but i think it is because the patch seems to interleave the rom in gd3 format and i could not deinterleave it properly, but this is a minor issue to the main problem i have).
the only games i could get to work successfully were mario paint, super mario world and axelay.
All games i tested are LoRom games which should work on the 12mb board, but as i said, some of them do not seem to work...
of course, the switch is set to LoRom.

is there any chance of getting this thing to work properly?

Sounds like discussion for the new app thread, since these questions are about the app not the hardware. However, here's my two bits:
Super Metroid does have flashcart protection that I haven't learned to patch out yet. I'm not sure if that's related to the current issue or not. If you can find me information on its protection I'll get right on that, otherwise it'll be the next thing I do after attempting to fix the 8MByte issue.
I've never tried Dezaemon or Castlevania Dracula X, so I can't answer those at the moment. I'll pin that.
There's a known issue posted (in the new host app's thread) about uploading games larger than 8MByte, so even if it was properly deinterleaved it wouldn't work with my app at present. The issue is changes in casting of USB packets in the up-to-date libraries. I'm working on a fix.

Got it working now thanks to a tip from Danin.
The problem was the size, the roms which did not work had to be padded to 8MB size (I use now LunarExpand for this), Super Metroid and also hacks do work flawlessly (if the sram is trimmed to 8KB by grounding A13 and A14 manually as i did in order to bypass the protection manually), Castlevania also works. So for others with the same or similar problem on 12MB Board, you might want to try this too.
Now there is only left the support for bigger files than 8MB and HiRom games .

It is not that hard to break the SRAM based copy protections in the relatively few games that have them. Certainly easier than having to solder any jumpers. UCON64 usually does an ok job of cracking those protections.

MottZilla wrote:It is not that hard to break the SRAM based copy protections in the relatively few games that have them. Certainly easier than having to solder any jumpers. UCON64 usually does an ok job of cracking those protections.

I tried ucon64 on some games, but it did only seem to get rid off the regionlock ingame, but the sram protection somehow did not patch out, even though ucon64 said so. this is why i did the manual mod to my board as i wanted to know if these games do work or not.

Does anyone know how to make this check for different sized SRAM show up on an emulator like bsnes or snes9x? I could find the routine if I can get it to show (I tried doubling the size of the SRAM file and it played fine) and make an IPS patch for anyone who needed it.

Well, UCON64 strips SRam checks. If it was as easy as "getting the check to show" it wouldn't be so hard to find the data for it. I'm working on a comprehensive disassembly of several games to catch patterns in SRAM checking behavior, I assure you that if you have to ask how to get it to show, it's very likely beyond your scope of patching. We're talking assembly-level opcalls..there's also no SRAM 'file' and it's not as easy as just changing a number..

Unless of course I'm completely misinterpreting your intention here. If so, I apologize, and will attempt to re-answer the question if you can clarify your meaning.

The question as I understand it involved how to configure the emulator with a wrong SRAM size so that one can trigger the code that draws the screen and then trace backward from that code.

Well then in that case, you're looking for BSNES as an emulator. We'll pretend we're using Starfox 2 - it's the only ROM I've processed with BSNES, as I was working on patching it in a manner that would work on real hardware, and BSNES is the most hardware-accurate emulator that I know of..

Make a folder, StarFox2.sfc (or similar) and put inside it program.rom (headerless ROM file, renamed) as well as a manifest.xml

Inside manifest.xml place the code for the original ROM - I forget what exactly goes there...it can be generated by the ROM purifier that comes with the app.. Following the example of Starfox 2..
Obviously you won't have the superfx sections for a normal ROM..the important part is changing ram size and adding mappings to reflect the increased size. Beyond that, a little Google-fu will probably clear it up. Perhaps get the RAM mappings from a game with larger RAM, and the rest from your target game? Hopefully that's a leg-up.

SNgamer wrote:

MottZilla wrote:It is not that hard to break the SRAM based copy protections in the relatively few games that have them. Certainly easier than having to solder any jumpers. UCON64 usually does an ok job of cracking those protections.

I tried ucon64 on some games, but it did only seem to get rid off the regionlock ingame, but the sram protection somehow did not patch out, even though ucon64 said so. this is why i did the manual mod to my board as i wanted to know if these games do work or not.

There are atleast three different options in ucon64. One applies "slowrom fixes" which no one should need now. Another applies region lockout "fixes". Then the last is "cracks" which is option -k which deals with copy protections. I've not come across a single game that doesn't work.

Emulators are very easy to fool into having the wrong amount of SRAM available as they read the imbedded rom info/header at $FFC0 for that. Just change it and you can easily trip the protection. But you could always just check the source code for ucon64.

The problem with pattern searches though is if the pattern is too small you risk a false positive that might break a game. This chance is reduced if you aren't trying to patch every game, but instead only when you have problems. The better idea would be to check the game title string located at the imbedded info block and then searching for the pattern.

Infact you could just have a table of all the games that may need cracks and when a game is chosen to write you could prompt the user if the game detected has any patches available for region or protection cracking, asking them if they wish to use them.

There is not a huge number of games that need these cracks. This is from a list I have.

Breath of Fire II
Demon's Crest*
Donkey Kong Country 1,2,3*
Earthbound*
Front Mission - Gun Hazard (J) - Has a note about translated version I believe.
Killer Instinct*
Kirby's Dream Course
Lufia II - Rise of the Sinistrals
Mario no Super Picross
Mega Man X*
Super Mario All-Stars*
Super Mario All-Stars & World
Super Metroid*
Tetris Attack
Uniracers


Ofcourse this list is just some old list I found which may have some inaccuracies and may be incomplete. Those with * I know have protection for sure.

Danin wrote:Well, UCON64 strips SRam checks. If it was as easy as "getting the check to show" it wouldn't be so hard to find the data for it. I'm working on a comprehensive disassembly of several games to catch patterns in SRAM checking behavior, I assure you that if you have to ask how to get it to show, it's very likely beyond your scope of patching. We're talking assembly-level opcalls..there's also no SRAM 'file' and it's not as easy as just changing a number..

Unless of course I'm completely misinterpreting your intention here. If so, I apologize, and will attempt to re-answer the question if you can clarify your meaning.

Don't assume because I have a low post count that I don't know what I'm talking about. I have cracked many Region checks and other protections on many of these retro systems ( I hack Game Genie assembly codes for years). I wanted to have find the routine easily instead of checking every conditional branch on the boot of the game.

I will try your method Mottzilla and if that doesn't work then I will try your suggestion Danin. Once I find the routine I plan to release a patch for that specific game and not an all in one because more than likely each game will have the check in different locations.

EDIT: Tried to look at the header and at $FFC0 and there is nothing there about the ram size in the Super Metroid (JU) rom, but it does show in other roms.

Helder wrote:Don't assume because I have a low post count that I don't know what I'm talking about. I have cracked many Region checks and other protections on many of these retro systems ( I hack Game Genie assembly codes for years). I wanted to have find the routine easily instead of checking every conditional branch on the boot of the game.

Okay, it would appear that there's been a misunderstanding here - on my part, which I apologize for.

Don't get me wrong - I guessed because of your wording that you didn't know what you were talking about. (And was wrong.) I don't care one bit about your post count - look at mine. Sounds to me - by your second post - that you knew more than I do before you even signed up. I can admit that freely. I misunderstood your question, and incorrectly judged by it - and stated that it was possible that I may've done so. I apologize if you felt slighted, it was not my intention.

Though, I ask in all curiosity - why not just read the UCON64 source code, find the patching entries, and apply them to the ROM, then create an IPS for it? That seems much easier than disassembling protection routines, especially for games like Earthbound that have a ton of them that aren't always apparent and often called many times within the game's code. I definitely agree with your intention, but the means of going about it might be a little time-hungry.

Danin wrote:

Helder wrote:Don't assume because I have a low post count that I don't know what I'm talking about. I have cracked many Region checks and other protections on many of these retro systems ( I hack Game Genie assembly codes for years). I wanted to have find the routine easily instead of checking every conditional branch on the boot of the game.

Okay, it would appear that there's been a misunderstanding here - on my part, which I apologize for.

Don't get me wrong - I guessed because of your wording that you didn't know what you were talking about. (And was wrong.) I don't care one bit about your post count - look at mine. Sounds to me - by your second post - that you knew more than I do before you even signed up. I can admit that freely. I misunderstood your question, and incorrectly judged by it - and stated that it was possible that I may've done so. I apologize if you felt slighted, it was not my intention.

Though, I ask in all curiosity - why not just read the UCON64 source code, find the patching entries, and apply them to the ROM, then create an IPS for it? That seems much easier than disassembling protection routines, especially for games like Earthbound that have a ton of them that aren't always apparent and often called many times within the game's code. I definitely agree with your intention, but the means of going about it might be a little time-hungry.

You are correct in it being time consuming but it's something I enjoy doing so to the average person it's time consuming but to me it's enjoyable plus I learn of how the game is programmed in the process.

UCON64 patches DO work on Super Metroid. I had to use it on the Zero Mission hack because I was triggering the SRAM protection. I don't remember which command-line switch you have to use though... -k maybe?

Helder wrote:You are correct in it being time consuming but it's something I enjoy doing so to the average person it's time consuming but to me it's enjoyable plus I learn of how the game is programmed in the process.

Hey, I totally respect that. If you enjoy it, and enjoy learning how it all works, more power to you. The entire host app was basically "I'm bored, I want to improve this, let's do some learning." so I really can relate. If there's anything else I can help with, I'll be more than happy to do so. There's actually a build of SNES9X that has a builtin debugger too, if you're interested I'm sure I could find a URL someplace, but I think from here maybe PM would be better than flooding this thread. Drop me a line and I'll try to chase it down.

Thanks but that is what I use as well as M.E.S.S since that has an amazing debugger and here is the patch if someone would be willing to try it out on real hardware to see if it works. This patch if for a Headered (JU) rom and completely bypasses the check routine which runs literally thousands of times with various checks in between the routine to either erase the saves or show the piracy screen and also erase the saves. If this proves successful then if there are games with such protections that have no fix in Ucon64 then I can take a look for anyone who needs it.

GG code:
6D69-17AF
DF61-1DDF

IPS Patch with Checksum Fixed: