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
Newcomer's Board / Re: Ps1 translation tutorials
« on: March 16, 2014, 11:13:12 pm »
The PSone can be considerably easier to hack, specifically because you can simply rebuild the ISO with each major hack. For example, if one wants to replace a file with another of larger size, the task can be accomplished within a matter of moments. That said, CDmage, etc., is only useful for replacing files of the same size.

Things get hairy with PSone translation, however. You must either know or learn r3000a dis/assembly. In most cases, there's simply no way around it. However, once you've located the function that parses and displays the text, it becomes a breeze.

I say that dis/assembly is required, because the spacing between font characters - typically, Japanese characters are spaced further apart, as opposed to English. Of course, this isn't always the issue with every game in existence. You might get lucky, where only a simple texture hack is required.

I should also note that most developers used their own custom CD File loading methods. For example, most CAPCOM games use an internal structure (located in the executable) that details LBA and file size, which works especially well and more reliable than standard SDK functionality.

The best emulator for hacking is most likely pSX, as it includes a memory/RAM viewer/dumper, asm view, register viewer, VRAM viewer, etc.

All said, I do not suggest translation hacking, if you've never hacked on the PSone before. Start with simple texture hacks, and work your way up from there.

I'd really like to see people getting more into PSone hacking.

KC's armips application is astoundingly useful, but there are hundreds of games that need utilities for specific file-types and such.

Furthermore, hacking on the PSone is especially easier, compared to cartridge ROM formats that need expansion, updated pointers, etc.

Gaming Discussion / Re: Final Fantasy VIII Steam Release
« on: December 15, 2013, 03:39:42 pm »
This whole "Aali's OpenGL driver" is confusing. I mean did Aali create this himself and square used his driver to put FFVIII to pc or did square make the driver,Aali modified it and since its squares they were able to use it? Im confused because if Aali made it wouldnt it be illegal for them to use it to create a game or wouldnt square be smart/capable enought to make thier own driver to port the games over?

But ya i would love to see FFIX on pc. Would be nice to have all 3 games.

I can't speak for the video driver/patch, but it was confirmed that they outright used hcs64's vgmstream for audio playback, initially giving absolutely no mention/credit to hcs and the many people who developed the vgmstream music code. Specifically, the developers of this port encoded the original MIDI data to OGG streams, setup loop points and used vgmstream to utilize the audio stream.

Once it was brought to their attention (in other words, once they were 'found out'), they released a patch which gave credit to hcs and vgmstream developers, mentioned in a text file.

Furthermore, it was reveled that this rerelease simply uses the original EXE inside of a frontend-type EXE (where the wrapper governs the original).

Basically, a lazy port-of-a-port to cash in on the brand name.

Well, first I would suggest downloading a stable version of biofat, for reference (download).

I'm not familiar with Multimedia Fusion 2 and use WinAPI, as Gemini suggested. WinAPI is simple to utilize, compact/doesn't produce bloated executables, very-well documented at Microsoft websites and compatible with all versions of Windows.

That said, a few pointers and examples:

As henke37 suggested, you'll need to know how the file is handled. Because you stated that you don't know r3000 dis/assembly, I'd suggest looking at the file in hex.

For the EMD archive file, the index (a list of file pointers) is located at the EOF (end of file), like so:

00000000 00000000 000032AC 00003584 00009ABC

The dummy entries (zeroes) represent just that - dummy data - meaning that slot is empty/blank. Judging the list above, it is shown there are 5 files located in an EMD archive, where each value is an absolute pointer to each data.

Obviously, there isn't a 'filesize list', so you'll have to manually calculate the sizes for each file, yourself. Hopefully, I shouldn't have to explain how to accomplish that. ;P

Once you have created your function to handle the EMD filetype, the next step is getting your menu to work, which I will only touch upon. For reference, you'll have to look into something called 'resource' - a simple tool such as 'Resource Hacker' should help.

This is my simple setup for menu IDs, running in the Windows loop (WndProc() function), under the WM_COMMAND message:

Code: [Select]
case BIO1_DIS_EMD:
szFileName = GetFileName("EMD", "Bio Hazard File (*.EMD)\0*.EMD\0\0");

BIO1_DIS_EMD is the menu ID, located in resource and 'activate' only when the user selects the appropriate option from the menu.

The GetFileName() function is a simple frontend, of sorts, for Microsoft's GetOpenFileName() function that uses a dialog window to select any given name of a file.

Bio1 is a class for the "Bio Hazard / Resident Evil" game, where DisArchive() is the actual function that handles the file (extracts all contents from an EMD archive).

Beyond that, there's not much else that I can help you with, as I haven't the time to teach programming skills. I hope that helps. :)

Create a Win32 project and you have exactly what you need to develop a BioFAT clone.

Ironic, because the classes I've created are part of something of a whole, which I call "BioClone".

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: November 07, 2013, 08:11:35 pm »
A very small amount of data is stored for the original Metroid.

Save data for original Metroid is 0x28 bytes, and begins with the following 'header':

Code: [Select]
Hex: 11 19 19 30 52 4F 49 44 5F 33 5F 42

The rest of the data...

Code: [Select]
57 CC 00 20 00 00 00 00 00 00 00 00 00 02 06 06 00 00 50 36 A4 BB 66 46 64 66
...somehow produces the following password:

002000 000000
00W06O 0000bD

As mentioned, I ported the essential code from John Ratliff's password generator, ran that password through it and dumped both the raw and decoded data - no match. It doesn't even resemble the data provided in the Zero Mission SRAM.

I should note that the password generator code was successfully ported, and is verified to be working 100% properly - there isn't any error.

Here are both the raw and decoded forms of data, from the password above, ran through the password algorithm:

Code: [Select]
00 00 80 00 00 00 00 00 00 00 08 00 19 80 00 00 09 4D 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 10 00 33 00 00 00 00 09 4D 00 00 00 00 00 00

Any attempt to manually modify the data will result in a black screen upon boot of original Metroid; pressing start button will go to the title screen. The save data gets erased and the password is reset to NULL (all zeroes).

That said, I believe the MZM data for original Metroid is custom, unless the data goes through more conversions and en/decodings (note: I never looked into FDS savegame data).

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: November 07, 2013, 03:58:20 pm »
I can haz special edition GBA?! :D

^ I have no idea how to change the ID, as it seems to be hardcoded into the ROM.

I've also made more progress with the overall SRAM of Zero Mission... and the amount of checksums this thing undergoes is fucking ridiculous.

1 checksum for the header + two backups (total of 3)
1 for each save game+backup (total of 6)
1 for each 'key' setting (total of 4)
1 for 'time attack' + backup (total of 2)
1 for original Metroid data + backup (total of 2)

...for a grand total of 17 checksums (!), and I haven't even looked into the button log info for the Demo that plays at the title screen (produced by Debug ver. ROM, usable in retail).

The original Metroid data is strange (to me), and any attempt to modify it results in erasure. I included John Ratliff's password algorithm code into my app, to see if the raw and/or converted data is the same as MZM data... and it is not.

The original Metroid data begins at offset 0x7FD8, and backup is stored at 0x7FB0. Any help figuring this last piece of the puzzle would be appreciated.

Furthermore, because I went through the trouble of including John Ratliff's password algorithm, the app I am creating will be a universal savegame creator/modifier for the following games:

Metroid II (nothing coded, yet)
Super Metroid
Metroid Fusion
Metroid Zero Mission

With the exception of figuring out how original Metroid data is handled for MZM, the only thing left to do is creation of GUI dialog, so, this app will be finished soon.

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: October 31, 2013, 02:11:58 pm »
Small Progress Report:

The "hypothetical 4th save slot", mentioned earlier in this thread, isn't a buffer area.

It is a backup slot. In fact, the area 0x36E0~0x6D40 (0x1220*3) is reserved for backup-copies of the three save games.

For example, if the data in save slot #2 is corrupt, you will receive the following error message, and the backup located at 0x4900 will be copied to 0x12A0 (the area reserved for save slot #2):

That said, each save slot ID is stored twice in the SRAM and should be properly handled during modification, deletion, copy, etc.

November 02, 2013, 12:57:37 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Small Progress Report:

Metroid Fusion uses the same algorithm for checksum calculation, only the SRAM is structured slightly different.

Each save game is 0x1200 bytes, and data begins at offset 0x200 in the SRAM. Like Zero Mission, each save game is copied for backup purpose, but again, structured differently.

Code: [Select]
Metroid Fusion Save Data
0x0200 Save Game A
0x1400 Save Game A (backup-copy)
0x2600 Save Game B
0x3800 Save Game B (backup-copy)
0x4A00 Save Game C
0x5C00 Save Game C (backup-copy)

Newcomer's Board / Re: About creating patches for multi-disc PSX games
« on: October 29, 2013, 11:13:40 pm »
FF7 FF8 and FF9 use LBA tables to reference files and data.

The same can be said for basically all games from CAPCOM (the various Resident Evil games, MegaMan titles, etc). LBA tables are stored in the executable, however, using a very simple structure called "CdPos". On occasion (Resident Evil titles, specifically), simple checksum values for each file is stored with corresponding LBA entires.

It's much faster and fail-safe to access files this way, compared to the generic SDK functionality.

That said, as Bregalad mentioned, it's all very much game-specific. When modifying the contents of archives/files, sizes will obviously change, in which case you'll be obligated to patch each disc in order to correct the LBA table.

Personal Projects / Re: Mega Man 9 NES
« on: October 26, 2013, 10:55:39 pm »
To quote The Definitive Guide to ROM Hacking for Complete Beginners:

...unless you plan to do a significant portion of the work... then most ROM hackers will avoid your attempt to start a group because it looks like you're wanting to take credit for their hard work.

Sooner or later, if I ever want to see this project done, I need to learn 6502, which is easier said than done. Right now this appears to be merely a neophytic project.

Hmm, I don't think that's the case, with all projects.

Quite honestly, I think you need to find someone who is just as passionate about the project as you are. If someone is really dedicated to such a task, credit is subjective in nature. After all, what's more important: e-peen+1 or making others happy by producing real results? If it's the latter, then there's absolutely nothing wrong with stepping up and leading project like this... and that usually entails learning things that you hadn't previously known (6502 assembly, in this case).

That said, I sincerely wish you the best, and definitely look forward to any progress made.

Personal Projects / Re: Capcom Games Editor (NES)
« on: October 26, 2013, 10:40:51 pm »
Megaman series, perhaps ?

Being the definitive series for the NES, by CAPCOM, I second this notion.

...and to answer your question, spiiin, yes - I'm sure people will use this application to create some new stuff.

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: October 25, 2013, 10:41:36 am »
Well, that certainly worked, x0_000. Many thanks to You! :beer:

In your initial post, you made it seem like the strings are to be written afterward, which is exactly where I went wrong.

Anyways, it's fixed now, and here's the code in C (for future reference from anyone interested):

Code: [Select]
// This brief example sums an extracted save slot data (0),
// beginning at 0x80 in the SRAM file (0x1220 bytes).

signed int Sum = 0;
signed int Buf = 0;
signed int NegSum = 0;
signed long int _Offset = 0x00; // Starting at "ZERO_MISSION_010" string

for(unsigned int n = 0; n < 1159; n++, _Offset+=0x04)
case 0x10:
case 0x14:
fseek(_File, _Offset, SEEK_SET);
fread(&Buf, 4, 1, _File);

Buf && 0xFFFFFFFF;
Sum += Buf;


Sum -= 1;
NegSum = (-1 - Sum);

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: October 25, 2013, 12:46:56 am »
Would a Zero Mission SRAM Checksum also need to include password memory for the unlockable NES game?
Or is that already part of the SRAM data?

Good question, I'll have to get back to you on that. Guesstimate: probably.

In that case, what is the problem? The checksum is fine, and the save data is being read. What kind of behavior are you expecting this save data to have?

Sorry, I should have specified - the SRAM is modifiable while in memory, using VBA. :P

I need an algorithm for the checksum, so that I can create/edit savegames from scratch, without the use of an emulator. Again, any help is very much appreciated, and you will be credited in the app that I finish creating.

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: October 25, 2013, 12:15:00 am »
Slot 0/A

I know these screenshots seem 'messed-up'/impossible, but they are the result of various modifications (and verified working). If you're curious, SRAM can be modified after bootup, hence how I was able to map it without a checksum algorithm. The checksum will be recalculated at system shutdown or player death (return to title).

October 25, 2013, 12:18:48 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Although it looks like you also put data at where a hypothetical 4th save slot would be.

That's quite interesting, but no, I did not put data into the hypothetical 4th save slot. Perhaps, it is a temporary buffer area?

ROM Hacking Discussion / Re: RockMan 8 Prototype 1 - Level builder
« on: October 24, 2013, 10:50:42 pm »
I somehow overlooked this during my initial sweep, heh.

...aaaand it's b0rken - there isn't any controller functionality for this and required a nasty asm hack to get it working.

The "OBJECT TEST MODE" can be fixed, though, I'm not sure it would be worth the effort.

In addition, this build contains the exact-same "PAGE SELECT MODE" that is found in the 2nd alpha-prototype (example).

Also, this build contains a "SOUND TEST" similar to that found in the retail version (example), but completely lacking the EQ. Some statistical strings are different, as well ("EDT" and "SUB" are missing). Just like retail version, a hack was required to get the statistical strings to be displayed.

...and last, but not least, there is a simple function that displays the player position and health (not worth picturing).

I'll have a new patch available, soon.

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: October 24, 2013, 10:32:45 pm »
Hmm... that didn't seem to work.


I've provided a working SRAM file, in entirety - it won't be difficult to isolate the individual (0x1220 byte) save data.

If you figure a solution, please provide the mathematical algorithm in c/c++ format. :D

ROM Hacking Discussion / Re: MegaMan 8 - Debug Menu
« on: October 20, 2013, 08:37:18 pm »
The Cutting Room Floor I'm sure would love to see this documented on their Megaman 8 wiki page.

Protodude, from "Protodude's Rockman Corner" suggested that I do the same, and I've already whored my results at the tcrf forum: :P

Besides archival purpose of the original, hidden functionality, the real purpose of my work on these debugging features will be for a future ROM hacking project.

So far, I've built a PAC archive file dis/assembler to extract+repack contents (both PSone and Saturn version supported), and a ROM/ISO rebuilder (PSone version, only).

From what I've been told (and read from others), it will be the first MM8 hack. Hopefully, many more will follow.

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: October 18, 2013, 08:13:04 pm »
You start at SaveOffset, 0x0. When I say "word" I mean a sequence of 4 bytes, which are reversed in the ROM, so the sequence 0x0 0x1 0x2 0x3 in the ROM should be read 0x03020100. Also it might not be clear, but you save X and -1-X as a word as well.

Ah, okay. Seems simple enough.

I just needed clarity, because a WORD in my compiler is only 2bytes, as I stated, where a DWORD is 4bytes. I had a feeling there'd be something different about GBA architecture.

Again, many thanks for your help!

ROM Hacking Discussion / Re: MegaMan 8 - Debug Menu
« on: October 18, 2013, 08:09:09 pm »
It would be nice if you added ASM patches for both unaltered debug menus (for such purposes as documenting debugging features, like in tcrf), and for the tweaked one you made.
Interesting :)

Also one more noobish question: Is Playstation asm that hard and terrifying as people on the net suggest? (I'm a noob who can't even figure out in 65c18 how to hook code to somewhere far away in the rom because I don't know if i should put the hi-rom adress with JSR or the memory adress or the absolute adress starting from 0)
And do you have a documentation with you to share to the poor soul yours faithfully? I love collecting those for potential future endeavors.
I though it uses exclusively r30000 but I saw some debuggers fro psx emulators having r5900 (wtf?)

I admire your work. It's something like magic for me at this point  ;D

I plan to release two patches - one for the unaltered functionality (as seen in the first post of this thread), and the other containing fixes and brand-new injections I've made. I know all too well how purists can be. :P

As for R3000 dis/assembly, it's fairly easy if you have a decent understanding of how simple programming works. For example, if you've ever written an application in c/c++, then ASM language should be a breeze to learn. If not, it never hurts to pick up a new hobby. It could certainly be debated, but I'd say that learning ASM is actually easier (as opposed to c/c++), but only because there is so very few things to remember.

Here are a few resources:

The PSone strictly uses R3000, whereas the PS2 uses R5900. I can only assume that the emulators you've tried have either completed and/or in-development support for the PS2.

...and, it should go without saying that the results I've produced are many thanks to KC's armips application, found here:,8413.0.html

Many thanks for the feedback! It keeps me going... :D

October 19, 2013, 02:34:16 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I figured out what the "FLAGCHANGE" menu is used for...

Programming / Re: armips assembler (v0.7c released!)
« on: October 18, 2013, 07:25:53 pm »
This application is, by far, the best utility I've ever used for PSone projects... so, many thanks, praise and spanks!

This may be bit of an oxy-moron (aka, dumb question to ask), but is there any chance of disassembling capabilities? For instance, it would be great to dump certain areas of R3000 code to modifiable text.

Furthermore, any chance to add support for PSone PSY-Q symbol format (*.sym files)? It would be great to dis/assemble those, as well.

Programming / Re: Metroid Zero Mission - SRAM Checksum
« on: October 18, 2013, 07:15:46 pm »
@snarfblam - Thanks for the link! I was previously unaware of that Metroid community.

Wow, many thanks, x0_000! :o

I'll try the method you describe, asap.

I'm just confused on a few things:

1. Add all the words in the save slot except the words at [SaveOffset,0x10], [SaveOffset,0x14] and subtract 1 (Call this X.) Store X in [SaveOffset,0x10] and -1-X in [SaveOffset,0x14].

Do I start at [SaveOffset,0x18] or [SaveOffset,0x00]?

Also, words for my compiler are 2bytes, is it the same size for GBA? Endian-swapping isn't an issue for me, but should I take it into account?

Pages: 1 2 [3] 4