Maybe visualizing things as streams of bytes helps. A "spritesheet" can be technically interpreted as a large bitmap containing other smaller bitmaps in a certain other. Let's do the maths. A 32x32px 256-color sprite uses 1024 bytes (4x4 tiles, 64=8*8 bytes each tile). Roughly speaking, the 4MB RAM of the DS can contain up to 4096 different such sprites (of course, in practice, this number will be lower, since you are also using memory for code, data and other assets). You can group the sprites into spritesheets in any way you want as long as they don't exceed the size limit (e.g. 64 individual 256x256px spritesheets, or 32 spritesheets of 512x256px etc., not to mention you can theoretically fit a single 2048x2048px spritesheet). Using 4-bit sprites doubles the numbers above. Now considering that you don't store everything in WRAM, but in some filesystem type, the limits are much much higher. A 64MB ROM can contain up to 65536 single sprites. Of course, the implementation details matter in order to decide the "exact" limit of the system in use. Do we need to load the entire spritesheet into memory, or are we going to use (and cache) parts of it at a certain time? Is there some sort of compression used? (in which case, the WRAM may dictate a spritesheet's max size, if the compression algorithm works by decompressing the entirety of the data, not relevant pieces of it).
(
