Jump to content

Shrinking the ROM


Belf
 Share

Recommended Posts

So I was an idiot and expanded the fe7 rom to 28mb. My concern is that when I use zahlman's song editor, it adds some hex each time I change a song, and it could eventually reach over 32mb. Should I just use the decrease rom size option in a regular hex editor, or will that just cut out stuff starting from the end? Or does it find free space to terminate?

Link to comment
Share on other sites

There WAS an option to add an address to write to if you knew where the free space was. Since you didn't specify it, it added to the end of the ROM.

So if you're gonna shrink the ROM, you're gonna have to know what EXACTLY you're deleting.

"Decrease ROM size"? WTF is that option in a hex editor?

My "Decrease ROM size" is highlighting stuff and pressing the "delete" button.

Link to comment
Share on other sites

There WAS an option to add an address to write to if you knew where the free space was. Since you didn't specify it, it added to the end of the ROM.

So if you're gonna shrink the ROM, you're gonna have to know what EXACTLY you're deleting.

"Decrease ROM size"? WTF is that option in a hex editor?

My "Decrease ROM size" is highlighting stuff and pressing the "delete" button.

Okay, I was just confused since I was using windhex which doesn't let you just select and delete hex. I used HxD and it worked.

Btw, what exactly is added to the end of the rom when you use the song editor? I'm pretty sure I specified a location to place the ripped midi.

Link to comment
Share on other sites

Okay, I was just confused since I was using windhex which doesn't let you just select and delete hex. I used HxD and it worked.

Btw, what exactly is added to the end of the rom when you use the song editor? I'm pretty sure I specified a location to place the ripped midi.

If you specified where exactly to write your song data, then there should be NOTHING written to the end of the ROM.

Link to comment
Share on other sites

If you specified where exactly to write your song data, then there should be NOTHING written to the end of the ROM.

I think Zahlman said that there is still stuff written at the end, because I absolutely specified locations to put the new song data.

Link to comment
Share on other sites

Saved song files are in a raw binary format based off of how they are stored in the ROM. They contain the following pieces in order:

- The metadata struct, consisting of:

- One word with a track count, two zero bytes and a count of used instruments (the burning code needs to know this). When the song is burned, the instrument count is erased and default values for priority and reverb are written in. For converted MIDIs, the instrument count is zero.

- The location of the instrument map. For converted MIDIs, this is an absolute pointer value. (You should decide what ROM you're going to insert the MIDI into before converting it, or else you'll have to hex-edit this pointer manually after burning.) For ripped songs, it's an offset relative to *the start of the file*. (This also allows the burning code to find the end of the last track.)

Note that in the ROMs, the metadata normally comes AFTER the tracks. However, it doesn't really matter because of how the pointers in the metadata work.

- The location of the start of each track. Each is an offset relative to *the start of the file*.

- The actual track data, in the same order as the original. Pointers within each track are replaced with an offset relative to *the current track*. Tracks that couldn't be burned are just skipped. The instrument IDs are modified to work with the "local instrument map" described below.

- Zero-padding to a word boundary.

Songs converted from MIDI end here.

- A "local instrument map" that only holds as many instrument structs as were actually used in the track. Percussion samples and individual instrument samples are mashed together. The first entry in the map represents the percurssion instrument, and is always 80 00 00 00 00 00 00 00 00 00 00 00. The sample pointers in the rest of the entries are converted into offsets relative to *the start of the sample data*; so the next one also always has a middle word of 00 00 00 00.

- The samples, in the same order as the local instrument map. Each is zero-padded to a word boundary.

If they wrote crap to the end of the ROM no matter what you do, it would have borked my FEditor free space list.

49640594.png

Your command would have consisted of:

burn [table address] [ROM address]

From the sample.

open AW

rip 0x271728

open FE7

burn 0x69d9c0

close test

It only has one address. THAT would add things to the end of the ROM.

Edited by shadowofchaos
Link to comment
Share on other sites

If they wrote crap to the end of the ROM no matter what you do, it would have borked my FEditor free space list.

49640594.png

Your command would have consisted of:

burn [table address] [ROM address]

From the sample.

It only has one address. THAT would add things to the end of the ROM.

Well, perhaps FEditor is appending something to the end? Does editing text or portraits possibly do that?

Link to comment
Share on other sites

Well, perhaps FEditor is appending something to the end? Does editing text or portraits possibly do that?

Yes, if your checksum was screwed up at one point, which it most likely was.

Open up FEditor and click "List Free Space" and click "help" and "Debug Output". Chances are, you have LITTLE free space and FEditor's adding stuff to the end of the ROM and then marking the stuff you replaced as free space.

Link to comment
Share on other sites

Yes, if your checksum was screwed up at one point, which it most likely was.

Open up FEditor and click "List Free Space" and click "help" and "Debug Output". Chances are, you have LITTLE free space and FEditor's adding stuff to the end of the ROM and then marking the stuff you replaced as free space.

You're absolutely correct. It's saying my checksum is not, "EBAFC92D" and there is nothing in the free space list.

Okay, so FEditor is appending shit to the end of my rom. If I'm able to change the checksum so that it is correct, where will the new data be overwritten? Maybe I should just start over with a clean rom, but how can i prevent checksum errors from occurring if I want to hack and expand the ROM?

Link to comment
Share on other sites

Fix it everytime after you edit the ROM with something that's NOT FEditor.

That way you don't lose your freespace list. If you save with FEditor while it says "checksum is not *blah blah blah* it'll fix it... but your free space will be lost and all it's gonna do is append stuff to the end of the ROM. And you'll have to specify your free space manually on the FEditor Memory manager screen (the default window when you open up a ROM).

And I ALREADY told you how to fix your checksum.

It's the checksum at the end. It doesn't match what's expected.

If you have HxD, open your ROM in Nightmare and do your edits, and then save it. Afterwards, go into HxD, go to the end of the ROM and delete the last 4 bytes. Go to "Analysis", then "Checksums", click "CRC-32" and then "OK"... you'll see the checksum at the bottom of the screen...

Write it at the end of the ROM like you would a pointer, replacing the 4 bytes you deleted earlier...

For example, if your checksum was "1301A6F4", you would put "F4 A6 01 13" at the end of the ROM...

What exactly are you going to do to the EN ROM anyway?

Link to comment
Share on other sites

Fix it everytime after you edit the ROM with something that's NOT FEditor.

That way you don't lose your freespace list. If you save with FEditor while it says "checksum is not *blah blah blah* it'll fix it... but your free space will be lost and all it's gonna do is append stuff to the end of the ROM. And you'll have to specify your free space manually on the FEditor Memory manager screen (the default window when you open up a ROM).

And I ALREADY told you how to fix your checksum.

Sorry about that, I wasn't thinking about the fact that when you graciously helped me in the past, it was related to this stuff.

So anyways, if I fix the checksum now, and after every time I make a change, say in nightmare or APE or the song editor or ANYTHING that could modify the hex that is not FEditor, fix it again, then theoretically nothing should be appending to the end of the rom anymore?

Also instead of fixing the checksum, is it easier to just manually specify the free space on the FEditor Memory manager? Or is that not recommended?

Link to comment
Share on other sites

Sorry about that, I wasn't thinking about the fact that when you graciously helped me in the past, it was related to this stuff.

So anyways, if I fix the checksum now, and after every time I make a change, say in nightmare or APE or the song editor or ANYTHING that could modify the hex that is not FEditor, fix it again, then theoretically nothing should be appending to the end of the rom anymore?

Also instead of fixing the checksum, is it easier to just manually specify the free space on the FEditor Memory manager? Or is that not recommended?

Feel free to use that instead if you don't want to deal with the checksum anymore. I use a bit of both.

Link to comment
Share on other sites

Feel free to use that instead if you don't want to deal with the checksum anymore. I use a bit of both.

So are you using the default free space of D00000 to E00000, or did you expand your rom and are using the added data as your list? Is the default free space really enough for many portrait and text edits, or will it be necessary to allocate more free space?

Link to comment
Share on other sites

It really depends on how much crap you put.

Unless you're putting in the amount of graphical changes comparable to Dream of Five... That's USUALLY enough.

Disregard this if you're importing a lot of GBA songs from different sources via Zahlman's Song Editor. Instruments imported from there take up A LOT of space. And I mean A LOT.

Link to comment
Share on other sites

Yeah that's mostly because it also copies the instrument samples (which average something like 10kb per instrument IIRC) and it has no idea if it's making duplicates of anything. :/

The "default free space" is 1MB. Budget accordingly. Learn how much space things take up, and learn how to calculate how much space it will take up.

Also I think I've heard reports that the D00000-E00000 range in FE7 might not be 100% safe, but I don't recall the details.

Honestly FEditor is a broken hack at this point and I (we all, really) got a lot of good ideas from it but at this point I'd rather reinvent it than maintain it.

Link to comment
Share on other sites

That's... kinda what nm3 is? Except that there will be a bunch of totally separate tools on the side to handle *creating* data; nm3 is for extracting and inserting stuff. The big problem with FEditor is that it tried to be this monolithic thing that handles both sides of that and also takes over managing your freespace with information that's actually in the ROM that causes problems for every other tool and vice versa. The nm3 approach is that you create content with totally separate tools (or extract something with nm3 and use totally separate tools to modify it) and then insert it with nm3. Freespace management is still an issue but I'm planning to have it record information in a separate file. (The design is a little tricky because nm3 is meant to be more than just a hacking tool.)

Link to comment
Share on other sites

That's... kinda what nm3 is? Except that there will be a bunch of totally separate tools on the side to handle *creating* data; nm3 is for extracting and inserting stuff. The big problem with FEditor is that it tried to be this monolithic thing that handles both sides of that and also takes over managing your freespace with information that's actually in the ROM that causes problems for every other tool and vice versa. The nm3 approach is that you create content with totally separate tools (or extract something with nm3 and use totally separate tools to modify it) and then insert it with nm3. Freespace management is still an issue but I'm planning to have it record information in a separate file. (The design is a little tricky because nm3 is meant to be more than just a hacking tool.)

Nightmare 3? I'm still using the original nightmare because it has those convenient dropdown menus. Was there any major differences though between nightmare 2 and nightmare?

Link to comment
Share on other sites

Nightmare 3?

No, it officially doesn't stand for that any more. It works totally differently. It's just nm3 cuz that's a cool name for something.

Edited by zahlman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...