Some programming languages are called ASM.
ASM is not exactly a programming language.

Forgive the Homestar Runner joke, but it's basically true: ASM is not so much a language as a catch-all term for the myriad sets of processor-specific operation mnemonics. Like programming languages in the higher-level sense, basically all forms of ASM can do similar things, just with slightly different syntax and semantics, but in this case, ASM translates directly into machine code. All a basic assembler really does is turn the little leet-speak abbreviations like MOV or LDA or ASL into the equivalent numbers the processor (or emulator thereof) comprehends. It's really kinda cool when you get down to it. My earliest ASM hacks involved hand-assembled machine code.

Now, if you've found general ASM tutorials but they didn't help, that's because ASM knowhow (which is readily retooled for different platforms) is separate from hardware knowhow. That is, you can write a program in ASM, but that doesn't mean you know how to access the graphics hardware or memory mappers or joystick inputs or anything on an actual system. And we've got documents for that sort of thing.

Anyways, here's what you want to look for.

1. This will involve a debugger. I recommend FCEUXD for NES games, BGB for Game Boy, VBA-SDL-H used in tandem with VBA for GBA titles, and Geiger's SNES9X Tracer used alongside vSNES for SNES games. The first step, or so I figure it, is to set a breakpoint on where the tile map data is stored. If you don't know what a tile map is, I suggest you brush up on the basics of game system graphics. If you don't know what a breakpoint is, you need to brush up on the basics of software debugging. Anyways, once you've figured out what instruction writes the map data to VRAM, work backwards from there and find out where the map data is coming from to begin with. That's your start. No clue as to the rest; I've never had reason to do it myself. ^_^;

2. On NES, it's crazy-hell. On GB and SNES, it's much simpler, although only "easy" should the stars align just right. And on GBA, it's a freakin' no-brainer. See, what the NES, GB and SNES have in common is that they can only see a small "window" of a game ROM at a time. Those windows are called "banks". Now, NES games have a bunch of different mappers that are used to determine which memory addresses come out to which ROM addresses at a given time, and expanding a ROM usually involves reprogramming a game to use a different mapper. Yes, "reprogramming". On GB and SNES, it's the same thing, except there are only a handful of different mappers for GB, only two real ones for SNES, and none of them have the issue that kills expansion on the NES: the hardware expects the "PRG ROM" to be located in a certain place, and changing the size means changing the PRG's position and everything that points to it. So anyways, you can change a GB or SNES ROM's size without having to rewrite the whole freakin' game, but getting the game to recognize your new data can be trying: in all three cases, you will likely have to add code to store the current bank, change it to point to your new data, then restore the original bank after you're done. On GBA...well, the entire ROM can be addressed at once, so no more banks! Woo-ha!

Hope this is some help.

Some programming languages are talkin' animals.
ASM will get what it deserves.

For the NES, you only have to change the mapper if the ROM was already at the limit.
To expand PRG, you have to double the PRG-ROM size, but it has to be added before the last 16KB of PRG.
(might be 8 on some mappers, but I move the last 16KB to be safe).
(so if the game had 128KB of PRG, I'd copy the 128KB of PRG (just to be safe), then I'd put in 112KB of blank space, followed by the last 16KB of PRG (again, to be safe).
The NES doesn't know the data's moved, since most mappers expect the last 8 or 16KB of CPU address space to represent the last 8 or 16KB of the PRG ROM. And the rest of the data hasn't moved.
I've swapped banks I was in before, just have to realize where you are relative to the current bank, and continue your code in the same position in the new bank.
So, like if STA $8000 is the code to swap a PRG bank, and the command STA $8000 is $500 bytes into the bank A, and you are swapping bank B in, you'll want to continue your code at $503 bytes into bank B.
Trouble is finding a place where you can safely insert a 5-byte long bankswap command (typically a 2 byte LOAD followed by a 3 byte STORE) (and the game may also store a variable that says what ROM bank is stored in each swappable bank)

(only exeptions I've seen are Namcot 106 (mapper #19), which expects extra ROM space at the beginning for some reason, and if expanding a MMC1 (mapper #1) PRG ROM to 512KB or more. With more than 256KB PRG, all bankswaps will be relative a 256KB portion of the ROM. So you'll have to write to an extra register to set which 256KB chunk is "active".

Actually, games store the level map in their own format somewhere in the ROM.



I think you just changed the tilemap in VRAM. Sort of like changing a game's geometry data in the graphics card's VRAM, but not on disk. As soon as it gets reloaded, your changes will be overwritten.

You'll have to use BSNES v0.13 (it's on the site in the utilities section) for setting a breakpoint in VRAM. Does anyone know how to set a VRAM breakpoint in Geiger's SNES9X?

Note also that while every possible address on GB can be used, the same cannot be said for the NES (or SNES, IIRC).

Maybe I forgot to menction, but I have no idea what a breakpoint is ;_; Any tutorials or docs made about that?

No. I don't think you can in Geiger's. I usually scan a trace file for loading the VRAM source offset before a manual VRAM transfer or DMA register setup for VRAM transfer.

Generally though, I don't need to look for things getting stuck in VRAM too often. I usually have figured out a RAM location or ROM location of the source data.