NES Mapper History to 1988 and Blaster Master Code Analysis - Talkin' Code Ep. 1
ฝัง
- เผยแพร่เมื่อ 6 มิ.ย. 2024
- Unscripted look into the history of Famicom/NES cart capacity, Mappers, Sunsoft, and a deep dive into Zero Page and the Stack using Sunsoft's Blaster Master
If you would like to support this channel, here is a link to the Displaced Gamers Patreon page - / displacedgamers
Twitter: / displacedgamers
Facebook: / displacedgamers
Instagram: / displacedgamers
0:00 Opening
1:03 Topics
3:05 NES ROM and Mapper History
6:54 Sunsoft
8:17 Zero Page
13:25 The Stack
23:45 Outro
#Programming #NES #History - เกม
i love this channel and the content.
Аналогично, оба ваши канала это то что греет меня зимой.
I watch both of you guys. Great work.
this guy is a great teacher, right? 8bit RE teacher.
Can't like this enough
@@BeAfraidOfBaobabs also try a heater or fireplace.
Fun fact: The 65c816 that the SNES was based on solved the whole moving data to zero page conundrum by having a register that lets you define where zero page is.
@@ginxxxxx fair question\observation. This is why they renamed it to "direct page." :)
@@ginxxxxx not a very clear question, but I think I know what you're trying to ask. Having the direct page register already stored in the processor is faster than having to decode an extra byte when not using direct addressing mode.
It's like a segment register! The 16-bit predecessor to the modern x86 had segment registers that act as a base address for various memory accesses. They're still present in x86_64, but they're significantly more limited in favour of just using direct addressing (in virtual memory, which is a whole 'nother beast).
@@angeldude101 I could see the similarities there, yes. x86 based instructions make my head hurt, though.
@@BradCorrupts Well then I hope you don't have to work with the Gameboy or Gameboy Colour. ;)
(The Gameboy's processor was based on the 8080 and Z80, which are the distant ancestors of the modern x86_64, so the Gameboy is kind of an uncle to modern PCs in a sense. That said segments weren't added until the 8086, so you don't have to worry about them in the Gameboy.)
Definitely a fan of this format. You manage to stay pretty concise and on topic even though it's unscripted, avoiding the usual pitfalls
I too really enjoyed this video format, despite it being less scripted. Getting a chance to learn from your insightful expertise is always a pleasure for me.
I hope you move onto GameBoy at some point!
Unrelated to your actual content, but your steady speech flow and buzzing bass voice are a real plus!
What this guy said.
I just wanted to comment that this video series seems great to me.
Thank you for this! I've always been curious about a few things you mentioned.
Hey JohnRiggs, because of your video tutorials on making new Snes and Nes labels as well as the repair videos, I've been looking into making Snes games that I can put on a real cartridge, and then I found this video.
Finally, someone made a video on the chronology of mappers!
I'd like to do a scripted version at some point that has all the details in it - or even do a scripted series on each of the various mappers and explain some of the intricacies of how they are used. I need a bit more experience with them first, though.
@@DisplacedGamers That would be so cool!
@@DisplacedGamers Yes please!
I love the idea of the actual programmer coming across this video and being like, "Hey! Someone actually recognized my work!" I feel like a lot of the subtlety and nuance in coding, especially in those days, really goes unnoticed.
GCC automagically performs a similar optimization when it emits the final assembly code: if a routine ends in a call to another one, instead of emitting a call instruction it emits a jmp to it. This way, when the second routine ends, instead of returning to the caller (the first routine in question), it returns to ITS caller. This way, the pop instructions aren't even needed, and you can chain lots of routines and return with a single ret instruction! :D
Is this tail call optimization?
@@jimmyhirr5773 Yes, I believe that's what it's called.
@@TheJamieRamone The other cool thing about tail call optimization is that if the tail call calls itself (that is, it's recursive) the tail call can still be turned into a jump. This makes recursive code much faster and prevents the recursive code from stuffing the stack.
@@jimmyhirr5773 Ooo, I hadn't even thought of that! Mondo-kewl indeed sir! :D
@@TheJamieRamone The tail call optimization I talked about is really common in functional languages like Scheme. In functional languages, it's difficult or impossible to update variables, so there aren't many for loops or while loops. Instead functional programs will typically use recursion. Tail call optimization is essential for programs in those languages to have good performance.
When you scrolled down in the code and I saw the two PLA lines, I immediately said out loud, "holy crap that was really smart". Something relatively simple, but if you look at the bigger picture, they really optimized the hell out of the code to squeeze as much as they could out of the system as they could.
It's more like, "premature optimization is the root of all evil" stuff.
This was an awesome video. I come from a very high-level-language background (Java, C#) so seeing some of the assembly tricks makes me simultaneously horrified and impressed. Case in point, during the section here about the stack, my brain immediately went "you FOOL! don't mess with the stack! it will crash EVERYTHING!" because that's how it is in Java, but the way you explained it is remarkably simple and clearly details the risk vs reward factor of the trick. Very well done!
Sunsoft's base-model FME-7 mapper chip doesn't provide any extra sound capabilities; only the 5B variant of it (used exclusively by "Gimmick!" for Famicom) did. Not that the overseas NES models would have been able to use them easily, anyway; the audio line from the Famicom cartridge port was relocated to the expansion port on the bottom of the console, and was never used commercially during the console's lifetime.
That means that the excellent Return of the Joker soundtrack is achieved using just stock NES hardware.
Thanks, Michael. You could probably tell I kinda tagged that in there as an afterthought after doing the main timeline up until Blaster Master. (My voice even sounds like I recorded it at 2 a.m. because... I recorded it at 2 a.m.)
yup, sunsoft's audio programmers got very clever with the triangle and dpcm channels.
Blaster Master has always been such a distinct and intriguing game. I love finally learning about how it works!
8:12, just one small correction: while some versions of the sunsoft FME-7 do have expansion audio, there's no way for an unmodified NES to actually take advantage of it as there's no audio input/output pins on the cartridge port, unlike the famicom.
Very nice and informative video though! I love the content
Yeah the old-school programmers that build these games had no shortages of clever little tricks to get an extra cycle here or save a couple of bytes there... And it adds up in aggregate. Having the limitations they had back then (not being able to throw more silicon at the problem) really led to some elegant solutions.
Incredibly cool. At this point I know enough Assembly to write a NES game, more or less, but I hardly know anything about writing Assembly WELL, so stuff like this is invaluable!
About mappers, I hope one day you will make video about pirate multicart mappers too and how is that 9999999 in 1 carts are worked. Like at Super Mario Brothers, it let you start at different worlds (like 9th, alphabets ones or half cloud) or changing game physics, like moon jump.
Regarding Zero Page, it's an interesting optimization. I actually first learned about it from Bill Gates when he was talking about optimizations they would do in Assembly. He was excited saying something like "You save a byte! And back then saving a byte was a big deal" or some such.
Yeah, using the zero page isn't about faster memory access, it's the fact that the immediate memory address has one less byte in it due to the high-order byte being implicitly zero. Having to fetch one less byte in order to execute the instruction means the instruction gets executed in one less whole clock cycle -- which can _really_ add up in tight loops.
I thought the zero page was the best part of the video...until my mind was completely obliterated by the stack explanation. That is some master (blaster) level programming. Astounding.
I honestly think it would be very cool if you turned teaching assembly into a series
The retail lifecycle of the NES is really defined by an inflection point during 1986-88, centered around the start of MMC1 releases, because that's when the global RAM supply seesawed from glut to shortage. During the glut, every game on cart, as well as arcade games, pinballs, etc., suddenly grows a soundtrack, multiple themed worlds, and animations, because the available storage space had a Moore's Law doubling at fire-sale price points - and then in 1988, a whole bunch of games are delayed or cancelled because the desired chips aren't available; smaller scoped games briefly get more representation again before returning to trend in 1989. This event did two things for the NES - it was a disincentive to continue with FDS games and to instead invest big in mapper chips(because carts suddenly got cheaper), and the 1988 delays created the preconditions for Mario 3's big 1989 rollout in the US, with the most extensive marketing campaign any video game had seen to date. After that point, there are new mappers, but it's an incremental change and mostly overshadowed by new console releases.
I really appreciate content like this. Looking forward to more of this series.
Love that you’re uploading more often! Great content!
great video. love the format
Echoing a common sentiment: this "informal" format rocks. I love your videos generally, and I love this new one too, but in a different way. Keep it up!
love this new format, hope you'll create more of these videos, it's very interesting. Thank you!
Love the video, code reviewing is very interesting and informative, learning ASM tricks and optimizations is fantastic.
This is a great video and format and style. Good job dude!
This was a great video. I really dig the format.
Great channel! Thank you, I appreciate all of the work you're doing here.
You have a knack for explaining things. Thoroughly enjoyed! 👍
This is so great. For me the this in depth analysis is incredibly interesting. I hope its interesting to enough other viewers that it pushes you to make more videos in this series.
I just subscribed and I am an engineer and programmer. I LOVE THIS! I went into engineering because of video games and I would write video games when I was a kid. Because games were so expensive I would have my mom buy computer magazines with programs in them you can type in basic and save to a tape. I am 45 years old, so you know around the time I grew up*80s. Keep it up! I still write code in assembly for products when using 8-bit microcontrollers. I also write most programs in C for the 32-bit microcontrollers i use... But I still use Assembly and I can write code for a 8-bit controller that people would have a hard time doing in C on a much faster and capable controller!!! anyways keep it up! Happy i found this channel.
I was hoping you'd start doing something like this. Great video.
I always appreciate your "normal" videos as they are usually more technical than the usual video. This deeper dive is really great. There were times that I wished some topics were covered in more depth, and this provides an appropriate context to do just that! This is great.
The history perspective was great, thank you!
Great stuff =D Love this level of detail!
Definitely keep on doing this format. I absolutely love the idea of someone knowledgeable talking about old games and more specifically how they were made. I've been writing my own nes emulator for some time now, and all this really helps to deepen the knowledge about the system. Thanks!
Great video and your tone of voice and pacing is excellent!
This was amazing work thank you.
I really enjoyed the relaxed, deep dive style of this format. Definitely a keeper.
That was the best explanation of the Stack I ever heard of, man. I don't know how to program but I love opening up the debugger and figuring out how these games work, so I'm really glad to see there's a dedicated channel all about game-related tech and reverse engineering; keep up the excellent work!
You seem really cool and you make some of the best technical retro gaming content around.
I'm so used to C and similar languages that watching someone execute a double-return by manipulating the stack directly hurt my brain a bit. It's not that I didn't know you could do that; it's that every rule of structured programming says you *shouldn't* do that.
Assembly really is its own special programming environment.
Yeah this must be hell to maintain!
@@renakunisaki It's a console game on a pre-internet console. "Maintainence" wasn't something that was even considered.
That's not to say that they threw away code between projects. I suspect "Hydra" was a common bit of code that they kept and maintained from early projects.
I enjoyed this. It really did feel more relaxing than many of your videos (already pretty relaxing tbh), and I enjoyed listening to you pick apart some of the things you'd been thinking about. Would definitely be interested in more videos like this in the future.
You are my Ben Eater of video games. Please keep up the amazing content.
Great content. Love the industry and technology commentary. This kind of context gives an appreciation for the developers of the time, but also an appreciation of where we currently are. The cartridge hardware evolution was kind of dope.
This is great, like the casual conversation. Podcast style is good
This was great and really interesting. I think this format worked well.
Pretty simple trick in retrospect but I’d never considered it before.
Great video, I think this series could be really good! Definitely a good idea!
learning so much here, thank you !
Sweet, keep this going man!
You're awesome, please keep doing what you do.
This was amazing; really enjoyed all of this. More of this, please.
The 6502 really intended zero page to make up for their lack of registers, so it's cool to see a game make use of that. Also really interesting to see them chop off the stack to save return time.
Just love how you make an old game return to light and show how complex it was. Still an underrated channel, but the content is pure gold. Great video, as always!
Really enjoyed the vid. Thanks
As a programmer and someone who likes learning how the video games I grew up with work, I really appreciate your channel and this deeper dive into the code. Thanks for making this, and really hope you'll do more!
The unscripted format is perfectly fine and welcome addition, I enjoyed the discussion and your insight.
Also, I had never heard or seen sunsoft's Gimmick! game The soundtrack is freaking amazing using the Sunsoft 5B mapper audio.
I also enjoyed this format a whole lot. If it allows you to create more content then I’m all for it. Hopefully you’ll also keep making the behind the code series as well.
Your channel has been stellar since its inception.
Thank you so much. More Behind the Code is on the way.
Tokaido Gojusan Tsugi was not developed by Sunsoft, it's a TOSE game, like Ikki and a few others, but the mapper part still applies to them. Good video! :)
Love love love this!
6:36 love those names. Hey, this is a great new series. I hope it works out that you can do more of these.
I was literally just thinking about finding a video about NES/Famicom mappers like 4 hours ago...I'm not kidding! Perfect synchronicity! 👍👍
This was SMOOOOTH! You seamlessly went through everything and it was smooth. This was also fairly understandable for me (until you got to stack). So even if I didn't completely understand everything, it was still enjoyable to listen to. Good job man!
"Let me pass on to you the one thing I've learned about this channel: Nothing here is exactly what it appears. Not Loops, not Pointers, not Stacks.. and not even Zero Pages."
As someone who also has a background in computer science, I enjoy your videos probably for a different reason than most do. I'm awful at explaining things and trying to teach/communicate my methods to others. So seeing how well explained everything is here, it brings a lot of joy to me that others will most definitely learn from this and understand it. Keep up the good work!
On another note...I'm really glad I got to take a class on Assembly language recently...I actually understood what was going on!
Hope to see more videos like this in the future!
That is really neat, pulling a return address from the stack if its not needed. I had never thought about using the stack that way before. It seams an essential piece of knowledge about JSR. Thanks.
Very awesome format!
10/10, I'm here for it. Love casual nerdspeak.
im a super novice when it comes to code but i watch alot of these types of videos and yours especially. you are the only person that explained the stack in a way i could understand. it seems so logical now as basically a roadmap back through the program as it jumps around but others would just say 'last in, first out' and leave me hanging. ill still probably just use my basic skills to make cheats on the emulator but the mystery of the stack has been solved for me today.
Loved the video, the kind of optimizations those guys did in the early days is mind bogling!
Messing with the stack returns show they knew "If I leave my house to do groceries and then visit the Bank, why the heck i'm i going back to the groceries to then go home?".
Loved the serie's concept, keep them comming!
You go to the store, realize you don't have cash, so go to the bank to get it, then back to the store. But if you discovered you don't have enough cash, no point returning to the store...
That was really nice to listen to!
I was actually analyzing Blaster Master's code myself recently, with the aim to make a video of my own explaining the pause trick. I came across the double PLA trick and my modern software developer sense just about had an aneurysm. It's definitely clever, and it definitely saves a lot of cycles and instruction bytes, but it's so counter to modern programming practice that I couldn't help but hate it a little bit.
Loved the video. Keep up the good work!
This is the kind of crap you can only pull when you legitimately have NO concern about portability. ;-)
Is there a particular portability concern? "Call subroutine, call subroutine, conditional jump to Exit, pop address from call stack, Exit: return" seems pretty generic to me.
I hope you are going to do more such vids in future!
The content is better than you promoted at the start of the video. Very good work!
I've paused the video a bunch of times to read along with your narration because I'm very unfamiliar with assembly, and I'm so happy to say that I fully understood pretty much everything you showcased!
Using the stack like that is crazy. How I would write that example in other languages like C or Python is by letting the Collision Detect function return a boolean. If the boolean is true (or false, that choice is arbitrary), the Object Damage function would immediately return to the Example Start.
Now that I'm writing this comment I realize that your Assembly example has one less branch than what I described, as Collision Detect can jump straight to Example Start, instead of first going back to Object Damage. It's a double return!
EDIT: I've read the other comments and I didn't realize that it's pretty much a manual tail call optimization, that's so cool! I didn't recognize it as such, even though I've recently experimented a lot with them in C, as I thought tail call optimizations were only relevant with recursive functions. I guess that a goto in C could recreate the trick, although using gotos in C is discouraged for the sake of readability, of course. :)
The visual comparison between SMB3 and TTA has me hopeful that a future episode will dive into the allegations that Konami flat out ripped off code from SMB3 during the production of TTA via analysis of the power gauge and movement timings
Many thanks for the information.
Interesting methods. This is one of my favorite NES games for sure! Any videos on Solar Jetman?
fantastic lots of fun this way too, I think you're just good enough with enough experience that you know how to pace and set up intrigue to keep things interesting even in a loose format.
I definitely like this format and if it can help you make more content quicker then by all means please keep using it!
Even though I'm a (mostly) backend web developer, I find these videos fascinating. I would love to see you tackle how speed run techniques work inside the code. For example in Zelda II how does the healer glitch work?
Anyway, I love your content and I'm sure it's a ton of work to keep up with. Looking forward to see how your channel grows 👍
That was incredible. I only know visual basic, basic programming and I could follow quite well.
Best game to talk about, one of my favorites, this was extremely interesting!
Really nice video, I use this technique sometimes (PLA PLA RTS) to skip the previous routine in game hacking, though I haven't found good use for it yet, but it's definitely a interesting technique.
Very cool!
What a fantastic video. I personally welcome the opportunity to watch more of these videos, if you are on the fence about making them.
This is excellent.
Another advanced stack technique you'll see is programmers using it for implementing a switch statement. They'll load an address (minus one) from table,x and push that onto the stack and then immediately rts.
There's also tricks where the called function pops the return address, reads additional information, updates the address, and returns it. That lets you write code like:
jsr print
.text "hello world"
lda etc...
Stack manipulation is so interesting. I'm sure that if you dive into later titles you'll see some _real_ magic happening with it.
I'm impressed. I doubt I'd have ever thought to try copying to zero page and back. It seems so counterintuitive, like no way that actually saves enough time to offset the copying... But it does!
I am a programmer by trade, and I found this video to be fascinating!
great format. i hope it's not going to disappear after a couple of episodes.
Same.
Great video.
Also i love comparing the old old games to the newer games of the console. Even if theres some hardware additions found in the cart the sheer difference is baffling.
Like you said, comparing Mario1 to Mario3, needs to be viewed differently for each game. But if you do compare the two just to see how its improved code-wise its ridiculous how many tricks and cheats theyve developed in the same console generation.
This feel like a podcast about coding a nes games. I like it.
As someone who has released a lot of hacks for the NES, your videos really tickle my interests in many ways, and almost feel like the kind of videos I would make myself. I think I actually prefer this style, as it's slower and thus easier to follow, but I do enjoy walking through assembly myself and like learning about some of the tricks the programmers used. Keep it up!
Thanks! I'm sure you have a ton of insight on the hacks that you've done that people would love to hear about.
@@DisplacedGamers If I had the subscriber count that you have, I might have done it! :D But seriously, I haven't done much hacking for a year or two, and I always felt my channel (Psyklaxia) was a niche within a niche, and it would never realistically gain traction. I guess your channel proves me wrong!
I like using the stack. First time i decided to make it useful was with batari Basic for Atari 2600. The DPC+ kernel has a 256byte stack free to use, yet nobody really talks or bothers about it. I was wanting to cycle the score value to level number then back to score when entering the next wave. This was for my game City Defense which is kind of like Missile Command. The reason i decided to make use of the stack was i ran out of RAM to store the values. Basically like the "hold this wrench" philosophy. So at the end of the wave i would *poke the score value to the Stack in a certain location and *peek/retrieve the wave value from below. Then do the same to restore the score value to be displayed after the intermission screen. Basically like handing the wrench then saying "no take the screwdriver" ok "now take the wrench back and give me the screwdriver again". Ever since then i have always tried to make use of the Stack in one way or another, even when not short on RAM just for fun. It's not RAM however it's useful to store and retrieve values to save precious RAM.
These videos are the few times I feel like I use my computer science degree these days. Also, did you have to repair a sink lately? :P
It would be hilarious to see one of these episodes about how the code to Action 52 would look like or do one about the arcade game LED Storm. No one ever mentions that game ever and that one was optimized pretty good back when it was released too I think.
Good stuff.
I will admit it sounds strange hearing your easy going format compared to your usual structured formal method but it was still pretty concise.
But I liked the topic of this video. As an amateur whose trying to gain an understanding of computers and coding hearing about these details is both fascinating and helpful. I'm also a lover of efficiency and tricks to gain more out of so little. And now that I have a better understanding of the stack that I've been hearing a lot of now I just need to learn how to utilise it when coding. Thanks.
I really enjoy this as a partner format for you channel... especially if we get more great content.
Would you be open to doing a video discussing your tool chain and resources for beginners and intermediates?