1: This one was a request, and I ended up digging into perhaps 5+ games so I could compare them. Honestly, doing a "NES Software Development and Mapper History" series with episodes centered on individual companies (Konami, Sunsoft, Namcot, etc.) might be fun to do. That said, it would take quite a bit of reversing to get notes on an entire library. 2: Obviously, I had quite a bit of speculation in addition to trying to make my case. Maybe there is lots of other unoptimized code in this game, but I was very surprised with how the mapper switch logic was assembled as well as how many switches occurred on a per frame basis. What do you think? Did I make my case, or should I have taken a different approach?
I think a mapper history series would be super fascinating! Would also be interesting to see how the challenges of dealing with the difference in audio hardware due to both the differences in chip and the NES's lack of audio pins on the cartridge port. (Not to mention how PAL games run slower and later games would account for this!) For example, to tie with Konami, I have a working theory about how they handled doing the music for later games. Super C is part of the Contra series, which seems to be more popular in the US than Japan - so it would be a waste to compose the music with fancy new audio channels the US couldn't use. Instead, compose the soundtrack using the Famicom/NES's built-in audio in mind, making heavy use of DCM samples but not using any chip audio. This would not be a challenge to release in Japan anyway. Lagrange point is an RPG, which at this point did not sell well in the US - so give it cool music that uses VRC7 chip audio and don't even bother to release is in the US. Castlevania III on the other hand, that sells well internationally and probably at around equal levels, so clearly Konami thought it was worth composing the soundtrack to make heavy use of chip audio, but then hire a second composer to do the entire soundtrack from scratch only using built-in audio for the international market. ..Of course, this is only a hypothesis :p
I was captured by it, quite sophisticated video! even on that surface level I think it's a great and useful contribution for the community :) The captions for the images at 12:05 are I think switched, because your words to it say the american version was cut. also probably someone went "we still need to optimize our game" and someone else "nah bro, nested mapper loop go brr"
I made the 'Mapper history by release date' page on the Nesdev Wiki, it's not a complete list. Surprisingly GNROM (#66) arrived in the US before any other mapper, used by Gumshoe. Then the order was: CNROM (#3), UNROM (#2), MMC1 (#1), BNROM (#34), DEROM (#206), MMC2 (#9), ANROM (#7), then finally MMC3 (#4). DEROM is almost like a cut-down version of MMC3, but it was available one year before the real MMC3. Notable games to use DEROM were Ring King, RBI Baseball, Karnov, and Gauntlet.
I knew that some companies used custom mappers, and I knew that Nintendo controlled production outside of Japan, but it never occurred to me that going through NOA's production pipeline meant that they'd have to abandon their custom mappers and it DEFINITELY never occurred to me that the custom mappers might have a different featureset than Nintendo's in-house mappers. Dang. You just solved a LOT of long standing "Why did they change this for the EN release?" mysteries.
The most notable time Nintendo allowed a custom mapper was for Batman Return of the Joker. That game really does need the 1K bankswitching window for character data. For sprites, you need Player, Projectiles/common sprites, and two enemies, and for backgrounds you need the 1K switching for all the cool tile animation. Can't do that on MMC3.
@@CptJistuce Also Namcot 109. It was used in Karnov, Ring King, Gauntlet, RBI Baseball, and a few others. It was like a cut down version of the MMC3, but it was actually available one year before the real MMC3.
I was thinking the same thing! And how many other crappy Western releases were only crappy because of Nintendo's arbitrary restrictions, rather than the fault of the devs themselves?
"Arc Hound died so Contra Force could walk. Very slowly" 💀 - Great video, DG man! Now let's hope some brave modder take the challenge to make the game run properly as should. ⭐⭐⭐⭐⭐
Good video. There is a HACK of this game called "Super Contra 6". This hack also seems to have fixed a lot of the slowdowns that the original game is most infamous and criticized for. However, the intro sequence and the ending are now somewhat corrupted. It might be interesting to analyze that HACK to check the performance improvements that have been introduced in it without changing the MMC3 mapper.
If that's the case then maybe it's easier to hack that hack back into Contra Force (changing the graphics back) rather than trying to change the mapper on the original?
When you mentioned the redundancies in the bank switching calls, I noticed that there were a couple of instances where it implied that the code was executing a bank switch to the SAME pair of banks in the same order consecutively (ie switching to 4/5 when it was ALREADY on 4/5). Clearly that's an optimization that could be taken advantage of and one that would be pretty simple to manage, aside from the fact that the code might not even realize that it's executing that pointless switch. Or rather, the programmer doesn't realize that because the code is so obtuse at compile time. As someone learning how to manage code banking on retro systems (MSX/Z80 and C64/6502) this was an extremely insightful thing to watch, even if a lot of it was "make sure you encapsulate your code properly". (Granted, in my case, a casino game probably can be done in discrete chunks-- or at least that's my working theory-- compared to the very dynamic nature of an action game, so even if a lot of this wasn't applicable to my current situation, it's still a great help.)
I'm always humbled when I can sit through one of these and understand most of what he's talking about; because even just understanding is only like 10% of the work he's doing, and it shows how talented, smart, and motivated he is. Like, think about it, this stuff isn't open source, it's decompiled, debugged, and reverse engineered. I've put less work into making a game than I think he does into a single one of these videos.
There is only one way to learn and become more familiar with these things. Too often people are averse to listening to content that they don't 100% understand. Kids don't understand what adults are talking about at first, but then they begin to contextualize what they hear and then begin to understand. That is how we learn, even if we're a little slower at it as adults. Also, don't be afraid to pause the video and do some research when you don't understand something. I'm here on the journey of learning with you friend 🤣
The fastest way to bankswitch code/data is to not do it at all. Arrange the code and data properly so you minimize the total off-page jumps and calls. You can still get a fast, interruptible, off-page jump (8K bank change) that can be interrupted, and it adds 8 instructions of overhead (jump, set bank number, set register number, variable write, register write, variable write, register write, jump), that would be about 26 cycles and 20 bytes. Off-page calls need to restore the bank number as well, so they're slower.
I remember now that similar bank switching woes account for the slowdown in Zelda II, in that case it is the conversion from the FDS to the MMC1. I have dealt with this ... sorta ... in romhacking, trying to figure out how to place additional code in which banks to avoid any bankswitching at all, if possible. As always, the video is very well structured and informative. I always enjoy these, thanks so much for making them.
Thank you. I also did a bit of speculation on Zelda II and bank switching in Talkin' Code, but I didn't actively investigate it - Just did an Event Viewer capture of Register Writes while walking on Maze Island. That's really cool that you have examined it.
@@DisplacedGamers Oh, I was going off your video on that one haha. Now I have done extensive work with Zelda 1, a similar conversion, and it bank switches a fair amount as well. That port minimizes its bank switching by copying a chunk of often-used executable code into SRAM, and it seems to run just fine on the NES. I don’t know if that borrowed that trick for Z2.
These are my FAVORITE videos that you do. I played this game (And strider) as a kid, and wondered what they hell was wrong with the game? What was it that made the first party games so good? I love these deep dives where you look in the code and unravel what happened. Thank you for posting this. These are so much fun!
Tengen of all companies, during the short time it produced licensed NES games, managed to get Nintendo to manufacture carts using a Namco mapper chip that provided MMC3-style CHR banking before MMC3 existed for developers. Gauntlet uses this, in addition to four-screen mirroring. (So does Ring King, so it wasn't just Tengen) Given that Tengen left the Nintendo licensing system pretty quickly, that probably says something about how financially feasible this was for development houses...
Licensed games as a whole was financially a rip off for the companies and put hundreds or thousands out of business due to the obscene costs involved in manufacturing games on Nintendo systems
A few months ago I played the game with the CPU overclocked, and came to your conclusion at the very end that the game still had a lot of issues. Great video. You make a very strong point.
Ideally if we could get a late version of the prototype japanese "parent game" we could confirm your reasonable hunch and potentially make an optimized version based on the correct mapper
Great explanation translating something techy into language that non-coders like myself could understand. Seeing the game run at full speed does seem to have a "TMNT-ness" to it. Great work!
I don't know a thing about programming or making video games, but your videos make everything so simple and easy to follow. You really have a gift for instruction/teaching. Keep it up!
You mentioned Tiny Toon Adventures for the NES - it'd be really fun to see a code breakdown of that comparing it to Super Mario Bros 3 since it seems to have a 1:1 reverse engineering of that game's physics.
You explain this sorcery very well for mere mortals such as myself. Thank you mr wizard of code, i appreciate the time and effort you put into every one of your videos.
Fantastic video! I've always been amazed by how different the music from Castlevania III is between its NA and JP versions, it seems porting these games to different mappers was both a feat of engineering and a true art.
My only complaint is that these episodes don't come out more frequently. I am aware that they must take a ton of time to produce. Thanks again for producing high quality content. I think your theory is very likely correct.
To be fair though, I think Contra Force is a game where the Ninja Turtles-style platforming works. You're going to be fighting at a range, and most of the jumps aren't really all that tricky, so it's not as bad as it is in Turtles. I love Contra Force for the sheer audacity of level 4. It's one of those "Only a classic game would do this" kinds of levels.
If someone wanted to take on the difficult work of making an optimized Contra Force, it wouldn't need to be as difficult as it was for Konami's greatly constrained programmers. It should be possible to create a call graph for all of the routines in the code. Dynamic analysis (playing the game) could find which routines often lead to each other and which ones don't. This would allow you to reorganize the code so that routines that often call each other are in the same bank.
Yeah. I assume there would be some sort of analysis that could be done in the modern era. Just hook into the code/emulator, play it, and gather information.
It really is like a coprocessor for the PPU. It has to know when the PPU is fetching background tiles, and when it's fetching sprites. That lets it provide a separate 8K of selection for sprites vs backgrounds. It's also needed for the 8x8 attributes mode. In the 8x8 attributes mode, it has to watch how the PPU does its repeated 4 fetch sequence, then redirect the Attribute Table fetches to its internal memory instead.
If anyone is thinking "At least we don't have to deal with this on the PC", stop. Bank switching was absolutely a thing on the PC. If you've seen the letters "EMS" in a DOS config file, that's a bank-switching system for the PC. Originally coming in the form of expansion cards following the Expanded Memory Specification, the functionality was later implemented in software in drivers such as EMM386 for later versions of DOS on systems with more memory.
Stinks that NOA refused to let developers use their own mappers and custom chips for its market. It makes for an interesting problem: which release is the "definitive" release? For example, sometimes the domestic (Japanese) release is rushed, and the overseas release delay window allows bugs to be fixed. But if those bug fixes also coincide with having to use an NOA mapper, changing the overall presentation in some way, which release would be considered the "director's cut"?
I don't why I love these videos so much. I never had a NES back in the day and only remember playing SMB 1 & 3. And double dragon. And one of the Megamans. I just watched the story of a game I've never played having shite performance and yet that half hour flew by. Great channel!
I find this sort of thing extremely interesting despite having a low understanding, so I listen to your content during work. But I also find calm and thorough explanations to be very relaxing, so sometimes I fall asleep to it at night too. Thank you for both things.
18:38 In the standard Japanese romanization "ou" is a long o, not a long u. "Jou" is pronounced like the English name "Joe", just with the O sound extended.
as someone who loves reverse-engineering, dissecting games i'm interested in, and learning about every minute difference between versions of a game, i thought this video was cooler than usual. i'd definitely be interested in a series showcasing interesting cases of Famicom -> NES ports where they had to adjust the code for different ROM mapper hardware. especially if there are mid-localization prototype roms to look at in addition to retail roms. though i get the feeling what i'm picturing would be so exhaustive as to be ungodly boring for people other than me. 😅 either way, keep up the good work! love your videos!
I love how you explain this stuff to those of us that arent super familar with it in a way that makes a ton of sense and is understandable. Your MM3 video was a joy to watch ( yes Im behind on a backlog of stuff to watch) I would love to know how the marathon in Capcoms Gold medal challenge is programmed and how it factors in energy loss
Given that we've done a couple videos talking about mappers now, I'd be very interested in seeing a full video dedicated to them. What the different mappers could do compared to nothing or each other, how you actually worked with the different mappers, etc. Some of that stuff is touched on here, such as the different bank capabilities of the Nintendo and Konami mappers, and the different code snippets that address them, a more in-depth look at that for all of the popular mappers would be very interesting.
It sure is. Konami were typically mad geniuses in getting the most out of hardware. Gradius III is the big SNES Konamoly. Contra III, on the same system, makes SNES Gradius III look like a bootleg even if it weren't already a big downgrade from the arcade GIII.
God damn it, no. The fun of the phrase "Konami Anomaly" comes from the repition of consonant and vowel sounds. It's like a vocal drum roll. Konamaly just sounds like two french films raising a kid together. Onami Anomali is the operative bits here, and you don't get that from Konamaly. No respect for the craft these days, I tell yeah.
Great video! I was sunk in for the long haul, and nice work on the design guesses. Would be great if you could get feedback from the original teams to see how close you were. Feels like your ideas were the only way it could have happened.
Thank you so much! You explaining everything so good, even I who don't have any idea how to program understanding something, at least very basics things.
DG is back with another video and it's a ripper! It not only explained the games' oversights, but I really like how you explain it while throwing in humor and analogies and then propose ideas on how to fix the game. Great video as always!
hoping that one day a prototype of arc hound floats up on the internet, if only because the potential for a quasi-official patch to be slapped together to get this game to run on the original chip would be interesting, even if it never ends up utilizing real hardware
Great video as usual!. I was checking the MSRP for Castlevania 3 in 1990 and it was priced at 44.95, so Konami pretended to save about 5.00 USD by shoehorning the game to a MMC3 mapper like Mission Imposible which was priced at 39.95, I guess Konami didn't have too much faith on the NES at the end of it's life cycle. Arc Hound should've been released in Japan and not be sacrificed as an American Exclusive just to release a broken game.
I can honestly say, I have no idea what you are talking about most of the time, but really glad you explain it as such ..and hopefully understand it little by little
We had this game on a Russian Famiclone called dendy. And due to it using pal, Contra Force actually ran a bit faster since it had more time for the cpu due to pal running at 50fps as opposed to ntsc’s 60fps
Great video! Loved the visualizations and the conspiracy theory. Also, very funny how fixing the problem via an emulator just leads to the discovery of another problem XD
I'm going to make a video topic suggestion that I don't expect to happen any time soon. Just know that one random viewer would be interested in a look through the different ways developers handled the conversion from 60fps for NTSC games to 50fps for PAL. We know that sometimes they modify speed values for movement/physics to get a close approximation. (This caused a PAL-only glitch in Super Mario Bros. that made sub-4:54 runs possible!) Sometimes, games that target a lower framerate would make up the difference by not "holding" every frame, giving the same overall speed but with a touch of jank. And some games.... did nothing, and played 17% slower on PAL. I'm sure there are also examples of games that handled audio and gameplay in different manners, just like how lag will slow the music in some games but not others. I don't know, it seems interesting to me, but maybe there's not really much to it.
I've played it on emulators that have 'overclocking' setting and it's not a bad game but at it's released speed? It's a chore. Can it be patched to run on an actual NES at a more fun speed? I'mma watch this and see what's up. :)
While I personally had never played the games in question (Contra Force, Tiny Toons) back when I originally had an NES, this was definitely an enlightening video as to the intricacies of bank-switching-related slowdown on Western releases of games!
I feel it was perfectly understandable why Nintendo wanted to have companies only release 5 games a year since the US had just seen the crash of 1983 due to over saturation. What I don't understand is why keep companies from using custom mappers outside of Japan? Consistency? I don't agree. Brand control I feel would be more along the lines of what I'd think it to be.
Thanks for the awesome explanation, giving the time the game was lauched and all you explaned, really makes sense that the game was intented for VRC6 and MMC5. So that's a game that desperatelly needs a mapper rom hack, but that whould require quite some effort.
Thanks for the information, it would be wonderful if someone decides to change the mapper of this game so I can play it on the console without the annoying slow scroll.
As a chiptune enthusiast, the possibility of this game being developed for the VRC6 really tickles my fancy. I'm already a big fan of this game's soundtrack, and I can only imagine how much greater it could have been with the enhanced audio.
I'm curious how much of a speedup we'd get just by changing to MMC5 and doing your "Step 1: Change mapper logic". For the banks that are 16k consecutive, the table lookup and switch could be replaced with a direct call to switch to those banks. The rest would require a table lookup, but I wonder if this would be enough to make the game more consistently 60 fps.
I assume at the very least that frames that barely need a second 1/60th would manage to squeeze into 1/60th. Average fps would likely increase, but there would still be instances of double frame time being required.
Awesome video on my fav YT channel. About banking CHR ROMs like in Contra (J) to animate the trees and whatnot, what if you just bankswitched every tile you had to make some sweet full-screen animations?
When using bank switching, you have a particular window size to use (ex: 1K, 4K, etc.). I suppose you could flex character RAM in order to constantly copy bytes from PRG ROM to CHR RAM, but you would be at the mercy of NMI time for pushing so many bytes while also performing your standard NMI operations.
The whole production control thing, which, it should be noted, Sega of America had also engaged in, was out of distrust that American video game developers would not get overzealous and once again release so much crap that there'd be another crash that could've killed video games for even longer if not forever. Unfortunately, Nintendo of America's implementation screwed over Konami's and Sunsoft's own mapper chips by gobbling up two pins for the legitimacy check. But Konami themselves also boo-boo'd by not biting the MMC5 bullet which was superior to their own design anyway. Oh, what could've been if games were treated as more than mere tech toys earlier in their existence…
Actually, the NES cartridge connector has more pins than the FamiCom cartridge connector. The extra pins are all unused, routing down to the underside expansion connector so a cartridge could communicate with an add-on. ... The external audio pins exist on that expansion connector. It would be trivial to have shipped an "audio board" that consisted of a connector, two traces, and a resistor. And the audio board would be cheap enough to include with every external audio game.
The problem then is how to install the "audio board". You need to break apart the plastic, and that requires a sharp object. Nintendo was paranoid about anything potentially dangerous involving children. They even recommended against using Alcohol to clean cartridges just because they thought it was too dangerous for children.
Contra Force was the only Contra game I ever got and I never knew it wasn't supposed to be slow. Also it was a bootleged late 90th version with the "glued over" chips 🤔
What I didn't know until recently is that not all Famicom cartridges were manufactured by Nintendo like they were in the West. They sometimes would release cartridges for 3rd parties but by and large the 3rd party companies manufactured their own Famicom games themselves. So, I don't understand why Nintendo and really most console companies position themselves to be the sole manufacturers for games in the first place other than for leverage or control. If the 3rd parties are responsible for designing, testing, and manufacturing the carts themselves, but you still make a cut due to it being on your hardware, isn't that way less of a financial risk both in short term and the long term? Then the other question is, since their insisting be the sole manufacturer of overseas games, would it really have impacted anything logistically if Nintendo bought the mappers from the 3rd party developers and incorporate it as extra parts to their cartridge assembly line? Imagine if you're Konami for a sec like, you're going to force me to waste time and money redesigning a fully functioning and working game so it can operate with your inferior mapper? Nintendo was something else back then man.
the oft-cited reason for their initial decision to strictly regulate their game lineup in NA was because of the "video game crash," a glut of cheap and sometimes unplayable game software and unsold Atari and Colecovision etc consoles. By '84 or so consumers were kind of "over" the videogame craze and Nintendo considered it very important (and perhaps rightfully so) to win back their confidence with a "Seal of Quality"
I suspect that one reason is because of manufacturing costs. Manufacturing has significant economies of scale: unit costs go down as the number of units produced for an order goes up. Forcing third party developers to use Nintendo's mappers (and cartridge shells, circuit boards, etc) reduces the unit cost of cartridges for everyone. I bet it also allowed Nintendo to charge a hefty markup to its third parties because they had a monopoly on those mappers. Nintendo wasn't the only company to do this; Sega insisted that their third parties use Sega-produced cartridges and pay a $10-15 per-cartridge license fee for the Genesis. You can imagine what the third-party developers thought of this. Accolade and EA even produced unlicensed cartridges for the Genesis. In Accolade's case it led to Sega v Accolade. There's a fascinating history there that you would probably enjoy if you like Displaced Gamers.
@@slMagnvoxThe video game crash was due in large part to retailer expectations. (Good games sold well, bad games warmed shelves. Retailers just saw a lot of video games didn't sell in a market they assumed was a fad from the start, and declared the fad over.) That said, there was also a major economic recession that popped off in the US, so people suddenly had far less disposable income for video games. Consumers weren't "over" video games, they just couldn't buy them because they were broke and stores got out of the business fast.
A strange thing that occurred to me - by this time in the NES' llifecycle, Batman: Return of the Joker would have released. This is significant as the game featured the Sunsoft FME-7 outside of Japan, as Nintendo had relaxed some of their restrictions on manufacturing to the point where custom mappers were seemingly allowed. That being said, it makes you wonder why Konami would switch from their own propriety tech to the MMC3 (if this was indeed a fact of Arc Hound/Contra Force's dev cycle). Maybe it was still cheaper to have Nintendo handle the mapper than use their own...?
As a kid and later as retro gamer I many times was wonder why it's lagging so much? Giant sprites, box physics, or maybe to much destroyable objects? This game also have bug where you can just hold jump while unpause game and jump from thin air.
1: This one was a request, and I ended up digging into perhaps 5+ games so I could compare them. Honestly, doing a "NES Software Development and Mapper History" series with episodes centered on individual companies (Konami, Sunsoft, Namcot, etc.) might be fun to do. That said, it would take quite a bit of reversing to get notes on an entire library.
2: Obviously, I had quite a bit of speculation in addition to trying to make my case. Maybe there is lots of other unoptimized code in this game, but I was very surprised with how the mapper switch logic was assembled as well as how many switches occurred on a per frame basis.
What do you think? Did I make my case, or should I have taken a different approach?
I think a mapper history series would be super fascinating! Would also be interesting to see how the challenges of dealing with the difference in audio hardware due to both the differences in chip and the NES's lack of audio pins on the cartridge port. (Not to mention how PAL games run slower and later games would account for this!)
For example, to tie with Konami, I have a working theory about how they handled doing the music for later games.
Super C is part of the Contra series, which seems to be more popular in the US than Japan - so it would be a waste to compose the music with fancy new audio channels the US couldn't use. Instead, compose the soundtrack using the Famicom/NES's built-in audio in mind, making heavy use of DCM samples but not using any chip audio. This would not be a challenge to release in Japan anyway.
Lagrange point is an RPG, which at this point did not sell well in the US - so give it cool music that uses VRC7 chip audio and don't even bother to release is in the US.
Castlevania III on the other hand, that sells well internationally and probably at around equal levels, so clearly Konami thought it was worth composing the soundtrack to make heavy use of chip audio, but then hire a second composer to do the entire soundtrack from scratch only using built-in audio for the international market.
..Of course, this is only a hypothesis :p
I was captured by it, quite sophisticated video! even on that surface level I think it's a great and useful contribution for the community :)
The captions for the images at 12:05 are I think switched, because your words to it say the american version was cut.
also probably someone went "we still need to optimize our game" and someone else "nah bro, nested mapper loop go brr"
OK.... so, where is that 400% speed up button on my N8 Everdrive Pro? 🤔😜
I made the 'Mapper history by release date' page on the Nesdev Wiki, it's not a complete list. Surprisingly GNROM (#66) arrived in the US before any other mapper, used by Gumshoe. Then the order was: CNROM (#3), UNROM (#2), MMC1 (#1), BNROM (#34), DEROM (#206), MMC2 (#9), ANROM (#7), then finally MMC3 (#4). DEROM is almost like a cut-down version of MMC3, but it was available one year before the real MMC3. Notable games to use DEROM were Ring King, RBI Baseball, Karnov, and Gauntlet.
it was great, I think some speculation is 100% ok when the speculator is experienced and knowledgeable and can make a solid case for it
I knew that some companies used custom mappers, and I knew that Nintendo controlled production outside of Japan, but it never occurred to me that going through NOA's production pipeline meant that they'd have to abandon their custom mappers and it DEFINITELY never occurred to me that the custom mappers might have a different featureset than Nintendo's in-house mappers. Dang. You just solved a LOT of long standing "Why did they change this for the EN release?" mysteries.
The most notable time Nintendo allowed a custom mapper was for Batman Return of the Joker. That game really does need the 1K bankswitching window for character data. For sprites, you need Player, Projectiles/common sprites, and two enemies, and for backgrounds you need the 1K switching for all the cool tile animation. Can't do that on MMC3.
@@DweditIf I'm not mistaken, the FME-7 is the only third-party mapper ever allowed by Nintendo America.
@@CptJistuce Also Namcot 109. It was used in Karnov, Ring King, Gauntlet, RBI Baseball, and a few others. It was like a cut down version of the MMC3, but it was actually available one year before the real MMC3.
@@Dwedit I stand corrected!
I was thinking the same thing! And how many other crappy Western releases were only crappy because of Nintendo's arbitrary restrictions, rather than the fault of the devs themselves?
Whenever anybody says "remastering an old game shouldn't be _too_ hard to do", I'm going to give them the link to this video.
Ha!
"Arc Hound died so Contra Force could walk. Very slowly" 💀 - Great video, DG man! Now let's hope some brave modder take the challenge to make the game run properly as should. ⭐⭐⭐⭐⭐
Good video. There is a HACK of this game called "Super Contra 6". This hack also seems to have fixed a lot of the slowdowns that the original game is most infamous and criticized for. However, the intro sequence and the ending are now somewhat corrupted. It might be interesting to analyze that HACK to check the performance improvements that have been introduced in it without changing the MMC3 mapper.
Oh that's good to know. Wow.
If that's the case then maybe it's easier to hack that hack back into Contra Force (changing the graphics back) rather than trying to change the mapper on the original?
When you mentioned the redundancies in the bank switching calls, I noticed that there were a couple of instances where it implied that the code was executing a bank switch to the SAME pair of banks in the same order consecutively (ie switching to 4/5 when it was ALREADY on 4/5). Clearly that's an optimization that could be taken advantage of and one that would be pretty simple to manage, aside from the fact that the code might not even realize that it's executing that pointless switch. Or rather, the programmer doesn't realize that because the code is so obtuse at compile time. As someone learning how to manage code banking on retro systems (MSX/Z80 and C64/6502) this was an extremely insightful thing to watch, even if a lot of it was "make sure you encapsulate your code properly". (Granted, in my case, a casino game probably can be done in discrete chunks-- or at least that's my working theory-- compared to the very dynamic nature of an action game, so even if a lot of this wasn't applicable to my current situation, it's still a great help.)
I won't pretend to 100% understand everything you discuss in these videos, but I always look forward to them.
You can tell he enjoys what he's talking about and that's one of the reasons I watch these videos even if I don't understand all of them.
I'm always humbled when I can sit through one of these and understand most of what he's talking about; because even just understanding is only like 10% of the work he's doing, and it shows how talented, smart, and motivated he is. Like, think about it, this stuff isn't open source, it's decompiled, debugged, and reverse engineered. I've put less work into making a game than I think he does into a single one of these videos.
There is only one way to learn and become more familiar with these things.
Too often people are averse to listening to content that they don't 100% understand.
Kids don't understand what adults are talking about at first, but then they begin to contextualize what they hear and then begin to understand. That is how we learn, even if we're a little slower at it as adults.
Also, don't be afraid to pause the video and do some research when you don't understand something.
I'm here on the journey of learning with you friend 🤣
Yup, same here. I can kind of follow along, and also every new video is an event.
There's nothing too complex in this video. Really not much to not understand
The fastest way to bankswitch code/data is to not do it at all. Arrange the code and data properly so you minimize the total off-page jumps and calls. You can still get a fast, interruptible, off-page jump (8K bank change) that can be interrupted, and it adds 8 instructions of overhead (jump, set bank number, set register number, variable write, register write, variable write, register write, jump), that would be about 26 cycles and 20 bytes. Off-page calls need to restore the bank number as well, so they're slower.
Love every comment you write, Dwedit. I always appreciate your added insight and detailed responses.
Best way to avoid the problem is to never make a problem to begin with.
I remember now that similar bank switching woes account for the slowdown in Zelda II, in that case it is the conversion from the FDS to the MMC1. I have dealt with this ... sorta ... in romhacking, trying to figure out how to place additional code in which banks to avoid any bankswitching at all, if possible.
As always, the video is very well structured and informative. I always enjoy these, thanks so much for making them.
Thank you.
I also did a bit of speculation on Zelda II and bank switching in Talkin' Code, but I didn't actively investigate it - Just did an Event Viewer capture of Register Writes while walking on Maze Island.
That's really cool that you have examined it.
@@DisplacedGamers Oh, I was going off your video on that one haha. Now I have done extensive work with Zelda 1, a similar conversion, and it bank switches a fair amount as well. That port minimizes its bank switching by copying a chunk of often-used executable code into SRAM, and it seems to run just fine on the NES. I don’t know if that borrowed that trick for Z2.
These are my FAVORITE videos that you do. I played this game (And strider) as a kid, and wondered what they hell was wrong with the game? What was it that made the first party games so good?
I love these deep dives where you look in the code and unravel what happened. Thank you for posting this. These are so much fun!
Thank you!
Tengen of all companies, during the short time it produced licensed NES games, managed to get Nintendo to manufacture carts using a Namco mapper chip that provided MMC3-style CHR banking before MMC3 existed for developers. Gauntlet uses this, in addition to four-screen mirroring. (So does Ring King, so it wasn't just Tengen)
Given that Tengen left the Nintendo licensing system pretty quickly, that probably says something about how financially feasible this was for development houses...
Tengen's licensed games used the Namcot 109. Their unlicensed games used a clone chip called MIMIC-1.
Licensed games as a whole was financially a rip off for the companies and put hundreds or thousands out of business due to the obscene costs involved in manufacturing games on Nintendo systems
A few months ago I played the game with the CPU overclocked, and came to your conclusion at the very end that the game still had a lot of issues.
Great video. You make a very strong point.
Ideally if we could get a late version of the prototype japanese "parent game" we could confirm your reasonable hunch and potentially make an optimized version based on the correct mapper
Indeed. I wonder if it is out there somewhere.
Great explanation translating something techy into language that non-coders like myself could understand. Seeing the game run at full speed does seem to have a "TMNT-ness" to it. Great work!
I don't know a thing about programming or making video games, but your videos make everything so simple and easy to follow. You really have a gift for instruction/teaching.
Keep it up!
Thank you!
We need a game genie code to add 400 lines of NMI to real hardware
lol
You mentioned Tiny Toon Adventures for the NES - it'd be really fun to see a code breakdown of that comparing it to Super Mario Bros 3 since it seems to have a 1:1 reverse engineering of that game's physics.
You explain this sorcery very well for mere mortals such as myself. Thank you mr wizard of code, i appreciate the time and effort you put into every one of your videos.
Thank you!
Fantastic video! I've always been amazed by how different the music from Castlevania III is between its NA and JP versions, it seems porting these games to different mappers was both a feat of engineering and a true art.
In Japan, the MMC5 even added to extra audio channels to the Famicom, but these features were not available to NES developers.
The Chariots of Fire comparison got a genuine laugh from me 😄
I love this channel. I am not a programmer. I use Python once month at best. But I find it so fascinating to see these deep dives.
Thank you!
My only complaint is that these episodes don't come out more frequently. I am aware that they must take a ton of time to produce. Thanks again for producing high quality content. I think your theory is very likely correct.
Thank you!
To be fair though, I think Contra Force is a game where the Ninja Turtles-style platforming works. You're going to be fighting at a range, and most of the jumps aren't really all that tricky, so it's not as bad as it is in Turtles.
I love Contra Force for the sheer audacity of level 4. It's one of those "Only a classic game would do this" kinds of levels.
If someone wanted to take on the difficult work of making an optimized Contra Force, it wouldn't need to be as difficult as it was for Konami's greatly constrained programmers. It should be possible to create a call graph for all of the routines in the code. Dynamic analysis (playing the game) could find which routines often lead to each other and which ones don't. This would allow you to reorganize the code so that routines that often call each other are in the same bank.
Yeah. I assume there would be some sort of analysis that could be done in the modern era. Just hook into the code/emulator, play it, and gather information.
Loved it! I like how you get so much material selected and basically build a path to realizing one or more of these bug fix/patch projects.
18:43 "...the MMC5 has a salad bar's worth of modes available..."
MMC5 was (is?) a real powerhouse! Some says a true coprocessor even.
It really is like a coprocessor for the PPU. It has to know when the PPU is fetching background tiles, and when it's fetching sprites. That lets it provide a separate 8K of selection for sprites vs backgrounds. It's also needed for the 8x8 attributes mode. In the 8x8 attributes mode, it has to watch how the PPU does its repeated 4 fetch sequence, then redirect the Attribute Table fetches to its internal memory instead.
If anyone is thinking "At least we don't have to deal with this on the PC", stop. Bank switching was absolutely a thing on the PC. If you've seen the letters "EMS" in a DOS config file, that's a bank-switching system for the PC. Originally coming in the form of expansion cards following the Expanded Memory Specification, the functionality was later implemented in software in drivers such as EMM386 for later versions of DOS on systems with more memory.
This is one of my favourite channels all around here! Content is and has always been spot on. Keep up!! 🧡
Stinks that NOA refused to let developers use their own mappers and custom chips for its market. It makes for an interesting problem: which release is the "definitive" release? For example, sometimes the domestic (Japanese) release is rushed, and the overseas release delay window allows bugs to be fixed. But if those bug fixes also coincide with having to use an NOA mapper, changing the overall presentation in some way, which release would be considered the "director's cut"?
Maybe you want the Japanese Contra's animations, but you also want the international Contra's rock graphics! Or the robots.
@@BagOfMagicFood No one wants the robots. Let the silly european version stay dead.
@@CptJistuce A lot of people who grew up with the robot version have an attachment to them.
@@todesziege That's fair. I was being unfairly dismissive of Probotector.
I don't why I love these videos so much. I never had a NES back in the day and only remember playing SMB 1 & 3. And double dragon. And one of the Megamans.
I just watched the story of a game I've never played having shite performance and yet that half hour flew by.
Great channel!
"At what point in the development process would a programmer give birth to this monstrosity?"
So many amazing phrases in this one. Great video too!
I find this sort of thing extremely interesting despite having a low understanding, so I listen to your content during work. But I also find calm and thorough explanations to be very relaxing, so sometimes I fall asleep to it at night too. Thank you for both things.
Awesome job! It was interesting to hear about the work of mappers and banks. I finally found out why one of my favorite childhood games was lagging.
2:52 "non-NMI interrupt" ...so, a non-Non-Maskable Interrupt interrupt?
Y---yeah.
(kinda sad I didn't put it that way...)
I like where you're going with this -- just rolls off the tongue.
18:38 In the standard Japanese romanization "ou" is a long o, not a long u. "Jou" is pronounced like the English name "Joe", just with the O sound extended.
Introducing Akuma Gouki's western cousin: Akuma Joe
(You are correct. 'Akuma Joe' just struck me as funny.)
Akumajō for all you diacritics aficionados and -nadas.
Very thorough breakdown and comparison! Great work!
as someone who loves reverse-engineering, dissecting games i'm interested in, and learning about every minute difference between versions of a game, i thought this video was cooler than usual.
i'd definitely be interested in a series showcasing interesting cases of Famicom -> NES ports where they had to adjust the code for different ROM mapper hardware. especially if there are mid-localization prototype roms to look at in addition to retail roms. though i get the feeling what i'm picturing would be so exhaustive as to be ungodly boring for people other than me. 😅
either way, keep up the good work! love your videos!
Deliciously detailed and explained video, as always.
I always look forward to your rare videos, they are of good dives and quality. Keep it up!
Thank you!
I love how you explain this stuff to those of us that arent super familar with it in a way that makes a ton of sense and is understandable. Your MM3 video was a joy to watch ( yes Im behind on a backlog of stuff to watch) I would love to know how the marathon in Capcoms Gold medal challenge is programmed and how it factors in energy loss
Today I learned about the Performance Graph! That's awesome
Given that we've done a couple videos talking about mappers now, I'd be very interested in seeing a full video dedicated to them. What the different mappers could do compared to nothing or each other, how you actually worked with the different mappers, etc. Some of that stuff is touched on here, such as the different bank capabilities of the Nintendo and Konami mappers, and the different code snippets that address them, a more in-depth look at that for all of the popular mappers would be very interesting.
Sweet, I was always hoping you would do a tech dive on this game!
Your explanation of nmi using the pink overlay is genius!
Konamoly
“Translate to English” 😂
We were all thinking it he just said it
It sure is. Konami were typically mad geniuses in getting the most out of hardware. Gradius III is the big SNES Konamoly. Contra III, on the same system, makes SNES Gradius III look like a bootleg even if it weren't already a big downgrade from the arcade GIII.
@@CarbonRollerCaco Gradius 3 has a lot more going on screen at anytime than Contra 3
This is a fascinating breakdown! Please keep doing these deep dives.
I immediately suspected bankswitching would be the bottleneck, I love your videos man!
“Call it a Konami Anomaly”
“Konamaly” was RIGHT THERE
THISSSSSSSSS OMG!!!!
My brain automatically smushed Konami and anomaly together when he said it. I took mental damage when he didn't do the same.
I literally stopped the video just now to come find this comment.
@@tonysanchez314 same
God damn it, no. The fun of the phrase "Konami Anomaly" comes from the repition of consonant and vowel sounds. It's like a vocal drum roll. Konamaly just sounds like two french films raising a kid together. Onami Anomali is the operative bits here, and you don't get that from Konamaly. No respect for the craft these days, I tell yeah.
a day with a DG upload is always a good day.
Yes!
I always wanted to tell you how great these videos are, but i would always arrive a year too late, so, thank you!
First! Thanks for solving this mystery from my childhood
Haha, i was so sure you were going to pull a "so i rewrote the bank switching code to use the vrc6 mapper" at the end there
Me: "Maybe I should rewrite the....!!"
Also Me: "...Maybe I should finish the video."
CPU usage and fps display for NES, what a time to be alive…
I was going to ask you to review this game and then I came across this video. Thank you.
Great video! I was sunk in for the long haul, and nice work on the design guesses. Would be great if you could get feedback from the original teams to see how close you were. Feels like your ideas were the only way it could have happened.
Thank you so much! You explaining everything so good, even I who don't have any idea how to program understanding something, at least very basics things.
Incredible research as always. Keep it up
DG is back with another video and it's a ripper! It not only explained the games' oversights, but I really like how you explain it while throwing in humor and analogies and then propose ideas on how to fix the game. Great video as always!
Very interesting stuff! I would also love to see a video that explains how the entities are defined in SMB1 and how their update routines work
hoping that one day a prototype of arc hound floats up on the internet, if only because the potential for a quasi-official patch to be slapped together to get this game to run on the original chip would be interesting, even if it never ends up utilizing real hardware
Great video as usual!. I was checking the MSRP for Castlevania 3 in 1990 and it was priced at 44.95, so Konami pretended to save about 5.00 USD by shoehorning the game to a MMC3 mapper like Mission Imposible which was priced at 39.95, I guess Konami didn't have too much faith on the NES at the end of it's life cycle. Arc Hound should've been released in Japan and not be sacrificed as an American Exclusive just to release a broken game.
As a fan of Contra especially around that era as a kid, somehow I didn't even know this game existed. I can see why.
I can honestly say, I have no idea what you are talking about most of the time, but really glad you explain it as such ..and hopefully understand it little by little
OMG this is so fantastic. You really made this sing.
We had this game on a Russian Famiclone called dendy. And due to it using pal, Contra Force actually ran a bit faster since it had more time for the cpu due to pal running at 50fps as opposed to ntsc’s 60fps
Great video! Loved the visualizations and the conspiracy theory.
Also, very funny how fixing the problem via an emulator just leads to the discovery of another problem XD
I'm going to make a video topic suggestion that I don't expect to happen any time soon. Just know that one random viewer would be interested in a look through the different ways developers handled the conversion from 60fps for NTSC games to 50fps for PAL.
We know that sometimes they modify speed values for movement/physics to get a close approximation. (This caused a PAL-only glitch in Super Mario Bros. that made sub-4:54 runs possible!) Sometimes, games that target a lower framerate would make up the difference by not "holding" every frame, giving the same overall speed but with a touch of jank. And some games.... did nothing, and played 17% slower on PAL. I'm sure there are also examples of games that handled audio and gameplay in different manners, just like how lag will slow the music in some games but not others.
I don't know, it seems interesting to me, but maybe there's not really much to it.
So close to 100k! You deserve every subscription and more
I've played it on emulators that have 'overclocking' setting and it's not a bad game but at it's released speed? It's a chore. Can it be patched to run on an actual NES at a more fun speed? I'mma watch this and see what's up. :)
Can it be patched? He just answered that in the final bit. Yes, but it would take a nontrivial amount of work to do.
While I personally had never played the games in question (Contra Force, Tiny Toons) back when I originally had an NES, this was definitely an enlightening video as to the intricacies of bank-switching-related slowdown on Western releases of games!
I feel it was perfectly understandable why Nintendo wanted to have companies only release 5 games a year since the US had just seen the crash of 1983 due to over saturation. What I don't understand is why keep companies from using custom mappers outside of Japan? Consistency? I don't agree.
Brand control I feel would be more along the lines of what I'd think it to be.
Lets gooo new DG Game
This was the most I’ve ever learned about MMC chips. Love it! 😊
Thanks for the awesome explanation, giving the time the game was lauched and all you explaned, really makes sense that the game was intented for VRC6 and MMC5. So that's a game that desperatelly needs a mapper rom hack, but that whould require quite some effort.
Thanks for the information, it would be wonderful if someone decides to change the mapper of this game so I can play it on the console without the annoying slow scroll.
Thanks for another deep dive! I never knew that Nintendo didn't allow custom mappers for American releases, but that explains so much.
God, I love these videos. Amazing!
As a chiptune enthusiast, the possibility of this game being developed for the VRC6 really tickles my fancy. I'm already a big fan of this game's soundtrack, and I can only imagine how much greater it could have been with the enhanced audio.
I'm curious how much of a speedup we'd get just by changing to MMC5 and doing your "Step 1: Change mapper logic". For the banks that are 16k consecutive, the table lookup and switch could be replaced with a direct call to switch to those banks. The rest would require a table lookup, but I wonder if this would be enough to make the game more consistently 60 fps.
I assume at the very least that frames that barely need a second 1/60th would manage to squeeze into 1/60th. Average fps would likely increase, but there would still be instances of double frame time being required.
You can change the region to PAL or Dendy to simulate having a little extra CPU time. The game still runs slowly.
Great video.
I did not understand much of it, but great video!
Ha! Thanks for watching.
Konamaly was right there! :D love your content as always
Awesome video on my fav YT channel. About banking CHR ROMs like in Contra (J) to animate the trees and whatnot, what if you just bankswitched every tile you had to make some sweet full-screen animations?
When using bank switching, you have a particular window size to use (ex: 1K, 4K, etc.). I suppose you could flex character RAM in order to constantly copy bytes from PRG ROM to CHR RAM, but you would be at the mercy of NMI time for pushing so many bytes while also performing your standard NMI operations.
Willow animates a whole lot of tiles at once by bankswitching the entire 4K character page. It has to, because that's the CHR bank size for MMC1.
As depressing as the world and its subset of modern gaming is, videos and mindsets like this give me hope. Awesome video and thanks. :)
man you so close to 100k subs!
Incredible work.
Slowdown akin to watching Chariots of Fire, huh? 😂 I love the ‘80s film reference when discussing a 1980s era game. Fantastic scenes, too!
Really facinating!
I loved this video. Thank you!
Always look forward to these.
The whole production control thing, which, it should be noted, Sega of America had also engaged in, was out of distrust that American video game developers would not get overzealous and once again release so much crap that there'd be another crash that could've killed video games for even longer if not forever. Unfortunately, Nintendo of America's implementation screwed over Konami's and Sunsoft's own mapper chips by gobbling up two pins for the legitimacy check. But Konami themselves also boo-boo'd by not biting the MMC5 bullet which was superior to their own design anyway. Oh, what could've been if games were treated as more than mere tech toys earlier in their existence…
I think you forgot to explain what those pins used to do. They were used to allow carts to provide custom audio hardware.
Actually, the NES cartridge connector has more pins than the FamiCom cartridge connector.
The extra pins are all unused, routing down to the underside expansion connector so a cartridge could communicate with an add-on.
...
The external audio pins exist on that expansion connector. It would be trivial to have shipped an "audio board" that consisted of a connector, two traces, and a resistor. And the audio board would be cheap enough to include with every external audio game.
The problem then is how to install the "audio board". You need to break apart the plastic, and that requires a sharp object. Nintendo was paranoid about anything potentially dangerous involving children. They even recommended against using Alcohol to clean cartridges just because they thought it was too dangerous for children.
Glad to see you again!!🎉🎉
So THATS why some japanese games were more advanced! Nintendo forced them to use Nintendo-brand mappers. That seems.... extremely short sighted.
Contra Force was the only Contra game I ever got and I never knew it wasn't supposed to be slow. Also it was a bootleged late 90th version with the "glued over" chips 🤔
What I didn't know until recently is that not all Famicom cartridges were manufactured by Nintendo like they were in the West. They sometimes would release cartridges for 3rd parties but by and large the 3rd party companies manufactured their own Famicom games themselves. So, I don't understand why Nintendo and really most console companies position themselves to be the sole manufacturers for games in the first place other than for leverage or control. If the 3rd parties are responsible for designing, testing, and manufacturing the carts themselves, but you still make a cut due to it being on your hardware, isn't that way less of a financial risk both in short term and the long term? Then the other question is, since their insisting be the sole manufacturer of overseas games, would it really have impacted anything logistically if Nintendo bought the mappers from the 3rd party developers and incorporate it as extra parts to their cartridge assembly line? Imagine if you're Konami for a sec like, you're going to force me to waste time and money redesigning a fully functioning and working game so it can operate with your inferior mapper? Nintendo was something else back then man.
the oft-cited reason for their initial decision to strictly regulate their game lineup in NA was because of the "video game crash," a glut of cheap and sometimes unplayable game software and unsold Atari and Colecovision etc consoles. By '84 or so consumers were kind of "over" the videogame craze and Nintendo considered it very important (and perhaps rightfully so) to win back their confidence with a "Seal of Quality"
I suspect that one reason is because of manufacturing costs. Manufacturing has significant economies of scale: unit costs go down as the number of units produced for an order goes up. Forcing third party developers to use Nintendo's mappers (and cartridge shells, circuit boards, etc) reduces the unit cost of cartridges for everyone. I bet it also allowed Nintendo to charge a hefty markup to its third parties because they had a monopoly on those mappers.
Nintendo wasn't the only company to do this; Sega insisted that their third parties use Sega-produced cartridges and pay a $10-15 per-cartridge license fee for the Genesis. You can imagine what the third-party developers thought of this. Accolade and EA even produced unlicensed cartridges for the Genesis. In Accolade's case it led to Sega v Accolade. There's a fascinating history there that you would probably enjoy if you like Displaced Gamers.
@@slMagnvox Notably, the 1983 video game crash WAS mostly confined to the North American market.
@@slMagnvoxThe video game crash was due in large part to retailer expectations. (Good games sold well, bad games warmed shelves. Retailers just saw a lot of video games didn't sell in a market they assumed was a fad from the start, and declared the fad over.)
That said, there was also a major economic recession that popped off in the US, so people suddenly had far less disposable income for video games.
Consumers weren't "over" video games, they just couldn't buy them because they were broke and stores got out of the business fast.
@@jimmyhirr5773 Liked just for the punchline at the end. 😄
I can just hear his voice delivering that line.
9:30 In North America that is. In PAL regions they used the Konami label plus Palcom.
A strange thing that occurred to me - by this time in the NES' llifecycle, Batman: Return of the Joker would have released. This is significant as the game featured the Sunsoft FME-7 outside of Japan, as Nintendo had relaxed some of their restrictions on manufacturing to the point where custom mappers were seemingly allowed. That being said, it makes you wonder why Konami would switch from their own propriety tech to the MMC3 (if this was indeed a fact of Arc Hound/Contra Force's dev cycle). Maybe it was still cheaper to have Nintendo handle the mapper than use their own...?
"And then you notice the ninja turtles like physics..."
This smells like another video 😂
Maybe after my Contra Force nightmares stop.
*YOU ARE A FCUKING LEGEND* FOR MAKING THIS EPISODE!! Thank you for sorting out a huge part of my childhood nightmares (with this game) ❤
@@mwk1 😄 Hahaha! Your comment brings a smile to my face, esp the sly use of the f-bomb, circumventing the censor algorithm.
Huh, always wondered why this specific game was so laggy, guess now I have my answer, thanks!
As a kid and later as retro gamer I many times was wonder why it's lagging so much? Giant sprites, box physics, or maybe to much destroyable objects?
This game also have bug where you can just hold jump while unpause game and jump from thin air.