...not to mention: expanding a game's size (expanding ROM size) sounds easy, but it's often more complicated than it sounds. Three things I've run into doing romhacks with mapper-based games:
1) Finding spare room in the fixed or hard-wired PRG bank is often difficult -- all the "commonly-used" routines or "critical guts" throughout the game are usually stored here. In most cases that's 16KBytes (often $C000-FFFF),
2) Misidentifying "free space". As dougeff mentions, "free space" in a game is usually denoted by long sequences of $FF or $00. However, it's plausible (and often true!) that, for example, 16 linear bytes of $FF or $00 could be actual data used by the game and is not free space. The only way you can truly identify what's unused vs. used is by i) reverse-engineering the entire game (and when I say entire, I mean ENTIRE -- not parts, but all of it), and/or ii) using an emulator that has code/data logging and doing literally EVERY SINGLE THING you possibly can (I've talked about this before
Experience and gut feeling tell me that people today probably use a combination of both, in addition to what we did in the late 90s/early 2000s: did disassembly and reverse-engineering, determined what we could, and took a chance/hoped that it really was free space.
You wouldn't immediately know if it wasn't either -- it might have been data that was only used in a super obscure part of the game, so during your own development/RE'ing/testing you never encountered it, but after the IPS patch is released, some random person is like "this romhack freaks out and maybe crashes when you go into Derpderp's house when you have the gold key equipped and you're wearing the invisibility cloak!" It's problems like this that really suck with romhacking, because you as one person literally cannot test every single thing. Welcome to the joys of romhacking.
3) Sometimes you get lucky, where the original code swaps PRG or CHR banks using "sane" bank numbers. That way you know, for example, bank numbers 0-3 are original code or graphics, and bank numbers 4-7 are OK to use for new efforts; i.e. the code does (effectively) lda #2 / sta $chrpageselect
to select the 3rd CHR page.
However, there are times where programmers were trying to be smart or maybe lazy or left in a bug/quirk from development, and they end up doing lda #6 / sta $chrpageselect
(maybe not literal value 6, but based on some other value), and it works because the hardware (in that configuration) might effectively be doing chrpage & 0x03
(or chrpage & %0011
), thus 6 (%0110) is the same as 2 (%0010). You start using CHR page 6 in your code, looks great/works great, but then somewhere later in the game (in code you haven't touched) suddenly your new graphics show up (page 6) rather than the originally-intended ones (page 2) and you're like "?!?!".
This can apply to PRG pages too, not just CHR. It's worse with PRG because code then crashes, rather than with CHR where you might just see incorrect graphics (and thus have visual indicator of what might be wrong).
Anyway, more often than not, I tend to recommend folks *not* expand the game/ROM size if they can avoid it. But there are absolute cases where expansion is the only possibility due to new code/graphics/things being introduced and not having enough "free space" in the original. In that scenario, you get to reorganise the layout (the fixed or hard-wired PRG bank/page is the most important), followed by changing any PRG/CHR swapping code to use the now-potentially-different PRG/CHR page/bank numbers (depends on mapper and what you moved, in combo with what I described above). Sometimes it's easy and Just Works(tm), other times (as denoted in (3)) it's painful.
Jason's other thread is about Blaster Master, so I imagine this thread is probably discussing the same game (re: how to implement a high score). Blaster Master is a mapper 1 (MMC1 (MMC1B2)) SLROM game
(128KB PRG, 128KB CHR).