Why is the Famicom's video output shifted one tile to the right?

[133MHz]

Does somebody know the technical and/or historical reason(s) for this? It always bugged me out and made me think that my TV set was misaligned. Could we classify this as one of the Famicom's mysteries?

[nintendodork]

Does it happen even when you use an R/F Famicom?  It could also just be your TV..on some games in some parts, there's always a BG colored "frame" on the sides of some games on my 20'' flat screen I have in my room..

[133MHz]

It happens on the Famicom (RF or AV doesn't matter), on the NES, Famiclones, etc.
What you describe is that you're looking around the overscan area that's not usually displayed by a standard CRT TV set, usually the background color leaked into those areas (and sometimes garbage scrolling/sprite data) because it wasn't meant to be seen anyway.

[nintendodork]

Thanks for answering that!  I was always wondering what that meant.

[Trium Shockwave]

Maybe they were using that "unseen" area of video to preload some sprite data into the PPU's cache? That's all I can come up with.

[UglyJoe]

Maybe they were using that "unseen" area of video to preload some sprite data into the PPU's cache? That's all I can come up with.

Nah.  The data loaded into the PPU can just sit in the PPU memory.  It doesn't need to be on screen.

[L___E___T]

It doesn't happen on Wii  

but I guess that's besides the point.

[nintendodork]

That's 'cause the Wii isn't over 20 years old   It was made for present day TVs

[133MHz]

I think he's referring to an accurate emulation standpoint.
For an emulator to be 100% accurate, the same behavior should be recreated.

Something a little OT: Did you know that the Wii Virtual Console NES games use iNES headers?!
What a bunch of hypocrites

[NintendoKing]

Modern Televisions are wider then televisions in the 1980's so the system is unable to compensate which causes extra area around the sides.

[UglyJoe]

Something a little OT: Did you know that the Wii Virtual Console NES games use iNES headers?!

If the roms didn't have a header, the emulator would have no way of knowing which mapper it needs to emulate.

[nintendodork]

So then where did they get the header for use in the NES back in the day?

[133MHz]

If the roms didn't have a header, the emulator would have no way of knowing which mapper it needs to emulate.

But such a HUEG company like Nintendo should have more than enough resources to invent a system themselves, aren't they the ones with access to the whole FC/NES documentation and the source code to many of the games?

It bugs me out because they're heavily against emulation and homebrew, but at the same time they're using a system invented by the very same people they're trying to crack down

So then where did they get the header for use in the NES back in the day?

A real FC/NES console does not need a header to run a cartridge. It just works.

[UglyJoe]

So then where did they get the header for use in the NES back in the day?

Mappers work by writing values to hadware-specific registers.  The game's code assumes the mappers is present.  In the case of an NES cart, the mapper is of course there, so it works.  When you dump a ROM from a cart, all you get is the code and graphics (PRG and CHR).  There's nothing in the code that says "I use this mapper"*.  So, if the emulator just runs the code, the writes to those registers go unnoticed.  You need the header to tell the emulator which mapper (if any) to use so that those registers actually do something.

* If you look at the code, you might be able to guess based on what non-standard registers are being written to, but this method is unreliable for a number of reasons.

[nintendodork]

Do the creators of iNES know Nintendo is using their emu?