So I've worked Vs. SMB into my SMB meta-disassembly and currently am just defining the alternate palette stuff with the same palette constants I'm using for the 2C02. However, these are completely jumbled on this and other arcade unit versions of Famicom titles according to https://www.nesdev.org/wiki/PPU_palettes
First off, this article mentions the 2C04 palette for SMB under the -0004 heading, but I'm unsure whether this means PlayChoice-10 SMB or Vs. SMB (or both?)
For the jumbled palettes, is it known exactly how those are mapped inside the PPU variants themselves, whether the color generator is wired (traced? dunno the right term for a sub-component in an IC) completely differently, or if generally the same color generator is present down in the die somewhere and there's a decoder sitting between it and the IDs passed to CRAM? Additionally, there seem to be a few variations, is it known if these represent distinct boards/ICs and as such a given mapping would represent the behavior of a board across titles that use it, or if there was some sort of variable component put between the CPU and PPU that would've used the same versions of those ICs but could've translated color entries differently?
Where I'm going with this is whether I should define a system-level header that supplies the palette entry remaps or should consider these remaps more-or-less specific to Vs. SMB (according to the wiki some titles share the jumbled palettes but I'm unsure if this points to dependable behavior of a specific IC or rather just what translation/remap table was applied to that handful of titles.)
TIA for any info, I'm hoping the end result is something where I can define the palettes the same in the source files and push all the remapping to the headers, that way only true differences in palette are present in sources, the headers handle all the abstraction.
First off, this article mentions the 2C04 palette for SMB under the -0004 heading, but I'm unsure whether this means PlayChoice-10 SMB or Vs. SMB (or both?)
For the jumbled palettes, is it known exactly how those are mapped inside the PPU variants themselves, whether the color generator is wired (traced? dunno the right term for a sub-component in an IC) completely differently, or if generally the same color generator is present down in the die somewhere and there's a decoder sitting between it and the IDs passed to CRAM? Additionally, there seem to be a few variations, is it known if these represent distinct boards/ICs and as such a given mapping would represent the behavior of a board across titles that use it, or if there was some sort of variable component put between the CPU and PPU that would've used the same versions of those ICs but could've translated color entries differently?
Where I'm going with this is whether I should define a system-level header that supplies the palette entry remaps or should consider these remaps more-or-less specific to Vs. SMB (according to the wiki some titles share the jumbled palettes but I'm unsure if this points to dependable behavior of a specific IC or rather just what translation/remap table was applied to that handful of titles.)
TIA for any info, I'm hoping the end result is something where I can define the palettes the same in the source files and push all the remapping to the headers, that way only true differences in palette are present in sources, the headers handle all the abstraction.
Statistics: Posted by segaloco — Mon Mar 18, 2024 4:44 pm — Replies 0 — Views 67