NES vs Famicom Disk System - Zelda, Disks, Mappers, and "Ports" - Talkin' Code Episode 2

How do cartridges and the Famicom Disk System map into CPU addressing? What are the differences between MMC1 Cart Zelda & FDS Zelda?
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
#NES #FDS #Zelda

[@Psyklax]

Having translated a couple of FDS games, I have to say it's quite interesting to compare what goes on in the code. From a hacker's perspective, I think I preferred it: I didn't have to go chasing code around multiple banks, there's just a file on the disk with the data I need, and you have some freedom with changing things. The redundancy in cart games is a nightmare for a hacker because some NES games are completely full of data and you don't know necessarily what you can remove to make space for your new data. On the FDS disks, no problem, just make the file bigger, and as long as you don't fill the disk then you're all good. Of course, the player is oblivious to this. 😊

[@DisplacedGamers]

Hey thanks for commenting on this, Psyklax! I was hoping to hear from anyone involved in working with FDS games. I feel like the FDS technical community is rather quite small when compared to the cartridge community. Thanks for all of the work you have done.

[@williamdrum9899]

@@DisplacedGamers I think it's probably because the bios is so hard to find 🤣

[@williamdrum9899]

Out of curiosity, how does loading work? I'm guessing there's an interrupt that handles it, and you supply a starting address and it loads in the next 32k starting at that address?

[@jimmyhirr5773]

@@williamdrum9899 FDS disk data contains a sequence of files. Each file has a header that contains a file ID and load address, among other things. To load one or more files, the program calls the Load Files routine in the BIOS and gives it a list of file IDs to load. The routine then loads them into the addresses specified in their headers. I got this info from the NesDev wiki and the "Famicom Disk System technical reference" by Brad Taylor.

[@matthewrease2376]

@@williamdrum9899 it's really not tbh. I've "acquired" the BIOS multiple times over the years from different sites.

[@makeitrein7366]

I like where Chris mentions "if technical things aren't your thing hang in there", I mean.. I come to this to WATCH the technical lol. So good, keep up the good work Chris!

[@Ryusagi]

TBF, not everyone who has interest in this stuff understands the finer details and just here for the wizardry.

[@DisplacedGamers]

Ha! Yeah. I sometimes stick things like that in a video in case someone on YT is like "Sure. I'll click on this thumbnail/video" and then moments later is like .

[@nickwallette6201]

That was a very polite way of saying "If technical things aren't your thing.... why are you here? Poor thing, are you lost? Where's your mom?" haha

[@beipiaosaurus]

One thing I like about this channel is that it has just the right amount of technical information. I have absolutely no experience with programming, computer science, etc., but the explanations and figures make it easy to follow.

[@LinkEX]

21:32 "Data Circus" would also make for a nice series title, if you ever planned around starting a third series besides "Talkin' Code" and "Behind the Code".

[@Altandf4]

We come for the technical. Don't be afraid of it!

[@Pezmage1]

Man, watching your videos makes me feel like I'm 5 years old being snuck into a college course. I have zero computer science/programming experience or education and I still found this super interesting and informative. It's neat to see under the hood of the games that shaped my childhood!

[@SynaMax]

You make understanding memory maps and mapper chips so interesting and entertaining to listen to; can't get enough of these videos, man!

[@ejmc6378]

Damn, that was fascinating. For such simple and primitive looking games, they sure do appear to be a convoluted nightmare underneath. Old tech is crazy interesting!

[@QuestionBlockGaming]

Words cannot describe the visceral reaction I had seeing the *sea* of yellow dots on the Zelda 2 portion. Good lord!

[@RT55J]

What a coincidence. I was just explaining to someone the other day about how the NES Metroid is a port of the FDS Metroid. From the looks of it, it sounds like Zelda uses a lot more bankswitching, while Metroid uses a lot more redundancy --- each level data bank shares a substantial amount of code and data at the beginning of it, shares the same memory layout for the actual area-related data inside it, and contains a full copy of the music engine at the end of it. IIRC the original FDS Metroid was only 90KB or so (IIRC), and when when I crunched the numbers it turned out (quite naturally) that the NES version was also the same size after removing the redundancy. It would be interesting to see how much more world data could fit in Metroid 1 if the game was refactored to remove this redundancy, but that's a project that I have long since put on ice.

[@DisplacedGamers]

Nice, RT-55J. I was wondering about Metroid. If the original Metroid was 90KB, they obviously had plenty of room for bank redundancy as well as to add the password save system. Since Metroid uses the same PCB configuration as Zelda but left out the battery, I've been meaning to see how it uses that SRAM ("Work RAM" a much more appropriate term here) for data and/or code. I wonder at which point in the project they abandoned the saves in favor of the password system for the cart port.

[@RT55J]

@@DisplacedGamers IIRC, there is some unused code in the NES version for a proper save system (with multiple slots and stuff), but it might just be leftovers from the FDS version (idk). The main chunk of data that I recall getting copied to WRAM is the 32x32 map index array (denoting which ID numbers for each map screen). The enemy RAM is also awkwardly split between the on-system RAM and on-cart RAM. I'm not aware of any any code that gets copied to WRAM (could easily be an oversight on my part though). While I got decently far into learning how the code was structured on a macro scale, I ran into some roadblocks when trying to decipher the precise semantics of a lot of it (mostly due to sticking my head in the clouds of an uncommented disassembly, rather than getting dirty on the ground with a debugger). I hope to revisit the project eventually.

[@billkendrick1]

In 1998 I wrote a game for the Atari 8-bits (in Action!, a high-level language that compiles to 6502 machine code). It was disk based, mostly in that graphics data was stored in a big file that I opened and read from at start-up. I was flabbergasted to receive a copy of my own game, on cartridge, in the mail one day. It was a very early MaxFlash cart from AtariMax. The trick was that the cart can simulate disk I/O, assuming the program simply does OS calls for reading data. Many disk games just magically work on these (and other similar) carts! Very interesting to see just how differently it works (and how much effort was needed) on the NES. I'm guessing the Atari XEGS carts based on earlier disk games required similar effort. Great video, as always! Happy new year!

[@DisplacedGamers]

Oh that's a good point about the Atari XEGS carts. Now you have me curious about it. I feel like the Atari 8-bit platform is underrepresented in terms of its appreciation and attention today. This Action! that you mentioned also sounds rather interesting.

[@williamdrum9899]

@@DisplacedGamers It's a programming language similar to ALGOL I believe, designed to compile to 6502

[@teranokitty]

I absolutely love what you're doing with both Talkin' Code and Behind the Code! These definitely satiate my curiosity about the inner workings of my childhood games.

[@maxbrown4594]

According to TCRF, the Pols Voice's microphone weakness wasn't removed from the code in the NES port, just inaccessible with NES controllers. With the effort it must have taken to put Zelda on the NES from FDS, I'm surprised they skipped that, they would have known the hardware limitations by then... Maybe they already had plans for the cartridge-version famicom re-release and didn't want to mess with it? Also, the famicom cartridge version retains the graphical changes like the Zora outline... I wonder if the FC cartridge re-release was based on the NES version, but with the JP text crammed back in?

[@williamdrum9899]

I own the Famicom cartridge version and I think it's safe to say they did in fact just take the gold cart and essentially stuff it back in. The font for the HUD is the same as the NES version, and the mic does in fact work.

[@Jono1874]

@@williamdrum9899 are you sure? I tried it and could not get it to work.

[@rangerreview1780]

I say it was simply safer and easier to just leave the mic support in the code. So they wouldn't risk breaking something else in the game. Regardless of the US controllers having no mics. US Pokemon Red and Blue did the bare minimum in getting things to just work. After combining so many different things from the JPN versions of Red Green and Blue.

[@johneygd]

@@williamdrum9899 does the famicom version of zelda also retains the enhanced audio from the fds disk version or not???

[@williamdrum9899]

@@johneygd The cartridge version does not.

[@kri249]

I'm new to the technical aspects and slowly learning but your visuals explain things so much easier. And makes the inner workings of the game just as fascinating as the game itself.

[@reaper84]

Well done episode. Don't be hard on yourself, that your other videos are more eleborat. This Format here is just fine, and detailed enough to be very satisfying. Great work!

[@timdene]

Brilliant explanation of how it all works under the hood. These videos are brilliant. Thanks for making them!

[@jksoftware1]

Since the code cannot run without changes that came from the Disk System to a cartridge I 100% agree with you. You make a GREAT case. At the start of the video, I did not agree but at the same time I did not know there were so many differences between a cartridge and the disk system. Great job explaining it.

[@DaWhiteTyger]

I heard "Form Voltron!" that's so awesome! Love your jokes because you sound like you'd be a talker for any generic company, yet you roll out funnies like this gem. Kudos dude! Thanks for all the displaced code videos.

[@jordanwright853]

Great stuff. Very well put together as always Chris.👍Don't hold back on the technical, for those who don't understand yet, this is how you learn. These videos are excellent for those really wanting to get a look at what's going on under the hood.

[@pandnh4]

I spent a few days trying to find an understandable video on mapper chips. At 07:25 you broke that down better than anybody else on youtube.

[@dionelr]

That’s pretty amazing. No idea how they had to code things in the old days. We’re largely cpu and Ram plenty now, but this kind of optimization is crazy to me. It’ll be interesting to see the size of game rims later in the NES life, like Mario 3 or Kirby’s Adventure.

[@williamdrum9899]

I believe Mario 3 is 512K and Kirby's Adventure is 1024K. Pokemon Gold/Silver were a massive (for a game boy game) 2048K

[@wishusknight3009]

@@williamdrum9899 SMB3 is 384k, Kerby was 768 and Pokemon was on the gbc that didn't have the same limitations for memory management.

[@wishusknight3009]

In general the larger the game on the nes, the more amount of redundant data was often needed between the banks. Which made games of larger sizes become harder and more impractical to manage. But by the time SMB3 and Kirby came around, they became way more adept at optimizing this and mitigating this effect. Clever use of the SRAM space was crucial.

[@vyor8837]

Still need to optimize for cache limitations.

[@JadeLockpicker]

@@wishusknight3009 ... Pokemon R/B was on the game boy, not the game boy color. And while it had a built in mapper chip, it was basically the same 16k switchable 16k not switchable mess for ROM. (RAM, on the other hand, was _much_ more interesting, as you could have up to 16 banks of 8k of switchable _RAM_ in your cartridage. WHich I'm betting saw all kinds of interesting abuse over the years.) This still leaves a similar bank switching nightmare, mind you, but now it's even _more_ of a dance. (and then you hear the absolute insanity that went into compressing the data for the Gen 2 games for the GBC. Yeah, I'm going to say that's a trip)

[@AstroBilly777]

Thanks again for going above and beyond to present all this amazing info in such a concise and engaging way!!

[@rchassereau2]

Always interesting and I learn a lot from these videos, really enjoy them.

[@RynRobitske]

I've seen your videos pop up in my feed from time to time, but this one - this one got me to subscribe. 🤣 Such a beautiful and thorough explanation on how the NES and Famicom handle data and what programmers had to deal with at the time. Being educated a high-level programmer, I'm still amazed as what we had available to us back then given the limitations on those devs.

[@BrianJones-wk8cx]

Just stumbled on to your channel last week, and loving every minute! Thank you for the insights and analysis!

[@50shadesofbeige88]

These are fun to listen to. Keep up the good work! Also I don't think it's too technical.

[@fasterThoughts]

You are an absolute gem mate, great content, love the technical detail.

[@TravisTev]

Fascinating stuff. I've always wondered about the lag on the overworld screen or the NES version of Zelda II, and while the presence of excessive bank switching alone may not necessarily prove anything, it does seem to be a sign that something fishy might be going on with the code, either due to a bug or simply missing optimization or suboptimal bank organization.

[@GalileoAV]

I love that way of describing it, "data circus".

[@kickstartavalanche]

Love how in depth and hashed out your explanations are, while I'm thinking I've just learnt code 😄

[@DouglasZwick]

So cool! I love hearing about this stuff. I would really love it if you would cover Final Fantasy in a video, either in Talkin' Code or in Behind the Code. There's a ton of cool stuff (and some interesting mistakes) they did in programming that game that I think would be really fun to see you explore. In particular, there's this part at the ending screen where the words "The End" get drawn out onto the screen, pixel by pixel. I would love to see you analyze stuff like that.

[@canyahearmenow4]

Suggestion for future Talkin' Code episode: What's happening in the code that causes that excessive bank switching and lag when Link is walking around the overworld in Zelda 2 and can it be "fixed". Could just be a 3-5 minute Talkin' Code Shorty. Thanks for the great video as always!

[@pokepress]

I think there is a hack that “fixes” it by using a later mapper that is more efficient in switching banks to speed it up. I took a quick look and there are ones for MMC 3 and MMC 5.

[@heitortremor]

Gimme all that good technical stuff! I love it!

[@pointedspider]

Bender: I had a nightmare! There were 1s and 0s everywhere! I.. I....I thought I saw a 2!

[@theretrospectivegamer]

Love these episodes! I wish I could work up the courage to do some unscripted stuff but it would likely just end up with me comparing everything to Zelda and going down an obscure rabbit hole.

[@DisplacedGamers]

... kinda like this episode? Ha! (I cut so much stuff out of my rambling in this one) I say do it - if you are off-screen, then you can start a segment over as many times as you want as well as trim out sentences or paragraphs to help stay on topic without needing to worry about cutting away from your on-camera self.

[@theretrospectivegamer]

@@DisplacedGamers ha! You got enough in there to keep it interesting though! I know you started some on-camera stuff too and that would be a big step for me. It takes me long enough to edit as it is, so that would be a big stretch. Some unscripted stuff would let me get a bit more out though too. Thanks for your reply!

[@LegendBegins]

Very interesting. I'd love to see more videos like this!

[@tomsko863]

I'm liking this format alot. I can only understand a fraction of your technical mumbo-gumbo but I'm getting the gist of it. Thanks for the clear presentation.

[@bdjeffyp]

A brilliant way to showcase the difference in how the FDS and NES work within their respective limitations! Thanks for making this and pulling back the curtain a bit!

[@emmanueloverrated]

The bank switching on that screen (Zelda 2) is, I'd bet on it, caused by the tilemap filling routine not being on the same page as the Map data. It had to swap between the two pages to load the tilemap indexes as the screen scrolls. Pretty confident they couldn't afford duplicating the routine between the pages. You could explore this hypothesis by looking at the ROM.

[@infinitehush]

I love the new series, your videos always feel too short! If making them semi-unscripted means more/longer videos like these, KEEP DOING IT!

[@jopezu]

fantastic illustration of the mmc1's mapping function!

[@supersat]

This sorta feels like more of a port to the MMC1 more than anything. The FDS version managed to keep each screen within 32k of SRAM, and in fact it kinda looks like it's split between engine code and data on a ~16k boundary. Perhaps with a different mapper they could simply map in the right 32k of ROM each time?

[@DisplacedGamers]

I feel like if they had "re-ported" many of these FDS games to later mappers they could have improved performance. MMC1 helped jump the gap for getting disk games ported to cartridge, and later chips - take the MMC3 for example - added a bit more (I think I just made a pun there?) flexibility for bank switching. The MMC3 can do 8 KB bank switching. Splitting FDS code into 16 KB banks and having to swap those out can be challenging - imagine getting to do the same task but now you can break them down into 8 KB banks and swap those. You could eliminate redundancy thanks to gaining bank switch flexibility.

[@williamdrum9899]

Problem is you need a fixed bank at the "rear end" of memory, because without it the cartridge wouldn't know where to begin. When the NES/Famicom is powered on or reset, it loads the program counter (basically an internal register that keeps track of what "line" of code to run next) from the 16-bit value stored at $FFFC and then runs from there. Now you might ask why the bank still needs to be fixed even after you power on. Technically it doesn't, but the NES relies on interrupts to draw to the screen (60 times a second, whatever code is running in the main program will halt and jump to the graphics drawing code, and you can't disable that without turning off the screen.) The NES assumes that the 16 bit value at address $FFFA (the NMI line as it's often called) is correct, and would attempt do this even if that bank weren't loaded. Keeping a fixed bank is essentially "accident insurance" because the NES is a Ferrari with a cinderblock on the gas pedal and you've got to steer it away from crashing any way you can. (I'm not criticizing the design of the NES, all computers are like this at a hardware level)

[@johanmikes5604]

Genuine question here, i'm wachting technical videos on old hardware and stuff for a while and i think i could grasp 50% of all information and that i can follow every explanation of yours with some easy... (Side note i do not have any study or major in Computer science) but, one thing that for some reason i can't understand is "Why some parts of memory are mirrored?" theres any reason to mirror the internal RAM 3 times? or to mirror the PPU registers? or they are mirrored just to fill the gaps in the mapper? Really like your explanations, keep it up the good work!!!

[@davidmcgill1000]

The chips that use those address ranges aren't connected to the higher bits. This creates a repeating range of data as those chips are only responding to the lower address bits. Example for the PPU registers being that it has a chip select for the $2000 bit and is only addressed by $0001, $0002, and $0004 bits.

[@vilijar9065]

You might be interested in Retro Game Mechanics Explained channel, they have explanations some technical principles.

[@berylliosis5250]

As a side note to David's comment, it doesn't _have_ to be mirrored; there could be mapper logic that prevents it from reading that high (producing garbage results). However, that's both more expensive (need to implement the logic) and less convenient (can't use mapped regions when convenient), so it's not done.

[@davidmcgill1000]

Right. This mapper would (as a basic understanding) only need the 3 most significant bits, 3 address lines on the board, going to a decoder for handling the chip select lines for all mapped chips. 000 for RAM, 001 for PPU, 010 for the other registers, 011 for SRAM, and 100 for ROM. The board would need a lot more traces to send the remaining 13 lines to each and every chip. The RAM for instance is only wired to the lower 11 bits, leaving 2 bits unused making 4 mirrors.

[@johanmikes5604]

To david and Bery: Thanks! Now it makes a lot more sense to me. Just know that this is more of a side effect then a planned feature makes it easy to follow up on explanations. And to Vilijia: I will, i did watch some of the videos but a really need to dive more deep in it.

[@spartonberry]

What was interesting is that Nintendo's official emulation (such as Virtual Console) was designed to automatically load data from the disk as needed (such as loading screens) but with Zelda 1 FDS (such as I've heard on the Famicom Mini as well as the Zelda Game & Watch), Nintendo had to add a button input on the title screen to allow the demo to continue to roll but also be able to automatically load the game data once the player wants to start the game.

[@JB-mm5ff]

Just starting learning 6502 (been watching Shallan's vids, check them out if you want to get into this stuff) and it's crazy how being able to put what you want where in memory is convenient when there are so many unnecessary chunks all over the place.

[@williamdrum9899]

It's incredibly handy and it's something that's pretty much dead in modern programming (on modern computers, each time you run a program its memory layout is randomized to prevent hacking)

[@stevenschiro1838]

I just got sucked into Ben Eaters tutorials and builds for the 6502; really good stuff

[@JB-mm5ff]

@@stevenschiro1838 I'll check it out, thanks

[@Solidst8dad2112]

@@JB-mm5ff Check out Ben's Breadboard computer and 65c02 playlists good stuff!

[@RANCORDEV]

love this series and can't wait to see more!

[@drloko4013]

I enjoyed the more relaxed pacing of this video. I found it easier to absorb the details because they were presented more slowly than some of your other videos. For reference, I’m a technical person without any background in assembly programming. Thanks for creating this new series!

[@VinsCool]

I am here specifically for the technical details! Lol I love these videos

[@BunieLuv]

Love your videos, Subbed!

[@JoeSim8s]

Incredibly cool and interesting! Thank you!

[@atomicnoexcept]

Love these!!!!

[@dumpnchase]

Very interesting. Amazing how it works. Thanks.

[@jansenart0]

A port is a type of fortified wine, which has had its fermentation halted by artificially raising the fermenting juice's alcohol concentration by means of addition of a distilled spirit, until the mixture reaches at least 35 proof (17.5% ABV).

[@Gameboygenius]

Not to mention that in some languages, such as Swedish, rum is called rom.

[@ezg8448]

Great video! I felt the info was given in such a way it wasn't hard to get the gist of what is being said. I want to say the red colors used to represent the writing to RAM was far too light on my S21 and was too hard to make out.

[@SEGAClownboss]

Wow, I finally understand what that fabled mapper chip does, thank you.

[@E4tHam]

Fantastic explanation!

[@KeikakuLounge]

My capacity for understanding is not a factor in consuming content related to The Legend of Zelda. Thanks for the explanation. Interesting stuff, really.

[@GXSCChater]

Thank you for this video, dealing with a lot of ASM on my nes game, I now have a more understanding of mapper 30 and its 32 16kb rom banks. I also realized that jumping though banks can really take up a lot of processing power, but its the only way I can deal with running out of code space in the static bank.

[@simplyeditingtoday]

This was very educational

[@TheHylianBatman]

Man, I do not know anything about computer tech. What a cool series this is.

[@JH-pe3ro]

In discussing what a "port" is, there's a related concept that is used inside the industry, which is the SKU(shelf-keeping unit, a retailing term). In general, every SKU of a game that touches the software is going to be a new build, and therefore need "coding support". So NTSC and PAL builds of a cartridge game are two SKUs, localized releases of a game are new SKUs, and the FDS/cart releases would also be new SKUs. Depending on what changes, it could also be called a port, and the boundary of that generally revolves around whether the engine code is changing, versus data/assets. An invasive engine change like managing bank switching instead of disk loads certainly qualifies. Often in these older games with staggered launch dates, the later SKUs will incorporate bugfixes and design changes, so when examined historically, they serve as a record of the final stages of the development cycle.

[@sanderbos4243]

The visualizations are superb, for me it really makes the differences from only understanding roughly what you're saying to understanding exactly what you're saying! :)

[@possible-realities]

Nice video! Now I really want to know the strategies that the two versions use for what to read from disc, vs what to put in which bank.

[@aragorn420]

Incredible video

[@johneygd]

That’s absolutely interesting and mind blowing😁

[@notalostnumber8660]

I wish somebody would write the code in a more efficient way today, and minimize bank switching and the like, it'd be awesome to have TLOZ running with minimum lag

[@williamdrum9899]

I've only ever noticed lag at that one part of the game oddly enough.

[@MaxOakland]

This is super interesting. Will you do behind the code for the Doki Doki Panic FDS -> Mario 2 Cartridge port?

[@rafaelgadret]

Suberb video! Thank you!

[@imacommentator]

Thanks so much for useful info! I am trying to get into FDS translation and it is kind of cryptic, and there is little information on the net about FDS!

[@MariusRenn]

That is so interesting. I always thought bank switching was a rare thing, but it seems they literally just took the instructions, maybe did a little bit of grouping, and then switch to whatever bank is needed for that read. If you're lazy, you can make it seem like you have a lot of address space, at the cost of performance of course. Could definitely explain some of Zelda 2's jankiness.

[@MoustiluigiRandom]

Really damn interesting.

[@arlwiss5110]

I think the one thing I managed to learn was about load times but I still enjoyed the entire video

[@masterinsan0]

I could watch a deep dive of this level for every NES/Famicom game. I bet they all have stories to tell - for example I'd love to see you compare Castlevania III on the NES vs. Famicom, or do a delve into how they made games like Dragon Warrior/Quest IV so large given all this crazy bank switching they probably had to do.

[@fmsyntheses]

I've always been curious about the differences between the FDS and Famicom/NES. For instance, I know that the NES/Famicom version of Zelda 2 that was on cartridge has more colors but lacks certain sound effects.

[@nickwallette6201]

Based on that horror show of bank switching, it seems they were probably on a tight schedule and/or budget, and just duct-taped together the cartridge port as best they could.

[@williamdrum9899]

The FDS has support for an extra sound channel (which the NES wouldn't be able to use unless you modded it, even if you somehow hooked up an FDS to an NES) but as far as I can tell the color capabilities are no different

[@williamdrum9899]

@@nickwallette6201 Bank switching is a great tool but I have to admit it was handled very poorly in Zelda II. The drawback to it is that you have to be in the fixed bank to bank switch, otherwise the CPU would start executing who knows what (it would depend on the memory layout of the game's code, and could be managed with infinite time and patience, and nobody has either)

[@thomasmathew13]

@@williamdrum9899 that's not true at all. It was quite common to bank switch from the non fixed bank. You PHA the two address bytes to the stack to where you want to go once switched. Then you JMP to the bank switch routine. Use an RTS right after the bank switches, and it will return to the address you pushed to the stack.

[@knghtbrd]

I described above why the differences exist. When you're doing this kind of porting work, you kinda start by mechanically fixing the code-running from new locations, doing the bank switching where necessary, whatever it takes to make it run, right? And then something doesn't work (like those Z2 animations) because the nutty bank switching like mad doesn't work. You don't NEED those animations to work, so you just scrap them completely. The sounds are broken and you need those, so you redo them. (Most people think the sounds are largely interchangeable in Z1, some have a preference, and some honestly want a mix of both-I'm in that last camp!) Z2's dungeons … are all alike and need some gameplay tweaks. While you're at it and doing so much else, you do that too… Maybe you make that creepy AF Gannon laugh instead of that pissed off elephant… changes like that. Note, I haven't actually worked on FDS to cart ports, just on that kind of porting in the general sense.

[@jamesallen74]

As always excellent video. Question about the actual onboard RAM, 2K. If there's only 2K of ram on the NES board, where is the other 6k of mirrored ram stored? Or is it just 3 additional pointers/addresses back to the same 2k? So if I store value 4D in $0000, the system just returns 4D if I ask for $0000, $0800, $1000, $1800? We are not mirroring data to 3 additional physical chips of 2k ram. It's more "virtual", is that correct?

[@skipfred]

Imagine the post office only looks at the last four digits of a house number. When you address a letter to "1234 Main Street," it goes to 1234 Main Street. However, you can also send letters to "11234 Main Street," "21234 Main Street," "7651234 Main Street," etc., and they'll all go to the same address - 1234 Main Street. But there is still only one house.

[@TurboXray]

What do you use for the animation of the diagrams??

[@plgDavid]

Lovely. I kept hoping you would address the CHR-RAM logic, since a lot of data has to be read from disk or rom and uploaded to the CHR-RAM (in both case), do tile and sprite data relevant to the part of the game.

[@JawingSalamander]

I have looked at 2 bank-switching NES games so far, one is Metroid, which is mostly documented, and Athena, which is not documented anywhere I could find. And I can see the influence of the Disk System on the Metroid cart. It makes sense that a program loading from a disk would have a main game code which is loaded once, and then a piece which gets swapped out when you enter a new zone. And so, they made their porting easier by mimicking this setup in the cart. There's a specialized bank for each area like brinstar, norfair, hideout 1, etc. which gets swapped in when you move between zones. But, the main game code is > 16k, so there's a smaller redundant part of it in every bank except the gfx chars bank. But Athena is different, it's set up more like maybe an arcade game...The game code is in the upper fixed 16k plus additional code banks that get swapped in the lower 16k to run their code. And there is a bank with level data and a bank with music data as well as the gfx chars banks. There is no redundant code, but I think the number of bank switches may be higher this way.

[@DingPalado2002]

The CPU address from $4020 to $5FFF is Cartridge Expansion ROM (MMC5 chip)

[@RobertKreese]

Really interesting video! So glad I found your channel. Not that I have to know what's going on in the NES/Famicom but now I understand a bit more. Even a byte more. ;) One thing I have always thought of... As time went by, why didn't Nintendo release an expansion board with all the MMC, and other chips or even some more RAM etc. There is an expansion port under the console, and if they wanted I guess they could have added a bottom to the NES, making it far superior... Think of all the money they could have saved making cartriges, if all the chips where in that expansionboard instead. Don't know if that would have been possible and even a smart idéa though? What I love about the NES is the smoothnes of almost every game. The scrolling of the levels is almost always smooth. 50/60 fps constantly. And overall the console and it's hardware are truly amazing. No wonder it got so popular, especially with it's great games combined to this. I am still at this date being more and more impressed by this console.

[@Dark.Shingo]

Correct me if I'm wrong, but wasn't there a patch to fix the lag in Zelda II? Or am I imagining things?

[@SomeGuy712x]

I like how, while you were going in and out of level 1 in Zelda, you ended up showing the glitch that causes the first locked door to the north to become unlocked all by itself.

[@JohnSmith-qn3ob]

I saw a ROM hack that converts Zelda II’s mapper from MMC1 to MMC3. Would that speed up bank switching and prevent lag? Have you seen it or tried it?

[@DisplacedGamers]

I haven't tried it. It is certainly possible that it does. However, it could be that the person made the hack in order to let other devs start with an MMC3 Zelda project and make their own changes - like a starter set. An MMC3 conversion would alter the bankswitching logic but would not optimize bank layout. If the person that made the MMC3 conversion optimized it, then it is likely to have some degree of performance improvement.

[@kargaroc386]

From what I always understood: A port is a game moved from one system to another, and uses the same codebase. A remake is a game moved from one system to another, and uses a *different* codebase from the original - it's rewritten from scratch. It's pretty complicated though: Exceptions to both of these definitions can be found even in Mario 1 alone: Mario All Stars SMB1 uses re-made graphics and sound, but uses the *original* NES game code, re-assembled for the 65816. Meanwhile, SMB DX for the GBC uses the original NES graphics and sound, but the code was re-written from scratch for the Gameboy Z80/8080 CPU. Therefore, SMB DX for the GBC is a "remake", but Mario All Stars for the SNES is "just" a port. But, they remade the graphics for the SNES version, so calling it "just" a port sounds incomplete.

[@Possibleep]

8:47 very cool, embedding time within a frame on the screen to show 60hz changes at human speed

[@discretelogic6965]

Nice video. One addendum to the way bank switching influences performance. I have just moved from writing small, unbanked programs for the Gameboy - where MMC chips are called MBC for some reason - to banked ones using the SDCC compiler. I did some tests - on real hardware using a falsh cart and an MBC1 dev cart and a real EPROM - assuming that bank switching is a lengthy process that after switching required some pause in program execution to "get settled" into the new bank. As it turned out it does not. As soon as the memory write that switches the bank is performed, the data in the new bank is accessible instantly or at least when the next instruction is a load from banked ROM. The heavy switching activity in Link 2 on NES is an indicator that the program is doing a lot of work. Too much in fact to keep the screen update in the 1/60 second frame window, so we get lag. But the relatively few switches compared to the overall number of instructions the CPU could execute in 1/60s leads me to believe that the overhead from bank switching is marginal and not the reason for the lag but just an indicator. My educated guess for Zelda 2's lag is that is was just poorly ported from 32kb down to 16+16kb banked. If the programmer could have optimized the code to run free of lag on NES, preventing the bank switching would probably have reduced the lag far less than doing other optimizations.

[@DisplacedGamers]

I agree about the poor port to the 16+16kb banked for Zelda 2 - I want to give them the benefit of the doubt and say that perhaps the game data and code needed during gameplay required so much compromise moving from FDS that lag was inevitable, however that is SO much bank switching - and is rather inconsistent as you move across the map. It is possible that bank placement is OK, but the calls to various subroutines or just a simple loop is performing bank switching WAY more often than is actually necessary in order for the game to run.

[@rmyers99]

Me watching this video: "Oh, this topic looks pretty dry, I'm not sure I want to watch" ... (20 minutes later) "Wow, that was really cool!"

[@tonysanchez314]

Thanks!

[@DisplacedGamers]

Thank you!

[@lap456]

Most popole don't know it but that's how car and portable CD and DVD players got around some of the issues with movement. I know the buffer overflow issue is more of a thing form the pass but that's was ram inside the burner where is was worked on before the laser did it's thing. That ram was also where the data form the CD or DVD disk was held an player read it form their. That's why we had load time thing was because of that buffer. We never noticed it on audio and video disks since in that case all we doing was reading the information.

[@NEStalgia1985]

Chris tell ne you can explain hiw the cide works when it comes to utilizing the famicom Mic to kill pols voices.....please

[@FeralInferno]

Does anyone else feel like Yusuke Urameshi when Chris explains the code? 😅

[@trinidad17]

While maybe not as radical of a change as with the FDS, games that were modified to run using different mappers outside Japan also are technically ports, some featuring different graphics or using other tricks to emulate the lost functionality, with the porting difficulty depending on how much the original game relied on the original mapper.

[@ohnoitschris]

That was really interesting, thank you. Have you covered why NES' RAM is mirrored in an older episode?

[@jimmyhirr5773]

For every bit of the NES CPU memory address, there is a wire called an address line. The memory at $0000 to $1FFF uses 13 address lines. This represents 8K of address space (2 to the power of 13). A 2K RAM, however, only has 11 address lines. If address lines on the CPU aren't connected to the RAM, they are effectively ignored. The NES connects the first 11 address lines to the RAM, while the 12th and 13th lines are not connected to it. This is what creates the mirroring.

[@CarbonRollerCaco]

Damn, I didn't realize larger NES games used redundant data just as a lot of hard drive games do, and for a similar reason as well; the NES's limitation is the memory address range while a hard drive system's limitation is the amount of RAM.

[@PrinceSilvermane]

Is there a particular reason why they chose to use rapid bank switching instead of something like optimizing the code in a way so that you'd only need to switch banks when you enter an area that needs it? Would it just require too much of a rewrite since it was designed for the Disk System first?

[@FredrIQ]

Very good explanation of bankswitching. The GameBoy works in a similar way, except in reverse (with bank 0, aka the "home" bank being fixed to 0000-3fff and the rest, however many that happens to be, being placed at 4000-7fff. Also, looking at those FDS games, I'm surprised they didn't try to minimize pain for players by more dynamic loading. I always thought this was because the system couldn't run any code while it's gathering data from the disk, but judging by your Zelda example, that doesn't seem to be the case since it can choose to load only small parts at a time?

[@DisplacedGamers]

One thing about the hardware is that access is sequential instead of random. When the head reaches the end of the disk, it starts over. So if you are loading from different places on the disk, you may have to wait for the head to finish the current pass and start over before picking up the next set of (hopefully sequential) data that you need. Speed concerns and sequential disk read operations from the disk drive aside, dynamic loading throughout gameplay would add to the wear and tear of the drive. And with that said - you can write your own disk functions (and sacrifice some amount of your 32K of DRAM to run them). So I imagine it is possible to create something a bit more elaborate in terms of trying to anticipate data/code needs.

[@thomasmathew13]

Just to note that his example was just how Zelda works. With MMC1, you could also fix bank 0 to $8000-BFFF and have the switchable bank be at $C000-FFFF. Then there's also a 3rd mode where you can just swap all 32k at once, so no fixed 16k bank.

[@williamdrum9899]

@@thomasmathew13 Interesting, but I doubt many games used that last mode, as you'd basically need an identical copy of your interrupt vectors and handlers in every bank (and yes even the memory locations of each would need to be the same, something your assembler is likely to throw a fit at you for trying to do)

[@williamdrum9899]

@@DisplacedGamers I'm guessing disk reads were an IRQ generated by the BIOS by writing to ROM then?

[@toxicpsion]

@@thomasmathew13 what a circus 32k banking would be, trying to keep the jump table at $FFF[x] sorted. I tried it with a breadboarded 6502, and some PLA's once; made my head hurt, especially when you accidentally swap banks out from under your own Program Counter.

[@thedrunkmonkshow]

I know this is focused on the NES but many other systems at the time like Sega Master System/Game Gear, Sega Genesis, Gameboy, etc also used bank switching. But I have huge respect for the programmers at the time because instead of solely focusing on the game design itself, you would have to build everything from the ground up including considerations with the nuances of the hardware which had to be a frustrating nightmare. Now and days you can use a game engine or library that handles all of that low level labor for you so you can focus on the game design.

[@Epic_C]

If the 8K of SRAM is used for code, is this the reason why they added the note to hold reset before powering off? Is it possible for something in that process to actually corrupt save data somehow?

[@notalostnumber8660]

You didn't show the laggy maze with the tower of data

[@MrNickolay1986]

BTW, why do you need to mirror memory? Like, what's the point of having the same data across different memory ranges? Besides, aren't the ones at the high addresses be slower to access?

[@williamdrum9899]

So if the FDS bios resides at the upper range, does it handle NMI and IRQ rather than the programmer? I'm guessing it's like the Commodore 64 where the BIOS performs a JMP($####) to some address in RAM where you can load a pointer to your own interrupt handler. I've never done any coding for FDS (can't get the bios to boot) so I'm not familiar with what it can do

[@magicalgirlnicole]

Yes, that's absolutely right. The BIOS jumps to addresses set at the end of DRAM. There are three NMI addresses at $DFF6, $DFF8, and $DFFA that can be selected using the top two bits of $0100, a reset address at $DFFC, and an IRQ address at $DFFE.

[@williamdrum9899]

@@magicalgirlnicole I see, so you can change what you need NMI to do. Interesting. I don't think any other mappers do that (I've only ever worked with NROM, MMC1, VRC6, and NESMaker Mapper 30)