MMC5 Fill-Mode Bug: Extended Attributes Not Working

Hey guys, let's dive into a pretty interesting bug in the MMC5 mapper, specifically how it handles fill-mode attributes when you've enabled extended attribute mode. This is something that affects how the NES displays colors in certain areas of the screen. Essentially, the bug causes the system to ignore the extended attribute mode when it should be using it, leading to incorrect colors in fill-mode nametables. We'll break down what's happening, the impact, and how we can fix it. It's a bit technical, but bear with me; we'll keep it easy to understand!

The Core Issue: Ignoring Extended Attributes

So, what's the deal? Well, in the MMC5, there's a setting ($5104) that lets you switch to an extended attribute mode. When this mode is active, the game is supposed to pull attribute data (the color information for 8x8 pixel blocks) from a special area called ExRAM. This is super useful because it allows for more colors and more complex visuals. Now, there's another setting, $5107, which is used to define the fill-mode color. However, when we're in extended attribute mode, this $5107 setting should be ignored. The system should be pulling the color information from the ExRAM, but unfortunately, it's not. The current implementation in the code does not correctly handle this situation. The system is still using $5107 to get the fill-mode attributes, even when it should be using the extended attribute mode and pulling the attributes from ExRAM. This means the colors in these areas are wrong, and your game will not display the intended visuals.

Basically, imagine trying to order a pizza but the delivery guy keeps referencing an old menu. When you're in the extended attribute mode, the game should be using the new, better 'ExRAM menu' (with more color options) but it's stuck on the old $5107 menu. The result? You're not getting what you ordered! When the system is in extended attribute mode, it's supposed to use ExRAM. The code currently reads the fill-mode attributes from the wrong place ($5107), causing a display issue. We're talking about a bug that specifically impacts the way the system renders fill-mode attribute data when extended attributes are enabled.

Deep Dive: Where the Problem Lies

Let's get a bit more technical. The issue is pinpointed in the src/cartridge/mmc5.rs file. Specifically, the read_nametable function. This function is responsible for fetching the attribute data for the nametables, which define the layout of the game's visuals. The function reads the fill-mode attributes from $5107 before checking whether extended attribute mode is enabled. This is the root cause. This means that, regardless of what mode is selected, the system is first checking $5107 for color information and if extended attributes are not working, the game uses the default settings, rather than what is defined in the extended attributes. The code should first check the extended attribute mode (controlled by $5104) and then decide where to fetch the attribute data. If extended attribute mode is on, it should grab the data from ExRAM. If it's off, then it should check $5107. The existing code flow does this in the wrong order, causing the bug. Think of it like this: the code is asking for pizza toppings before it even checks if you want to order a pizza with extra cheese (extended attributes).

The NESdev wiki also confirms this behavior. According to the MMC5 documentation, when $5104 is set to mode %01 (extended attributes), the system should use ExRAM for attribute fetches, even for fill-mode nametables, and $5107 should be ignored. The issue highlights a misalignment between the documented behavior of the MMC5 and the actual implementation in the emulator. The current code is not adhering to the documented specifications. This causes incorrect color data to be loaded, which will cause visual issues in-game.

The Impact: What You'll See

So, what's the real-world impact of this bug? Basically, the fill-mode attribute data will be incorrect when extended attributes are enabled. This means that areas of the screen using fill-mode will display the wrong colors. The effect might range from minor color glitches to major visual errors, depending on how the game uses fill-mode and extended attributes. If a game relies heavily on fill-mode and extended attributes for visual effects, the impact could be significant, causing tiles to have the wrong colors, which would ruin the immersion or even make the game unplayable. If a game is trying to use a specific color palette in these areas, the incorrect attribute data would corrupt the intended look. This could lead to a variety of visual problems, such as incorrect shading, inaccurate color mixing, and generally a less polished, less appealing final product. The user's experience will be affected. The end result is a less visually pleasing experience than what was intended by the game developers.

This highlights the importance of accurate emulation. Emulators should try to match the original hardware behavior as closely as possible. When bugs like this are present, they can compromise the accuracy of the emulation and potentially render games unplayable or lead to an incorrect representation of the content.

How to Fix It: The Acceptance Criteria

The fix is relatively straightforward. The key is to make sure that the code respects the MMC5's intended behavior. The acceptance criteria for this bug is that when $5104 is set to %01 (extended attribute mode) and a nametable is mapped to fill mode, the attribute fetches should always use ExRAM-based extended attributes, not $5107. The order of operations in the code needs to be corrected. The code needs to first check the extended attribute mode and then decide where to fetch the attribute data. The existing code flow has this reversed, leading to the bug. By addressing this in the code, the colors in fill-mode nametables will match the intended colors defined by the extended attributes, providing a more accurate representation of the game's visuals.

The fix involves modifying the read_nametable function in the mmc5.rs file. First, the code should check the value of $5104. If the value indicates that extended attributes are enabled, the function must fetch the attribute data from the ExRAM. If the extended attributes are not enabled, only then the code can use $5107 to fetch the fill-mode attribute data. The existing code currently fetches the data from $5107 regardless of the extended attributes setting. This simple adjustment will ensure that the code works correctly, leading to accurate colors in fill-mode nametables when extended attributes are enabled.

In a Nutshell

So, to recap, the MMC5 has a bug where it's not correctly using extended attributes in fill-mode. This causes incorrect colors, especially when games use complex visuals. The solution is to change the code so that it checks the extended attribute mode before getting the attribute data. This will ensure that the game displays the correct colors, and everything will look as it should.

This fix ensures that the emulator accurately reflects the original hardware's behavior, which is essential for ensuring that games look and play as they were originally intended. When the fix is implemented, games that rely on fill-mode and extended attributes will display correctly, and players will experience the game as the developers intended.