Creating a ROM hacking utility... (or just rom hacking - Help?)

Easy? Hahahaha. You either know assembly for the 6502 or you don't. And you're either good at it or not. But you don't need to worry about that just yet. Most ROM hacks to edit levels require no knowledge of the system's ASM code. All you need to do is write a program to intake the ROM to memory and manipulate it as you wish and reoutput it. I don't know how much clearer it can be. First you should learn about the ROM by manually hacking it in a hex editor. After enough knowledge is present to you, it should be trivial to code an editor to make hacking the ROM easy.

You need to focus on hacking the ROM manually to get as much information on it as possible. Then it's again, as simple as coding a program to load the ROM and allow you to manipulate the things you've learned about.

alright, so the information I lack is hex editing utilities, and documention. Zophars, maybe?

You bet. You'll probably be able to find documents detailing how to use a hex editor to edit specific roms. Probably not ones for Blaster Master, maybe Kid Icarus. Generally though after you understand how one NES game stores map data it's alot easier to figure out other games. Remember lots of games do NOT use full tiled maps to store map data. Generally doing that would require much more memory. Lots of times they would compact values. I.E. 0 means this set of blocks here, 1 means this, etc. You could change those block definitions or which sets are where in a level. Mega Man games tend to use 32x32 blocks as I recall. So rather than HUGE tile maps, they are broken into 32x32 blocks which are defined elsewhere in the ROM.

i have no knowledge whatsoever of romhacking, and you probably know of this site anyways:

www.romhacking.net

it supposedly has a massive amount of documents pertaining to everything romhacking.

good luck.

Try Acmlm's Rom Hacking forum, here.

6502 ASM knowledge is definitely not required to make a functional editor. Locating data can be much, much easier if you do know 6502 because then you can just trace some stuff in a debugger and find the data, but there are ways to find data without the aid of 6502. A lot of my older methods are included in my own ROM hacking document, The Art of ROM Hacking. While it's becoming outdated, a ton of its information is still helpful for people (just ignore all occurrences of 'NESticle' and instead use 'FCEUXD'😉. It does have a few problems, like the table of RGB values for the NES colors is totally out of whack, the palette table isn't actually accurate (it's too bright), and some of it doesn't work properly with a non-IE browser (specifically the A graphic in the NES graphics format explanation), but it's still pretty good. I intend to go back and update it sometime, since it's gone some 3 years without updates and there are a lot more things I could add to it and fix in it.

Now, for an editor, the most important bits of data you'll want to get are TSA data, level data, and sprite placement data. TSA data defines what tiles make up what blocks - for example, in Mega Man games, you'll have those 8x8 pixel 'tiles' that make up 16x16 'blocks', and 16x16 pixel 'blocks' that make up 32x32 pixel structures. In fact, this is probably the most common system I know of on the NES. It, or variations of it, are used in games like Mega Man, Contra, Castlevania, and Ninja Gaiden. Other games will use 16x16 pixel blocks for their levels. Some games will use really weirdly sized structures, such as Metroid and Kid Icarus. These structures are variably sized, so they use a basic format and all are different sizes in the data (referred to as VSSA, or variably sized structure arrays). Anyway, TSA (or VSSA) data will allow you to edit the blocks that make up a level, which is necessary to have ultimate freedom of level design.

Level data uses those blocks made up of TSA data in order to build a level. Often, this level data will be uncompressed and thus will be fairly easy to edit, but it's not uncommon to see simple compression (and sometimes compression can be a real bitch and pretty complex). Mega Man, Castlevania, Ninja Gaiden, Boulder Dash, Battle City, and many others aren't compressed. Some, though, like Contra, Final Fantasy, and Lolo, will have simple RLE format (Run-Length Encoding, for repeating the same block over and over with very little data) and maybe an LZ variant (which allows it to copy one or more blocks from elsewhere in the data and reproduce those at the current location. Often, the blocks it grabs will be 16 blocks back). Some will have some simple binary compression where, for example, each block might have a 2 bit code telling it if it's uncompressed or, if not, what kind of compression to use (Faxanadu), or one of the bits of block ID is compressed and assumed to be 0 unless the compressed data says otherwise (Milon's Secret Castle). I think I somewhat covered level data in my document, so go ahead and give that a look. If it's uncompressed, you should have no trouble with it. If it uses RLE, then it'll be a bit more of an issue, but it's still an easy format, so the biggest problem will just be making sure that the level data the user is trying to save isn't too big when compressed. Other formats are a bit more difficult, but I'm sure you'll manage if you pick a game with any of those formats.

Sprite placement data is different in every game. Usually, you'll have one byte for page number, one byte for sprite ID, and one or two bytes for x and y location (if it's one byte, it'll be some sort of xy byte where one nybble is the x and one nybble is the y. Two bytes allows for more freedom of placement, but is obviously more space-costly, so it's not always used). I can't offer all that much general help for sprite placement.

Kid Icarus, Blaster Master, and Metroid all have editors available. Metroid's editor is very functional, but lacks several key features (elevator editing, GOOD item editing (it's there, but sucks horribly), door editing). If you want to work on Metroid, the source for MetEdit is available, so you could pick up where SnowBro left off. The editor thus far is a really good one, in my opinion. There is a Blaster master editor, but I don't know how good it is; I know very little about Blaster Master much because the overhead sections really turned me away from that game, so I've not really looked into the game. Kid Icarus' editor kind of sucks, and there is a good amount of data available on the game, if you want to go with that, so it might be a good choice. However, it, like Metroid, uses a VSSA format, which might be difficult to deal with because you'd have to make a drag-and-drop system like MetEdit uses *and* the block and level data is all variable in size, but it'd be great to see a good Kid Icarus editor.

If you need any information, data, or help, feel free to ask.

Best reply you're going to get about ROM hacking is right there. You couldn't ask for more.

Vagla freaking owns. I'll look into the tutorial in a bit. But... Great information. The blaster master editor thats out freaking sucks. The interface is terribly garbled, and it is not user friendly at all. You'd think that might kinda be the point... :/
But yeah, thanks for all the information. I'm sure I'll have a ton of questions - I'll post them here once I get a chance to look at that document.

One thing I was planning on including in that post and eventually forgot to was a link to my Faxanadu document, which contains just about all the info you would ever need to make a really complete Faxanadu editor. The host of the inter-web took that document and ran wild with it, finding all sorts of new stuff and completing the sections of my document that were lacking. This is an example of what you might need to do for the game that you choose to make an editor for; you're going to need to spend some time figuring out how everything in that game works (particularly the sprites, levels, TSA, and scrolling, as well as any sort of door system the game might have) so that your editor can support it. As you can see in that document, I covered level data, TSA, sprites, scroll, doors, and the compression the game used, and I even did a little bit of palette stuff, but since palettes are so easy, that section didn't really *need* to be in the document.

But yeah, so that document was a few days work. I imagine it'll take you longer since you're new, and I imagine that you'll also need to be playing through the game as you make changes to figure out what everything is doing, but you should still be able to do a lot of this sort of stuff hopefully without too much trouble. An important note: once you find pointers for stuff, you don't need to go around finding the starting location of everything and documenting it down like I did in that document (I did it for people who weren't going to be messing with pointers). The pointers are much more important than where the data currently is, since you can just use a pointer to find and even relocate the data. Once your editor uses and supports pointers, it'll be a much better editor because it'll be more versatile.You want to hardcode addresses as little as possible. A solution that Dan often uses in his editors, such as Rock and Roll, is to have a data file that the user can edit. In case the user is making extensive changes to his game, he can just edit the data file and the editor will reflect those changes. Moving a pointer table, for example, is no problem because you can just change the pointer table address in the data file. This is something you should consider doing in your editor. I definitely recommend looking to Dan's editors and, assuming you're doing Metroid or Kid Icarus, MetEdit for examples of how to do your editor.

Alright, so following through this document would be a good learning experience, even if I think faxandu sucks balls? :P I'm saving the two documents to my USB drive, and I'll work with them when I get home. I think the editor I'd do is between those three... which, I don't know. I'll work with the faxandu document first. Thanks alot for all the help... Anything else you have would be greatly appreciated.

Oh yeah! I have RockNES, and NESticle... Should I get a different emulator?

Definitely. FCEUXD (or FCEUXD SP, which I suppose it probably better. I wouldn't know because I've not used it, but I think it has support for conditional breakpoints) is the one to use. Don't touch NESticle unless you have an absolutely shitacular computer that really can't run anything else. It's both horribly inaccurate and crappy, and there are other emulators that do everything it does and better (read: FCEUXD), so there is no reason to do it. It's a shame that so many people still use that incredibly outdated program.

Additionally, RockNES won't help you much with anything beside just playing the game. I think it has a ROM patching feature that lets you hex edit on the fly, but FCEUXD also has this feature AND does it better than RockNES. RockNES isn't bad, but it's not totally featureful.

With FCEUXD, you can view currently loaded graphics (PPU viewer), view the nametables (the currently loaded backgrounds), hex edit on the fly, find RAM addresses with a very useful cheat console, and set breakpoints in the debugger, among other things. If you choose to use FCEUXD's neat features as opposed to just searching through the ROM with a corruptor or something of that sort, you'll be using the hex editor, PPU viewer, and debugger a lot. The debugger lets you find the code that writes to or reads from certain addresses, as well as find when certain code is run. It's incredibly useful; you can find out where the game is getting certain values from (so you can find tables of values or just the LDA #$xx opcode that is defining some sort of important value) or locate certain code that does specific things. The hex editor is a good way to see what something does without having to save in a hex editor, reopen the ROM, and go back to where you were. Just make a change in the hex editor and next time that data is loaded, it will be different. You can edit the ROM in the hex editor as well as RAM. It's really useful.

As I said, I have some Kid Icarus data, if you decide to look into it. I won't guarentee the validity of this data because it's been a very, very long time since I wrote this stuff down (looks like a lot of the addresses are 1 byte early, since a bunch of them appear on an FF when they should actually appear on the *next* byte. Oops. I'm sure you'll figure it out), but what I have that isn't marked with a question mark should be mostly right.

-----

Kid Icarus

1A691- 1-1 enemy data?

19A0C- 1-1, screen 1. Format- Color, Location (yx), Type. FF denotes the end of a screen.
19A5A- 1-1, screen 2
19C59- 1-2, screen 1
19E7E- 1-3, screen 1

B0F5- 2-1, screen 1
B2E4- 2-2, screen 1
B515- 2-3, screen 1

1A857- 3-1, screen 1
1A97A- 3-2, screen 2
1AA1B- 3-3, screen 1

FAFE- 4-1, screen 1

15C16- Maze Data start. Format- Location (yx), Type, Color. FF denotes the end of a screen, each screen starts with 1 unknown byte.
15E65- Maze room

1A1B9- VSSA data start, 1-x
1A2EC- TSA tile makeup, 1-x

B82C- VSSA data start, 2-x
B940- TSA tile makeup, 2-x

1ABC5- VSSA data start, 3-x
1AC77- TSA tile makeup, 3-x

FBFC- VSSA data start, 4-1
FCB8- TSA tile makeup, 4-1

1626C- VSSA data start, x-4
1631E- TSA tile makeup, x-4

-----

I find it very bizarre that the level format for the maze and standard stages are so different, but I do remember finding that to be the case. You might want to look into confirming that, if you do decide to go with this game. Furthermore, screens in this game end with FDFF, not just FF (as my ancient notes say). Kid Icarus uses the same engine as Metroid, and Metroid's format ends object data for each screen with FD and then has sprite data for enemies and doors, which is terminated with FF. Kid Icarus uses a different sprite format; instead of making it so that sprites hardcoded in each screen, they are told to appear on certain screens in the level. This means that you can repeat a screen without repeating the sprite data, unlike in Metroid. If *all* screens in Kid Icarus are indeed terminated with FDFF (so there is never any data between the FD and FF), the code could be changed so that it no longer looks for FD, but rather only for FF, which would free up a bit of space for new objects since screens would only need to end in FF. It's strange that they would leave in the FD if it's never used, though.

Anyway, yeah. Go ahead and play around with that data. I'm not sure it's 100% accurate, but glancing at the data, it seems more or less right. Also, for the VSSA stuff, you have TSA data that defines the 16x16 blocks (simple enough. It's probably 4 bytes per block, one for each of the 4 tiles that make up each block) and then VSSA data that creates objects out of those 16x16 blocks. VSSA data is pretty simple. You have rows of blocks, each row being of some length defined by the first byte of that row. So the first byte of an object (and note that it looks like some of my addresses for VSSA data are off by 1 byte, again. Ugh. If the address has FF as the value, go to the next byte. I don't know what I was thinking) is the length of the first row. If it's 01, then there is 1 block in that row. I'm not sure if you can do a 00 row; I recall that not being done in Metroid, so it's probably not possible (00 might be counted as 256). So you'll have 01xx where xx is the ID of the block in that row. After 01xx, you'll have another row, which is the exact same format. Maybe the first byte here is 04, so then the next 4 bytes will be the row, so you'll have 04aabbccdd. Maybe you don't want any more rows in this object, so you'll want to terminate it. You do that with FF. The end result of this 01xx04aabbccddFF object is this:

xx
aabbccdd

It'll be an object of that shape with 5 blocks (defined in the TSA data) whose IDs are denoted by those 2 digit values. I doubt you'll find this too difficult. What might be difficult is making a good editor for it.

Hope that all helps. Let me know if you have any questions.