NES vs VC Differences

[Dwedit]

I was just working with NAND dumps, so I never saw any WAD files. The NES roms aren't compressed once they are stored on NAND.

[ShaneM]

Back on topic. I've disassembled SMB2 USA for the VC (the original Wii 2008 edition; I'm under the assumption that the Wii U version is the same as this one, but I'm not paying another $5 USD to find out). The Wii one is based off of the NTSC PRG1 version. This VC one had some very bizarre changes. They are as follows:

Code: Select all

;In the iNES header, the 6th byte, found at 0x0006 was $40 in the original. It was changed to $42 on this ;version. 
;For those interested, more info found here [url]http://wiki.nesdev.com/w/index.php/INES#Flags_7[/url]

;Next 
;ROM 0x7E17 in the original has:
.db $26, $2a, $22, $26 ;the palette rotation used for "BOMB!" explosions.

;ROM 0x7E17 in the VC has:
.db $0e, $1e, $2e, $3e ;the palette rotation used for "BOMB!" explosions. WHAT?!? These are all black...but ;invalid blacks. Why not just used $0F??? Are far as I know all valid games use $0F as black.

;At ROM 0xC02E the original has:
.db $12   ;waterfall's water blue used in the sprite cycling

;At ROM 0xC02E the VC version has:
.db $0d   ;but wait...this is black on the NES but on the VC it shows up as a lighter blue than $12
;my only assumption is that VC uses the invalid palette $0d as blue...Notice the further remaining changes. ;They change every occurance of $12 to $0d with palettes. Does that mean $12 is invalid on the VC? I may have ;to wait to disassemble more games to find out for sure.

;At ROM 0xC156 the original has:
.db $12    ;I'll assume that this is the water used on icy stages like World 4

;At ROM 0xC156 the VC version has:
.db $0d   ;changed again

;At ROM 0xC27E the original has:
.db $12    ;I'm not sure what this is for, but I know that it is a palette change, similar to the ones above.

;At ROM 0xC27E the VC has:
.db $0d    ;otra vez  :roll: 

;At ROM 0xC29D in the original has:
.db $31, $12  ;palettes used for various objects, such as the platform that Birdo stands on.

;At ROM 0xC29D in the original has:
.db $30, $0d  ;it uses the strange blue again, but this time changes the light blue to a white.

More to come.
--ShaneM

[lidnariq]

These are all black...but invalid blacks. Why not just used $0F??? Are far as I know all valid games use $0F as black.

On the 2C02 and 2C07, all colors $xE and $xF are the same as $1D, all black. There's no real notion of any of them being "more valid" than any others.

[ShaneM]

These are all black...but invalid blacks. Why not just used $0F??? Are far as I know all valid games use $0F as black.

On the 2C02 and 2C07, all colors $xE and $xF are the same as $1D, all black. There's no real notion of any of them being "more valid" than any others.

But still, why use four different ones on SMB2 USA? Why not just stick with one form of black? What difference does that even make? --ShaneM

[lidnariq]

Given that they already repurposed color $0d to mean light blue ... maybe colors $xE on that game on the virtual console aren't black?

[ShaneM]

Given that they already repurposed color $0d to mean light blue ... maybe colors $xE on that game on the virtual console aren't black?

I assumed they were since the "BOMB!" effect was kind of epilepsy-inducing. I could be wrong but making them black would mean cutting out the effect. Then again, it would make more sense that they represented "new" colors since they are all different. I'll try the effect on Wii and see if they are blacked out or not. --ShaneM

[Sik]

It's the fullscreen blinking, right? If so yeah, that one is gonna cause seizures no matter what colors are used (even if the contrast is low), the only kind of safe full-screen palette trickery is fading (as long as it isn't so fast it's practically blinking). Maybe somebody used different blacks just so it still looked like a palette rotation in the patched binary?

As for the blue, for the record, stripped patterns can also cause seizures if they're high contrast enough, so it may be related. Although regarding the color being different, either the emulator makes it a special case for that game, or the change in the header caused a palette change as well.

[Dwedit]

Do they have any special colors in the palette that slowly fade between other colors? I could see rapid palette changes being patched to use those.

[ShaneM]

Given that they already repurposed color $0d to mean light blue ... maybe colors $xE on that game on the virtual console aren't black?

I assumed they were since the "BOMB!" effect was kind of epilepsy-inducing. I could be wrong but making them black would mean cutting out the effect. Then again, it would make more sense that they represented "new" colors since they are all different. I'll try the effect on Wii and see if they are blacked out or not. --ShaneM

Wow...Appearently, the effect is still valid. lidnariq was correct. So...what was the point of not just using the NES' given colors? The Wii version alternates with the exact same red, blue and green for the "BOMB!" effect, but just with repurposed palettes. They even match the NES' valid palettes, unlike the $0d blue's difference.

I had some free time, so I disassembled Kirby's Adventure. These are my findings: The Wii's NTSC version is based on the NES' PRG1 version. It has only one difference, found in the iNES header.

Code: Select all

;In the iNES header, the 6th byte, found at 0x0006 was $42 in the original. It was changed to $40 on this 
;version. 

original = %01000010
VC = %01000000

According to the wiki: "The PlayChoice-10 bit is not part of the official specification, and most emulators simply ignore the extra 8KB of data. PlayChoice games are designed to look good with the 2C03 RGB PPU, which handles color emphasis differently from a standard NES PPU. "

So this is the only difference for Kirby's Adventure on the Wii's VC edition.

--ShaneM

[tepples]

At $0006, is that the PC10 bit or the battery bit?

[ShaneM]

At $0006, is that the PC10 bit or the battery bit?

I just used the wiki. It seems to be PC10. http://wiki.nesdev.com/w/index.php/INES#Flags_7


I have disassembled Pac-Man for the Virtual Console. Here are my findings:

Pac-Man on the VC is based off of the 1993 Namco edition. It has two changes:

Code: Select all

Original: ;ROM 0x13A...something to do with game initialization
jsr $C17F ;everything here is in big-Endian format
lda $41
sta $2005
lda $42
sta $2005

VC_Edition: ;ROM 0x13A...something to do with game initialization
lda $41 ;everything here is in big-Endian format
sta $2005
lda $42
sta $2005
jsr $C17F ;I'm labeling this as a glitch fix. This seems similar to the Spiny box fix I made to SMB1, where ;the contents of register A were being overwritten because of a JSR being called too early. This is the ;second game to fix a glitch, the first being Zelda I on VC.


Original_Something: ;found at ROM x1F37. I'm not sure what this does, I tried corruption but it seems that ;this is something else that may be used later on in the game
lda $2002 ;everything is in big-Endian, here
lda $DF6C,Y
sta $2006
lda $DF6D,Y
sta $2006
lda $6C,X
sta $2007
iny
iny
inx
cpx $04
bne $E5

VC_Something: ;found at ROM x1F37. I'm not sure what this does, I tried corruption but it seems that this is ;something else that may be used later on in the game
lda $DF6C,Y ;everything is in big-Endian, here
sta $2006
lda $DF6D,Y
sta $2006
lda $6C,X
sta $2007
iny
iny
inx
cpx $04
bne $E8
nop
nop
nop ;really elegant coding, here :P  I can tell that this was done via hex editing.

--ShaneM

[Sik]

Wait, I just realized what tepples asked, it's actually Flags 6 in the wiki. Which would make it the battery bit indeed. Do those games save the progress in the VC? (but then again, does the Nintendo emulator not repurpose any flags, just to make sure?)

[ShaneM]

Wait, I just realized what tepples asked, it's actually Flags 6 in the wiki. Which would make it the battery bit indeed. Do those games save the progress in the VC? (but then again, does the Nintendo emulator not repurpose any flags, just to make sure?)

Well, I gave ROM, not RAM. 0x0006 is the 7th byte into the ROM. Battery (flag 6) is 0x0005 and is the 6th byte into the ROM. Kirby does indeed save, though, but not SMB2 USA. --ShaneM

[Myask]

Wait, I just realized what tepples asked, it's actually Flags 6 in the wiki. Which would make it the battery bit indeed. Do those games save the progress in the VC? (but then again, does the Nintendo emulator not repurpose any flags, just to make sure?)

Well, I gave ROM, not RAM. 0x0006 is the 7th byte into the ROM. Battery (flag 6) is 0x0005 and is the 6th byte into the ROM. Kirby does indeed save, though, but not SMB2 USA. --ShaneM

0-3: Constant $4E $45 $53 $1A ("NES" followed by MS-DOS end-of-file)
4: Size of PRG ROM in 16 KB units
5: Size of CHR ROM in 8 KB units (Value 0 means the board uses CHR RAM)
6: Flags 6

Nope. Flags 6 is in fact byte offset 0x6 (the seventh byte). 0x0 1 2 3 4 5 6. So, it's the battery bit, not PC10.

[ShaneM]

0-3: Constant $4E $45 $53 $1A ("NES" followed by MS-DOS end-of-file)
4: Size of PRG ROM in 16 KB units
5: Size of CHR ROM in 8 KB units (Value 0 means the board uses CHR RAM)
6: Flags 6

Nope. Flags 6 is in fact byte offset 0x6 (the seventh byte). 0x0 1 2 3 4 5 6. So, it's the battery bit, not PC10.

Ah, my bad. I have what's called dyscalculia, it's like dyslexia except I mix numbers up (sometimes). It is indeed the sixth byte and the sixth flag. I'll edit my posts to change the word "seventh" to "sixth". --ShaneM

EDIT: I fixed my notes. Sorry about that, guys. I've double-checked and everything else is correct. I've only changed all occurrences of the word "seventh" to "sixth".