Monster level up patch

I've been trying to reverse engineer a Japanese hack recently that does this very thing, but it being Japanese it's that much harder, and today I've about given up. I'm very interested in alternate difficulty choice.

It's actually really easy to do. You just load your data from a different place if a certain RAM bit is set.

As an example, for monster data it's basically changing all data loading like this:

Given you have LDA $CF0001,X (loading of second byte of the monster data)

It becomes:

Code:

JSR freeSpace
NOP             ;4 bytes replacing the LDA

org $XXXXXX
freeSpace:
LDA $1XXX       ;load your RAM byte for the difficulty choosing
BNE secDiff     ;if not 0, it mean a bit is set so your are on hard (or easy) mode.
LDA $CF0001,X   ;We are here because it's normal mode
BRA exit
secDiff:
LDA $F20001,X   ;load from the second difficulty set. Your second monster data would be at F2/0000.
exit:
RTS

You have to do something similar for all the data you want to duplicate. Making this for 3 difficulties is not so different. The other easy part is coding an event command to choose the difficulty via dialogue choice. The problem comes with editing the second data sets but the editor feature mentioned in previous post could fix this.

On my very old, never finished hack, I intended to have (well, actually I did implement...) 3 levels of difficulty selectable from an event just before the opening sequence. The difficulty mode would essentially select one of 3 sets of monster stats, with (for instance) HP being doubled for regular enemies, and 10 times for bosses.

You don't happen to have that hack still laying around by some chance? Or some documentation regarding the selectable difficulty?
I've been trying to reverse engineer a Japanese hack recently that does this very thing, but it being Japanese it's that much harder, and today I've about given up. I'm very interested in alternate difficulty choice

I think I do have it somewhere, maybe on an old hard drive. I've unfortunately lost a few hard drives over the years. But I think I have this particular one backed up somewhere. If I find it, I'll surely let you see it.  I can tell you that there's practically no documentation of any of it. I wrote most stuff on scraps of paper and hand-edited the events. All this particular thing involves is a couple of unused event bits, some new dialogues, and an event to run it all. It's really not very complicated. Of course, to actually do anything with it, you then have to add checks for those event bits in the appropriate places. Event bits are visible anywhere in the game, even battle, so it's a natural fit.

EDIT: Basically something like Madsiur said above. Whenever I made new data, what I would do is load it up in FF3usME on a copy of the ROM, edit the data, then copy the whole block from that ROM to my new spot in the hack. That way, you only need to know the starting address. I did that with several things, notably items.
If someone can make an editor that is capable of taking data start addresses, so that the data can be relocated and pointers find it easily, that would speed up hacking like 1000%. Not to mention the AI hacking I have in mind...

This is exactly why we should make a standardized "Expand Everything" patch as a new base-ROM.

This is exactly why we should make a standardized "Expand Everything" patch as a new base-ROM.

There are many data relocalization already existing or coming fairly soon:

1) FF3usME expansions
2) FF6LE+ expansions
3) modified FF3se monster graphic expansion
4) FF6ExpED drop/steal item expansion
5) Possibly multiple sets of data discussed in this thread
6) upcoming FF6EME monster expansion

#2 and #3 relocalizations are harcoded, #1 is semi-customizable and #4 is 100% customizable. #5 could become customizable. #6 will also be customizable and at the same time getting rid of #3. #4 might get features adding and the logic thing wouldbe to merge #4, #5 and #6 in a single editor that allows 100% ROM space management.

Someone might not want to implement all 6 points. If it's the case and you push #5 to the limit, considering you should keep 1 bank for extra ASM and events, you'll definitely want to consider a 48Mbit ROM expansion. I could see a patch pushing all expansions to the limit, a customizable ROM space editor could work with that and even re-relocate data if wanted. At that point maybe considering making a version of FF6LE Rogue that expand maps and has the FF6LE+ features without the patch and customizable ROM space to close the loop. If all expansions are customizable via editors, the patch serves little need.

What I think could be beneficial in the immediate is a Expanded banks suggested ROM map that takes in account fixed expansions as well as other details.

It's like you read my mind.

I was just thinking about how to bring up the idea to the community of having a new base ROM full of expansion space for many commonly-sought things. I have no idea what space is used by the various editors, though that would be a decent starting point.

Has anyone ever made a fully-reassemblable file of the game's assembly? I have one working for just the upper C2 bank (you know, the battle engine part). I don't think it would be terribly hard to do the same for the other banks and put each in a file, and use the include function to make a whole project of it.

Even the data could be labeled and included as bin files. That's not too useful if you don't have an editor that can find the data, though. Really it would be great to have editors that can take a known address for the starting point. The assembly, properly labeled, can point the loads at the correct spots.

Now we're talking, Imzogelmo. Some more mature romhacking scenes work from split disassemblies and just include binary blobs of data and graphics, then code editors or conversion tools to just work with those data files. You can make code and data changes, then just reassemble a new Rom. It's awesome. Sonic hackers do this I think, and there's a full split disassembly of FF1 on Rhdn.

---

There's a full disassembly labeled and formatted to be reassembled of the C3 bank by Magno. It's in Spanish but it's ready to go.

Has anyone ever made a fully-reassemblable file of the game's assembly? I have one working for just the upper C2 bank (you know, the battle engine part). I don't think it would be terribly hard to do the same for the other banks and put each in a file, and use the include function to make a whole project of it.

I can write a console app that strips the XX/XXXX: from each line of the text disassembly, put a ";" before each comment and put a $db before each data byte of the small tables scattered through the disassemblies. Given we agree on using xkas 0.06 as assembler that leaves only the branchings (BRA, BCC, BEQ, BNE, BCS, etc.) to label manually to have a functional xkas file.

Even the data could be labeled and included as bin files. That's not too useful if you don't have an editor that can find the data, though. Really it would be great to have editors that can take a known address for the starting point. The assembly, properly labeled, can point the loads at the correct spots.

Some more mature romhacking scenes work from split disassemblies and just include binary blobs of data and graphics, then code editors or conversion tools to just work with those data files. You can make code and data changes, then just reassemble a new Rom. It's awesome. Sonic hackers do this I think, and there's a full split disassembly of FF1 on Rhdn.

What you both describe would be the next step to be on the right track of realizing my vision of FF6 hacking (the hobby not the forum). To make this project a reality, I'd be willing to at least make my modified FF6LE/ZoneDoctor (limited to LE content) and FF3se read offsets from code and allow relocalization / offset choice of expanded data. Editing bin data files directly from the editors is a step further that could be done also though it require the source code of all useful editors.

I was never able to compile properly FF3se, the changes made were done by Hex editor. It worth another try though. One concern is FF3usME. Since now 95% of the data and formats it can edit is written in threads and wikis, I wonder why Lord J keep secretly his source code. MFC is not longer use to my knowledge and the app does nothing ground breaking (from the features point of view, displaying 4BPP graphics from a ROM, editing offset/byte arrays and performing bits shift or boolean operations is common). My point is changing usME code is almost central if you plan on editing bin files data and be able to re-assemble your ROM. I have no solution to this other than explaining this to Lord J and see. If someone was before (or still) getting in touch semi-frequently with him, it would be cool to try to get a hold of him. I can try but fear I'll never receive and answer (or one in 8 months).

There's a full disassembly labeled and formatted to be reassembled of the C3 bank by Magno. It's in Spanish but it's ready to go.

I have his C1 ASM file in my emails! I'll put it up on the wiki soon.

Has anyone ever made a fully-reassemblable file of the game's assembly? I have one working for just the upper C2 bank (you know, the battle engine part). I don't think it would be terribly hard to do the same for the other banks and put each in a file, and use the include function to make a whole project of it.

I can write a console app that strips the XX/XXXX: from each line of the text disassembly,  put a ";" before each comment and put a $db before each data byte of the small tables scattered through the disassemblies. Given we agree on using xkas 0.06 as assembler that leaves only the branchings (BRA, BCC, BEQ, BNE, BCS, etc.) to label manually to have a functional xkas file.

That's a great idea. I think the first two could be accomplished with Notepad++ or any text editing app that enables working in columns, but it's the branches that are the most time consuming. I think those are prime candidates for automation, actually.
Your app could actually start by parsing all branch instructions and their operands to find out the branch address, then finding the line that matches the branch target address, and insert a line with a generated branch label (generated from the target address; just something like "label_CX_XXXX:". Then do a second pass and trim the address and opcode cruft.
Also, xkas does need branch labels since it interprets branch operands as "number of bytes to branch"... but bass (and asar?) correctly interprets them as addresses and converts them. So bass would assemble a label-less file, if I understand correctly. But labels are necessary for the file to be human-readable, so...
I'd do this myself if I could code in anything but 65x asm. Anyway, I'm glad we're all on the same page about this! I actually opened a github account to host something like this eventually, but of course the wiki here is the perfect place for it.

That's a great idea. I think the first two could be accomplished with Notepad++ or any text editing app that enables working in columns, but it's the branches that are the most time consuming. I think those are prime candidates for automation, actually.

Some C2 comments are fairly lengthy and start in the offset zone of the line(s) after the one they are relevant to. Since we'd do labels programmatically, might as well do everything this way.

Your app could actually start by parsing all branch instructions and their operands to find out the branch address, then finding the line that matches the branch target address, and insert a line with a generated branch label (generated from the target address; just something like "label_CX_XXXX:". Then do a second pass and trim the address and opcode cruft.

Since a branch is always in the same bank it is declared, you just have to take the XXXX in as an example "BRA $XXXX" and find the line starting by "C2/XXXX:". You then insert a line prior to this one with your label and like you said trim the branch to insert the label. We could do the same with JSR, JSL, JMP and JML(?) but at that point it's a luxury but it would increase readability.

Also, xkas does need branch labels since it interprets branch operands as "number of bytes to branch"... but bass (and asar?) correctly interprets them as addresses and converts them. So bass would assemble a label-less file, if I understand correctly. But labels are necessary for the file to be human-readable, so...

I never used bass and I kind of dislike asar. I think from memory asar behave the same way as xkas concerning mandatory branch labels. We should however agree on an common assembler if we plan to modify the basic ASM disassemblies because there are some features and syntax differences.

I actually opened a github account to host something like this eventually, but of course the wiki here is the perfect place for it.

Both places are good. The wiki could have the official version (and even other legit ones) while Github allow other user to branch and create modified versions (I can't think of examples but I'm sure they are some).

I'm thinking the wiki would be a good place to host a complete vanilla split disassembly since it's easy to collaborate on commenting it then. Then, we could clone it to github and get cracking on a rewrite that integrates optimizations,expansions and bugfixes. Then anyone could clone it from there for their own project.

---

Regarding assemblers I'm partial to xkas because, well, it's the gold standard and the only one I've used.

---

Then again, byuu himself has this to say on the topic of xkas:

---

xas was the original. Its source code would make Cthulu tremble in fear.
I rewrote things to xkas when I learned how to use the spacebar, that went up to v06.
I wrote spcas for SPC700 assembly here. It was also garbage.
I rewrote xkas again when I learned what classes were, and how to write a recursive parser, to add support for multiple targets (for Mother 3's translation), that went up to v14.
I rewrote bass when I learned what abstraction was. That added support for optional table assembly.
I rewrote bass again after creating a programming language and learning how to implement recursive macros.
To this day, the program remains a patching assembler, and not a linking assembler. That was always its goal, though.

That people continue to use xkas v06 to this day (and syntax-compatible clones of it like ASAR) is one of my greater sources of shame. It would seem I'm responsible for the ZSNES of assemblers =(

---

Hey maybe we should open up a new forum thread on this topic instead of burying it here. ^^