[MMR]

what should i do to start hacking snes rom
I want to learn how to change the ROM codes, modify how sprites and game physics
if anyone can help me how should i start

[Isao Kronos]

The Newbie Package of REQUIRED Material

ROMHacking.net FAQ: You ask, we answer!
ROMHacking.net Getting Started Section: Newbies Go HERE!
ROMHacking.net Documents Section!
How to ask questions the smart way.
On the Essence of ROM Hacking
Talk with experienced people in our IRC chat and ask specific questions there.

[slidelljohn]

Good tools for snes hacking:
geigers snes debugger
vsnes for viewing geigers snes debugger savestates
bsnes plus snes debugger
lunar ips
lunar address
lunar expand
Tile Molester

Good reference material for snes hacking:
https://wiki.superfamicom.org/65816-reference
https://wiki.superfamicom.org/registers
https://wiki.superfamicom.org/memory-mapping
https://wiki.superfamicom.org/sprites
https://wiki.superfamicom.org/backgrounds

I know that you mentioned Gokujou Parodius on one of your other post so
I created a trace file of some of its code for you to look at.
http://www.mediafire.com/file/mjyp26xqzmd5jvm/Gokujou_Parodius_%2528J%25290000.log/file

This file was created using geigers debugger. In the debug console
I had trace once checked then I checked CPU under logging and then
I pressed the run button to run the game. I let the game trace code
until I started the 1st level then I unchecked CPU under loggin to stop
the trace. Checking the CPU under logging is what starts tracing the
code that the cpu is executing. Having the trace once checked will make
the trace file only document a section of code once. If it was not
checked then it could trace the same code multiple times. I only
sometimes use the trace once feature when tracing the cpu code. These
trace files get created in the same location as your rom that you
loaded into geigers debugger.

In the trace once file that I posted I put a few comments showing what
a few of the lines of codes are for on the 1st 2 sections of code.

When you start a game you start with 2 lives. Your lives value is in
ram at $7E:00A4 and in rom at $81:D72B

I put comments at lines:
$80/C642
$80/C645
$80/8782
$80/8785

Search for these in the trace file that I posted so you can see how the rom
value for your lives gets loaded from rom and stored to ram. If you want to
start with 4 lives instead of 2 click the show hex button in geigers snes
debug console and under viewing select rom then scroll down to 81:D72B
and change 02 to 04 and then hit save rom. Now you have saved your rom and
every time you play you will start with 4 lives. Just be sure to make a copy of
your rom file before you save it so you have a backup of the original file.

Remember google is your friend and a lot of questions that you might have
could be found by using a search engine or by reading the many documents that
are on romhacking.net.

Happy hacking and good luck on your journey into snes hacking.

[MMR]

@slidelljohn

thank you very much bro, it helped me a lot I already got a lot of things I didn't understand and good luck with your projects what will be next after gradius 3?

it's really hard to know where the levels and sprites code lines are going to try to figure this out by changing the hex values ​​randomly xd lol

[slidelljohn]

Your welcome, and thanks! I have a lot left to do
with gradius but I also have projects for 7th saga
and mega man x.

The vsnes tool will help you find what you are
looking for and you should play around with it.
For the sprites you need to look for the oam
ram. Open vsnes and a savestate that has a
sprite that you are looking for like maybe your
ship. After you open your savestate in vsnes
open the hex viewer in vsnes and scroll to oam
ram. The oam ram is the data for your sprites.
The link for the sprites that I posted shows you
that each sprite uses 4 bytes in oam ram. In the
scene viewer if you show the sprites you can see
them change if you change the bytes in the oam
hex viewer. Usually if you look at the oam ram
in the hex viewer you can find the same bytes
in the wram hex viewer. If you can find the oam
data in wram then you can trace your code back
to find out how that data got there for that particular
sprite. You can also do this with cg-ram which is for
your color palettes. Play around with this for awhile
and see what you can find. As you find stuff keep
notes for it in a rom map and a ram map. The more
stuff you document the more you will understand.

Here is a test for you. Try to find your ships color palette
in the rom.

Step #1 find ship color palette in cg-ram
Step #2 find cg-ram in wram
Step #3 trace code back to find out how it got in wram

When you go to trace the code for finding the color palette
make sure that you do not use trace once when you
trace the code. When you go to trace the code start the
trace just before the data for the color palette gets loaded
into wram then stop tracing after you see it appear in wram.