How come old games like Pokemon 1st gen are so small?

I DL’d the ROMS to play on my tablet, and I don’t get how these can be so small, like under a MB. Are these compressed? How do you fit worlds and cutscenes and character dialogue and music this extensive into under a MB? The only way I can think of is that the code for the game calls pixels from the Gameboy itself, so there actually isn’t any graphics, music or text in the code, its all just text calling certain things on the Gameboy internal hardware (which would explain why games made for B&W Gameboy have colour on them).
Is this what actually happens?

Here’s the first of a several-part series explaining how graphics worked on the NES. NES Graphics. The gameboy is not exactly the same, but basic concepts are the same.

The graphics are actually in the ROM, but they’re stored very efficiently, and there is hardware to support displaying a full image from lots of tiny repeated segments.

The number of pixels on a gameboy are laughably small compared to modern devices. More pixels need more memory. My wild guess is that the gameboy screen would take up less than a square inch on a modern smartphone.

You would be correct, though generous. Original gameboy resolution: 160x144. That of a samsung galaxy s6 is 2,560x1,440. So 1/16 of the s6 screen in width, 1/10 in length. (the screen is aproximately 4"x3") so the gameboy screen could fit in about a quarter-inch square of the smartphone screen.

People used to know how to write tight code…
The image used as an icon for a document on my current Mac takes more storage than the original Mac had RAM…

Text dialog is much smaller than recorded voice. Music and sound effects aren’t stored as digital recordings, but as sequences of commands sent to the sound chip. Graphics are low-res bitmaps with lots of reuse.

In most games it’s the data that takes up all the room. Sound files, texture files, animation keyframes, level geometry. Even in modern games, the actual code is pretty small by comparison.

There were quite a few tricks that were done to keep code size down on those old games.

Nearly all the art was tile-based. The game would have a library of 8x8 or 16x16 bitmaps, and large pieces of art like splash pages would just be a list of which tile to use for each spot on the screen. This saved a lot of space over having an actual bitmap image the six of the entire screen. In the Pokemon Gen 1 games, the overworld maps had an additional layer of compression where larger blocks of tiles were repeated, since you had so many pieces of map geometry that were used over and over again anyway.

Music and sound effects were not saved as digitized files - I don’t think the gameboy could even play digitized music - but as a list of notes that were just sent to the audio synthesizer chip. Even sound effects were all just a list of instructions to a synth to generate and mix together analog waveforms.

Likewise animations and cutscenes aren’t recorded as video, but as instructions telling the sprite handling hardware to place graphics on the screen and then move them around. The code takes heavy advantage of the rudimentary graphics processing hardware for all the hard work.

Those old games were also hand-coded, and the programmers were really good at saving space by re-using code for multiple purposes. I’ve dug through the disassembled ROM files for the original Pokemon Gen 1 and I’m really impressed with how efficiently it’s laid out. Buggy as hell, of course, but really compact.

If it worked, it’s not buggy!

(Might be a hack, but that’s a different thing…)

Also the original game boy was what, four shades of grey? A lot less colour information to store as well.

Even then, 1MB is still pretty huge. Eight bit computers in the 80s had anything from 1 to 64 kilobytes and games were generally loaded in one go. Everything had to fit into that space. But assets were simpler, there were no sampled sounds and programmers used their brains to get stuff to fit. Elite famously used procedural generation to support two thousand planets in a game that ran on a 32kb computer - and half of that memory was taken up by the display (no GPUs with dedicated memory back in those days).

Even the Commodore Amiga had entire games on an 880kb floppy disk. The A500 came with 512kb.

In 1982 David Horne wrote a playable chess game for the the ZX-81, using 672 bytes of memory. It was missing a few rules (castling and en passant chief among them) but that’s still a hell of a thing.

I don’t know Pokemon specifically, but a lot of old games also had procedurally-generated worlds. In Pitfall, for instance, nobody ever actually decided what the world map was going to look like, because if they had, storing it would have taken all of the space they had available. Instead, they created code to generate each screen from “random” data, and then seeded the pseudo-random number generator from a known constant so it’d always be the same. They might have tried a few different seeds before they found one they liked, but it was still basically random.

Another trick: On the NES, I believe that the console had an extended character set that included a lot of often-used graphical elements, so if you wanted to use one of those in your game, you could just use a single eight-bit character value to specify it. Alternately, I think that games could choose to set their own sprites for those characters, if there was something special they were going to use a lot. For instance, Final Fantasy had characters that were icons for a sword, a helmet, a shield, and so on, so you could have an item called “Dragon [sword icon]”, or “Silver [shield icon]”.

To get technical, David Crane used something called a “polynomial counter,” which is a type of algorithmic counter that creates a pseudo-random sequence (an 8-bit value in this case). He also made this counter reversible, so if, say, your polynomial generates a sequence of values like 12-35-74-23, if you enter a seed of 74 and increment it, you’ll get 23. If you then decrement, you’ll get back to 74. So this corresponds to going right (incrementing) and left (decrementing) on the screen. Then, these 8 bits corresponded to the screen layout, basically defining the underground, the tree patterns, the ground patterns, and the objects. The actual polynomial counter was something like 16 or 17 bytes according to Crane (I’ve never actually looked at the disassembly), the total routine under 50 bytes, and it created 256 unique scenes in a very tight bit of code.

And I do recall, as you do, various starting numbers being tried out until a satisfactory initial value was found for the polynomial counter. It’s pretty cool stuff. That was a 4KB ROM running on a system with 128 bytes (not mega, not kilo) of RAM.

Actually, I should say, “if you enter a seed that generates a value of 74”, rather than entering a seed of 74.

I believe you are correct. The NES could do samples, which were mostly used to create drum sounds which were used in the background music, e.g. in the Underground remix in Super Mario Bros 3, though it was used for digitized speech in at least one Sesame Street game involving the Count.

The creator of PocketNES, an NES emulator for the Game Boy Advanced, used the sound capabilities of the included Game Boy chip to make sound, and the one thing that is missing are those digital samples.

I in fact only know of one GB game that used digital sampling–Pokemon Yellow, surprisingly. This was a somewhat enhanced version of the first Generation games designed for the Game Boy Color, although it was backward compatible with the Game Boy.

It’s big feature was the inclusion of the Pikachu from the anime, who roamed around with you rather than being in the Pokeballs in your pocket. And the developers had the great of idea of taking the “roar” or “call” of that Pikachu from the anime, instead of the odd sound effects they usually used.

They took a 1-bit sample of the Japanese voice actor saying “Pika” and played it at full tilt on the CPU, and were surprised at how good it sounded. But notice what I said–full tilt. As in, the CPU was completely occupied and could do nothing else–even on the GB Color CPU that was twice as fast as on the original GB.

Considering all that, it seems quite unlikely there was any way to have digitized background music.