Before, i thought that SNES has a "slow motion" effect whenever something cool happens in the game like that zelda's bomb spot or jumping over a flame snake and dodging a dog and two zombies in ghouls n ghosts
Changing the speed of the game for the enjoyment of the player, when it is just lag. That's how Space Invaders changed the speed of the UFOs while playing. Drawing all these sprites basically made the rendering slow, because each frame took so long, but the more UFOs you shot down, the less there was to process and the faster the game ran.
I know from the depths does that. When an ammo storage detonates the game goes into slowmo for a second (intentionally). Then again the game's performance also tanks when large vehicles collide (because they're both made of thousands of blocks). So the accidental cool highlighting is still going strong 😂
How the actual crap did people figure this stuff out? "AH YES, WE'LL HAVE AN ELECTRON BEAM DIRECTED BY MAGNETIC FIELDS AT 60hZ TO CREATE THE ILLUSION OF A PERSISTENT IMAGE."
The 60hz was out of convenience for how American power worked. I'd recommend you watch Technology Connections, as it breaks down how analog TV works in far more detail than this channel does.
You're making these videos so well it's incredible. This is what I wish I could have seen five years ago when I was struggling with that stuff, and at the same time it's only now that I actually *understand* it. Can't thank you enough for everything you're doing!
8:08 That image of the instruction timing shown in the context of screen draws and what happens outside the screen is one of the most elegant presentations I've ever seen. Major kudos.
Your videos are a masterpiece, instead of just speaking, and mentioning just the happy path, you show extremely well-designed instructional graphics and exhaustively explain in detail every mode of operation and edge case. You are a legend, my friend 🙏🏻
Thanks for the awesome, easy to understand, video! Reminds me of the book Racing the Beam, which talks about developing for the Atari 2600, which was a herculean feat because the hardware was incredibly limited.
That's exactly what I was thinking! Nick montfort visualized the Atari screen much the same way as in this video, and that forced blanking during h blank is familiar from old atari games with lots of black artifacts like space invaders
A lot of the more advanced graphical techniques can be traced back to the 2600. For later systems they were used for complex effects but were sort of optional. But the design of the 2600 means you basically need to do them as a matter of routine. Almost all 8 and 16 bit systems do variations on this stuff though. Does remind me of the Atari 8 bit home computers; They essentially have an upgraded version of the 2600's graphics chip, but then have a second chip that is like a special-purpose CPU, which for basic tasks does the stuffing of the data into the main graphics chip for you automatically. This design was exceptionally flexible, and let you do things like switch graphics modes 5 times in a single screen, changing resolution, colour depth, to text or graphics mode, etc, all basically without CPU intervention. It's still the same principle though; Change the data each scanline...
Yeah, pretty much the frame buffers solved that issue, so from then onwards you only had to race the beam during VBlank, the display was handled automatically.
The Atari 2600 was a machine designed to run Tank. Making any other game run on it required that your cartridge pretty much hack the console in real time.
Really cool video on CRTs and Blanking! I never really noticed the black flashing on the top of the screen, but this is really cool to see at a hardware standpoint! Thanks for another awesome video!
Correct me if I'm wrong, but the black bar at the very top of the screen would probably be hidden by the TV's over-scan, thus you would never actually see it on a CRT.
If the bar is sufficiently small, its possible it could be hidden; however, there's not really a limit to how badly it can lag--the black bar could even take up the whole screen if the v-blank routine took an insane amount of time.
Best one yet! I didn't want this video to end. I'll never forget the flickering black line at the top of the screen, now I know what causes it. The Sega Genesis and its infamous CRAM dots make more sense to me now as well, I better understand why programmers needed to hide palette changes in the 'offscreen' code.
this is so cool. I stumbled upon this while doing some super Mario world research, and I'm glad I did. 10/10 best explanation series ever. Animations, commentary, and info is just so great. I can't believe learning can be this enjoyable, even after graduation! Thanks
Hoooooly crap, what an informative and incredible video. You go into some incredibly in-depth things here, but you manage to explain them in layman's terms that anyone could understand, with some amazing editing thrown in. Dude, you're a legend.
What a fantastic series. I mean this in all seriousness, this series deserves recognition well beyond the bubble that is youtube and the gamer-kid sphere. Outstandingly comprehensive with superbly produced presentation.
Really loving this series so far! I understand almost nothing about the hardware/code aspect of these things (Games/Consoles) and have always wanted to understand it. Your explanations and visual examples have really helped me to understand these things! Thank you so very much for your amazing work, and I look forward to seeing your next video! ^~^
Congratulations on those gold videos, this is the kind of information I searched so much on the internet in vain. These SNES delays mainly when there are many koopas in SMW I believed to be a limitation of the sprites table, I never imagined that the problem would be directly related to the old tvs
mmh. Really well explained. Worth noting that a major advantage of PAL systems (which is rarely utilised, because doing so would make games that are almost unplayable on an NTSC machine, which for obvious reasons isn't great if you expect to sell the game... It would preclude selling it in America or Japan...). Anyway, they have a substantial advantage in terms of how much VBLANK time you have to work with. It's anything up to 85% more time. In theory this would allow some really complex graphical routines that would choke an NTSC machine, but as I said, for practical reasons this tends to be avoided. (except in tech demos.) This by the way isn't an advantage to the SNES specifically. Variations of this advantage show up nearly across the board in 8 and 16 bit consoles and home computers. It's such a big advantage that a lot of the demoscene uses PAL machines in preference to anything else...
Or maybe arcade cabinets tend to build on PAL system instead? I'm not sure if that's the case though. (At least in China, many old cabinets were probably pirated ones, while newer ones basically just don't have to worry about these stuffs at all, and there aren't really any LCD screen that works exclusively on 50Hz.)
That seems unlikely, but it's possible. Most arcade machines are simply more powerful than home systems in general. You can see that by looking at the Neo Geo, which had a home version with the same specifications as an arcade machine, but was exceptionally expensive...
CRT arcade machines didn't use PAL, NTSC or any color encoding, they used RGB component signal. Refresh rate is controlled by the game, doesn't necessarily have to be 50 or 60hz. For example original Mortal Kombat runs at 53Hz.
Thank you for the great video! Is the script or tool you used for overlaying the overall timing utilization (14:49) something that occurs in real time, or composited in post-production? If it's a script, it would be a wonderful TASing tool!
I use a modified version of this script I made to create that scene: pastebin.com/2rmgbL7V It's built for lsnes and the offsets at the top are set for the English version of Super Mario World (it should work for any SNES game given you know where to hook those two parameters).
Holy shit I just found you and your stuff is great. For someone with such high quality stuff you deserve more subscribers. Keep doing what you’re doing man
I am absolutely amazed to find out that "slow down" didn't happen at ALL how I thought it did. (Though to be fair, I was a kid when I formed my thoughts on how it happened!)
I sort of pictured it as so much info getting dumped onto the processor that it literally had to slow down, so the machine was just doing everything it always did, but at a slower pace. I now see that a CPU running "slower" now makes no sense. And how could you cram more info into it than it could take at once? =o)
Well, CPU would just run at constant speed unless you use some sort of variable crystal clock to mod the CPU, or the CPU can run multiple cycles in one clock tick. Both aren't happening in retro CPUs. As for CPU running slower, it can happen in modern CPUs, for combating overheat situations. (That's mainly why laptop seems to "degrade" in performance over time.) As for cramming more info into the CPU, well, people actually found ways to do that. But it's a bit too complicated so the simple way to say it is, info lines up better nowadays and thus CPU can take less time grabbing the info and spend more time working on it.
野龍 Which is great information my 36 year old self understands, but my 8 year old self would have been like, "That's a whole lot of words I don't understand." Then he would have farted at you because farts were the epitome of comedy at that age.
Dargonhuman At the time you was 8 I wasn't even born yet. And since I'm in China, the thing is, people are still believing that human bacteria can infect computer and thus every computer room have their visiters taking their shoes off. Also, even nowadays, just how easier it is to explain how CPU power improves over time anyway? :) I mean, most people, including me when I was a teenager, would just think that "better clock speed = higher performance" and assume we know everything already XD
This is so well-explained and animated that it was easy for me to understand the concept despite not being knowledgeable on this topic. Really good job with this video!
i've being watching all your videos about nes/snes and it really blows me away; i'm noob at the subject but you made me understand with more ease, and i really appreciate it!
These are great videos. As someone who used to write emulators for their full time job: I'd want you on my team. You explain the Super Nintendo hardware very well.
The visualizations are just wonderful, I've been working with these concepts in mind for years (albeit on the NES, but it's 90% the same) and it's great to actually see it represented by something more than activating a tint register when spinning begins to see a visual representation of the CPU load.
Thanks, Mr. Explained! This channel is just amazing and explains things very well. I not only learned how the SNES works, I also now know how CRTs draw images. After watching this I finally could understand Technology Connections' video on television, heh
MegaZeroX7 it surely does. In fact, the light gun used in the SNES detects the point you're aiming at by reading the CRT position when you fire it. Basically, the light gun is pointing at a specific point, and when it detects light, it tells the SNES to read the CRT position to determine where you're aiming Sadly, because of this, it doesn't work on LCDs
@@ddnava96 wait, I thought the SNES had a white square for one frame when you pulled the trigger, and whether or not the gun saw that square determined if you shot.. or am I thinking of the NES light gun?
@@flurf5245. That one with white squares was on the NES and it had to stop the game while it was showing the squares. The SNES had a more clever approach with the CRT position in order to calculate it immediately without needing to stop the game
Had to comment on that data visualisation you pulled out for the time it takes for everything to happen in a frame. I work with data as part of my job and that's one of the best things I've seen this year.
And here I was thinking that this episode would be boring, when I can now safely say it was one of the most interesting ones to date! Can't wait for the next one!
I really thought I wouldn't understand this topic, but your explanations and visual representations are great. I had this doubt for ages and now I clearly understand what's happening. You are the best.
Wow, now I'm so interested about HDMA, having revisited your earlier videos on this subject! Awesome work! Very detailed and informative. The math explanation in Mode7 is top notch! :) And as with this video is likewise very very well made. Even if you may grasp some of these on the fly without really understanding what it does, your videos make one see exactly what's going on.
Interesting that the DRAM strip in the frame paint is in the exact spot that people exhibit the video flaw of a lighter line in the video output...I wonder if writing to DRAM is causing a strain on some of the components which leads to this video artifact on many aging SNES consoles...
I always thought it was coupled noise, but hm, it could be PSU fluctuation. Might be interesting to watch the 5V rail on a scope with a h-sync trigger.
It's a common flaw to other systems too. The Mega Drive/Genesis frequently develops the same problem. Fundamentally it's some kind of noise on the video output. Though the exact source is unclear. There are many known fixes for the Mega Drive, and on that system it clearly has nothing to do with DRAM, but on the SNES... I'm not so sure. It's also a form of visual artifacting mostly seen on the earliest revisions of the console. (There are at least 4 versions of the hardware internally) I have a super Famicom that is from 1990 and shows the problem quite strongly nearly all the time, but then I have a PAL system which is a much later revision (1994 I think), and while the effect is still there, it's all but invisible except on very dark backgrounds. (especially black). I've taken both apart so I know that they are completely different hardware revisions... Definitely noise of some kind... But I'm still not entirely sure what the source is.
0:52 Actually, the Trinitron TV's (and any TV's made after the patent expired that used the technology as well) use a single electron gun with 3 cathodes, and an aperture grill. Non-Trinitron TV's used a shadow mask along side what you showed on screen. All of this is assuming that a color TV is being used. A black and white CRT TV is exactly what you showed on screen.
Wow, this is top quality stuff dude. I'm amazed! Would you consider doing a very simple introduction to programming on the SNES? ie; explaining the boilerplate code, drawing a single pixel, etc..??
Fantastic video. I don't think I've ever really understood why the SNES only used 224 lines instead of 240. I've always figured that the V-BLANK period for the SNES was the same as the VBLANK period for a TV. Now it makes sense.
Great series so far! I have one tiny correction: you don't actually show the beam "point" move downwards during the scanline itself. Due to how the magnets and hardware works, vblank and hblank are mechanical timings designed to let the magnets "settle", and during scanout, the vertical velocity of the beam is constant -- it moves downwards just as much during the scanline as it does during hblank. The phosphor screen itself is typically designed to counter this tilting effect, and on cheap TVs, the tilt is considered a small enough artifact that it's not counteracted at all.
Back In The Day when I developed for the Nintendo DS (whose PPU was similar to the SNES's but it allowed register updates and DMA during rasterization), I actually used a trick to visualize what routines were taking up my frame time so that I could order my routines appropriately, by changing a palette entry at the start of each function. This let me see when in the frame each function was running and how long it took, so I could then change the order they were run in and try to prevent them from occurring during or after their part of the screen refresh. :) This is a trick I picked up from the demoscene, since the Amiga had the "copper" coprocessor which was used in this way purposefully (and some enterprising PC developers figured out means of simulating it in the main CPU instead).
We used to do the same on PS2 also, it had a background colour register you could write at any time during the frame. Kind of epilepsy inducing if running at anything lower than 1 frame though!
Some of the finer minutia goes over my head but overall I understand these videos pretty well. I'm very much of a fan of this approach to explaining how an old console works, your active examples and demonstrations make it far easier for a visual learner like me to better understand it. And for period accuracy of the time, even if you could actively notice at that one point that black line at the top when the background was updating from that bomb explosion, you really wouldn't be able to physically see it on a CRT because most TV sets of the day had thick plastic framing around the tube that would crop off the edges of the screen, a little on the sides and a lot at the corners. All the ones I ever owned did. Of course, if you're into retro consoles, I'd still recommend an old CRT TV to play them on, it's how they were meant to be seen.
Huh, if you look at the diagram at 5:57 in full-screen, you get a weird optical illusion. If you look at the horizontal pattern for a short time, then look at a plain wall, you see a weird bit of colorful noise, like what shows up on old TV with no signal. If you look at the pattern for a long while, then look at the wall, you see a bunch of trippy, vertical/diagonal/curvy, colored lines.
Before: "Hey yo, what you see on screen are just pixels changing color depending on what you do in the game, a beam projects it one by one! ezpz lemonsqueezy!" After watching the video: "Fucking hell..."
Man I'm loving these, can't wait for more! Anyone know where to find more videos like this? I'd be really interested on a detailed breakdown of how, say, the Sega Genesis worked. Anyway, keep up the fantastic work!
I love how programmers back in the day knew all of this about the hardware and just used it to their advantage. One way I could see it being used is maybe preset a puzzle or physics effect, have a timer that is really just a couple frames and use those lag frames to do all the movement calculations, then it just spits out preset values for where things would go. Not sure if the RAM is big enough to store all that but it's a start
And then there is Space Invaders. It gets faster by shooting down enemies and thus advancing the game. Less sprites = less stuff to draw = faster frames. From a technical standpoint the game lags immensly at the beginning and gets faster and moire fluid with every hit.
When I turned off my SNES on my old TV I had, it would always show colorful lines, mostly blue and purple on a black background. Now I get an idea what those lines were for.
>Processor runs out of instructions this frame
"I'll try spinning, that's a neat trick!"
Before, i thought that SNES has a "slow motion" effect whenever something cool happens in the game like that zelda's bomb spot or jumping over a flame snake and dodging a dog and two zombies in ghouls n ghosts
shhhhhh, it's all totally intentional
Changing the speed of the game for the enjoyment of the player, when it is just lag.
That's how Space Invaders changed the speed of the UFOs while playing. Drawing all these sprites basically made the rendering slow, because each frame took so long, but the more UFOs you shot down, the less there was to process and the faster the game ran.
When I was a kid playing SHMUPS I thought: huh, it’s slowing down the game when it gets really hectic. How thoughtful! 😅
@@HappyBeezerStudios that’s awesome: I never thought of that, but it makes perfect sense!
I know from the depths does that. When an ammo storage detonates the game goes into slowmo for a second (intentionally).
Then again the game's performance also tanks when large vehicles collide (because they're both made of thousands of blocks). So the accidental cool highlighting is still going strong 😂
I'm always impressed by the really detailed and precise animations that help visualize things.
These are like professional quality videos, this dude is a god
yeah
I went on the comment section just to write the same thing. The level of detail to help people visualize concepts is amazing.
I came here to say the same thing.
How the actual crap did people figure this stuff out?
"AH YES, WE'LL HAVE AN ELECTRON BEAM DIRECTED BY MAGNETIC FIELDS AT 60hZ TO CREATE THE ILLUSION OF A PERSISTENT IMAGE."
And people get for granted all these technologies while "simple stuff" like old TVs are so complex.
The 60hz was out of convenience for how American power worked. I'd recommend you watch Technology Connections, as it breaks down how analog TV works in far more detail than this channel does.
amaaaaaazing vid :O
@@YaroKasear TechnologyConnections is awesome!
Thank Philo Farnsworth for that one.
You're making these videos so well it's incredible. This is what I wish I could have seen five years ago when I was struggling with that stuff, and at the same time it's only now that I actually *understand* it. Can't thank you enough for everything you're doing!
These might be the best visualizations I've ever seen to enhance explanations of a topic, and I'm a 3Blue1Brown fan. Damn you're good
8:08 That image of the instruction timing shown in the context of screen draws and what happens outside the screen is one of the most elegant presentations I've ever seen. Major kudos.
Your videos are a masterpiece, instead of just speaking, and mentioning just the happy path, you show extremely well-designed instructional graphics and exhaustively explain in detail every mode of operation and edge case.
You are a legend, my friend 🙏🏻
The visualization of instruction run times mapped to electron beam location is superb. The entire video is great, but that particularly stood out.
These videos are absolutely perfect every time, you deserve 44 MILION subscribers rather than 44 thousand.
Keep up the amazing videos!
I would say 2 billion.
@@nathansos8480 2.147 billion
The realtime visualization of the blanking/spinning animation is extraordinarily good. I feel spoilt with the quality we're getting.
Thanks for the awesome, easy to understand, video! Reminds me of the book Racing the Beam, which talks about developing for the Atari 2600, which was a herculean feat because the hardware was incredibly limited.
That's exactly what I was thinking! Nick montfort visualized the Atari screen much the same way as in this video, and that forced blanking during h blank is familiar from old atari games with lots of black artifacts like space invaders
A lot of the more advanced graphical techniques can be traced back to the 2600.
For later systems they were used for complex effects but were sort of optional.
But the design of the 2600 means you basically need to do them as a matter of routine.
Almost all 8 and 16 bit systems do variations on this stuff though.
Does remind me of the Atari 8 bit home computers; They essentially have an upgraded version of the 2600's graphics chip, but then have a second chip that is like a special-purpose CPU, which for basic tasks does the stuffing of the data into the main graphics chip for you automatically.
This design was exceptionally flexible, and let you do things like switch graphics modes 5 times in a single screen, changing resolution, colour depth, to text or graphics mode, etc, all basically without CPU intervention.
It's still the same principle though; Change the data each scanline...
Yeah, pretty much the frame buffers solved that issue, so from then onwards you only had to race the beam during VBlank, the display was handled automatically.
The Atari 2600 was a machine designed to run Tank. Making any other game run on it required that your cartridge pretty much hack the console in real time.
Really cool video on CRTs and Blanking! I never really noticed the black flashing on the top of the screen, but this is really cool to see at a hardware standpoint!
Thanks for another awesome video!
Correct me if I'm wrong, but the black bar at the very top of the screen would probably be hidden by the TV's over-scan, thus you would never actually see it on a CRT.
If the bar is sufficiently small, its possible it could be hidden; however, there's not really a limit to how badly it can lag--the black bar could even take up the whole screen if the v-blank routine took an insane amount of time.
How does your comment say "1 day ago"?
It's only been less than an hour!
Patrons can get early access ;)
Are there examples of games in which we can easily observe this problem?
Best one yet! I didn't want this video to end. I'll never forget the flickering black line at the top of the screen, now I know what causes it. The Sega Genesis and its infamous CRAM dots make more sense to me now as well, I better understand why programmers needed to hide palette changes in the 'offscreen' code.
this is so cool. I stumbled upon this while doing some super Mario world research, and I'm glad I did. 10/10 best explanation series ever. Animations, commentary, and info is just so great. I can't believe learning can be this enjoyable, even after graduation! Thanks
Hoooooly crap, what an informative and incredible video. You go into some incredibly in-depth things here, but you manage to explain them in layman's terms that anyone could understand, with some amazing editing thrown in. Dude, you're a legend.
I'm... going to need to watch this once more. I couldn't take in everything at once.
You really go out of your way to make these videos in depth.
What a fantastic series. I mean this in all seriousness, this series deserves recognition well beyond the bubble that is youtube and the gamer-kid sphere. Outstandingly comprehensive with superbly produced presentation.
Really loving this series so far!
I understand almost nothing about the hardware/code aspect of these things (Games/Consoles) and have always wanted to understand it. Your explanations and visual examples have really helped me to understand these things!
Thank you so very much for your amazing work, and I look forward to seeing your next video! ^~^
Congratulations on those gold videos, this is the kind of information I searched so much on the internet in vain. These SNES delays mainly when there are many koopas in SMW I believed to be a limitation of the sprites table, I never imagined that the problem would be directly related to the old tvs
mmh. Really well explained.
Worth noting that a major advantage of PAL systems (which is rarely utilised, because doing so would make games that are almost unplayable on an NTSC machine, which for obvious reasons isn't great if you expect to sell the game... It would preclude selling it in America or Japan...).
Anyway, they have a substantial advantage in terms of how much VBLANK time you have to work with.
It's anything up to 85% more time. In theory this would allow some really complex graphical routines that would choke an NTSC machine, but as I said, for practical reasons this tends to be avoided. (except in tech demos.)
This by the way isn't an advantage to the SNES specifically. Variations of this advantage show up nearly across the board in 8 and 16 bit consoles and home computers.
It's such a big advantage that a lot of the demoscene uses PAL machines in preference to anything else...
Or maybe arcade cabinets tend to build on PAL system instead? I'm not sure if that's the case though. (At least in China, many old cabinets were probably pirated ones, while newer ones basically just don't have to worry about these stuffs at all, and there aren't really any LCD screen that works exclusively on 50Hz.)
That seems unlikely, but it's possible. Most arcade machines are simply more powerful than home systems in general.
You can see that by looking at the Neo Geo, which had a home version with the same specifications as an arcade machine, but was exceptionally expensive...
CRT arcade machines didn't use PAL, NTSC or any color encoding, they used RGB component signal. Refresh rate is controlled by the game, doesn't necessarily have to be 50 or 60hz.
For example original Mortal Kombat runs at 53Hz.
Worstplayer
But it doesn't stop people from turning a SNES into an arcade machine. Not sure if the game can adjust hsync and vsync though...
One of the reasons C64 demos were so more popular in Europe.
Thank you for the great video! Is the script or tool you used for overlaying the overall timing utilization (14:49) something that occurs in real time, or composited in post-production? If it's a script, it would be a wonderful TASing tool!
I use a modified version of this script I made to create that scene: pastebin.com/2rmgbL7V
It's built for lsnes and the offsets at the top are set for the English version of Super Mario World (it should work for any SNES game given you know where to hook those two parameters).
Pastebin? Dude, get a GitHub! This is useful stuff!
Holy shit I just found you and your stuff is great. For someone with such high quality stuff you deserve more subscribers. Keep doing what you’re doing man
The quality of the animation is always super good; even if I know most of the stuff I just can't sdtop looking for a single second
I am absolutely amazed to find out that "slow down" didn't happen at ALL how I thought it did. (Though to be fair, I was a kid when I formed my thoughts on how it happened!)
How did you think it happened as a kid?
I sort of pictured it as so much info getting dumped onto the processor that it literally had to slow down, so the machine was just doing everything it always did, but at a slower pace. I now see that a CPU running "slower" now makes no sense. And how could you cram more info into it than it could take at once? =o)
Well, CPU would just run at constant speed unless you use some sort of variable crystal clock to mod the CPU, or the CPU can run multiple cycles in one clock tick. Both aren't happening in retro CPUs.
As for CPU running slower, it can happen in modern CPUs, for combating overheat situations. (That's mainly why laptop seems to "degrade" in performance over time.)
As for cramming more info into the CPU, well, people actually found ways to do that. But it's a bit too complicated so the simple way to say it is, info lines up better nowadays and thus CPU can take less time grabbing the info and spend more time working on it.
野龍
Which is great information my 36 year old self understands, but my 8 year old self would have been like, "That's a whole lot of words I don't understand." Then he would have farted at you because farts were the epitome of comedy at that age.
Dargonhuman
At the time you was 8 I wasn't even born yet. And since I'm in China, the thing is, people are still believing that human bacteria can infect computer and thus every computer room have their visiters taking their shoes off.
Also, even nowadays, just how easier it is to explain how CPU power improves over time anyway? :) I mean, most people, including me when I was a teenager, would just think that "better clock speed = higher performance" and assume we know everything already XD
This is so cool. I knew exactly how a CRT worked but I had no idea how it worked in relation to oldschool consoles.
Wow, well now I know why that happens in Zelda with that bomb spot.
Each new entry in this series is a real treat that I patiently wait for. Awesome work man! I am so looking forward to the SPC700 video.
This is so well-explained and animated that it was easy for me to understand the concept despite not being knowledgeable on this topic. Really good job with this video!
Your videos are so freaking good, it is unreal. I wish you continued success.
11:28 - so that explains the quick black bar I've noticed in ALttP when one lifts the big block in the basement of the Thieve's Town dungeon.
i've being watching all your videos about nes/snes and it really blows me away; i'm noob at the subject but you made me understand with more ease, and i really appreciate it!
These are great videos. As someone who used to write emulators for their full time job: I'd want you on my team. You explain the Super Nintendo hardware very well.
Best video in the series so far, in my opinion. Really interesting stuff. Good work!
The visualizations are just wonderful, I've been working with these concepts in mind for years (albeit on the NES, but it's 90% the same) and it's great to actually see it represented by something more than activating a tint register when spinning begins to see a visual representation of the CPU load.
Thanks, Mr. Explained! This channel is just amazing and explains things very well.
I not only learned how the SNES works, I also now know how CRTs draw images. After watching this I finally could understand Technology Connections' video on television, heh
Awesome video as always! I never knew that actual CRT functionality was calculated in the SNES!
MegaZeroX7 it surely does. In fact, the light gun used in the SNES detects the point you're aiming at by reading the CRT position when you fire it. Basically, the light gun is pointing at a specific point, and when it detects light, it tells the SNES to read the CRT position to determine where you're aiming
Sadly, because of this, it doesn't work on LCDs
@@ddnava96 wait, I thought the SNES had a white square for one frame when you pulled the trigger, and whether or not the gun saw that square determined if you shot..
or am I thinking of the NES light gun?
Yes, You’re thinking of the NES. Unfortunately that also doesn’t work on LCD screens
@@ddnava96 That's amazing. See, this is why we should have stuck with CRTs.
@@flurf5245. That one with white squares was on the NES and it had to stop the game while it was showing the squares. The SNES had a more clever approach with the CRT position in order to calculate it immediately without needing to stop the game
Had to comment on that data visualisation you pulled out for the time it takes for everything to happen in a frame. I work with data as part of my job and that's one of the best things I've seen this year.
This is really interesting. The little infographics are well put together and clear too - thanks for this.
And here I was thinking that this episode would be boring, when I can now safely say it was one of the most interesting ones to date! Can't wait for the next one!
I really thought I wouldn't understand this topic, but your explanations and visual representations are great. I had this doubt for ages and now I clearly understand what's happening. You are the best.
I get so happy every time you upload!
Great video! You did a good job of explaining one of the more important but overlooked parts of retro graphics.
You've done an amazing job here, excellent work!
The level of detail you give on these concepts is worthy of a GDC talk if not outright it's own course
LOVE the commentary. I guy I know said that you've discontinued it. If that's true I hope you start again. I fucking love it.
Wow. Just when I thought this channel was dead, you upload! Awesome!
This one probably took a bit longer to make due to how precise and dense the animations had to be.
I had no idea so few instructions could be completed per frame. Thanks for the visualization!
Wow, now I'm so interested about HDMA, having revisited your earlier videos on this subject! Awesome work! Very detailed and informative. The math explanation in Mode7 is top notch! :)
And as with this video is likewise very very well made. Even if you may grasp some of these on the fly without really understanding what it does, your videos make one see exactly what's going on.
Interesting that the DRAM strip in the frame paint is in the exact spot that people exhibit the video flaw of a lighter line in the video output...I wonder if writing to DRAM is causing a strain on some of the components which leads to this video artifact on many aging SNES consoles...
I always thought it was coupled noise, but hm, it could be PSU fluctuation. Might be interesting to watch the 5V rail on a scope with a h-sync trigger.
It's a common flaw to other systems too. The Mega Drive/Genesis frequently develops the same problem.
Fundamentally it's some kind of noise on the video output. Though the exact source is unclear.
There are many known fixes for the Mega Drive, and on that system it clearly has nothing to do with DRAM, but on the SNES... I'm not so sure.
It's also a form of visual artifacting mostly seen on the earliest revisions of the console. (There are at least 4 versions of the hardware internally)
I have a super Famicom that is from 1990 and shows the problem quite strongly nearly all the time, but then I have a PAL system which is a much later revision (1994 I think), and while the effect is still there, it's all but invisible except on very dark backgrounds. (especially black).
I've taken both apart so I know that they are completely different hardware revisions...
Definitely noise of some kind... But I'm still not entirely sure what the source is.
That's the first thing I thought of too when I watched the video!
Both of you are correct. It's coupled noise from the DRAM refresh pin.
Wow, that animation for H-blank and V-blanking was so good. I had always seen those but never really knew what they meant, good job!
These are some amazing visualizations. Thank you for doing this series.
This was incredibly fascinating, and your animations helped so much to clarify things!
0:52 Actually, the Trinitron TV's (and any TV's made after the patent expired that used the technology as well) use a single electron gun with 3 cathodes, and an aperture grill. Non-Trinitron TV's used a shadow mask along side what you showed on screen. All of this is assuming that a color TV is being used. A black and white CRT TV is exactly what you showed on screen.
Writing a simple composite or rgb display program for a pic or fpga really gets the idea across how analog screens worked
Wow, this is top quality stuff dude. I'm amazed!
Would you consider doing a very simple introduction to programming on the SNES?
ie; explaining the boilerplate code, drawing a single pixel, etc..??
I love these videos! I always come in confused and come out with actual knowledge, plus I love learning how electronics work! Keep it up!
Fantastic video. I don't think I've ever really understood why the SNES only used 224 lines instead of 240. I've always figured that the V-BLANK period for the SNES was the same as the VBLANK period for a TV. Now it makes sense.
I learn so much in these videos... really fascinating stuff. Keep up the good work!
great video, really informative and the visuals helped explain everything clearly
I love these videos. It's one thing to explain it, but us simpler minds need 14:47 and it all becomes crystal clear.
Great series so far! I have one tiny correction: you don't actually show the beam "point" move downwards during the scanline itself. Due to how the magnets and hardware works, vblank and hblank are mechanical timings designed to let the magnets "settle", and during scanout, the vertical velocity of the beam is constant -- it moves downwards just as much during the scanline as it does during hblank. The phosphor screen itself is typically designed to counter this tilting effect, and on cheap TVs, the tilt is considered a small enough artifact that it's not counteracted at all.
So simply it moves down in a zig zag fashion, just as the sewing stitch.
This video was EPIC! I now know more about the SNES than I ever did before... I can't wait for more!
dude your videos are awesome, I see them since more than a year for first time I comment, keep up the good work!
Very nicely done, I liked the animations you've used as well as the subject itself!
Back In The Day when I developed for the Nintendo DS (whose PPU was similar to the SNES's but it allowed register updates and DMA during rasterization), I actually used a trick to visualize what routines were taking up my frame time so that I could order my routines appropriately, by changing a palette entry at the start of each function. This let me see when in the frame each function was running and how long it took, so I could then change the order they were run in and try to prevent them from occurring during or after their part of the screen refresh. :)
This is a trick I picked up from the demoscene, since the Amiga had the "copper" coprocessor which was used in this way purposefully (and some enterprising PC developers figured out means of simulating it in the main CPU instead).
We used to do the same on PS2 also, it had a background colour register you could write at any time during the frame. Kind of epilepsy inducing if running at anything lower than 1 frame though!
Some of the finer minutia goes over my head but overall I understand these videos pretty well. I'm very much of a fan of this approach to explaining how an old console works, your active examples and demonstrations make it far easier for a visual learner like me to better understand it.
And for period accuracy of the time, even if you could actively notice at that one point that black line at the top when the background was updating from that bomb explosion, you really wouldn't be able to physically see it on a CRT because most TV sets of the day had thick plastic framing around the tube that would crop off the edges of the screen, a little on the sides and a lot at the corners. All the ones I ever owned did.
Of course, if you're into retro consoles, I'd still recommend an old CRT TV to play them on, it's how they were meant to be seen.
This is awesome and very well explaned! I can't believe how much time it must've taken to edit!
New RGMX and 3B1B videos on the same day?!? I can die happy now
That animation with the previous frame's scanlines slowly fading to grey is just fantastic.
Excellent depth of content here. And well demonstrated. Thankyou :)
Omg. You are a monster! Excelente video my friend! You rule!
Huh, if you look at the diagram at 5:57 in full-screen, you get a weird optical illusion.
If you look at the horizontal pattern for a short time, then look at a plain wall, you see a weird bit of colorful noise, like what shows up on old TV with no signal.
If you look at the pattern for a long while, then look at the wall, you see a bunch of trippy, vertical/diagonal/curvy, colored lines.
Great visualizations!
Before: "Hey yo, what you see on screen are just pixels changing color depending on what you do in the game, a beam projects it one by one! ezpz lemonsqueezy!"
After watching the video: "Fucking hell..."
When I saw the ray whipping around it gave me dirty thoughts and I just fucking died
Damn, I love your animation, I like to learn visually and that really helps
Man I'm loving these, can't wait for more! Anyone know where to find more videos like this? I'd be really interested on a detailed breakdown of how, say, the Sega Genesis worked.
Anyway, keep up the fantastic work!
This was a very informative video, now I feel like I finally understand these concepts.
Your videos are so great I never thought I could understand and learn something like this though a youtube video
Another excellent video! Thank you for these!
Awesome video! Really makes me feel spoiled, working with modern systems where you no longer need to race against the beam this way :)
So well explained and presented so well on top of that. 11/10 stars
This is amazing. Really well done
Fantastic video! This explains a lot! Thanks for the content!!
Fantastic content, well researched and highly informative.
Really love these videos, keep em coming!#
Terrific work as always :-)
"This all takes place within a frame of course"
That's actually really fuckin impressive for what it's doing, this shit amazes me
Incredible presentation! :)
You're awesome dude. Fiending for my next fix
I love how programmers back in the day knew all of this about the hardware and just used it to their advantage. One way I could see it being used is maybe preset a puzzle or physics effect, have a timer that is really just a couple frames and use those lag frames to do all the movement calculations, then it just spits out preset values for where things would go. Not sure if the RAM is big enough to store all that but it's a start
Amazingly detailed explanation! Thanks a lot!
And then there is Space Invaders.
It gets faster by shooting down enemies and thus advancing the game.
Less sprites = less stuff to draw = faster frames.
From a technical standpoint the game lags immensly at the beginning and gets faster and moire fluid with every hit.
This was a great video. Thanks for making it.
When I turned off my SNES on my old TV I had, it would always show colorful lines, mostly blue and purple on a black background. Now I get an idea what those lines were for.
After this, will you make a video series about the Master System's VDP modes?
I don't know what they are
Holy shit those are some good animations!
I sleep whenever I watch your videos.
Thanks, I'm in college.
Great video! Loved it!