Are there typically limits to the size that ROMs can be when it comes to emulators?
I was thinking about large ROM hacks like Only Up 64 (Vinesauce's Joel game play video here for an example of what I am talking about) that state that they can run on real hardware and it made me wonder about ROM hacks and homebrew that can't run on real hardware.
What kind of limitations do these ROMs face when their limitations are emulators and not real hardware? For example is there a size limit to what a GBA ROM can be? Could you make a super in-depth hundred+ hour game for the GBA that takes up 100 GB?
I guess I am curious about what limitations are hard coded into emulators for things like accuracy and what are some examples of ROMs that have gone above and beyond or notable emulated systems where the the limitations of real hardware are frequently bypassed.
It depends on what you mean by "size". It also depends on the console.
Many ROMs only allow for a limited amount of storage to be addressed. To work around this, cartridge based ROMs used bank switching; basically, the cartridge pretends to only contain a small amount of code/data, but when you change some code, the contents of that code/data are swapped out with data coming from another chip. To the console, it looks like the chip has been partially or entirely switched out, and new assets can be loaded into RAM.
You could, theoretically, have an unlimited N64 game because the N64 allows for external coprocessors. The "cartridge" interface is basically directly connected to the system internals, and there are very few requirements that force you to actually put storage chips where the console was designed to load data storage from.
There's very little preventing you from making a cartridge that pretends to be a ROM containing data at boot, but is actually a much faster computer that will just feed the N64 data by swapping out the "contents". For example, you can bootstrap the N64 to load some code into RAM, then let a modern PC hooked up to a cable from the cartridge take over, where you can run games petabytes in size, with only the stuff necessary for rendering to the display being returned back over the cable. On the SNES, this stuff was used to add coprocessors to games to extend the lifetime of the console by adding accelerators.
In practice, you'll probably be limited by the CPU power, RAM, and the ±5MB/s transfer speed of the cartridge bus before you're limited by storage size. We could've probably seen multi gigabyte N64 ROMs had the console been powerful enough to still be relevant when those chips became affordable. In practice, most of them were 64MB in size.
As for GBA games: some GBA games used bank switching (executing specific instructions that made the cartridge pretend all/most of the ROM contents suddenly changed into something else), but for a screen that size, there's not really a point to using more than a couple hundred megabytes of ROM to be honest. You're going to need to design as chip to do that, and design a I/O protocol to switch banks. The GBA only has a 24 bit interface (16MB), but you could design a protocol that's like "if I write $BEEFEE to address $ABCD the next four data reads I request will be the bank number", allowing you to "access" 2^96 different banks, all sized up to 16MB. If you can eat the cost of designing hardware, you have effectively unlimited storage.
Disc based systems will have physical limits, but disks can be swapped out midway through. Various PlayStation games used this. As long as you have enough RAM/memory card space to track all of your state, you can effectively has as many disks as you want, though the user will have to swap them out. Virtual consoles don't have such limitations on the input, but the hardware is designed for only accessing a limited amount of storage, so you can't load a 40GB image into a PS1 emulator and expect it to work without rewriting some low-level code; the CD drive can only take offsets into the disc for so far.
Interestingly, cassette based games are effectively unconstrained by design. Loading data will take forever, but you could feed a terabyte sized cassette into a C64 and hit play.
So in short, cartridge based systems and disc based systems all have methods of effectively unlimited storage, with cartridge games being more user friendly at the cost of custom hardware. In practice, this requires design decisions that ROM hacks may not be able to do.
the NES had some titles where there were two ROM banks where access to one of them were switched when a certain part of the game was reached. this had to do with the limited RAM of the system i believe. you could technically do this but hundreds and thousands of times.
technically, it would also be possible to increase the RAM capacity and make it emulator-only. it has been an emulator detection feature to try to access a memory adress outside of the possible capacity.
AFAIK, the contents of the cartridge was entirely loaded into RAM, so one bank of ROM chips needed to be a specific size. the cartridge of course gets much more expensive if you double the storage, so it wasn't done very often.
Bank switching is necessary because the 6502 chip in the NES has a 16-bit address space, with the bottom 0x4019 (~16K) bytes being reserved for system use (RAM, PPU/APU features, and controller I/O). Cartridges therefore only had access to a ~48 KiB range of address space (although in practice I believe only the top 32K was typically used for ROM), so bank switching was needed to be able to fully access anything larger.
Bank switching is necessary because the 6502 chip in the NES has a 16-bit address space, with the bottom 0x4019 (~16K) bytes being reserved for system use (RAM, PPU/APU features, and controller I/O). Cartridges therefore only had access to a ~48 KiB range of address space (although in practice I believe only the top 32K was typically used for ROM), so bank switching was needed to be able to fully access anything larger.
Limits depend on the original hardware. For instance if the device uses 16 bit "addresses" to refer to locations in the cartridge storage and read a byte at a time, you'll only be able to make use of the first 2^16 bytes (64k) of storage regardless of how much extra data you throw in there. An emulator could in theory support extensions to get around that but then you're not really emulating the original hardware.
Nice video. Do you have an example of a ROM hack or homebrew that can't run on real hardware? The only limitations there is that you can't load it because you have limited access to run unofficial software.
I am pretty sure the storage has no limit in software, only by the hardware used to make the games. It's the memory usage that's most limiting. Can only have so much stuff loaded at one time. There are some clever tricks and workarounds to this tho. Like swapping sprite sheets to increase enemy variety or swapping color on the fly to have more than 4 colors at once.
The ROMs themselves got larger over time as they started making larger capacity chips to store everything. If you simply wrote a ROM to be emulated without having to fit it on a physical cartridge, you could make it as big as the drive meant to hold it.