NES Scrolling Basics featuring Super Mario Bros. - Behind the Code 

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.

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.

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.

Yeah, people look at the nametable mirroring and think "it's storing the data TWICE?!" when it's really just REFERENCING the data twice.

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?

Right?? :)

Same!

Same here!

Ha! Thank you.

Poppycock. There's no such thing as a simple man that loves coding. ;

@@CarbonRollerCaco Ok fair, haha!

I was always curious about that

If memory serves me correctly, didn't Super Marios 3 have scrolling left capability?

​@@tenslider6722Yes

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.

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

Plenty more episodes to follow!

Thank you!

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.

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.

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)

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-wfrNnwJrujw.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?"

Ha! I would love to make it to 100k if possible. Thank you!

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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-wfrNnwJrujw.html

Cool! What flavor of assembly does your class use?

x86

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.

Thank you!

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

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.

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.

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 👍