Well... every byte costs money, but it's really quantized. If your game doesn't fit in a power of 2, you have to pay more to get the bigger one (and maybe even a lot more if you also need to include a mapper, plus using a mapper means you've got to adjust your code and what not). But if you're using 75% of your quantized space, you don't need to be that picky.
The last time I built a ROM (in the 90's) it had 7 free bytes of space. That was not a coincidence. It was larger than that and then optimized until it hit a nice power of two and then I stopped optimizing.
It is quantized, but not necessarily to a power of two. RAM and flash sizes of 3x2^n are common even in contemporary microcontrollers, and it’s clearly possible to use fewer R chips then your bus decoder supports in the less integrated computers of yore.
And once you have a project with a fixed amount of ROM, either because the hardware is at a point in its life cycle where you can’t change it, or it’s third-party hardware and you have to use what you get, or because you’re already at your BoM budget, then your software will behave like an ideal gas - it will expand to fill the available ROM. This happens because until you run out of ROM, you will write your software in whatever way is easiest to get your job done. But then once you run out of ROM, you will go back and look for something that you can make smaller. Then you can add a few more features or whatever, until you run out of space again. This process will repeat until you’re done, but your ROM will always be nearly full.
Software complexity following an ideal gas law is an analogy that works in a ton of ways… time (you’ll keep adding stuff until you’re running close to a deadline at which point you have to actually decide what to cut), head count (complexity will rise to match the number of people working on it, since people aren’t just gonna sit idle), speed (it’ll get slower until it’s “noticeable” on the dev’s machine, at which point it gets optimized), etc etc etc.
I’ve tried to use this analogy to PM’s who have trouble understanding why adding more engineers to a project doesn’t make it go faster: the software expands to fill its container.
