How Super Mario Bros Was Made Into 40 Kilobytes 

This was my most complex video I ever made, and I'm thankful for all the positive feedback. Side note: Some of the live action audio sounds bad because I was using some brand new crappy lavalier microphone.

Another interesting thing to note is that the bushes and clouds use the same sprite. That was kinda mind blowing when I heard it the first time.

7:18 No, the music was not created in a tracker. Trackers weren't even around back in 1985. Most video game sound programmers back then coded their music directly in assembly, manually typed hex code, or some form of MML.

3:12 That's actually the CIC chip, which was used to prevent unlicensed games from being played (and the identical one inside the console was the cause of the infamous "blinking red light").

3:54 "While the game never changes vertical axes" That's actually part of the reason why Super Mario Bros. 3 has the miscolored band of tiles on the right side of the screen; because the game has vertical scrolling, it has to load in more at a time, so it has little troubles like that.

"And unlike today" *shows game from 10 years ago*

3:11 I believe that chip is the 10-NES Lockout chip that made sure only licensed games fro the right region were played.

The entire Mother series is like 40MB. Edit: I swear to god stop replying to my old ass comment! Edit 2: So you people wanna reply, huh? Then I'll give you a little question. Who is my favorite Toaru girl?

Title: 40 kilobites Image: 41 kilobites Me: *visible confusion

I feel like this really only said 2 tricks they did to reduce the memory of the ROM, and the rest was just technical info on the NES itself. I was hoping to learn something specific about SMB but it was almost all facts that were true for any NES game

1:04 Yo what is the AVGN doing there?

The assembly code displayed at 05:26 is actually a Linux program for the Intel x86 family of processors. It prints "Hello world!" to STDOUT, and exits. I think it will probably work on any BSD kernel based operating systems if the two syscalls are the same (such as OS X). I'm too lazy right now to look the syscall numbers up. (I used to do a lot of x86 assembly programming, so I instantly recognized this.)

CORRECTION: The "black" color of the palettes can be easily changed just like the other slots of the palettes. However, only *one* background color; more than one would require changing it while the screen is being rendered, whoch some games indeed do If that wasn't the case, the sky in SMB1 would be black at all times.

You didn't even explain how the levels are compressed to fit on the ROM, thats what I came here for.

I recently discovered your animation channel...and then found out you left it...but guess what? I love this new type of content more than animation! So I subscribed!

Atari 2600 game programmers DREAMED of having the power of the NES back in the day. _They're_ the ones who deserve to be admired. Actually, before RAM became affordable and processors became much faster, all those old systems had to make compromises and use different methods to stretch that RAM and lack of processor speed as far as they could. This resulted, most of the time, in games that focused on game play rather than eye-candy since game play was all they had. The best example I can think of for a programmer squeezing every last drop of processing power out of a game system is David Crane's "Pitfall!" for the Atari 2600. This game was 4k, yes FOUR kilobytes, which is 1/10th the size of Super Mario Brothers ROM, yet it contained 256 screens and has many different aspects such as scorpions, rolling logs, swinging vines, alligators, treasures to capture and much more. Here's David himself talking about how he did it! ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-MBT1OK6VAIU.html

3:12 that's the 'key' for the NES-10 lockout chip on the NES motherboard. It was designed to prevent third party games from running, though it was eventually circumvented and is primarily a source of annoyance these days as any dust between the NES-10 cartridge pins and the lock would result in a blinking power light and the game not booting.

I am actually a sophomore in college taking computer engineering and it is mandatory that we learn how to properly program a 6502 with assembly language and seeing all of the cool things done with it back then is cool, too bad it isn’t used much now.

As a kid i never really understood how tiny amount of information 40-70kb of data was. As an adult i am simply baffled by how they were able to pull this off. So many tricks used to reuse assets. Also we have been spoiled today by storage space, its almost not even a factor anymore. So using MP4s and images is more common as theyre richer and easier to work with than raw data.

Micromages *Allow me to introduce myself.*

3:12 Congratulations,that is a CIC Lock-up Chip

1:27 My man actually dissed my child. As a crying child once said: "STO-OP!!! HE'S ALREADY DEAD!"

This makes me realize how far technology has gone

7:46 That’s the DankPods song that makes me remember him every time I hear it.

I want to note that the context of the release of Super Mario Bros. in Japan is pretty important and notes how the game was crammed in a tiny cartridge in 1983 Nintendo released the Family Computer or Famicom fot short and for the first 2 years of the consoles life you really only saw very simple arcade like games for several reasons, one of those being hardware limitations and Super Mario Bros. on the Famicom absolutely pushes the limit on what you can do with just the stock hardware heck that's partially the mindset the development team had when creating Super Mario Bros. a little later after Super Mario Bros. released in Japan Nintendo would launch the Disk System add-on for the Famicom which at the time was more capable of storing a lot more data than cartridges but advancements in technology soon after made the Disk System obsolete couple that with piracy being a problem and the disks themselves being at risk of not working you can see why an NES release was scrapped Nintendo and other companies would create new mapper chips for future cartridge games which literally added in hardware inside of the cartridge that the system can use this video doesn't really go into this context and as a result I don't think it properly explains why they even had to do all of this

Now a days a picture a single frame is a thousand times bigger than a whole game

Very familiar for those of us who started years earlier on the Atari 800 or similar 8-bit system. There was roughly a four year gap between when the Atari 8-bit computer (and 5200 console) and Famicom chip sets were engineered. This meant Nintendo's engineers had a significantly larger transistor budget, though the amount was a rounding error by today's standards. This allowed for greater sprite counts and displayed color depth and more complex audio but one can also see some difference in the basic choices the two groups made. Atari placed an emphasis on color range, supporting a palette of 128 colors in the original CTIA chip and 256 in the later GTIA upgrade. (You could directly replace the socketed chip to upgrade.) This allowed for some tricks the NES cannot reproduce. Also, the Atari didn't have sprites in the traditional sense but rather four pairs of what were called player-missiles. A player was an 8 pixel wide band that ran the entire height of the screen. These were mono colored, so the pixels in the band were either visible or transparent, allowing for one player to appear to be several objects in different vertical locations. The missile was a 2 [pixel wide version of that vertical band. The missiles were actually a fifth player divided up to provide and adjunct missile to each player. This was a compromise from the transistor count that would have been needed to have a full 8 player objects. The later Amiga systems, which had some of the same engineers involved, had similar full screen height objects but also had for the time powerful hardware functionality that allowed moving software defined objects around well enough to do things well beyond what sprites provided. Up until then there was a division of having lots of hardware support for character or tile mapped displays or doing everything in software on bit mapped displays like the Apple ][. Combing the two changed a lot of the rules for developers, which is why the Amiga was the platform of choice for for young developers for many years. Later, when those developers were married with families to support, the platform of choice was the one that came with a steady paycheck.

I’ve been looking for a channel like this one because I’m not big on game design and can’t understand a lot but the way you explain it is easier to under stand

The video was extremely educational, while also being simple enough for everyone to understand. Also, the edits were amazing, it'd been a while since I'd seen someone put so much work into that. Great job dude!

I genuinely love this new channel from Joseph! *:D*

7:18 No. even though we do that today, back then, there were no trackers! Everyone just coded the music in assembly.

fun fact, only the first image of assembly is MOS 6502, the other one is intel x86. Also, in the 6502 one, the CLC line is superfluous since the sum is always $66 and won't set the carry flag and the code doesn't even check for it anyways.

1:23 there's a Pipe bomb in your mailbox

3:17 that is the NES lockout chip, anti-piracy measure that worked pretty well, until it didn't

I’m so happy I found this channel! Keep up the great work!

Your doing better and better! This was edited extremely well keep up the good content

3:13 that is the lockout chip (copy protection)

Nice video! You can actually access all 32KB of data, it's the bigger games where the "bank switching" comes in and you have to move chunks of data around. Also, there are emulators with wonderful step-through debuggers like Mesen. Glad to see stuff like this though =)

*slaps down cardboard NES "sorry, I don't have the real thing" You, sir, have earned a sub.

just found out about your channel. awesome content dude, incredibly high quality. keep it up!!!!!

6:57 Wait isn't that from the 8-Bit Guy edit: nevermind it is I wasn't looking when he displayed the message on screen

Nice video. Just a note. 6:05, this is not a standard scheme. E.g. Metroid uses two 16 kb banks, one fixed, and the other switchable, in order to access the rest chuncks of the ROM. This is because Metroid is a 128 kb ROM, and it doesn't fit in 32 kb. But Super Mario Bros can access the whole code and data without any switching.

Very informative and entertaining! Love the style. You've earned a new subscriber.

4:51 recent 3d games will use 10 different 3d models with hundreds of textures to have sprites (npc/objects) have different colors, this is one reason why today's games are soooo huge. Hope they learn to use tricks like the early days.

Nice! Loving the new channel. I can definitely sence the Scott The Woz vibe, if that's what you're going for.

1:26 you will now get smited by the all might gaben, god of steam, bringer of unusuals and CS:GO skins and the Half-god (3) himself.

The chip you're not sure about is actually the CIC, that was used to verify the card was authorized to run on the console.

This is so helpful and informative I always thought how gba games or old games had small memory size back then now I understand thank you!

2:28 My Favorite but most accurate part!

Btw that third small chip is the CIC. It provided copy protection for the console. Modern vintage gamer has done at least one video covering it. There's a matching chip inside the NES. They use some lock and key type thing. Look it up, it's pretty fascinating.

OH GOD YOUR EDITING IS SO GOOD THE HUMOR OH GOD I LOVE THIS

Great job putting this video together!

Just looking at the Yandere code made my eyes bleed. Should have just used enums instead of strings, with the Flags attribute for stuff like what is witnessed.

1:28 Trust me, it takes a lot more time to master tf2 than you might think

Amazing video. I’m a child of the 80’s and NES remains the only system I have in my living room to this day. Also, I am a visual effects compositing artist by trade, and technical limitations and time are always present no matter what the budget of the project is. Doing my job as a comp artist, you constantly have to problem solve to get the results the client is looking for, without crashing the workstation as well as the final render. So I can fully appreciate and respect the NES dev teams who were up against crazy limitations, and still produced amazing games. It’s all about thinking outside of the box to find those creative tricks to get the job done.

Really liking the new type of content it’s very entertaining and educational! :D

Man you have a good style of humor Wanna know a sad part In the philliphines most kids didnt even know what a console was which was sad and now 2020 I only see kids having "bootleg" consoles And the dumb part is they didnt knoe their consolr is fakr

Back then developers had to figure out how to fit all the data with such small storage, but now developers have to figure out how to afford to use all the hardware since the files are huge.

That chip that you have no idea what it is, is the "Lockout Chip". The NES was the first console to feature any kind of lockout system. It was implemented because of the video game cras if 1983.

To be honest with you it's fascinating how you uncover this while I grew learning about this when I wanted to start my journey as a programmer 25 years back...

2:23 And that the Nokia 3310 vs IPad Pro

5:41 "Y'know those debuggers to know exactly what problems you have so you can easily fix them?" No. No I do not.

It is an incredible video. Great details and great talk!

Just found this channel and I love your content!

The sound part was referenced from The 8-bit guy's video, previously known as the ibook guy, the visuals from his video

While a really good quality production, sadly it was full of miss-leading information and even mistakes. I highly recommend you have someone knowledgeable in the details review your completed video next time, so you can fix bad info before a final version. This way they can make sure you understood the important details right and simplified correctly.

loved the video. I subscribed, you remind me of other RU-vidrs with millions of subs who do stuff like this. keep up the good work!

To answer your question, "how did they compress mario into one cartridge with huge scrolling levels," they stored level data as a collection of vertical 32px wide strips (the chunk that they load in on the fly for scrolling) and they reuse them A LOT. Thats how

It’s kind of like getting a table from ikea. To save space, the table comes disassembled with instructions to put it together.

03:12 No, this is not RAM. It's Nintendo's lockout chip, an anti-competitive measure to prevent competitors from making games for Nintendo's console. There's a counterpart chip inside the console that talks to this chip and performs a handshake during reset. If the keys don't match, it sends the CPU a permanent reset signal. 03:33 No. It's a tile map. The tile set (or the character set) is what's held in the cartridge ROM and contains the definition of each tile that can be used. The tile map is the way the console organizes the image on the screen, dividing it into tiles (characters). Then it can store just the numerical index of the tile that should be displayed at a particular place of the grid on the screen. The tile map stores those indexes, it maps the tiles onto the screen. 03:36 Wrong again. Tile sets are collections of _tiles_ , not _pixels_ . Each _tile_ is a collection of pixels. 04:00 Nope. Each TILE had that limitation, not a TILE SET. The tile set doesn't care about colors. Each tile made of pixels just stores the indexes of one of four colors from the palette, but it doesn't specify what particular colors are they. The information about those colors are stored in the palette, and there's a couple of different palettes the PPU could choose from when rendering the tile map. The number of the palette has been stored for every tile in the tile map, so each 8×8 box on the screen could use only those 4 colors from one particular palette, but another 8×8 box nearby might have used a different palette of 4 different colors. So overall, there might have been more than 4 colors on the entire screen, but not within a single tile. 05:12 Yeah, figures… :q So WHY DO YOU MAKE A VIDEO ABOUT IT IN THE FIRST PLACE?! :P Next time you decide to "explain" anything to your viewers, make sure that you understand it yourself well enough. Otherwise, all you do is just spread misinformation and make fools of your viewers and yourself. And if anyone wants to know how graphics worked on NES consoles, there are much better videos out there, like "How old-school graphics worked" (2 parts) by The 8-Bit Guy, "NES Graphics Explained" by NesHacker, or the series of videos on Retro Game Mechanics Explained. I recommend you to watch _that_ instead. You'll learn much more, and more correctly. This is probably where the author of this video learned about all of this (and understood less than half of it). I even recognize some of the pictures. E.g. the one about the sound channels is directly copied from The 8-Bit Guy's video titled "How Oldschool Sound/Music worked". Plagiarism is not cool :q You could at least draw your own picture.

“Sorry, I don’t have the real thing” Funny man, you make me hahah

As a Gameboy Homebrewer I love this video.

8:08 me: all of the above

Video: 40 Thumbnail: 41 I have been tricked, backstabbed and quite possibly bamboozled

So impressed with the quality of your NES replica. ;)

i just want to say that drawing made for the thumbnail is amazing :>

"Than what tf2 offers" ..impossible, perhaps your archives are incomplete

Another amazing storage-related thing was how gamefreak managed to fit the entirety of johto _and_ kanto on a single gameboy (color) cartridge. This was thanks to the one and only satoru iwata. May he rest in peace

Awesome Video! Very informational and educational!

Short answer is reusing assets, midframe memory swaps and reducing and reusing the lines of code to the minimum to still accomplish what they needed to do. It really is impressive what they were able to do back then with so little to work with.

A little more data? Going from 4 kb to 40 kb is HUGE.

"Sorry I dont have the real thing" *pulls out the controller

You made this channel just in time as I’m going through a Nintendo phase rn

I lost my freaking mind when you pointed out that a screenshot of the game took more file space than the game itself

It feel like this video is gonna have millions of views in like 5 years, I guess...

3:12 That is actually the lock out, ( cic ) chip used by Nintendo to make it where only games officially licensed by them for the system would play, although some companies still manage to find ways around it at the time.

I know colors worked with pallettes and tiles were color limited so it took very little data to define a tile. They would reuse tiles and pallet swap tiles. Clouds and bushes were the same tile set etc... sprites and backgrounds etc we're just functions of the video chips. Level data was reused, sometimes pallette swapped to feel fresh, enemies added. But with all that I still don't think I'd be able to write it all in 40k. Early game devs were very talented to be able to do all that in a time frame where the system stayed relevant. To be familiar with 6502 assembly and color and sound chips and write games in a few weeks to keep things moving seems like a lot to accomplish. While maybe 6502 assembly was pretty common at the time every system and desktop computer has different video chips or no real video processing at all. and there were a few different sound chips too. Code wasn't entirely portable and tile sizes and sprite limits could completely change the feel of a ported game. But as great as those guys were there is still a few guys who can take an old piece of hardware and do things it was never intended to do. Some demo art and game code optimizations out there are mind blowing but it takes more time to plan things out than would have been practical in the lifespan of the original devices.

It was fun seeing someone a decade ot more younger than me explain a problem I know quite a bit about already.

>Implying BoTW has more content than TF2 >Laughs in in hat smulator

"NES game developers were [...] the early pioneers of game development" Er...not really, no. Videogames existed long before the NES did. Not even console stuff, but computer games too.

You making that fake nes made me immediately give this video a like. This was really good! You made it interesting to watch, thanks for teaching me a thing or two.

2:33 The best censor i ever heard my life :D

0:54 pov your the nes

6:26 yeah, that's a lot cleaner than my code. edit: I just realized, mine is cleaner

nice video! it's weird how this is almost the only vid about how nes games were made, ur vid quality was super good too for only having 8k subs why do I sound like those comment bots lol

Thank you for making me aware of Micro mages or the actual games made for retro consoles :')

i actually have very severe time limitations with a modern computer: i want to program a good chess engine (>2k), and i managed to code all the pieces rules in a very optimal way (about 10ns on average). Calculating an attack map to determine if castling is legal (or if you're in check, but that doesn't have to be implemented, because i can use pseudo-legal moves anyway) is already suboptimal (69.04ns/move), and move generation (seeing where each individual piece can go) is beyond slow (109.94ns for about 10 pieces on board). And considering that these calculations will have to be performed millions of times, i would really like to target something along the lines of 5ns/piece for my pseudo-legal move generation function.

3:10 the smaller chip is a piracy lockout chip which talks to a similar chip in the console to block unofficial games.

I had no idea I needed this!

Having a 12 year old say, "remember cartridges?" Is like Benjamin Button saying "hello, fellow kids!"