I would've expected more books on HTML to be around.

Bank swapping is not so much ASM knowledge as hardware knowledge.

By writing to certain addresses, you can swap banks, or read the current bank from a particular register.

Oh, that's simple. The start point is fixed. The reset vector is 2 bytes at $FFFC-FFFD. What ever address is there is where execution starts at. The only thing that changes is what bank is loaded into the $F000-$FFFF space initially, and that varies from mapper to mapper.

For example, mapper 16, the last $4000 bytes of PRG-ROM are hard-wired (can't be swapped) at $C000-$FFFF. So, for say, DBZ3 (since I can still remember it), PRG-ROM is from 0-$3FFFF. That last $4000 bytes ($3c000-3FFFF) is the bank that'll be hardwired. So you go to $3FFFC, and what ever address is there (I don't remember right off) is where execution starts.

EDIT: This is specific for the NES. Other CPUs have reset vectors (or may be different entirely), so you'll need to check some documentation about those chips. Here's an okay explanation of the reset vector. Look under "What's Happening?"

Is there a GUI yet?

I like Mednafen, I just don't like having to type huge paths and stuff. >_>

Well, it's actually + $3C010-4000F because of the header.

You should also know that $FFFA-FFFB and FFFE-FFFF control the NMI and IRQ routines (can't recall which is which, but you may need to know them, since those routines can happen at any time in your code, so you'll need to be prepared if they bankswap on you. If they do, they're probably loading the original ROM bank bank in. Hopefully, it's reading some RAM value that held the last value written to the bank control register, and you'll just need to update that value when you bankswap. Or it could read banks from a table, which is uglier.)

Most mappers' registers can't be read, since they usually occupy the same address range as ROM. Like mapper #3 allows you to write a CHR bank to any value between 8000 to FFFF(*), and that CHR bank will be swapped in. But if you try to read it, you'll just get a value from the ROM.
(I later realized that $2000 and $2001, which configure the PPU, shouldn't be read either, and that's why the FDS BIOS routines that write to $2000/1 will copy the value to RAM, so you can read it if you need to )


(*)this mapper's bus conflict is kinda besides the point, so I'm ignoring it.

As for reset vectors,
I believe the SNES uses the same reset vectors, but it's at $7FFC for games with 32KB banks and $FFFC for games with 64KB banks (since they'll both resolve to $80:FFFC in the SNES memory map)
GB/C I believe starts at $0100, which is supposed to be a jump to the start point (since $0103 is where the cart header and license-unprotection Nintendo logo starts)

Built in GUIs are redundant, at least for Windows (Even DOS has a few good frontends):



Runtime changes for some things would be of benefit for Mednafen, but that itself doesn't require a GUI.

There is one for Win32:

http://lhsp.s206.xrea.com/works/frontend.html

I still prefer QuickPlay + edited INI file. Being able to run any of my ROMs from one common interface (And having most of my console ROMs in 7z archives) is invaluable, and the one thing I'm really missing in my current adventures of jumping headfirst into Linux.

And to keep this on topic... :p

Learning the language of the CPU of a computer is only half (or less) of the battle. You also need to have an understanding of the peripheral hardware in the machine, like the RAM, video hardware, sound hardware (Which in the case of the NES *is* the CPU), etc.

Shit like $0200 - $07FF (RAM), $6000 - $7FFF (SRAM, if a game has it), $2001 (PPU register that controls color emphasis, monochrome mode, enabled/disabled sprite layer), yadda yadda.

While I understand the architecture somewhat, my biggest obstacle was simply programming the damn thing, since I am extremely weak at programming in general; a lot of the concepts of what need to be done escape me, so I was pretty limited in what I could do with that Dragoon X Omega II hack I was a part of. I did, however, become a lot more proficient than I ever have been over the course of a few months, mainly just by reading a ton and experimenting a lot.

NESDev is a godsend for information: I would suggest making that one of your first stops.

Also, FCEUXD (I hear FCEUXDSP is good too, but I never used it) is invaluable for assembly hacking, mainly because of the quality of Parasyte's debugger and the awesomeness of bbitmaster's real-time hex editor.

The hex editor lets you manipulate RAM or ROM on the fly, and highlights what has been changed in red; you can undo to hell and back as well, if you screw something up. I got to the point where I was conceiving/entering all my hacks in machine code in the thing, and it was *easy*; no other NES hacking environment is so user friendly.

There are also some other interesting tools, like the code/data logger. I used this to quickly track down the routines for the HEAL/PURE/TENT/CABIN/Etc items in Final Fantasy by going to the item menu, starting the logger, using an item, then dumping the log to a stripped iNES file.

A quick browsing with a hex editor showed small strings of code in a sea of 00s, since it only logs what was executed into the stripped ROM, at the address it's located.

Searching for the first few opcodes in RAM during the item screen revealed where the game was loading the routines, and I set execute breakpoints there; from that point I was able to trace the code, gut the bastards, and splice in my own routines in their place: This allowed me to create unique item effects.

I also traced some of the routines the game already had (Like refilling MP from the House, the save routine, etc), so I could call them as needed without having to reinvent the wheel, so to speak, which saved tons of room (I was extremely limited in free space in this particular bank).

Once you even get a taste of assembly hacking, you'll wonder why in the hell you never learned how to use it earlier... I went 8 years without bothering to even really try to learn/use it, and regret it immensely.