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.
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
@@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.
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
@@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.
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.
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.
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
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.
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!
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!
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.
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!
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.
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.
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.
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.
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)
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?"
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.
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.
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'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!
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. ua-cam.com/video/wfrNnwJrujw/v-deo.html
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!
One other interesting thing that only happens occasionally on real hardware: if the write to $2000 at the end of the game logic lands perfectly on one PPU clock cycle, it will mistakenly reset the X scroll position for one line. This is easiest to see in 1-2 when jumping on top of pipes you may get a random flicker of green. It only happens in about half of games because it's affected by exactly what time the PPU and CPU come out of reset relative to each other, and it's a conclusive sign that the game isn't running in an emulator.
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.
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!
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.
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.
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.
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
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
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.
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.
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.
@@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.
It's the same thing with racing games. Is the car moving forward though the track with the camera following or is the car stationary while the stage moves around it. Fyi, I don't like the idea that your character stays in place while the level moves around him, in any game.
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
@@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.
what if you unsolder the mirroring thing on the mario pcb and solder the other one?.
Рік тому
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.
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)
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!
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.
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?
Na składance 168in1 na Pegasus było kilka wersji Super Mario Bros, gdzie było zastosowanych kilka takich "sztuczek" z tablicami. Najpopularniejsza z nich to znana (a może nie) na całym świecie wersja "Dream Mario" ;-)
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 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.
Great video cool stuff. I have one quick question. I'm assuming you're using MESEN? I can change values in WRAM/SRAM thru making "cheat codes". I cannot edit them directly in memory viewer. How are you able to edit values directly in nametable ram to get the clouds to appear in that level? Is there another viewer that allows one to change values without having to make a cheat code?
Hi! Do you plan to make a video about 4 way scrolling? Like they do in games like Dragon Warrior? It really confuses me how games can do that. How do they know which metatiles to load? Do they load everything into memory?
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.
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.
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.
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.
Never clicked on a video faster. This is rapidly becoming one of my favorite channels
Right?? :)
Same!
Same here!
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?
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!
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
Chris, please don't stop making this content!
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.
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!
Please. Make a video about Mario's move and jump physics. And how it's calculated. Thanks for a great work
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!
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.
I automatically subscribed after a few minutes.
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.
These videos are helping me fix up my NES homebrew game I am working on and helping fix some issues for my older one
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.
I benefited greatly from your explanation of "addressing" within the context of programming. Thank you!
Thank you for introducing me to Wolf & Raven.
Thank you!
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
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.
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
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.
Awesome! I didn't know this channel uploaded more videos, I'm happy
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)
ua-cam.com/video/wfrNnwJrujw/v-deo.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?"
aw, very nice reference to My Life In Gaming, they really are the comfort food for retro gaming nerds.
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.
What a perfect video to watch before my Assembly Language class
Cool! What flavor of assembly does your class use?
x86
This channel is exactly what I was looking for! As a programmer, this is invaluable info.
Please continue!
Plenty more episodes to follow!
The particular information at 11:27 is used in speed running mega man 2, and Castlevania. Kinda cool
Another killer video that dives deep into the inner workings of the NES. Love all of your videos are amazing.
I have no words for how invaluable this video is.
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.
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.
I was really cool to see the solder pads. Kinda cool that you control over scrolling in hardware.
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 just realized after reading those names that you were the "My Life In Gaming" people. Very cool.
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!
Makes me really appreciate the games they put out on the NES!
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.
ua-cam.com/video/wfrNnwJrujw/v-deo.html
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!
This was great! I learned. I clapped. I didn't cry. Loved the MLIG reference.
"Beyond the far right". I like the sound of that. I'm stealing it.
Just found your channel.. Loving the Mario stuff, would love to see much more mario..
For some reason I was expecting Ikari Warriors when you were going to demonstrate vertical scrolling.
ive really come to appreciate these videos. thanks for putting in so much effort :)
Wow! Programmers and developers are very intelligent and great with numbers. Bc I feel like I need a beginner programming course
One other interesting thing that only happens occasionally on real hardware: if the write to $2000 at the end of the game logic lands perfectly on one PPU clock cycle, it will mistakenly reset the X scroll position for one line. This is easiest to see in 1-2 when jumping on top of pipes you may get a random flicker of green. It only happens in about half of games because it's affected by exactly what time the PPU and CPU come out of reset relative to each other, and it's a conclusive sign that the game isn't running in an emulator.
Interesting! Scrolling is really complex so it's nice to have a video for reference :)
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.
If the background moving to the left, or Mario to the right? Both, and you can see either, depending on movement.
I would love to see a video on how sprite scaling works. I love the old Sega super Scaler games.
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!
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!
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.
You had me at learn everything all at one, I'm In!
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.
Now I want to know more about SMB3, Zelda, and Megaman tile scrolling methods!! :D
More NES technical stuff! Keep going!! 👊😎
Keep up the great work!
I love watching your videos.
Yes! Another video! I love this channel ✌️
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.
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
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
These videos are put together so well! I'm really enjoying your content, keep up the good work!
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.
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.
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.
I'm pretty sure Castlevania 3 actually uses all 4 screens during certain sections. I'll check tomorrow
It's the same thing with racing games. Is the car moving forward though the track with the camera following or is the car stationary while the stage moves around it.
Fyi, I don't like the idea that your character stays in place while the level moves around him, in any game.
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 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.
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.
what if you unsolder the mirroring thing on the mario pcb and solder the other one?.
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.
Super Mario Bros. 1 widescreen confirmed! :P
Imagine having to go through this lecture before ever playing Super Mario Bros in 1985.
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 👍
As someone with very little knowledge of some of the more involved bits, the conceptual aids help a great deal (:
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!
This makes me wonder how Mario 3 works with all that horizontal and vertical scrolling at the same time
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.
Great video!
Incredible video.
That's the whole comment.
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?
Na składance 168in1 na Pegasus było kilka wersji Super Mario Bros, gdzie było zastosowanych kilka takich "sztuczek" z tablicami. Najpopularniejsza z nich to znana (a może nie) na całym świecie wersja "Dream Mario" ;-)
I would be interested to know the actual change of the hand traps in world 8 triggering and the code behind that
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.
Clouds the same as Vegetation
can't unsee it now 🤣🤣
It’s wild to imagine how different my life might’ve been had Chris been one of my teachers or early professors.
amazing video, keep up the good work
Are there any plans for an “advanced mirroring concepts” video, or maybe an “in-depth look at a bunch of popular mappers” video?
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.
Super interesting!
Great video cool stuff. I have one quick question. I'm assuming you're using MESEN?
I can change values in WRAM/SRAM thru making "cheat codes". I cannot edit them directly in memory viewer.
How are you able to edit values directly in nametable ram to get the clouds to appear in that level? Is there another viewer that allows one to change values without having to make a cheat code?
Hi! Do you plan to make a video about 4 way scrolling? Like they do in games like Dragon Warrior? It really confuses me how games can do that. How do they know which metatiles to load? Do they load everything into memory?
i hear a sample used in the song "hoppie"