Breakpoints are pretty much that, you can also log things (though that is probably better called watchpoints or just logging) and some debuggers will allow actions at those points as well. Here you have the classic read, write, execute breakpoints. The do much as you expect -- if something is written to it will stop and detail what is going on, if something is read as part of a DMA read/general read it will stop it and detail what is going on and if something is actually executed (not just read) it will trigger at that point.
The what is going on part is key, mainly as it will have what instructions led to that point and so if you want to say change what sprite is loaded you can put a read breakpoint on the sprite in the ROM, when that eventually gets read into VRAM you have the instruction that did it. You may have to work backwards from there (it might just be you have found the proverbial grunt that pulled the trigger where you may want the general) but by this point changing the sprite load location is so much busywork.
Memory viewer is much like it sounds. The game console/device has memory, the memory viewer can view it (usually at time you tell it to open the memory viewer or in real time) and it usually looks and acts much like a hex editor (complete with ASCII decode of the hex on the right, though here you should also have the option to load a table). Most will also allow you to manipulate the memory and this would be no exception, again it works much like a hex editor with the only real difference being it has a dropdown box on the top left to select between various memory types/locations.
As the memory on most old consoles has a defined layout/map ( http://en.wikibooks.org/wiki/Super_NES_Programming/SNES_memory_map
) it will probably also be split along those. Though I would not do without one for most purposes it is kind of like hex editing -- you can do an awful lot in it but if you ever see someone do something it is probably the result of a lot of work before then and/or a party trick.
Also I am not sure what the current hotness is for SNES debugging. bsnes changed a lot of things but Geiger’s Snes9x (or some of the other SNES9x versions) are still useful and may be what people know/have guides for, equally no$sns appeared not so long ago and has a few fans (his other emulators have top flight debugging options, this is not quite as nice but beats a lot of other things). For http://www.romhacking.net/utilities/241/
then it should open with a debug window, you may need to click run to start the game.
Once in it if you click show hex (second button down in the third column) it will bring up the memory viewer, you may have to select view RAM. I should also note you have reasonable cheat searching options as part of the emulator as well -- "all" cheat making amounts to memory searching but one need not be making cheats in the traditional sense to find some value here.
Breakpoints. Third column, top button. It will pop up a new window. Put the memory address in you want to halt on and select whether you want write, write or execute (or some combo of them). When it changes it will halt the game and pop up some text in the debug console.
It will look something like
My breakpoint was for a write on 7E0026
$8F/FF79 E6 26 INC $26 [$00:0026] A:0B43 X:0000 Y:00A2 P:envmxdIzc
INC means increase, as the machine is 16 bit you have to fiddle with things if you want more 16 bits of addressable memory (hence the slight complexity in the memory map stuff linked above)
assembly language is just a human readable form of machine code, maybe with some niceties for obvious things. Basic processors do not actually know how to do all that much so most things, especially on older processors, are built up from basic adds, multiplies (though the SNES does not have this nor a divide instruction), read this area, write this area, compare this to that and act accordingly. You can speak to the memory in various ways (these vary with processor) but a lot of what you do will concern the registers. These are sections of extremely fast memory in the CPU and is arguably what determines the bit of a machine* (if you have 8 bit registers you have an 8 bit machine, 16 bit makes for a 16 bit machine.....), the SNES comes in very low with just three of the things available for general use which are known as A, X and Y. A is also known as the accumulator. Technically there are more registers in the CPU but they have defined functions, also parts of the hardware that handle certain tasks can also be known as registers (to save confusion if you want to call the former CPU registers and the others hardware registers then feel free).
Though there may be many instructions, the SNES is on the lower end at 91 or so (what counts and what does not can be debated a bit), it is usually a core set that most things will use (the maths, basic memory manipulation, something to compare and branch accordingly).
With it being such a direct translation of code it is about the only thing you can really convert between on computers. Trying to go from assembled code back to C/C++ is very hard (see the halting problem), though there are some options and some even higher level languages have even more options. I should say though that the vast majority of SNES games (basically everything older than the PS1) will be programmed almost exclusively in assembly in the first place.
This would mean the guide to assembly is really "find the CPU datasheet, there you go", in practice it is perhaps a bit easier as not everything detailed in the datasheet will be used, also the system, or in the case of the SNES even the game, itself may (will) have extras the CPU might not account for. With the SNES being marginally popular around here you do have a few options for the rest of it http://www.romhacking.net/?page=documents&category=&platform=9&game=&author=&perpage=20&level=&title=&desc=&docsearch=Go
, the SNES programming book that the memory map was from is also good and http://problemkaputt.de/fullsnes.htm
is also good.
Assembly hacking is considered the hardest part of ROM hacking for a reason so do not be too put off if you find it hard at first.
*what is marketing, what is tech and what is something in between is a hot issue, or would be but most people consider it done to death. I usually roll with "what are the sizes of your general use registers" as how I determine the bit of a machine.
Anyway I am saying nothing that has not been said several times before in several other guides, most of which were written by people far more familiar with the SNES than I and done after actually thinking about it so I will leave it there.