This man has earned a  :cookie:. Hell, make that half a dozen cookies: :cookie: :cookie: :cookie: :cookie: :cookie: :cookie: :cookie:

You pretty much had the exact response I figured you'd have. Look at what you just wrote. You practically just asked 'How do I hack a game using assembly?' That's not much different from just 'How do I hack a game?'. Surely, you can understand why that question can't be answered. Or at least, nobody is willing to answer it.

First, assembly is different depending on the platform. If nothing else, it's different because the hardware is different between the platforms. When it comes to assembly, you've got to learn about the hardware (in some cases nothing more than where RAM and ROM are addressed, but hardware knowledge is still required to some degree) or you're not going to be able to do a lot with it anyway. There are already THOUSANDS of assembly tutorials all over the Internet. We even have a nice handful pertaining to ROM hacking here on the site.

Second, every game is different. How to change the height in one game may do absolutely nothing to help you do the exact same task or any other task n any other game. The only useful part of the exercise would be how to use a debugger and the ROM hacking CONCEPTS used to come up with the information.

No document is going to be able to teach you how to APPLY the assembly code knowledge into game logic for your case. That's just the way it is. You can only learn some of this stuff by doing it and asking questions. The only thing you can hope to learn from a document to assist on these levels are the concepts of how to use a debugger, and the concept of how to insert your own code in a game. Beyond that, it's up to you to put things together. It's up to you to figure out how to hack. This hobby requires self learning more than most. Reverse engineering assembly code into game logic is simply a developed skill.

What I'm getting at is there is a reason why these documents don't exist and probably never will. A specific document outlining how to change the height in sonic's jump just isn't going to be too useful outside of the task of changing the height in Sonic. On a side note, go to our database. We already have fully disassembled commented code for Super Mario Brothers. That should explain far more in the direction you're hoping for anyway.

A document explaining the concepts on how you might do a hack like that would be better. Something removed from the specific lines of code. Everybody thinks if you hold their hand and tell them step by step how to change the jump height in Sonic, they will be able to do anything with Sonic. That's simply not true. You're too busy looking at the specific steps of this instance to learn the concept of what's being done. When I help people, I point them in right directions and explain concepts and make them fill in the blanks in between. No step by step. This way they learn the mechanics of how to do this and can go off on other tasks without needing to ask step by step for the next task that may be different. Sometimes it's a frustrating process, but it's the concepts that open the door to be successful at any task, not the specific line of code.

It challenges the student to make connections which is the key to learning and I am firm believer in teaching in this manner and have been very successful over the years.


It sounds like what you really need is a document on how to use a debugger or additional information on the hardware. What do you suppose the relationship is between savestate and ROM data? Well, there's little if any other than teh fact the data was DERIVED form the ROM in some way. What is a savestate? It's just a snapshot of of the current contents of the CPU, RAM, VRAM etc. None of that data has to be contained in the ROM as it appears there. (Although often times some of that data was copied directly from the ROM as is). The key to relating the ROM to a savestate is finding out HOW the data got to where it is in the savestate.

That's related to the hardware and assembly. You'll use your debugger to backtrack on HOW values came to be in the savestate. You'll form the relationship by looking at the game code. No document is going to be able to tell you HOW to form that relationship, just how to use the debugger and give the hardware knowledge to know what registers or values you should be looking for.


It doesn't matter if it's an NES based document. That's a common pitfall I've seen at least monthly for the past 10 years. I was even in it when I moved from NES to SNES. Then it became clear they are one in the same like all tile based cartridge systems. What's really different between NES and Sega Master System when it comes to ROMhacking? Nothing other than the difference in hardware. So, what does that mean? It means you need to get yourself a technical hardware document for it which we already have here and do the exact same thing you would do with the NES.

The only pitfall you may have is in available TOOLS. Otherwise, you do the exact same thing. You'll use your debugger, tile editor, hex editor etc the same ways to find and change the necessary data.

It's the exact same thing for all tile and cartridge based consoles with differences only in the hardware. The basic system design and the way you hack them are absolutely the same. Once you get to N64, Playstation and the CD and 3D era, things change a BIT, but are STILL conceptually almost the same. You just have some added concepts you'll need to know in order to deal with CD media and 3D graphics instead of tile based. Remix and repeat. If you get a solid grasp on the concepts, you can be successful hacking almost anything.

P.S. The hacking process is significantly harder without tools though. If you choose a system that doesn't have any available tools, you're in for a long haul. You can still use the same concepts, but if you can't see the game code run or use a debugger, it's much harder to arrive at definitive answers on where data comes from, how it is processed etc. Honestly, if I were going to hack a system without tools, I'd probably attempt to create my own rather than fumble through the painstaking process of having none.

It's like building a house without a hammer or saw. You can still do it with perseverance, but it's going to take much longer most likely and you'll have to come up with alternative ways to cut your boards and put them together.

I can certainly understand where you're coming from. I hope you didn't take any offense to my previous post. I'm not criticizing you for asking the question. I only wanted to exemplify the point as to why some proposed missing documents have never been created. You, and many others at a a similar skill point, ask for these documents, but they can't really be created, or if they are, are of limited value as opposed to other documents aimed at other tasks or lower levels. Just trying to explain why nobody really makes them.

Don't get me wrong. I'm not saying no more documents are needed. Not by a long shot. Sure, some more documents should be created on the subject. However, I feel they need to be concept oriented and not of the specific variety which seems to be the type you, and others, perceive to be what you need. I do think more documents should be created, just removed from specific lines of code for a specific platform and a specific game. Perhaps some pseudo code or perhaps a task with examples of how it can be done on several platforms. Or just forget about all that and explain it on a high conceptual level instead, leaving it to the user to be applied to their specific task. Which while that seems like it might not be that effective, my practice has found it indeed seems to be.

Of course, documents of this nature aimed at a higher skill level are quite an undertaking. I've had the want to do some for a long while, I just haven't been willing to put in the time yet. I'm sure some others feel the same. It's probably a bigger undertaking than writing up another how to make tables or how to use a tile editor type document.

You're also correct in your understanding. The SMB assembly code is limited in it's usefulness. While it certainly does have educational value and may help one make some connection between assembly and game code logic and help solidify assembly knowledge itself, it is indeed going to be of limited help help in other projects. Mileage will of course vary on the individual. Maybe you will pick up some things to assist in other projects, but I'd bet most for that would come from the mechanics of tinkering with the ROM based on that document rather than the information it contains directly.

And yes, people would indeed be disappointed when changing the jump height in Sonic, and then trying to change the jump height in Sonic 2 or for mario, that they can't if they didn't pick up on the concepts and just focused on the code which is typical. Not everybody is typical mind you, but generally speaking.

I'm afraid the ROM hacking world probably will not get much more user friendly. It's a very individualized self learned hobby as has been said. ROMhacking.net attempts to help the user friendliness come through, but it's effectiveness is still limited. But really, if you spend the time to really go over many of the documents available here and the Getting Started section(if you're a complete newbie), and have DONE some tinkering with ROMs as you go through them, you'll more than likely have achieved the skills you need to succeed. Many people READ a document, but they never actually DO anything with a ROM. It's just a class with textbook only learning. If you never get any hands on, it's going to be much more difficult for you. You may think you understand the document completely, but you've got to try it out and see. Hands on is necessary in ROM hacking.

I'll tell you what is, in my opinion, the quickest way to advance through the more advanced levels of ROMhacking and get the help and information you need. It's a simple formula:

1. Read all that you can.
2. Give it a try. Try and DO something with your ROM.
3. If you hit a wall, ask a question either on the forum in private to another hacker you know. Ask a smart, specific question, showing what you've tried to do, and what isn't working right.

You're very likely to get an answer to help you. Rinse and repeat. You'll get to the head of the class in no time. People around here are much willing to help if you've demonstrated you've tried to help yourself. Your peers can provide some quick missing links that can really go a long way and can be more effective than any document.

Many people that come through here just don't bother trying to help themselves enough and blame the system or lack of documents. They're the people that are either ignored here or in some cases ridiculed.


I'm not really aiming those last few paragraphs at you personally. They're just some observations.

If I remember, the first 0x200 or so bytes in a Genesis ROM are header data (I know $100-1FF is the cartridge header).
As data is not code, the results will be junk.
I've found doing a full-ROM disassembly is fairly useless, as disassmblers can't tell data and code.
It's better to use a tracer to find where the code you're interested in is in the ROM, and then disassemble just a portion of the ROM.

Data and code are usually not separated into nice little homogeneous chunks. More often than not you find a block a code, a little data (could be graphics, could be sound), more code, etc. The header is usually something console specific that contains release information and the like. Most of the time it's nothing to terribly important, but always check the appropriate documentation to know for certain.

Hmm well that's annoying. Any idea as to why that is? I would have thought that once the programmer(s) finished writing the code it would be compiled and everything put on the rom in a certain, predetermind space. That way the author would know roughly where to make references to for graphics and so forth and could change any errors near completion. It seems rather nonsensical to have graphics (or others) stored half way through code.

@creaothceann - Are you actually asking that or just being pedantic? I ask because sometimes it is hard to tell though written word the tone of a sentance. To me that looks like your trying to knock an obviously inaccurate and 100% made up example but I may be misinterpreting your post. The fact that your post comes over 1 hour after RedComet's clear explanation that "Data and code are usually not separated into nice little homogeneous chunks" and yet yours still is only leads me further to belive that you are some how trying to correct my blatantly off-the-top-of-my-head example. Or maybe your trying to help me understand that it is more likely that a section of code would end at XXXXXXFF rather than XXXXXX00 since FF is the highest value allowed in such circumstance and would therefore more likely symbolise the end of a section with 00 being a new begining. If this is the case I suggest a bit more explanation than "More like this, right?" Of course if you are genuinely asking if that is right then you can probably disregard most of what you just read and I apologise for all the assumptions I just made of you.

Yep, creaothceann tried to tell you that "nice little chunks" would work out more like XX00 to XXFF because that's how banking works in original roms There are, as Spikeman said, addressing boundaries for certain instructions as well as mappers.
So in gameboy (top off my head example...) only 16k banks can be addressed additionally to the first 16k of the rom which can be used at all times. So data is not going to spill into another bank like in your example.
Of course, there are games that let you spill data deliberately over some rom banks (to save rom space; Devil Children gbc games, anyone?).

And that's pretty much all he tried to point out
[Oh yeah, banking varies between platforms - be aware of that!]

cYa,

Tauwasser

Cool cool. It's probably best to get in the practice of keeping examples like above more accurate anyway just to reinforce the ideas in my head.
 
I quite like to keep topics on topic and I'm surprised no-ones mentioned how far off from Decompressing Grapics we are now so I am going to stop putting questions in this thread (unless of course someone posts something I have to reply to.)

Thanks for the help again I feel I've learnt quite a bit from the last few post.  :thumbsup: