News:

11 March 2016 - Forum Rules

Main Menu

SNES Tutorials

Started by Cyclone, November 09, 2022, 10:08:55 PM

Previous topic - Next topic

Cyclone

Hi, I am looking for beginners snes hacking and ASM tutorials. And how to use debuggers

Thanks in advance.

akualung

#1
https://www.romhacking.net/?page=documents&category=&platform=&game=&author=&perpage=20&level=&title=snes&desc=&docsearch=Go

There are several tutorials and other kind of info related to snes on the "documents" category on this site. There was also a general romhacking roadguide or something similar, on a pinned post on the forum.

I used some time ago a site that had a snes asm tutorial which was divided into short lessons and started with the most basic concepts (how the 65C816 works, its registers, etc), but sadly it was discontinued. I think it was called snes asm adventure or something similar, but I can't find it now.

edit: I found it, it's this one https://georgjz.github.io/snesaa01/

I found it last year and the last written chapter was from 2019 (chapter 7, I think), so I assumed its author had just given up on it. But I now see that he has written a few new chapters recently.

Happy hacking!  :thumbsup:

FAST6191

The above is the proper answer.

More generally... actually debugging and in many cases assembly* is fairly similar between systems so it may pay to find something more developed for whatever and then pivot after the basics have clicked.

When the basics are at least there enough to start to understand the meanings of the actions taken most will then find whatever hardware documentation there is.

*learn one and you can learn two, learn two and they all start looking similar. Obviously there can be exceptions; learn NES 6502, z80 for whatever contemporary system and try to jump to high end X64 SIMD instructions and you might face an uphill struggle/have to fall back on any maths background.

https://www.plantation-productions.com/Webster/ https://stuff.pypt.lt/ggt80x86a/asm1.htm both being for PC but a nice primer in both cases, if video is your thing then
https://www.youtube.com/watch?v=hE7l6Adoiiw&list=PL6B940F08B9773B9F&index=1
It moves more into Java in later stuff but earlier things are assembly enough to make it all make sense, C to go with that and that together acts as a nice primer, if a bit slow going if you already know some of it.

There may well be a SNES equivalent of http://www.coranac.com/tonc/text/toc.htm which is a guide to writing homebrew code for the GBA and all its hardware (much of which is similar to the SNES or references it), http://problemkaputt.de/fullsnes.htm is not as nice as some of his other documents on console hardware but still good stuff.

Can do the basics of things though.

Debuggers.
In the basic model of computing (advanced security makes things more complicated with different levels) then a piece of memory can be having three things happen.
1) Data being written to it.
2) Data being read from it.
3) Data on it being executed by the CPU.

Consequently there are three basic breakpoints (as in break when this condition is met)
Break on Write aka BPW in many emulators/debuggers
Break on Read aka BPR in many emulators/debuggers
Break on Execute aka BPE or BOE in many emulators/debuggers
Some will combine those into break on access, run to line is a special case of break on execute (usually set when you want it to stop at a given location a few instructions on from where you landed as it is doing something you don't necessarily care about), many will have conditional options you can tack on top of things (break when written but only if greater/less/equal to... sort of thing). Watch points/log points are also a thing where instead of hitting pause when something happens it notes it to a text file/output such that you can examine it later.

"All well and good but that does not help me understand much in and of itself" you might say. Indeed. Debugging is then a long game of what changes as a result of this and work backwards accordingly.
Cheats form the basis of a lot of things. So you want to know atk stats and how they work in a game. You could try finding stats in the game, good luck with that (there are some weak methods but yeah). Instead find the enemy HP ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial https://doc.kodewerx.org/hacking_snes.html ) via standard cheat searching methods. Do an attack such that you damage the enemy (bonus is you have their HP location so can refill it easily enough if you need more/forgot to equip the basic starter sword to go against the end boss), somewhere in the previous calculations on damage will presumably have been atk stats, or if not you get to share with the world it is likely bugged so don't worry about it (atk would be rare to be glitched, luck and other such things rather less so).
Data will eventually end up in VRAM to be displayed on the screen, get to a point before it is (start of level, enter a dungeon, recruit a new character, reset to title menu... it does not matter, if you were good you would have already had a savestate) and set a breakpoint on where it will land. Get it to appear (start the level, enter the dungeon, recruit that character, start a new game/continue a previous save...) and up will flash the breakpoint saying this is what wrote it, here is where it found it. If you are lucky you have the location in the ROM (welcome to a concept called tracing by the way) via whatever means (DMA read, CPU read, BIOS call, assignment by some means...), if it is from the RAM then chances are some compression happened in the middle and you now have a front row seat to how it did it (no more shall custom compression be a project halter).
Did something happen as a result of a button press? Well good thing the button state lands in a particular part of memory probably every frame or so and gets read (possibly to another area which is what code operates from if it is good -- it is called debouncing, it is done because mechanical switches vary and you don't want the is it/isn't it to change between reads in a frame and have the game behave oddly -- B not pressed so no need to fire a fireball, few instructions later another read says pressed so start running and you don't have that fireball "shield" as a result -- gamers will tolerate a lot but that will get your game called broken quickly enough).
Same for audio, same for everything really. This is why many a hacker's bedtime/just for fun reading is the hardware documentation for the object of their interest.

Logging mentioned above has a crazy, though some say genius, cousin in stuff like https://fceux.com/web/help/CodeDataLogger.html (don't know if SNES stuff has it but many will). This will maintain massive logs of things that happen and allow you do see new code executed -- usual example being something like you care about jump mechanics in a game, you could see where the sprites are in the OAM, you could watch the controls, you could watch the sprites to see if the jump one is loaded, you could find some internal location state, you could even find what channel plays the boing noise and watch that. All fun and viable in their own way but maybe not for this game. Instead logging is used. Here you will find somewhere and so everything but jump such that it sees any internal clocks, idle animations, walk, background animations, music playing... and then the newest instructions it has not yet done will be what it shows when you do actually jump. It is about as system grinding as ROM hacking really gets (give or take encoding videos for those few things that do it or some types of patch making on large optical media systems) as you are making very large logs and parsing them, but anything vaguely modern should be able to handle it for anything that might plausibly be mistaken as being on the SNES and maybe PS1.

Quickfire round of other things to know/wish someone would have given me when I set about learning
Registers. Two meanings but the main one for assembly is the CPU has sections of blistering fast memory, 16 bits in this case (it is kind of how we get the definition, at least until the pond scum that makes up the marketing department gets involved). How many you have varies between CPU (NES effectively having 3 general purpose ones, SNES kind of being the same way http://problemkaputt.de/fullsnes.htm#cpuregistersandflags , modern X64 PC having a rather more complicated setup but definitely larger however you care to slice it). The other meaning is specialist parts of memory that function in similar ways to some of the non general purpose registers (controller state for what buttons are pressed, the OAM for what sprites are doing as far as location and flipped/rotated/whatever nature, palette they are using).
NOP is not always an instruction in the instruction set of a given CPU but functionally can be made. It is short for "No Operation" and basically gets the CPU to twiddle its thumbs for a cycle (or more in some cases). Useful when you want to remove something from happening but delete is obviously a bad thing.
You can look at the long lists of instructions, even worse if you try it for X64 PC stuff, and try to memorise them all. I would instead say get a core list of things.
For my money there are three classes of them
1) Maths. Addition, multiplication, subtraction (not always available), division (rarely available actually/special measures needed), logs, Boolean algebra/logic, sorts of things you might find on spreadsheet guides https://help.libreoffice.org/Calc/Mathematical_Functions
2) Housekeeping
So you have three registers. 48 bits is not much so you will want to move memory around from one to the other (see mov in most instruction sets), lose it and return it a bit later (see push and pop respectively), fiddle with memory itself and things like this.
3) Program flow.
Maths and shuffling numbers around memory is great and all but when games can literally be defined as a series of interesting decisions then you kind of need to test the results/make decisions. Enter program flow, or loops as most programming languages will introduce the notion to you as ( https://www.tutorialspoint.com/cprogramming/c_loops.htm being one example).
Most things will be a compare these two numbers, if equal/less than/greater than/not equal to. This would be ID ELSE in most programming tutorials.
WHILE tends to be check this given thing and if it is this then do this, otherwise do that.
FOR tends to be like WHILE but maybe adds 1 to a given value every go around and once it reaches a point (good/safe coding might be if greater than, lesser coding might use equal to hence why going over an original value might do odd things in games where it had hard limits normally) you do something else.

NOP then becomes really useful in these sorts of things -- want to disable a save hash, great somewhere in it will be a compare the value of [all this, possibly crazy, maths] to value from the save itself, if they don't match then jump to/branch to the save no go path, ELSE carry on with life. A choice NOP in there so it jumps to the good path regardless then means you bypassed the save check and get to edit the save to your heart's content (possibly to have the game make the save correct upon next save)

MysticLord

I didn't read the previous replies, but Retro Game Mechanics (RGM) has a huge series of informational videos on SNES hardware features and general retro game mechanics as they are implemented in assembly language.

General SNES Info
https://www.youtube.com/playlist?list=PLHQ0utQyFw5KCcj1ljIhExH_lvGwfn6GV

SNES Audio
https://www.youtube.com/playlist?list=PLHQ0utQyFw5JD2wWda50J8XuzQ2cFr8RX

Specific Game Mechanics Implemented
https://www.youtube.com/playlist?list=PLHQ0utQyFw5KT8_MDSi0DHlVG_cGaY-Cu

Minor Bizhawk & Aftereffects Tutorial
https://www.youtube.com/watch?v=yuVx4QI6fIM&list=PLHQ0utQyFw5KFManV1_IkwJpBvlfiZQ9U&index=1

Consider the content of these videos essential to learn the vocabulary and familiarize yourself with the concepts before or while you dive into assembly language.

Cyclone

Quote from: akualung on November 10, 2022, 08:36:30 AMhttps://www.romhacking.net/?page=documents&category=&platform=&game=&author=&perpage=20&level=&title=snes&desc=&docsearch=Go

There are several tutorials and other kind of info related to snes on the "documents" category on this site. There was also a general romhacking roadguide or something similar, on a pinned post on the forum.

I used some time ago a site that had a snes asm tutorial which was divided into short lessons and started with the most basic concepts (how the 65C816 works, its registers, etc), but sadly it was discontinued. I think it was called snes asm adventure or something similar, but I can't find it now.

edit: I found it, it's this one https://georgjz.github.io/snesaa01/

I found it last year and the last written chapter was from 2019 (chapter 7, I think), so I assumed its author had just given up on it. But I now see that he has written a few new chapters recently.

Happy hacking!  :thumbsup:


Thanks so much. Looks very useful

Cyclone

#5
I am stuck on the first chapter.

I downloaded https://www.msys2.org/

But I get a blue prompt when I try to run the exe. "This app can't run on your PC"is there maybe a 32 bit version?

Edit... I got it downloaded but where do I get the bsnes+ source code?
I checked here.
https://github.com/devinacker/bsnes-plus
but which is the source?

Edit... Ok I got the source code downloaded.
I downloaded mingw-w64-install.exe and it gives an error. Not downloaded properly or something.

Cyclone

I found a none installer version on sourceforge.

The guide is asking to link it with the command prompt in windows. But there is no bin directory... I was able to link the other programs that the tutorials asked for I'm just stuck here.

Cyclone

Everything is good. Got it working. I finished the tutorial. Was very well written.

Are there any others that are as good as this one?