1

News Submissions / Re: ROM Hacks: New Hacks Added to the Database

« on: November 06, 2019, 12:31:22 pm »

I'd really love to be able to play that debugged Pokemon Stadium game, because I've always kind of wanted to make boss fights out of certain Pokemon, but none of the xdelta Patcher that I have seem to be working with the patches, and the xdelta Patcher that actually comes with the patch files doesn't seem to be working on my computer. It pops up for a split second and then vanishes. there's also a file that it won't let me unzip. Can someone help me get a patched file?

Just create a empty text file in the same folder, write this inside:

Code: [Select]

xdelta3 -d -s PokSta2-US.n64 jrra-np3e0-v1.xdelta out.n64
pause
Replace "PokSta2-US.n64" with the name of your rom file. And rename the text file as "whatever.bat" (be sure that is not "whatever.bat.txt"). Double click the file and done.

If your rom file name has white spaces you need to escape them with quotes, ex: "Pokemon Stadium 2.n64"

2

ROM Hacking Discussion / Re: YouTube/Google Video thread

« on: October 28, 2019, 05:15:32 pm »

https://webmshare.com/play/wZZ3R

fft wotl treasure hunter 9-bit rare items.

[Spoiler:]

3

ROM Hacking Discussion / [PSP] Final Fantasy Tactics - ULUS10297 - ASM Hacks

« on: October 15, 2019, 11:52:06 am »

Patch:
-Platform: PSP
-Game: Final Fantasy Tactics - War of the Lions (ULUS10297)
-Type: Improvement
-Name: FFT-RG
-Version: Alpha
-Hacks included:

Spoiler:

--Slowdown fix v2(Similar to already known slowdown fix)
--Add spell quotes back to the game
--Spell quotes always pop up
--Unlock novels
--Smart Encounters
--Battle Initial Camera v2
--Abilities in Arith skillset can be reflected
--Unlocked jobs v2(Removes all non level requirements for jobs)
--Battle jobs list(Fix what status jobs list show in battle)
--Formula 36 is now +PA_(X) and +MA_(Y)
--Mighty sword v2
--Crits always deal 50 percent bonus damage
--Remove dupe font data
--Replace font file ENG version
--Replace font width file ENG version
--Replace spell.mes file
--Replace snplmes.bin file
--Replace wldmes.bin file
--Rewrite all quick access text
--Null slps file in fftpack
--Null atchelp.lzw file in fftpack
--Null open.lzw file in fftpack
--Null world.lzw file in fftpack
--Null all quick text in the boot file
--Replace all quick access text

-Created with: Valhalla (alpha)
-These hacks were made by xjamxx only.
-Special thanks to: RafaGam, NoOneee, melonhead and Archaemic
-Download: here

4

ROM Hacking Discussion / Re: [Technical] [LZ?] Please, explain me compression algoritm in attached file.

« on: September 21, 2019, 01:23:29 pm »

That's a lot more info than the previous file, here a simple analysis:

Code: [Select]

'C(43)','h(68)','a(61)','n(6e)',
=Chan

'cellor(1b63)',':(3a)',
=cellor:

ff

' (20)','K(4b)','i(69)','n(6e)','g(67)',
= King

' (20)','P(50)','a(61)',
= Pa

f7

'p(70)','a(61)','s(73)','... I(3fa2)',
=pas... I

' (20)','u(75)','n(6e)','d(64)',
= und

fb

'e(65)','r(72)','sta(e2d0)','n(6e)','d(64)',
=erstand

' (20)','y(79)','o(6f)',
= yo

ff

'u(75)','\'(8166)','r(72)','e(65)',
=u're

' (20)','a(61)','n(6e)',
= an

ff

'x(78)','i(69)','o(6f)','u(75)','s(73)',',(2c)'
=xious,

' (20)','r(72)','eally(7d655071)',
= really

' (20)','I(49)',
= I

' (20)','d(64)','o(6f)','...(243f)'
= do...{end}

ffIndeed there's some sort of compression.

I don't think it is a dictionary compression. It could be a font compression (when you pack in a kanji slot many latin signs like 'ill')...

But this "sta(e2d0)" doesn't fit well in that theory...

And neither this "eally(7d655071)" 5 chars in 4 bytes...

Also there are no "NewLine" or "Page" special chars, those ff, f7 and fb must for that...

Hope these vagues ideas help you.

5

ROM Hacking Discussion / Re: [Technical] [LZ?] Please, explain me compression algoritm in attached file.

« on: September 21, 2019, 11:44:40 am »

I don't think this goes here:

Minor problems, informal help, and other regular forum inquiries should go in the ROM Hacking Discussion section or other more appropriate section.

Anyway,

From 0x455EA to the end (plus your description) it doesn't seem to be compressed (most of the text can be read).
Is more like text with commands, for example:
-the FF could be some sort of Pad or Pause
-the other F? could be bold font, sounds, references to names, pointers for more text or special objects.

In the end, it depends on context. I mean you should find a piece of file with some or all these commands and know what the game displays for that chunk of data while you play.

Probably the asm hacker of DQ Translations Team, is one of the few ppl that knows what you want.

6

ROM Hacking Discussion / Re: YouTube/Google Video thread

« on: September 19, 2019, 10:12:06 am »

https://webmshare.com/play/Lxe4e

fft wotl nanai novel (partial font edit).

7

Programming / Re: [Help] Repositioning a single sprite.

« on: September 17, 2019, 11:02:06 pm »

Lets explain a bit what each ips does:

-badprg.ips
Makes the modded PRG to have the same CRC as the vanilla PRG (09499f4d). But writes 4 bytes in the last for 4 bytes of the PRG (it won't load in any emu). Is just a bad PRG. Only use for testing purposes.

-expanded.ips (this is the one that didn't work for VirtuaNes)
Similar to -badprg.ips, but here in the NES header PRG size goes from 16 to 17 (so now the PRG is 0x44000 bytes long). I was hoping that adding a 0x4000 zeroed section with the last 4 bytes changed so PRG CRC match with vanilla, could bypass VirtuaNes prg-crc validation. But it just create another bad PRG rom. Only use for testing purposes.

-allcrc.ips
Here the entire rom file is tweaked to match vanilla rom CRC (a69079d4), without increasing the file size (for some reason beyond the scope of this thread, i needed to add 4 zeros to get the 4 bytes for padding). This patch won't work with VirtuaNes since PRG CRC is different from vanilla.

-allcrc-padded.ips
Similar to -allcrc.ips but rom size will increase by 4 bytes in order to fix the rom CRC. This patch won't work with VirtuaNes since PRG CRC is different from vanilla.

The big issue with VirtuaNes is that the emu reads only the PRG, so the size of PRG can't be changed and the last 6 bytes of PRG are important, tweaking the PRG to match the vanilla CRC is more complex (you must use something like spoof and specify what bytes can be used to tweak)

Now go back to work in VirtuaNES, but ceased to be compatible with puNES, and the official compilation of FCEUX, since in this hack the mapper 16 is changed by the mapper 17.

 On the other hand I use to compile VirtuaNES Plus, so I could not find the hexadecimal value given.

Don't change the mapper.
I tried with FCEUX 2.2.3 and it works (it never needed crc fixing)
I tried with puNES and it works (it doesn't need crc fixing)
VirtuaNES Plus, really hard to know which binary exe you have, but i tried this and it had the hex value (4D9F4909) twice.

Remember that every time you mod the PRG (even if its one bit), the crc will change so you will need to update whatever solution you are using to run the ROM in VirtuaNes.

8

Programming / Re: [Help] Repositioning a single sprite.

« on: September 17, 2019, 01:57:33 pm »

Here

Or

Just open the VirtuaNes.exe file (yes the exe) in a hex editor, search for (as hex value):
4D9F4909
You should see 2 hits (at least), then replace both with the modded PRG crc (change byte order), the OP original IPS has this one:
A5B3F339

And forget about fixing the crc.

[Spoiler:]

9

Programming / Re: [Help] Repositioning a single sprite.

« on: September 16, 2019, 09:13:35 am »

First, sics:

Nes rom (yes the .nes file), has sections:
-Header 16 bytes
-Optional whatever (the current rom we are talking doesn't have this)
-PRG Rom data (in this rom is 0x40000 bytes long)
-CHR Rom data (another xxxx bytes long)
-Optional (or not dunno) more whatever

You need to dump as a separate binary file from 0x000010 to 0x040010 (here is your B1-> A8 mod at 62b3)

You need to "tweak" this entire binary file, for crc-32 this can be done by modifying the last 4 bytes (if they are important for the PRG rom, it could be a issue)(first set them to zero, do all the stuff explained above and get your new 4 bytes).

Now with the tweaked file (0x40000 byte long), put it back in the rom file. In this case you will modify 62c3 and 4000c-4000d-4000e-4000f (this last 4 bytes will look like a random padding).


Second, nesrock:
Here, my explanation (based on the already given explanation):

Spoiler:

M1 = 'The quick brown fox jumps over the lazy dog'
M2 = 'Another string'
CRC32(M1) = 414fa339
CRC32(M2 padded with 0x00 0x00 0x00 0x00) = 80bd6d26
414fa339 XOR 80bd6d26 = C1F2CE1F
Flip(C1F2CE1F)=f8734f83
The multiplicative inverse of x^32 for CRC32 is always = cbf1acda.
https://en.wikipedia.org/wiki/Finite_field_arithmetic
https://en.wikipedia.org/wiki/Finite_field_arithmetic#Multiplicative_inverse
Use a GF(pn) calculator(also called the Galois field)
Cuz 100000000*cbf1acda mod 104C11DB7 = 1
https://en.wikipedia.org/wiki/Finite_field_arithmetic#Multiplication
Then:
f8734f83 * cbf1acda  mod 104C11DB7 = 5d9fe0f5.
Reverse each byte since CRC32 works with LSB of each byte first: baf907af.
By "reverse" you mean re-order; not flip the contents. So, we have
5D9FE0F5, which is 01011101 10011111 11100000 11110101 binary. You reverse the order of bits in each byte, resulting in 10111010 11111001 00000111 10101111, which is BAF907AF hex.
Verify that CRC32(M2 padded with baf907af) = 414fa339.

Update:
With what Cyneprepou4uk said (about last 6 bytes), i make this .py file:

Spoiler:

Code: [Select]

import BitVector as bv
import binascii

#pip install bitvector, if needed.

def reverseByteWise(x):
    y1, y2, y3, y4 = (x & 0xFFFFFFFF).to_bytes(4, 'big')
    y1_r = int('{:08b}'.format(y1)[::-1], 2)
    y2_r = int('{:08b}'.format(y2)[::-1], 2)
    y3_r = int('{:08b}'.format(y3)[::-1], 2)
    y4_r = int('{:08b}'.format(y4)[::-1], 2)
    return int.from_bytes([y1_r, y2_r, y3_r, y4_r], byteorder='big')

def addPRGSection(data,SIZE=16384):
    return data+b'\x00'*SIZE

def fixPrgCRC(infile,infile2,outfile,ADDSEC=True):
    poly = bv.BitVector(intVal = 0x104C11DB7) # "standard" CRC32 polynomial
    inv = bv.BitVector(intVal = 0x100000000).gf_MI(poly, 32)

    with open(infile,'rb') as file:
        data=file.read()

    original_crc=binascii.crc32(data)

    with open(infile2,'rb') as file:
        data2=file.read()

    if ADDSEC:
        data_modded=addPRGSection(data2)
    else:
        data_modded=data2+b'\x00'*4

    padded12_crc=binascii.crc32(data_modded)

    xored= original_crc ^ padded12_crc
    flipped=int('{:32b}'.format(xored)[::-1], 2)
    p_reversed = bv.BitVector(intVal = flipped).gf_multiply_modular(inv, poly, 32)
    p=reverseByteWise(int(p_reversed.getHexStringFromBitVector(),16))

    if ADDSEC:
        data_modded=addPRGSection(data2,16380)
    else:
        data_modded=data2
    data_modded+=p.to_bytes(4, 'big')
    with open(outfile,'wb') as file:
        file.write(data_modded)

    print("Original file CRC: "+hex(original_crc))
    print("Tweaked file CRC: "+hex(binascii.crc32(data_modded)))

def fixRomCRC(infile,infile2,outfile):
    fixPrgCRC(infile,infile2,outfile,False)

def rebuildROM_onlyPRG_noTrainer(infile,infile2,outfile):
    with open(infile,'rb') as file:
        data=file.read()
    sizePRG=int.from_bytes([data[4]], byteorder='big')
    header=data[0:4]+(sizePRG+1).to_bytes(1, 'big')+data[5:16]
    romPRG=data[16:sizePRG*16384+16]
    rest=data[sizePRG*16384+16:]
    with open(infile2,'rb') as file:
        data2=file.read()
    romPRG=data2
    data_modded=header+romPRG+rest
    with open(outfile,'wb') as file:
        file.write(data_modded)


if __name__ == "__main__":
    option=1
    if option==1:
        #Even adding an expansion to PRG bugs VirtuaNes. So it doesn't work.
        #It would be more easy to hack the emu than try to fix this...
        fixPrgCRC("ressen-prg-orig.bin","ressen-prg-modded.bin","ressen-prg-tweaked.bin")
        rebuildROM_onlyPRG_noTrainer("ressen.nes","ressen-prg-tweaked.bin","ressen-modded.nes")
    else:
        #Or just fix the rom crc, it won't work with VirtuaNes cuz need Prg crc
        fixRomCRC("ressen.nes","ressen-modded.nes","ressen-tweaked.nes")


Still it doesn't work for VirtuaNes...

[Spoiler:]

10

Programming / Re: [Help] Repositioning a single sprite.

« on: September 15, 2019, 10:24:02 pm »

"still taking me to school"
Yes nesrocks is right. After reading the VirtuaNes src, I found this:

Code: [Select]

DWORD crc = nes->rom->GetPROM_CRC();

        //Some more if's

if( crc == 0x09499f4d ) { // Dragon Ball Z 3 - Ressen Jinzou Ningen(J)
nes->SetIrqType( NES::IRQ_HSYNC );
eeprom_type = 1;
}
PRG_ROM goes from 0x10 to 0x40010.

So if you make your modded PRG_ROM to have this CRC-32: "0x09499f4d", your hack will run in that emu.

Which goes to nesrocks problem. A cryptography problem...

There are already solutions (done by others):
https://github.com/madler/spoof
https://github.com/rr-/CRC-manipulator


Its really late here like 2am, but here is an explanation (from 2 other ppl 4 years ago):

Spoiler:

Sorry I was not clear. All operations described below are done in GF(232).
P * x32 mod crc_poly is the remainder of (P shifted 32 bits to the right) after dividing by the CRC polynomial, which is how CRCs are computed).
inverse(x32) is the multiplicative inverse of x32 mod crc_poly. Multiplicative inverse means x32 * inverse(x32) mod crc_poly = 1.
Maybe there is another way but here is an example:
M1 = 'The quick brown fox jumps over the lazy dog'
M2 = 'Another string'
CRC32(M1) = 414fa339
CRC32(M2 || 00004 bytes) = 80bd6d26
XOR them together and undo the bitreverse: K = f8734f83 (note that XORing two bit inverted values will cancel the bit inverse)
The multiplicative inverse of x32 = cbf1acda.
Now P = K * inverse(x32) mod crc_poly
= f8734f83 * cbf1acda mod 104C11DB7
= 5d9fe0f5.
Reverse each byte since CRC32 works with LSB of each byte first: baf907af.
Verify that CRC32(M2 || baf907af) = 414fa339.



bontchev
Sorry, I'm still lost.
    M1 = 'The quick brown fox jumps over the lazy dog'
    M2 = 'Another string'
    CRC32(M1) = 414fa339
    CRC32(M2 || 00004 bytes) = 80bd6d26
So far, so good.
    XOR them together and undo the bitreverse: K = f8734f83 (note that XORing two bit inverted values will cancel the bit inverse)
Sorry, where did f8734f83 come from? 414FA339 XOR 80BD6D26 is C1F2CE1F. Even if we invert that, we get 3E0D31E0.
Edit: Given that I have misunderstood what you meant by "invert" (see below), we have:
C1F2CE1F hex is 11000001 11110010 11001110 00011111 binary. Reversing the order of bits (considering them as a continuous stream of bits, not on a byte basis), we get 11111000 01110011 01001111 10000011, which is F8734F83 hex. Is that what you meant by "undo the bit reverse"?
    The multiplicative inverse of x32 = cbf1acd
How did you get that from the numbers so far?
    = f8734f83 * cbf1acda mod 104C11DB7
Where did 104C11DB7 come from? Is that the generator polynomial for this particular CRC-32?
    = 5d9fe0f5.
I don't get it... According to my hex calculator, F8734F83 * CBF1ACDA is C5EDFC5BC6F0B98E. Mod 104C11DB7 results in 115CF38C? Am I misunderstanding what you mean by the operations "*" and "mod"?
    Reverse each byte since CRC32 works with LSB of each byte first: baf907af.
Again, I don't follow. If you invert each bit of 5D9FE0F5, you get A2601F0A...
Oh, wait, I think I got this part. By "reverse" you mean re-order; not flip the contents. So, we have
5D9FE0F5, which is 01011101 10011111 11100000 11110101 binary. You reverse the order of bits in each byte, resulting in 10111010 11111001 00000111 10101111, which is BAF907AF hex.



supersaw7
I should really improve my explaining skills
reverse = reverse the order of the bits, bit inverse = bitwise not.
0x104C11DB7 is the CRC32 polynomial, with the explicit x32 coefficient (most tables omit that).

11

Programming / Re: Help - Repositioning a sprite.

« on: September 15, 2019, 08:34:21 pm »

I never thought that I would be talking about NES modding, but your question got me curious.

After reading a couple of hours (with testing), your emulator issue is related to some sort of validation of BANDAI 24C02 mapper (16-5)(which only 6-7 games have it) for the PRG ROM data. So what can be done:
1. Change emulator as Cyneprepou4uk already suggested.
2. Wait for an update (or hack the emulator to bypass the PRG ROM validation)
3. Only modify the CHR ROM data (graphic data for the ppu or something like that)
4. Decompile (reverse engineer) the PRG ROM data and compile it for a more generic mapper or circuit (may be 04)(I believe this can be quite difficult, I could be wrong).

12

ROM Hacking Discussion / Re: YouTube/Google Video thread

« on: September 10, 2019, 10:48:21 pm »

https://giphy.com/gifs/QC1c6VHMwjchSSSYga/html5

fft wotl spell quotes.

13

ROM Hacking Discussion / Re: Want to start a project for FFT, which should i start?

« on: August 16, 2019, 08:28:55 am »

Well it has past almost a month and i finished my fftcv2 update.

I will upload it today.

I went savage, so it is an huge update hope you like it.

Back to my other projects...

14

Help Wanted Ads / Looking for a [JPN Translator] for a text book inside a [PSX] game

« on: August 16, 2019, 08:13:39 am »

Hi, it may not look specific but I am looking for someone who would like to translate 1119 sentences from nihongo to english (24000 chars, hiragana-katakana-kanji).

If interested pm me.

EDIT:

The user RafaGam had done the whole translation. Thank you a ton

15

ROM Hacking Discussion / Re: Want to start a project for FFT, which should i start?

« on: July 18, 2019, 01:01:51 pm »

Well 3 votes, 1 each...

Thanks to those who voted, but it seems that nobody cared too much, so I will just follow my will.

Cya.

16

ROM Hacking Discussion / Re: Want to start a project for FFT, which should i start?

« on: July 13, 2019, 03:03:34 pm »

They never did anything like 2, i mean like a tool. One user made an slowdown fix and a widescreen resolution hack. For 3, FFTPatcher is open source and it is on github the entire source code.

[Spoiler:]

17

ROM Hacking Discussion / Want to start a project for FFT, which should i start?

« on: July 13, 2019, 10:41:07 am »

Hi all, I am Zen. I am the one who uploaded FFTCv2 (though it's creator was xjamxx, my coding teacher). I have some free time now and i am willing to do something to share (which will help me to train my coding skills) but i am not sure what the community will prefer:

1) An FFTC v2 update:

Spoiler:

New Game Plus feature:
1- new check if defeat altima or create in the last event and add+1 (easy)
2- check in title screen if that happened -> new game goes to new game + (average, it may be erased after pressing new game but can be worked with temp data or temp call routines)
2.1- keep gold (easy just prevent overwrite)
2.2- keep poach inv (eeasy, same reasons)
2.3- keep all abilities and total jp points (average)
3- 'absorb' when writing into slot (average, but not sure)
4- R1 and L1 patch 'absorb' and zeros if moved to empty space (hard, space here is already an issue)
5- if monster, don't absorb and move it??? (more space required)
6- monster eggs erase data in the last slot (already).
No more learn on crystals.

2)An FFT WotL (for PSP) asm tool similar to FFTOrgASM (from the FFTPatcher suite) with many of the PSX asm hacks rewritten so they can be used in PSP and some new ones (like tweaking DK reqs).

3)[The most boring one] A code rewrite (in Python) of the FFTPatcher.

Yeah i know ... why not all, simple put not enough time for a single person.

So i ask what would ppl prefer?

Thanks for reading and leaving your opinion.