News: 11 March 2016 - Forum Rules

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - MeganGrass

Pages: [1] 2 3 4
Programming / Resident Evil 4 CRC [GameCube/PS2]
« on: August 31, 2021, 04:33:47 pm »
Code: [Select]
UINT CRCTable[0x100]{ NULL };

    // Variable
    UINT Bit = 0;
    UINT nBit;
    UINT pTable = 0;

    // Initialize
    do {
        nBit = 0;
        do {
            if ((Bit & 0x80000000) == 0) { Bit = Bit << 1; }
            else { Bit = Bit << 1 ^ 0x4C11DB7; }
        } while (nBit < 8);
        (CRCTable)[pTable] = Bit;
        Bit = pTable * 0x1000000;
    } while (pTable < 0x100);

    // Complete
UINT CalcCRC(UCHAR* Data, UINT len) {

    // Variable
    UINT Bit;
    UINT tmpCRC = NULL;
    UINT pData = 0;

    // Calculate
    if (len != 0) {
        Bit = 0;
        do {
            tmpCRC = tmpCRC << 8 ^ (CRCTable)[Bit ^ Data[pData]];
            Bit = tmpCRC >> 0x18;
        } while (pData < len);

    // Complete
    return tmpCRC;

If the save data is "System Data,"
Code: [Select]
CRC = CalcCRC(&GCIFile[0x40], 0x1E78); and CRC is stored at 0x1EB8.

If the save data is regular progression saves,
Code: [Select]
CRC = CalcCRC(&GCIFile[0x40], 0xEAF8); and CRC is stored at 0xEB38.

This code likely works on the Wii/PC versions as well (untested).

Programming / Metroid Prime Savegame CRC [GameCube]
« on: August 31, 2021, 04:25:34 pm »
I was curious about hacking this game's save files and was unable to find anything about it, except savestate hacking which I'm not aiming for. Soo.. I was able to create a quick bypass.

This AR code only works for v1.0 of the game and it simply Nop's the if/else branch if a mismatch is found. When active, you can save/load the game normally, and also load hacked GCI savegames without the game fussing about corruption and deleting the data.

Code: [Select]
$Bypass CRC Mismatch Error
0434ebd4 60000000

The actual CRC value calculation function appears to be located at 80315590, and it seems simple enough, but I can't find the proper value/s used to perform the bitwise operations. So, no tool for now.

Interestingly enough, it appears that the Trial/Demo version of Metroid Prime includes this exact same checksum algorithm; the function for that version is located at 8027260C. Maybe it's possible to force the Trial/Demo version to load save data..?

(For Slot A) The obtainable item bits start around 0x15CA and is about 0xC0 bytes. Visor opacity, brightness, etc is around 0x168A. The current suit is at 0x15D0, BE short, and accepted values appear to be 0-7.

Changing the starting location appears to be pretty tricky, and I haven't quite figured it out yet. I was able to change the save location from Tallon Overworld to Phendrana Drifts, but instead of starting at a save point, I was located at the entrance elevator.

Changing the visited areas:

...and a modified save file at the end of the game that will let you "peace out" on Ridley mid-fight and go straight to the Impact Crater:

ROM Hacking Discussion / Re: Mega Man 8 .PAC files and General Modding
« on: April 28, 2021, 02:00:42 pm »

Here's the basic utility I created for MegaMan 8 PAC files. Sorry..! Thought I had released it before..!!

It does reassemble the extracted data to PAC archives (for both PS and Saturn), but it does not disassemble the data within. Also, never mind the "MHP" option in the GUI menu; it was testing for another game entirely.

There's also an option to update the LBA stored within the PS executables, if you plan to modify the PAC containers beyond their original size. Additionally, there's some commandline options built-in to this, like so:


Sadly, I don't quite recall exactly how the LBA updater works atm, but I can look into it if needed; I still have the source. Just DM me.

I initially had plans to reverse-engineer this game after I discovered the retail build had a fully functional debug menu hidden within, but I got extremely busy with work plus college, and kind of moved on with other things.

What I do remember is is what you've already mentioned: there's raw pixel and palette data in the PAC files. Specifically for the PS version, the palette data is stored in huge chunks, where each palette is 0x20 bytes (4bpp).

There's also chunks of code in some of these, more commonly referred to as overlays. I don't recall if they're statically or dynamically placed in memory, as this is about the point where I stopped. There's a GUI option to inject the overlays into the executable for debugging (this was pre-Ghidra days).

Beyond that, here are some notes I made when going through this executable with IDA years ago:

Code: [Select]
// SLUS_004.53

// Controller
801B2954 // Controller 1
801B2958 // Controller 1 (delay)
801B295C // Controller 2
801B2960 // Controller 2 (delay)

800F8864 // ref in main
800FEF94 //
800FF47C //
800FF5C0 //
80101488 // (unused reference)
801019D0 // Main Game
80103B14 // (unused reference)

// STR
800FD444 // Controller Input for Miscellaneous STR
800FD5B8 // Miscellaneous STR
800FD654 // STR Playback (StSetStream, DecDCT) 0x2CC bytes
800FD9C8 // STR Playback (DecDCT) 0x284 bytes

// General
800FCD84 // Pre-Graphic (Swirl, Block, etc)
800FEBEC // Dr. Light's Lab
801003FC // Lost Life, Reset Level (use args)
80100438 // Lost Life, Reset Level (use args)
801004A8 // Now Loading (use args)
80100660 // Lost Life, Reset Level at Continue Point (use args)
8010073C // Now Loading (use args)
801008C8 // Exit to Stage Select
80100954 // Exit to Stage Select
80100A20 // Exit to Stage Select
80100A34 // Initialize Intro Stage
80100C34 // Initialize Stage
801010B0 // Graphic + Stage Clear + Save Game
8010123C // Stage Clear + Save Game
80101460 // End Credits
801017A4 // Display Tile Data
801218C0 // Save Game
80121CD4 // End Credits
80134944 // Title Screen
80134AFC // Title Screen
80134C2C // Title Screen

// Debug
80134E7C // Debug Menu
80134FA0 // MAIN MENU
801350F0 // FLAGCHANGE
80135368 // WORKVIEW
80135738 // VABVIEW
80135A8C // POWERUP
80135D74 // PARTS
8013609C // Statistical Display for FLAGCHANGE
801363F4 // Preset Variables for FLAGCHANGE
80136438 // Selection Cursor
801364D8 // WORKVIEW (Page 1)
801365D8 // WORKVIEW (Page 2)
80136728 // WORKVIEW (Page 3)
801367C4 // WORKVIEW (Page 4)
801368C4 // SOUND TEST
80136AF8 // SOUND TEST Equalizer

// Variables
8015E282 // Invulnerable (0x01=MAX)
8015E283 // Energy (0x80=MAX)
801C336E // Level ID
801C3370 // Lives (0x09=MAX)
801C3371 // Level Point ID
801C3373 // Level Load Flag (if 1, stage file is reloaded from disc)
801C3374 // Level Continue Pt Flag (if 1, "Continue Point" screen is displayed)
801D28F8 // Current BGM ID

Code: [Select]
This code controls which graphic will display when entering levels, etc.

li $v0, 1
sb $v0, 0x801D1848
j 0x80102E84
li $a0, 0x02 ; argument values range from 0x00~0x13
j 0x800FCD84

// values
0x00 Multi Swirl (Stage Load)
0x01 Multi Swirl (Stage Load)
0x02 Block Zoom (Title Screen) (Screen black as visible block area gets larger)
0x03 Block Zoom (Title Screen) (opposite of above)
0x04 Snake Domino (Screen black as visible block produces domino effect)
0x05 Snake Domino (opposite of above)
0x06 Ripple 1 (Screen black as visibility ripples downward)
0x07 Ripple 2 (Screen black as visibility ripples upward)
0x08 Ripple 3 (Screen black as visibility ripples leftward)
0x09 Ripple 4 (Screen black as visibility ripples rightward)
0x0A Ripple 5 (Stage Select)
0x0B Ripple 6 (Stage Select)
0x0C Ripple 7 (Stage Select) (Wily)
0x0D Ripple 8 (Stage Select) (Wily)
0x0E Time Swirl (Continue Point)
0x0F Time Swirl (Continue Point)
0x10 Multi Block Pt 1 (Status Screen)
0x11 Multi Block Pt 2 (Status Screen)
0x12 Same as Ripple 4, but faster
0x13 Same as Ripple 3, but faster


Code: ("STAGE00.PAC") [Select]
03 Has something to do with layout (visual)
04 Has something to do with layout (collision)
05 Has something to do with enemy sprites
09 4bpp CLUT
10 ???
14 4bpp CLUT
15 Item Description, Cutscene Text

Code: ("SELECT") [Select]
File #09
CLUT for File #11

File #10
CLUT for File #12

File #11
0x8000 bytes per chunk

00 Earth (Pt. 1)
01 Earth (Pt. 1), Font, Cursors
02 Stage Previews
03 Enemy Avatars
04 Enemy Sprites (Pt. 1)
05 Enemy Sprites (Pt. 2)
06 Enemy Sprites (Pt. 3)
07 Enemy Sprites (Pt. 4)

File #12
"Disco" graphics

April 28, 2021, 02:08:02 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Also, I found some assembly hacks I made with armips:

More specifically, these hacks enable the debug menu in MegaMan 8 USA Retail (SLUS_004.53) executable. The file-dates on this stuff is from 2012/2013, so I don't know if current builds of armips will play nicely with it.

Please note that "Stage Select" is not part of the vanilla debug menu; I created it from scratch and added it to aid any an debugging/modding efforts. Beyond that, I recall having to patch the Sound Test to get it properly working.

Personal Projects / Re: Resident Evil: True Director's Cut
« on: April 24, 2021, 12:34:52 pm »
Looking good :beer:

Thanks! I learned from the best! ;)

I might hop on our old chat client soon...?

The source code to this project is now available.



You are a goddess!
Thank you for this. :)

fix'd. You're welcome and please enjoy :)

Not exactly an unused area, just stuff that tcrf has yet to document.
Mega Man 8 [PSone] Debug Menu

News Submissions / Re: ROM Hacks: Super Mario Advance 4: eReader Version
« on: January 27, 2016, 07:04:54 pm »
Very nice! :)

...but where's the infamous "B Dash de Kakenukero!" level?

Programming / Re: Emu Accuracy analysis: FCEUX vs. NEStopia
« on: October 31, 2015, 09:27:45 am »
My guess is the name bsnes was changed when the emulator became a multi-system emulator and the name no longer seemed appropriate.
At first he added the first full support for the Super Game Boy (one emulator emulating the SNES and GB at once. Though last I tried it the GB core was still a work in progress, particularly sound. This allowed things like the SNES mode in the US/EU GB Space Invaders.) Then when cracking the ST018 expansion chip, it was discovered to have an ARM-based CPU, so with the help of a GBA hacker he added GBA support. He was also took the next logical step and and began work on DS emulation but dropped it once he realized the DS was too different to continue supporting it. Not sure how the NES got added in.

byuu was working on Far East of Eden Zero, so he renamed his emulator after the main character of that game. Maybe he had other reasons, though, I can't remember.

Ah, that makes sense. I wouldn't completely disregard an emulator because of the name given to it, however, I do disregard bloatware. I wouldn't download and use a file compression utility that doubles as an internet chat messenger. That is an outrageous example, but the same principal applies.

Too much is too much.

I wouldn't recommend Higan for casual users to use.  I'd recommend SNES9X instead.  Higan is made exclusively for accuracy-enthusiasts who have the hardware and technical know-how to deal with the quirks of using it and configuring everything properly.  They also have to be willing to not bother sending suggestions to byuu and stick purely with noting bug reports if they want to contribute to development (or fork the code if they can do programming).

People can complain about Higan but it is under GPL so just fork it and stick it up on GitHub and change the stupid UI/folder system to something better.  Perhaps use the 'Performance' core by default and integrate all 3 cores as a menu option instead of seperate executables.

Good point.

It just gives me peace of mind in knowing that the author put real care and thought into development, as opposed to those who've attempted the same for the sole purpose of bragging rights. It's nice knowing that when I boot a game with Higan it will work as the original developers intended, and that's something that other emulators can't guarantee.

I do recommend Higan for ROM hackers, though. All too often, people have designed hacks using something like ZSNES as a base for testing, without even putting any thought towards whether it will work on real hardware. On the emulation side of things, Higan is as close as one can get to that. I will respect a hack that works on real hardware much better than one that doesn't, no matter the grand scheme of said hack.

...and I can write c/c++ programming language just fine and have a pretty decent understanding of video game programming and such, I just don't feel the need to take it that far.

The thing with byuu is they always march to the beat of their own drummer.  That's just how it goes; their emulator their rules in a way.  Not that I agree with it but that is how they decided to do it.  They never made Higan for the community; it was always a personal passion project.  I find it ironic that byuu expects the wider emulation community to adopt Higan as a standard when he's so openly hostile to anyone that doesn't agree with them.

I totally understand the passion project aspect, I have a few of those myself. When it comes to presenting my results to the public, I can also handle constructive criticism, though... and that's where I begin to lose respect -- byuu doesn't even begin to consider that what he's done with the file/folder thing is just flat-out absurd, especially when he expects everyone to accept it.

Sometimes, the concept just isn't acceptable. It sounds good in theory, but is absolutely horrid in standard practice. It sucks to let go of these kinds of ideas, I've had to do it myself, but if one expects everyone at large to adopt, exceptions have to be made -- not the other way around in the case of the folder/file ordeal. There are much better ways to handle the situation and telling everyone to piss off most definitely isn't the right way to go about it when you're trying to get everyone to love you.

Programming / Re: Emu Accuracy analysis: FCEUX vs. NEStopia
« on: October 30, 2015, 09:38:31 pm »
Sounds like I'll never be using it then. I just want to play and hack games. I don't want that experience to be ruined by what seems like the author's bizarre and unhealthy fixation on something that's been taken to an illogical extreme to the detriment of the user.

Please, don't let my opinion prevent you from at least trying it. Seriously.

It's a most excellent emulator! just isn't user-friendly, at all.

Programming / Re: Emu Accuracy analysis: FCEUX vs. NEStopia
« on: October 30, 2015, 08:09:16 pm »
The dedication to accuracy that byuu has put into bsnes has always interested me and definitely will always have my utmost respect. His work on special chips is still an amazing accomplishment that I will always adore.

Rather unfortunately, everything became a mess when the file/folder thing was forced upon everyone; It's completely unnecessary and inconvenient. To make matters worse, everyone who has voiced their disliking of that "feature" is typically met with a "fuck off" type of response. Stop trying to make fetch happen, it isn't going to happen.

On top of that, you're practically forced to use an external app (snespurify) to manage your rom data before you can even boot a ROM in the emulator for the first time.

Accuracy doesn't matter in emulators when one has to jump through hoops to get the darned thing to boot... and not that it matters in terms of usability, but the "bsnes" title is infinitely better than "higan".

I hate that I have these complaints, I really just wish the emulator wasn't a hassle to use.

Programming / Re: NES equivalent for VBA's disassembler?
« on: September 20, 2015, 11:52:49 am »
So for GBA games, VBA has an ASM decompiler that lets you type in a ROM offset and attempts to interpret it as ASM code.

This program will let you disassemble a NES rom from any offset. The output disassembly can be recompiled, etc.

Like Disch said, you need to use FCEUX to obtain the ROM file offsets then feed it to the app. It also expects a program counter, for example:

$C000 - Program counter
0x03C010 - ROM File Offset

Example Commandline:
x6502 label address org 0xC000 start 0x03C010 finish 0x040010 rom ".\Mega Man 2.nes" out ".\DisAsm.s"

I don't understand. If you want to see how a game plays, you certainly won't be watching a speedrun, because those plays the game as quickly as possible, often by exploiting all kind of glitches.

For me, that's the entire point.

If I truly don't give a crap about it then I definitely don't want to spend hours of my life watching a video of it. Otherwise, I'm stuck with some amateur "reviewer" who makes immature sound effects and other failed attempts at humor, and that's if I'm even lucky enough to find something about it. Or even worse, some asshole who records every their every facial expression and embeds a small view in the a corner.

Also, not every every speed run exploits known glitches.

You'll only watch a speedrun if you already know the game very well.

Thus the argument that "speedruns are free publicity for the game" is nonsense.

Yeah, well, you know, that's just like, uh, your opinion, man. ;P

There's always exceptions.

I KNOW I can't be the only person in the world who's watched a video on youtube and said to myself "This game looks way more fun than I thought it would be". That's good for business. And to go back to something I said earlier, no review could give you a realistic sense of what a game actually plays like because they are all only about a few minutes long and only graze and generalize each aspect of the game. Actually watching someone play a game is a totally different experience and will give you a more realistic impression of what a game plays like. Anyone can make a game look good or bad with a few clips and deceiving words if that is their desire.

No, you're definitely not the only person.

On a personal note, I never trust any reviewer or critic, no matter how reputable they may be. These people don't speak for me and my interests... but like you, seeing and hearing a game being sampled on YouTube can definitely change my mind about something, even if it's the most trivial of ROM hacks.

And for games that I already have, I can't tell you how many times I watched a speedrun and dug out a game that I hadn't played in a long time because a video showed me how to make the most annoying parts (that prevented me from replaying as often) much easier. I just don't see how these videos are a realistic threat. Maybe some of the hack videos could be a negligible threat to Mario Maker but not enough of a threat that Nintendo should go after these videos. They're just being childish and playing right into the "giant corporate assholes" stereotype that people love to hate.

I get what you're saying here, and I could note  few examples of this myself, however, I would argue that speed runs are absolutely awful for business. ROM hack or no ROM hack.

Personally, I only watch speed runs when I don't want to actually play the game, but I'm still interested in seeing what it's all about. The only exception to this is when I want to see that new found glitch that everyone is talking about.

And before it comes back again, for me the real issue is not whether Nintendo has a right to do this because they obviously do. "Is it worth the effort?" is the better question. Honestly, I wouldn't even care if it weren't for the fact that I like some of these videos and a number of them have either given me a greater appreciation for a game I already had or showed that a game that I didn't have was actually worth my money and attention. Nintendo is stepping on my balls...

I don't have balls for Nintendo to step upon, but this recent move is rather unsettling.

As I mentioned before, it wouldn't make any difference if they scrub all videos from the internet - it most certainly isn't going to save their current video game console and it will only help to further hurt the brand by outcasting its own fan base.

I stand by my previous statement: This is yet another dumb move by Nintendo. I'm not sure what, if anything, can redeem them at this point.

Don't get me wrong.  I pirate shit all the time.  I don't have a problem with it.  The only real difference between us is I don't feel the need to rationalize it.  I don't like fooling myself.

Yup, I feel the same.

Gemini and myself recently chatted briefly about how discovering emulation changed our lives, way back when. In one instant, one may gain access to video games that they couldn't have previously enjoyed. Whether it be poverty and the inability to purchase, outdated or out of print systems and consoles, regional hindrance and anything else unforeseen, ROM sets can really open doors for many people, creatively speaking.

That feel for me were several of the NES Mega Man games that I had only dreamed about as a child. I would later go on to purchase the entire collection, but before that, I hacked video games as means of a creative outlet in order to stay busy so that I could ditch drug and alcohol abuse. I probably couldn't have accomplished that if it weren't for piracy.

That said, I wouldn't just start downloading movies, music and games for the sake of having them for my pleasure. There's a very fine line between honest intentions and just flat-out stealing.

Censorship much, Nintendo?

Pretty dumb move to alienate the very same people who likely gave inspiration for Mario Maker, especially when the company has been in dire straits for years.

Nintendo's nostalgia machine will eventually break down completely. The very same people they depend upon to buy the same recycled ideas year after year aren't going to be around to support them forever, and the facts are everywhere to support this notion. This blatant action to shit on the fanbase is a prime example of how desperate they really are.

Even if they managed to completely scrub the entire internet of ROM hacks, nothing would be enough to save this complete flop of a video game console. The writing is on the wall.

Mario Maker most definitely looks like a lot of fun, but doesn't allow for custom AI, custom textures, custom music and so on. The right people who are interested enough will find their way.

Programming / Re: x6502 Ricoh 2A03 Disassembler
« on: September 10, 2015, 03:47:16 pm »
The original topic is located here.

I don't have Windows 10 installed on any of my computers, so I have no way of testing anything on that operating system.

It works perfectly as intended on XP, 7 (both x86 and x64) and 8 (x64)

Pages: [1] 2 3 4