NES Scrolling Basics featuring Super Mario Bros. - Behind the Code
ฝัง
- เผยแพร่เมื่อ 31 ม.ค. 2022
- NES PPU, Scrolling, and some background talk - how does it all work?
If you would like to support this channel, here is a link to the Displaced Gamers Patreon page - / displacedgamers
Twitter: / displacedgamers
Facebook: / displacedgamers
Instagram: / displacedgamers
Music - / @wolfandraven
Stickmen Illustration by Zach McCue (Twitter & Instagram - @zoddman)
#NES #Programming #Mario - เกม
Man this brings in perspective when people glitch out games like Megaman 1 when the background doesn't match the logic. It all now makes sense.
In older consoles like the NES, there wasn't really a differentiation between different kinds of data - it was up to the programmer to handle those distinctions.
Which means, if you can bug out something in a game and get it to start reading data from an unintended address in RAM, those RAM contents then get fed through code that expects graphical data. Since there's no hardware distinction between these different kinds of data, it just goes right through and has very interesting effects.
since game mechanics are just writing values to specific places in RAM, you may actually be able to set specific RAM addresses to specific values (sort of like how Cheat Engine works) if you know which exact tile corresponds to the RAM address you want to change. This is how the SMB3 wrong-warp skip in the pipe level is achieved - they do this by clipping through the level in a particular way that scrolls the screen far beyond the normal boundaries of the level, until it begins to start reading other sections of the RAM. There is a specific section in RAM that can be changed to instantly trigger a warp to the end credits, and since that code is interpreted by the game as an object (like a question mark block), they can actually interact with that object and set the desired value into RAM directly.
That scrolling behavior was the reason for the doors in Metroid, that way the devs could hide the change from vertical to horizontal and vice versa.
Dude, we need MORE of exactly this kind of stuff! -- I've always been interested in how tiles, sprites, scrolling, etc. worked on the NES, and never knew the literal _hardware_ determined scrolling direction on some games! Such a fun bit of trivia! :D
I'm actually developing a scripting language based upon some of these old-school programming techniques, so the more of this kind of stuff you share, the more likely I can integrate some of the neat tooling/concepts I learn into a modern language! -- I already know quite a bit about NES programming methodology (thanks to my sprite animator background), but I was surprised to know there was even more NES programming-related concepts/techniques I didn't know! -- PLEASE do more of this kind of stuff! :D :D :D
Check out the channel "Retro Game Mechanics Explained". He is going through all the SNES hardware in a similar style.
@@sypwn Hey thanks!
Idk if I'm too dumb or if it is a language barrier (as english is not my first language) but I can't understand half the things he says
@@junior1388666 A lot of what he says is pretty advanced and complicated, so it's not that you are dumb or anything
@@relic374 Language barrier is most likely. Even if the hardware and code use a lot of terms that stay consistent around the world, the majority of them are in English as that's the de facto international human language of our little ball of dirt.
When it clicked that the ppu controller registers first two bits don't just act as overflow indicators, but select the nametable, I realized just how clever the system really is.
I never understood the mirrored nametables until this video.
Yeah, people look at the nametable mirroring and think "it's storing the data TWICE?!" when it's really just REFERENCING the data twice.
Never clicked on a video faster. This is rapidly becoming one of my favorite channels
Right?? :)
Same!
Same here!
Chris, please don't stop making this content!
I'm a simple man, I see a Displaced Gamers video, I watch and like it immediately. As always, amazing explanation and content!
Ha! Thank you.
Poppycock. There's no such thing as a simple man that loves coding. ;
@@CarbonRollerCaco Ok fair, haha!
when I was a kid playing n64 and ps2 games, I always thought to myself, "am I moving or is the world moving?"
always tripped me up as a kid ngl
You can apply that same question even without the games being involved. Just sit down on your couch, hands on your legs and just stare forward. Now realize the Earth is spinning at around 1,000 mph. And now understand the Earth is also rotating around the Sun at around 67,000 mph. Is the world moving or you or both.
@@death-by-ego The answer of course, is both you and the world are moving. You are being carried by the planet as it moves.
Been working on some Master System assembly lately. It's interesting how different, and similar the NES and SMS were at a programming level. As far as I know, the SMS does not have a second name table to play around with, just a single column on the left hand side of the screen that can be blanked for loading in new tiles, and 4 rows in the overscan underneath the main screen that the player never sees that can be used for vertical scrolling
I'd definitely like to get into the workings of the Sega Master System a bit more in the future.
@@DisplacedGamers Wow! I would love to see that! There's a bunch of games that have really interesting and unique effects. Plus it's almost identical to the Gamegear which has some even more interesting effects
There's PROBABLY good reasons for the similarities, though it would be hard to prove definitively.
The Master System's graphics chip is known to be a relatively straightforward extension of TI's 9918a VDP used in Sega's previous SG1000(as well as the Colecovision, MSX, and several other machines). In fact, the Master System VDP contains all four 9918a display modes alongside the new fifth mode that adds support for multicolor sprites and tiles. And the 9918a only had provision for a single screen of data at a time, at a resolution of 256x192. (This lineage, incidentally, is why Sega referred to graphics chips as VDPs. That was the TI terminology, short for Video Display Processor.)
Nintendo's PPU is PROBABLY based on the 9918a to some degree or another, hence the similarities. This isn't really a slam, before the Nintendo fans get mad at me. As the inventor of the sprite as we understand the concept today, there was a LOT of stuff taking ideas from TI's video display processors.
But the similarities in behavior certainly make it seem like Nintendo's engineers read the datasheet book for the 9918a and then designed a simpler, single-mode chip that was more tightly focused on games. And being designed a few years later, they were looking at the dawn of scrolling gameplay while the TI design came from an era where ALL games were single-screen.
(Most suggestively to this "shared history", Nintendo implemented one-bit collision detection in hardware instead of a more robust solution such as seen in Atari's GTIA and Commodore's VIC-II. One would expect a gaming-focused chip not bound by a legacy to have ... well, USEFUL collision detection).
@@CptJistuce Could you elaborate a little bit more on the last part? Why is the NES hardware collision detection bad and why are the other console/computers' much better?
@@allluckyseven Because the only thing it can tell you is "did sprite zero hit the background".
The TI solution, inherited by the Master System and Genesis, is a similarly useless single bit that tells you "two sprites touched, don't know which."
In either case, a software collision routine is required to figure out what's going on.
Atari's GTIA and Commodore's VIC-II chips both have a set of registers that will tell you which objects were involved in a collision and what kind of collision(sprite/sprite, sprite/BG). You don't have to spend CPU cycles figuring out collision.
Has anyone ever de-soldered the horizontal and then soldered together the vertical on the Super Mario Bros pcb before?
What happens? We need more data!!!
that would be really interesting
i don't have a cartridge or nes or ability to solder but i do have a rom and i could configure it to use vertical
however, if i do that I'll forget to update this comment
This is what I'm wondering about.
Expectation: Since the y coordinate doesn't increase in SMB, we would never access the data for "screen 2". Therefore:
1. The screen would look normal to start
2. As you moved to the right, less and less of the screen would look normal.
3. The right part of the screen would be a repetition of the left part of the screen
4. When you moved far enough to the right that the screen starts to wrap back to the top left, the wrapping part of the screen would look normal. When x=0, then the entire screen would look normal again.
5. Repeat 2 through 4 as you continue to move right.
@@smartperson1 So you’ll just loop the first screens because there is no physical pathway to read the appropriate data?
If you continue on this, I'd really be interested in seeing what the "game logic" is that tracks Mario and enemies' position in world coordinates and how it holds the world map in memory while playing through a level.
Nice! Talking about Super Mario Bros. and scrolling, I would love to see a breakdown of the code that fills in the new tile data in the game as you scroll to the right. The way I understand it, the reason that you can't scroll to the left is because the level data is being procedurally generated / unpacked based on a much more compact description as you scroll right, which was needed to make the game fit into the small ROM that it uses - there must be some interesting bits in that unpacking code!
I was always curious about that
If memory serves me correctly, didn't Super Marios 3 have scrolling left capability?
@@tenslider6722Yes
I think there’s a mistake in the graphic at 14:37 - $2400 in binary should be 0010 0100 0000 0000, not 0010 0101 0000 0000. Same for the others - the XY bits are duplicated in all the addresses, but they should only be there once. In other words, bits 9 and 10 should be zero for all of them.
Ahh goodness. That's what happens with binary numbers split up into like 20 photoshop layers. I think I migrated the grey font layer over from under the white font layer on accident and just didn't get my show/hide layers set correctly.
Thanks for pointing this out, Morgan.
@@DisplacedGamers no wuckas mate you’re an absolute champion
aw, very nice reference to My Life In Gaming, they really are the comfort food for retro gaming nerds.
Please. Make a video about Mario's move and jump physics. And how it's calculated. Thanks for a great work
I benefited greatly from your explanation of "addressing" within the context of programming. Thank you!
Another killer video that dives deep into the inner workings of the NES. Love all of your videos are amazing.
Even knowing all the details and having made actual nes homebrew, it's still fun to see this explained in a simple way. Its allways nice to see more people getting interested in this type of technical stuff!
These videos are put together so well! I'm really enjoying your content, keep up the good work!
I love this stuff.
I'm getting into the rabbit hole of programming and design so this is the information that I really like to learn about.
Awesome! I didn't know this channel uploaded more videos, I'm happy
Great video, it's amazing that for the early games horizontal or vertical scrolling was chosen by a hardware jumper on the cart itself, wild.
I never did anything with a NES, nor did I ever own one.. but I am very familiar with 6502 assembler.. Was very interesting to see this, and for me, you got exactly the right level of detail, I started knowing nothing about this hardware beyond the cpu, by the end, every detail of your story was clear, well done.
ive really come to appreciate these videos. thanks for putting in so much effort :)
My new favorite series to binge watch, thanks man, I'm trying to code my game, and these vids showing how insanely precise and meticulous programmers codes their games makes me less stress about crazy glitches or bugs, I will be on the watch for them tho.
This channel is exactly what I was looking for! As a programmer, this is invaluable info.
Please continue!
Plenty more episodes to follow!
Keep up the great work!
I love watching your videos.
I'm in the process of developing my own handheld console (some samples can be seen on my channel) and information provided on your channel are priceless. Excellent work on your explanations. Thank you!
I inject this straight into my veins, right up my alley. If these were an hour long I would love it. No such thing as too much information when it comes to this.
Yes! Another video! I love this channel ✌️
Just found your channel.. Loving the Mario stuff, would love to see much more mario..
These videos are helping me fix up my NES homebrew game I am working on and helping fix some issues for my older one
Thank you so much for this video. Im trying to implement software horizontal scrolling on a system that hasn't hardware scrolling registers. This really helps to get an understanding of how the NES hardware achieves it. Now with a clearer understanding i can try to convert the function into software. I already know how to bit shift "tiles" although the endless loop method really opens my mind to achieve the results in a more logical way.
I have digged my self into a very complicated rabbit hole ill spend the rest of the week researching. as this video left me with many questions
I have no words for how invaluable this video is.
You are a genius with how you explained mirroring.
I've often heard that NES games could only scroll in one direction at a time due to these limitations. But the second nametable seems like it holds enough tile data to wrap a couple tiles all around the screen. You don't need half a screens worth of tiles loaded off screen, only a tile or two. It would be complicated to code, but I feel like it would be possible.
Mario 3 and many other games scroll both in the X and Y axis at once, with the downside of having the tiles loading on the sides visible (but often hidden by CRT tvs)
th-cam.com/video/wfrNnwJrujw/w-d-xo.html This is a good video that explains why this happens to SMB3
The problem is that you can't really tell the PPU what's where in the nametable - there might be enough memory, but the PPU expects it to be laid out so that it can read the tiles left-to-right, top-to-bottom. There's no code for it to be customized so that you could have a clever algorithm that handles scrolling down by reading the first nametable from eg. line 5, then once it reaches the bottom of the nametable it reads the fragmented bits of the bottom 5 lines from the second nametable. It's all hardwired.
The way some NES games handled two-way scrolling is by utilizing the mirroring functionality - either by simply wrapping around (more useful with horizontal mirroring - you can have a vertical level that constantly wraps around horizontally), or by loading the tiles at the edge of the screen in the mirrored direction and using overscan or NES's display toggles to hide the magic.
The Commodore 64 did something similar to having one extra tile on each side. The screen was normally 40×25 tiles, but it was possible to decrease that to 38×24 so tiles could be loaded in the border. Unfortunately, the hardware only supported scrolling up to 7 pixels in each direction--enough to make the scrolling work, but only if the program was prepared to move every tile on the screen during vertical blanking.
I wonder if any systems took the approach of wrapping a layer of tiles around the screen while also supporting a full screen's worth of hardware scrolling (with wraparound)?
the screen can fix exactly one nametable. you can rely on PPUMASK to make it seamless, but you can also just not care and the overscan will cover it for you. the real question would be "if its possible why arent games doing it?"
They had a computer programming class before class hours at my elementary school back in the 80s. We were focused on using basic and doing Lego logo. I think I’m too old and removed to fully grasp everything you’re going over but man I would have absorbed this like crazy as a kid. I wish this kind of material had been available to me at that age. But the hardware was probably quite expensive at the time. Even having a computer lab back in those days was very recent phenomenon and was probably quite expensive. It was all Apple computers as well of course, so maybe that was also a barrier
Heck even if Nintendo Power published stuff like this it would have been awesome. I thought I was all technical talking about mode 7, this would have been another level!
I was really cool to see the solder pads. Kinda cool that you control over scrolling in hardware.
The notification for this video was the most pleasant of surprises.
I have always been curious about the loading of backgrounds off screen. Ever since I saw the boundary break episode on Minecraft when outside the first person view all the backgrounds disappear and reappear as you turn your head around. It's obviously a smart programming technique to save memory.
I know you tend to focus on the NES and Sega master system games but I'd love to see a video delving into the manipulation of backgrounds and sprites, like with mode 7 games. Just a thought. Either way love your work Chris. Cheers.
Retro Game Mechanics Explained put out several videos about the SNES's graphical trickery. That last-moment manipulation with HRAM is galaxy brain product.
@@CarbonRollerCaco I never heard of them but I might check them out. Thanks.
Thank you for introducing me to Wolf & Raven.
Thank you!
amazing video, keep up the good work
I automatically subscribed after a few minutes.
Great video!
the reason why mario 3 opens with curtains and has an animatronic stage theme is because of how the NES's scrolling the level to the left looked to Shigeru Miyamoto
I just realized after reading those names that you were the "My Life In Gaming" people. Very cool.
What a perfect video to watch before my Assembly Language class
Cool! What flavor of assembly does your class use?
x86
Interesting! Scrolling is really complex so it's nice to have a video for reference :)
"Beyond the far right". I like the sound of that. I'm stealing it.
You had me at learn everything all at one, I'm In!
A lot of this is over my head but it's interesting as heck anyway and you make a really good effort explaining each part so I have a much better chance of grasping the whole. Thank you so much!
I can't help but wonder now what would happen if you take the smb cart, unsolder the H blob and bridge the V instead.
You can do that in emulators! In smb, as the game tries to load new tiles on the unused part of the nametables, there is now space for only one screen, so you can see the graphics loading on the left side of the screen.
A video going in depth on how certain games handled simultaneous horizontal and vertical scrolling or used different nametable RAM configurations would be fun to watch. Only so many games used extra RAM to make all 4 nametables unique with no mirroring but I always wondered why they chose to do that.
I can’t wait to get home and watch this. This channel is super underrated. Can’t wait for when you have a million subs and I can say I was OG DG
Ha! I would love to make it to 100k if possible. Thank you!
More NES technical stuff! Keep going!! 👊😎
Makes me really appreciate the games they put out on the NES!
Very interesting indeed. When I was little and played Super Mario Bros for the 1st time I was blown away. You must remember that before that it was pacman and frogger on my brothers atari 2600. The NES was revolutionary.
It took me some time to realize what nametable mirroring was all about. But I wrapped my head around it a few months ago. Still, great video though! And familiar emulator, so I feel right at home!
Super interesting!
This was great! I learned. I clapped. I didn't cry. Loved the MLIG reference.
Nice video!!! It is interesting
Holyshit, this video make me appreciate the early gamedevelopers even more. Very intelligent people indeed, to have the brains to keep track of all this while making the levels.
Great video, did not understand much but it sounds good! XD
The particular information at 11:27 is used in speed running mega man 2, and Castlevania. Kinda cool
I guess this explains when the turtle shell will return after it gone off screen, it is only if an object it would bounce off has been drawn in the half screen off camera.
Can you do a visual representation for Super Mario Bros 3 and for games that do both horizontal and vertical scrolling since you already told us how it looks like on the board?
Retro Game Mechanics Explained has an excellent video related to the combination of Vertical and Horizontal mirroring, which is an excellent complement to this video.
th-cam.com/video/wfrNnwJrujw/w-d-xo.html
Omg the king returns 👑
Wow! Programmers and developers are very intelligent and great with numbers. Bc I feel like I need a beginner programming course
Now I want to know more about SMB3, Zelda, and Megaman tile scrolling methods!! :D
I would love to see a video on how sprite scaling works. I love the old Sega super Scaler games.
Love your stuff, but I have a minor accessibility quibble for those of us with color vision deficiencies.
At 1:52, the odd-numbered grid lines have changed from dark blue to a deep purple/pink(?). While I _can_ see the difference, I have to look for it and I didn't notice at first.
Some things that could help make it clearer for us colorblind folks:
1. Try using dotted or dashed lines for either the blue or purple lines
2. Make one set of lines thicker than the other
3. Show/animate the lines changing; in this instance, the change is hidden by the check pattern from 1:43 - 1:52 which makes it harder to notice
I'm not saying "don't use color" btw, just that it's best to not _only_ rely on color to differentiate things.
Cheers!
Something interesting about the statement in the beginning of the video is that exactly the same thing is still true in modern 3D graphics hardware. The camera never moves - the scene does.
Should mention that the fine x scroll selects a bit of the low byte of the 16-bit PPU shift register and the next byte is latched into the top byte every 8 cycles. That's really the key to smooth scrolling.
Your videos are amazing and easier to understand. I wish you do an episode about the mosaïc effect in Mega Man 5. It's gonna be very interesting.
For some reason I was expecting Ikari Warriors when you were going to demonstrate vertical scrolling.
4:58 As I understand it, there's address space reserved for up to four screens of background data, but the stock NES doesnt have independent vram for them. By default the NES simply points those two extra pages at the existing 2k sram, but provision was made for changing that if extra RAM was supplied on the cart, allowing later games to have all four screens active at once. Planning ahead.
Sadly, not the most useful planning, as you can manage 2-way scrolling with even a single screen. The only games (that I know about) that uses extra vram for 4 screens are gauntlet and its sequel due to how expensive it was and how little it provided, instead of using it as regular work ram.
@@mazionach Also Super Mario Bros 2. Remember the first level, if you get the Tanookie Suite, you can fly into the air and the screen scrolls upward.
@@ADreamPainter I guess you meant super mario bros 3, and that game only uses 2 screens vertically! If you notice on the right side, there are glitches due to the game having no space to update the screen so that you don't notice it.
@@mazionach Interesting, that makes a lot of sense... Yeah I mean Mario 3. But that also explains the design of Mario 2. Areas that you travel vertically, pause when you reach the screen edge while the camera moved upward or downward.
Clouds the same as Vegetation
can't unsee it now 🤣🤣
I had NO idea that scrolling could be configured by bridging two of the pads, I thought that was to be done in code. Fascinating! Thank you for this video! I love this series
I imagine that sort of hardcoding scrolling into the PPU saved game makers headaches given that scrolling would clearly be a common feature across most NES games. The NES was shockingly ahead of its time in terms of specialized hardware.
Not mentioned: the status bar at the top not scrolling with the rest of the screen. Most games would use hblank triggers to know when to update the scroll register. But not SMB 1, it lacks the hardware for that. Instead it busy loops waiting for the object zero hit flag to be set. What's object zero? The bottom part of the flashing coin in the status bar. As such, the flag is set when the coin is drawn.
Danke!
Thank you!
How this kind of scrolling works on the NES is a main reason why trying to do it too fast is generally a bad idea (as illustrated by hacks such as Superfast Mario Bros). The nametables can only be changed so fast, and if you overrun the loading zone data will get loaded incorrectly, resulting in onscreen "garbage".
Incidentally, Game Genie codes that directly affect the values in the nametable and attribute table seem to guarantee dramatic effects of what is seen onscreen, and would be at least part of what causes the spectacle seen with codes such as IKAAAE and YEAAAA activated.
I can imagine programming this would be a headache but I would enjoy it but we also see some very impressive games.
It's really not as bad as you think.
@@magickmskh I never said it was hard , I'm just saying how tedious it must of been, I'm a programmer myself
@@aurathedraak7909 I did Gameboy development many moons ago. Can confirm the tedium when you don't have a debugger and have to flash program chips every time you compile.
Super Mario Bros. 1 widescreen confirmed! :P
This is pretty cool. What about when you go up a vine how does smb do that if it is hardwired to horizontal scrolling?
In the original Super Mario Bros there's no vertical scrolling while you climb a vine. Mario just gets to the top of the screen and then a whole new level is loaded.
For what I remember, it doesn't scroll, it is like entering a pipe (there is a speedrun trick with this, entering a pipe instead of going through a vine, it depends on mario relative x position on screen)
Oh cool thanks for the explanation 👍
I'm now super curious on how Final Fantasy NES games handled vertical scrolling. When you walk up and down, you can see parts of the map drawn at the opposite direction that you're walking. I assume the vram size constraints would make the developers accept the visual glitch as a technical limitation of the system.
This makes me wonder how Mario 3 works with all that horizontal and vertical scrolling at the same time
I've got to say. Writing my own NES emulator was very helpful understanding these concepts.
if you know how to do these things, there's demand for one thing in the market of emulators that doesn't exist yet: audio volume control in Sega Genesis emulators... this already exists in NES emulators... this would be super useful to turn down the SFX of a game to listen the music play louder for example... some Genesis games have very harsh/trebly SFX when not being filtered by tube TV speakers
As someone with very little knowledge of some of the more involved bits, the conceptual aids help a great deal (:
I think it would've been way easier to understand (and also to explain) if you would've said that the PPU chip is designed to access a background made of four nametables (or say, a 64 tiles width and 60 tiles height background, or 4 kB of tilemap data divided into 4 pieces, nametables, of 1kB each) But the memory of those nametables is external to the PPU chip itself. And so, when designing the famicom, they included that PPU supporting four nametables but they included only two real nametables, only 2kBs of VRAM for that use, giving the mirroring effect.
I now have a burning desire to see what happens if you remove that solder from H and put it on V, then try to play the game. You can't leave us hanging like that!
Wow, even for something as simple as the original Super Mario Bros., ROM data alone isn't enough. Near, whatever their fate, was more right than I imagined.
And now I want to know about that attribute table.
love this shit!
cool
Incredible video.
That's the whole comment.
super ekstra
Great video - what emulator are you using - and what debugger? - What tools do I need to do a hello-world NES program with proper debugging : `step`, `next` and `finish` - registry watchers would be nice. - I used to do Borland Pascal with inline assembler, but thats over 20 years ago.
I'm not the channel owner but the emulator is called Mesen. It has all the debugging features built-in.
For programming I use Visual Studio Code and cc65 assembler. cc65 is quite powerful if you know how to use it's assembly features (which I don't really know.)
As Roddy said, I am using Mesen.
I want to say that writing an NES program from scratch may have several options in terms of language. Sometimes people find it easier to code software for a given platform in Basic or C first (you can write Atari games in basic, for instance), get their feet wet, and then start exploring assembly options when they have a better grip on the platform's timing and hardware.
@@DisplacedGamers - I am not a fan of Basic - I have done Ruby for 14 years professionally, - some php, golang etc - I think I could handle ASM but C is a good idea, and yea, the Atari must be very simple. - I guess the main thing is that in Borland Pascal, - I could set breakpoints in my editor - I could set watches for registers, and I could step & next through the ASM code which made things a lot easier to understand. - I know the MegaDrive has a hardware debugger that has some awesome features like that - I will try Mesen and see what it offers. - thanks.
best of the best;
I would be interested to know the actual change of the hand traps in world 8 triggering and the code behind that
Are there any plans for an “advanced mirroring concepts” video, or maybe an “in-depth look at a bunch of popular mappers” video?
Next time I watch MLiG I'll be sure to say hello to Captain Coury and Overlord Marc 🤣
Hold it, control it, and PPU, come on, let's see you scroll it!
Something I was hoping this would cover: since the text font patterns are referenced in the background nametable, how does the status text stay fixed on the screen while scrolling?