Are there typically limits to the size that ROMs can be when it comes to emulators?

Submitted ⁨⁨10⁩ ⁨months⁩ ago⁩ by ⁨CorrodedCranium@leminal.space⁩ to ⁨[deleted]⁩

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.

Hope that makes sense. I am pretty drunk.

source

Comments

Sort:hotnew top

skullgiver@popplesburger.hilciferous.nl ⁨10⁩ ⁨months⁩ ago
[deleted]
source
- TheaoneAndOnly27@kbin.social ⁨10⁩ ⁨months⁩ ago
  That was awesome to learn. Thank you.
  
  source
- QuarterSwede@lemmy.world ⁨10⁩ ⁨months⁩ ago
  Excellent, comprehensive answer!
  
  source
KpntAutismus@lemmy.world ⁨10⁩ ⁨months⁩ ago
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.

source
- DebatableRaccoon@lemmy.ca ⁨10⁩ ⁨months⁩ ago
  I thought the reason for switching was the storage limitations of a cartridge, not the console’s RAM
  
  source
  - KpntAutismus@lemmy.world ⁨10⁩ ⁨months⁩ ago
    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.
    
    youtu.be/ZWQ0591PAxM they mention switching storage at 1:10.
    
    source
    -> View More Comments
  - YaBoyMax@programming.dev ⁨10⁩ ⁨months⁩ ago
    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.
    
    source
dis_honestfamiliar@lemmy.world ⁨10⁩ ⁨months⁩ ago
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.

source
key@lemmy.keychat.org ⁨10⁩ ⁨months⁩ ago
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.

source
Kolanaki@yiffit.net ⁨10⁩ ⁨months⁩ ago
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.

source