This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

PPUMASK emphasize bits on NTSC and PAL

PPUMASK emphasize bits on NTSC and PAL
by on (#189446)
The NESDev wiki says that the emphasize bits for red and green are switched around on a PAL console:

Quote:
Bit 5 emphasizes red on the NTSC PPU, and green on the PAL & Dendy PPUs.
Bit 6 emphasizes green on the NTSC PPU, and red on the PAL & Dendy PPUs.

Source: https://wiki.nesdev.com/w/index.php?tit ... rs#PPUMASK

But it looks like none of the most popular emulators (fceux, Nestopia, Nintendulator) implements the PAL switch.

I made a little test program where I can go through all eight emphasize values with the d-pad. And no matter if I set the emulator to PAL or NTSC (of course, I do a hard reset after switching the region if the emulator doesn't already do it itself), the first value is always the red tint. PAL and NTSC behave identically.

So, is this a thing that all the emulators missed to implement? Or is this an error in the wiki? Or am I misunderstanding anything here?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189447)
DRW wrote:
But it looks like none of the most popular emulators (fceux, Nestopia, Nintendulator) implements the PAL switch.


Nintendulator definitely does, but only in the "unstable" 0.975 build.

I really need to just go ahead and release that version, whether or not it's "complete" enough (the original plan was to incorporate discoveries from Visual 2A03/2C02, but those have been rather infrequent).
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189448)
Reasons why you might see it in very few emulators:
  • Wasn't really a well known thing in this community until August 2014 (and didn't appear in the wiki before then): thread
  • Not a lot of games use emphasis, and almost none use emphasis bits for individual colours (e.g. usually all 3 at once for dimming, or cycling through all 3 quickly). The most notable game that does use an individual one (Noah's Ark) only uses blue.
  • Since it doesn't affect timing or CPU emulation, it's a purely cosmetic effect. Getting it wrong has a very isolated effect on the colour and doesn't break anything else.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189449)
Maybe this should be put into the bug tracker at
https://sourceforge.net/p/fceultra/bugs
(It requires you to register, otherwise I would have done it myself.)

I assume it should be a pretty mundane issue to fix for someone who knows the code and knows where to look at it. So, maybe it gets done for the next version if they are informed.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189453)
SF doesn't spam you, they're quite decent with the current owners again.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189454)
If you need the functionality now, in FCEUX you can use 512 entry palettes to customize emphasis behaviour. If you're looking for colour accuracy you'd probably want to use a separate palette for NTSC and PAL anyway. It's not like the flipped emphasis is the only difference in colour, everything's a different hue at least.

There are some RGB PPU palettes that come with it that do this, for example, but I don't think any of the included palettes are for PAL. Does anyone know a good PAL palette generator? (Or just a good reference palette?) I only know of NTSC ones like Bisqwit's or Drag's.

Yes, the code that expands 64 entry palettes to the internal 512 version should flip the bits for PAL though, as a very minimal approximation. It doesn't currently do this. (Probably there should be separate settings for PAL / NTSC mode palettes, so it will automatically switch when you change modes.)
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189456)
rainwarrior wrote:
If you need the functionality now

I myself don't need the functionality at all. It's merely about emulator accuracy and since fceux is still developed, pointing the developers to this issue might actually fix it.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189466)
The emphasis swap also applies to certain PAL Famiclones so it should probably go with the "Dendy mode" too. Then there is the duty cycle swap in these CPU clones (that FCEUX apparently already emulates in the next version).

For emulator accuracy, I'd also like if there were options for disabling the readability of $2004 and the looped noise feature of the APU to emulate earlier PPU and CPU revisions.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189467)
Pokun wrote:
to emulate earlier PPU and CPU revisions.

The NES has different PPU and CPU revisions? I alwas thought the NES versions only differ regarding the lockout chip, but otherwise work identically.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189468)
The very earliest of NESes—launch ones, I think, and basically no later—use the 2A03E and 2C02E.

We should probably have a page somewhere on the wiki keeping track of which revisions are in what hardware, and what functional changes happened.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189469)
lidnariq wrote:
The very earliest of NESes—launch ones, I think, and basically no later—use the 2A03E and 2C02E.

And what would that mean in practice, i.e. for the funcationality of the games?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189470)
I think I remember reading that the the 2C02E lacks readback from $2004?

The 2A03E does have the tonal noise mode.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189510)
Yeah Codemaster games often rely on reading the $2004, which does not work on, I guess, half of the Famicoms and maybe early NTSC NES systems. I guess this is because Codemaster reverse-engineered the NES so they had no idea that reading $2004 was bad for compatibility.
I remember these jumpy menus in Micro Machines happened in Nesticle too, so I guess it didn't allow reading $2004.

They say $2004 became readable from revision G-0 and later PPUs.
Looped noise feature was added to revision E CPUs or sometime earlier. The unrevised RP2A03 used in VS systems and certain non-VS System arcade boards as a sound chip (like the Donkey Kong 3 and Punch Out arcade boards) does reportedly not have looped noise. I suspect very early Famicoms also doesn't have looped noise.

My Famicom is the very common 1984 HVC-CPU-07 (round buttons, rough bottom) and has a RP2A03E CPU and RP2C02E-0 PPU. As expected, looped noise works but reading $2004 does not.

DRW wrote:
The NES has different PPU and CPU revisions?

I guess most revisions was just changes to the dye that lowered manufacturing costs, but some had new features, and these are the ones we currently know about.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189514)
Pokun wrote:
The unrevised RP2A03 used in VS systems and certain non-VS System arcade boards as a sound chip (like the Donkey Kong 3 and Punch Out arcade boards) does reportedly not have looped noise.

Such a chip was depackaged and photographed some time ago, and I was able to confirm by visual inspection that the looped noise was definitely not present - the LFSR's feedback was hardwired to use the last 2 bits, and the flip-flop for $400E.7 was entirely absent.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189555)
Emphasis bit swap already emulated in FCEUX.
But it's user controlled, not automatic:

Image

About audio:
Dendy mode don't have "swap duty cycles" by default
because only certain CPUs/NOACs (UA6527P, T1818) have this bug,
but some other chips (TA-03NP1-6527P CPU, for example) is correct.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189578)
DRW wrote:
But it looks like none of the most popular emulators (fceux, Nestopia, Nintendulator) implements the PAL switch
Mesen probably doesn't count as popular, but it automatically swaps the emphasis bits when in PAL/Dendy mode.
There's a manual option to swap the duty cycle for the square channels, too.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189706)
Quietust wrote:
Pokun wrote:
The unrevised RP2A03 used in VS systems and certain non-VS System arcade boards as a sound chip (like the Donkey Kong 3 and Punch Out arcade boards) does reportedly not have looped noise.

Such a chip was depackaged and photographed some time ago, and I was able to confirm by visual inspection that the looped noise was definitely not present - the LFSR's feedback was hardwired to use the last 2 bits, and the flip-flop for $400E.7 was entirely absent.

Yes this is the best kind of confirmation we could ask for. Thanks a lot!


Eugene.S wrote:
Dendy mode don't have "swap duty cycles" by default
because only certain CPUs/NOACs (UA6527P, T1818) have this bug,
but some other chips (TA-03NP1-6527P CPU, for example) is correct.

Yeah I think "Dendy mode" is a bit weird naming as there are several kinds of Dendy which these bugs may or may not apply to. And also other clones that also may or may not have them.
The general popular term for clones are "Famiclone", not "Dendy". But on the other hand, a "Famiclone mode" would be even vaguer.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189730)
Eugene.S wrote:
Emphasis bit swap already emulated in FCEUX.
But it's user controlled, not automatic

O.k., but I doubt many people know this, so the default configuration should be dependent on whether NTSC or PAL/Dendy was used.


About the PPU and APU revisions (or any revisions for that matter):

Is there any known situation where a licensed game behaves differently on different NES revisions? Or do the differences only refer to stuff that the official developers were discouraged to use anyway, so it only affects some obscure games that rely on "undocumented" commands?

For example, I don't know what the looped noise feature is, but is this something where the same game might output different audio on different NESes?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189731)
DRW wrote:
I don't know what the looped noise feature is, but is this something where the same game might output different audio on different NESes?
Not NESes, no, because all US (and European) ones support that.

But yes, there are a few games released in Japan that will sound different on older Famicoms vs newer ones. (e.g. Balloon Fight and Mega Man 1)
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189732)
O.k., Famicom is secondary to me. I only really care for the American front loader NES.

So, there are no noticable differences between all of the front loader NTSC NESes, independent from their manufacturing date?


But out of curiosity: Do you have an example of the noise effect on the Famicom that sounds different in the revisions? Or of any other difference?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189733)
The earlier Famicom revision just replaces the periodic noise with regular noise.

If you want a demonstration, open a suitable NSF with NSFPlay and use the APU2 settings to disable periodic noise.

Examples:
  • Solstice track 2 (main game music)
  • Mega Man 2 track 9 (quick man)

Or just open Famitracker and play with the noise channel. An effect of V01 turns on periodic noise, and V00 sets it to regular noise.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189734)
DRW wrote:
So, there are no noticeable differences between all of the front loader NTSC NESes, independent from their manufacturing date?
No, the 2C02G added the ability to read $2004. Most famously this affects Micro Machines.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189736)
DRW wrote:
O.k., Famicom is secondary to me. I only really care for the American front loader NES.

I wouldn't worry about looped noise too much. Only very early Famicoms doesn't support it, and the only thing they will miss out on is a bit less cool sound.
I'd avoid reading $2004 though (I won't be able to play your game if you rely on it! :)). $2004 is a pretty useless register anyway.

Quote:
But out of curiosity: Do you have an example of the noise effect on the Famicom that sounds different in the revisions? Or of any other difference?

I made an NSF in ppMCK (download in attachment) that plays all 16 possible notes of the noise channel with the looped noise flag clear (normal white noise), then it plays all 16 again with the flag set (looped noise). You can clearly hear the difference. Looped noise is more tonal and has metallic characteristics while white noise is more buzzing and is often used for explosions and similar sound effects.


This is the Family Basic version.
Just copy and paste (F12) in Nestopia with Family BASIC V3 (or any Famibe) and then enter RUN:
Code:
10 CLS
20 LOCATE 5,10
30 PRINT"NOISE CHANNEL TEST"
40 POKE &H4015,&H0F
41 REM ENABLE NOISE CHANNEL
50 POKE &H400C,&H0F
51 REM SET NOISE VOLUME TO 15 (MAX)
55 POKE &H400F,0
56 REM SET NOISE LENGTH
60 N=0
77 REM NORMAL NOISE TEST ALL 16 NOTES:
70 FOR N=0 TO 15
80 POKE &H400E,N
85 PRINT HEX$(N)
90 PAUSE 30
95 POKE &H400E,0
98 POKE &H400F,0
99 REM REINITIALIZE NOISE SETTINGS
100 NEXT
107 REM LOOPED NOISE TEST ALL 16 NOTES:
110 FOR N=&H80 TO &H8F
120 POKE &H400E,N
130 PRINT HEX$(N)
140 PAUSE 30
150 POKE &H400E,0
160 POKE &H400F,0
170 NEXT
 



Looped noise is the very cool metalic/electric drums you hear in Megaman 1 Fireman song and Megaman 2 Quickman music.
I believe the looped noise in Balloon Fight (at the end of the Game Over tune) is unintentional though. It might even been made before the looped noise feature was introduced in the APU. Plus it was simultaneously developed for the VS System which doesn't have it, as confirmed by Quietust.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189751)
Pokun wrote:
For emulator accuracy, I'd also like if there were options for disabling the readability of $2004 and the looped noise feature of the APU to emulate earlier PPU and CPU revisions.
I just added both of these options to Mesen - thanks for the NSF file, made it easy to test the noise channel option!
For $2004 reads, I have it returning the same as reads to any other write-only reg, based on what blargg said in an old thread about this:
blargg wrote:
$2004 reads back no differently than say $2000; it's a write-only register.
So the value read is based on the decay of the values in the PPU's 8-bit latch (if someone knows this to be incorrect, please let me know)

Are there any other known differences between the different revisions (NES, PAL NES, Famicom, Dendy) that I'm missing in this list?
-$2004 reads
-Emphasis bits
-Noise loop
-Square duty swap
-Reset not resetting the PPU on Famicom (this one I have not have implemented yet)
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189753)
These quirks distinguish NES-001 from NES-101:

  1. $4016 D2 is zero on NES-001 but open bus on NES-101.
  2. NES-101 reset button doesn't reset the PPU.

My controller test uses $4016 D2 to tell the difference between rectangle and dogbone controllers.

And the obvious:

  • Dot to CPU cycle ratio: 3.2:1 for PAL NES; 3:1 for other
  • OAM writing: Lines 241-260 for PAL NES; during vertical or forced blanking on other
  • NMI scanline: 291 for PAL famiclones; 241 for other
  • Field length: 262 lines for NTSC and RGB; 312 for PAL
  • Black border: 2 pixels on each side and 1 on top for PAL; none for NTSC and RGB
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189755)
The palette is readable on later revisions of the 2C02 and not on earlier ones. I don't know when this changed, however.

The 2C03/4/5, and thus presumably also early versions of the 2C02, don't have the OAMADDR bug.

The 2C07 both supports reading OAMDATA and lacks the OAMADDR bug.

I don't know of anything where we know it has an effect, but the 2A03letterless emits a 3/4 duty cycle value for M2 instead of 5/8 (as in the 2A03E,G,H).


I'm probably forgetting some more...
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189771)
According to the wiki RP2A03G has a test mode for the APU.
If pin 30 is pulled high on revision G, extra diagnostic registers are enabled on $4018~$401A, and the I/O ports $4016 and $4017 becomes open bus (so controllers won't work). On older revisions of the CPU, pulling pin 30 high instead causes the CPU to stop execution. It is normally connected to GND to be always low though.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189776)
Pokun wrote:
On older revisions of the CPU, pulling pin 30 high instead causes the CPU to stop execution.
In the 2A03letterless – see here – pin 30 is directly connected to the silicon substrate (see right center) while pin 20 (bottom center) is connected to the intentional ground.

I'm really not clear why pin 30 was bonded at all... but given how MOSFETs work, changing the body voltage (which is what I think pin 30 controls) would definitely cause everything to not work!
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189777)
So the wiki is incorrect?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189785)
lidnariq wrote:
Pokun wrote:
On older revisions of the CPU, pulling pin 30 high instead causes the CPU to stop execution.
In the 2A03letterless – see here – pin 30 is directly connected to the silicon substrate (see right center) while pin 20 (bottom center) is connected to the intentional ground.

I'm really not clear why pin 30 was bonded at all... but given how MOSFETs work, changing the body voltage (which is what I think pin 30 controls) would definitely cause everything to not work!


Pin 30 isn't connected "to the substrate" - it's connected to a "pin pad" (just like all of the other pins), which happens to consist of a square of conductive silicon with another square of metal layered on top of it, but that pin pad happens to be totally isolated from the rest of the circuit.

It's highly likely that pin 30 was simply unused in the letterless RP2A03 and was specifically implemented as a "clock halt" in one of the middle revisions prior to G; if anybody can get one of those chips depackaged, we'll be able to find out what's really going on.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189807)
Ok, so it looks similar to the CLK pin pad below it but it's missing the polysilicon connection to anything else. It's dark like the N-typed doped diffusion, so it probably is. So it seems to be wire bonded to an N+ region in a P-type substrate, so it should be equivalent to a diode pointing away from the substrate. I guess if anyone has a 2A03 it'd be easy enough to check for something that behaves like an undervoltage protection diode on that pin...

But thanks for the correction!
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189827)
tepples wrote:
$4016 D2 is zero on NES-001 but open bus on NES-101.
OAM writing: Lines 241-260 for PAL NES; during vertical or forced blanking on other
I knew there was something with the input ports, but didn't know the specifics. Also, according to the wiki D3-D4 are not the same between the Famicom & NES-101?
About OAM, the wiki says:
Quote:
In the 2C07, sprite evaluation can never be fully disabled, and will always start 20 scanlines after the start of vblank[10] (same as when the prerender scanline would have been on the 2C02).
Does this imply that during scanlines 261-310 the PPU repeats the sprite evaluation logic that runs during the prerender scanline?

lidnariq wrote:
The palette is readable on later revisions of the 2C02 and not on earlier ones. I don't know when this changed, however.
I tried finding a reference to this on the wiki, but couldn't. I'm assuming reading 0x3Fxx in this case would return the latch's data & fill the latch with the next byte?

lidnariq wrote:
The 2C03/4/5, and thus presumably also early versions of the 2C02, don't have the OAMADDR bug.
So the 8-byte copy from OAMADDR & 0xF8 to the start of OAM ram does not occur even if OAMADDR >= 8?

I just found your oamtest3 test rom while looking up more information about this. Ended up noticing that my sprite DMA code was still using a very old inaccurate patch (for no good reason) and a couple more bugs thanks to it! I added it to the emulator test page on the wiki.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189830)
Sour wrote:
Does this imply that [on the 2C07] during scanlines 261-310 the PPU repeats the sprite evaluation logic that runs during the prerender scanline?
We don't actually know. I've been meaning to write a simple test that will fill OAM with a specific convenient table and just log the value read back from OAMDATA for a full vblank, but have had no focus.

Quote:
I tried finding a reference to [palette unreadability] on the wiki, but couldn't. I'm assuming reading 0x3Fxx in this case would return the latch's data & fill the latch with the next byte?
Yeah, exact same as in the rest of the 0x3xxx memory range.

Quote:
So the 8-byte copy from OAMADDR & 0xF8 to the start of OAM ram does not occur even if OAMADDR >= 8?
Correct. It definitely does happen in the 2C02G and some of the famiclones, doesn't happen in the 2C03, 2C04, 2C05, and 2C07.

If I've stated this correctly, Sachen's Huge Insect (the best-documented instance of relying on this bug) should fail on the Famicom Titler and any other console that uses one of the RGB PPUs.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189871)
Sour wrote:
tepples wrote:
$4016 D2 is zero on NES-001 but open bus on NES-101.
OAM writing: Lines 241-260 for PAL NES; during vertical or forced blanking on other
I knew there was something with the input ports, but didn't know the specifics. Also, according to the wiki D3-D4 are not the same between the Famicom & NES-101?

It seems that D3 and D4 are identical on the NES Toaster and the NES Toploader, only D2 on $4016 is different.


The wiki is a bit confusing, but if I understand the wiki correctly this should be the case:

Famicom (HVC-001)
$4016.3 and $4016.4: Open bus
These are also not available neither from the expansion port nor the controller ports.

$4017.3 and $4017.4: Input on Expansion Port pin 4 and 5 respectively

$4016.2: Input on Controller Port II pin 6 (used by the microphone)
$4017.2: Input on Expansion Port pin 6


AV Famicom (HVC-101)
$4016.3 and $4016.4: All 0
These pins are not available from the controller ports unlike on NES.

$4017.3 and $4017.4: Same as Famicom.
These pins are not available from the controller ports unlike on NES.
People often mod their AV Famicom so that these pins are connected to the controller port II as well. Makes Zapper and other NES peripherals work.

$4016.2: Open bus
$4017.2: Input on Expansion Port pin 6


NES-001
$4016.3 and $4016.4: Input on Controller Port I pin 6 and 5 respectively
$4017.3 and $4017.4: Input on Controller Port II pin 6 and 5 respectively

$4016.2: Always 0
$4017.2: Always 0
Not accesible from the controller ports either.

*The expansion port have accesss to most pins though.


NES-101
$4016.3 and $4016.4: Same as NES-001
$4017.3 and $4017.4: Same as NES-001

$4016.2: Open bus
$4017.2: Always 0


Pinouts:
Code:
Famicom Controller Port Pinout (front)

 Port I     Port II
  _____     ______   
 |12345|   |123456|
  ¯¯ ¯¯     ¯¯  ¯¯
P I   1: +5V, 2: CLK $4016, 3: P/S, 4: Data $4016.0, 5: GND
P II  1: +5V, 2: CLK $4017, 3: P/S, 4: Data $4017.0, 5: GND, 6: Mic $4016.2
Note: P/S is latch and comes from the $4016.0 output on both controllers.


NES Controller Port Pinout (front)

 Port I               Port II
               _                            _
       GND -- |1\                   GND -- |1\
 CLK $4016 <- |27\ -- +5V     CLK $4017 <- |27\ -- +5V
       P/S <- |36| <- $4016.3       P/S <- |36| <- $4017.3
   $4016.0 -> |45| <- $4016.4   $4017.0 -> |45| <- $4017.4
               ¯¯                           ¯¯
Note: P/S is latch and comes from the $4016.0 output on both controllers.

HVC-101 have the same ports as NES but is missing D3 and D4.

Famicom Expansion Port Pinout (front)

  1___________________8
   \ o o o o o o o o /
  9 \ o o o o o o o / 15
     ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1: GND, 2: Sound >, 3: IRQ <>, 4: $4017.4 <, 5: $4017.3 <, 6: $4017.2 <,
7: $4017.1 <, 8: $4017.0 <, 9: $4017 CLK >, 10: $4016.2 >, 11: $4016.1 >,
12: $4016.0 > (latch), 13: $4016.1 <, 14: $4016 CLK >, 15: +5V
 <: Input, >: Output, <>: Bidirectional



Did I get everything right? I think the wiki should be updated to include this kind of information more clearly.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189941)
Between your post and the info on the wiki, I tried putting this all together and got this (as far as possible read values):
Code:
Port     $4016      $4017
Bit      76543210   76543210
NES-001  ---CC00C   ---CC00C
NES-101  ---CC-0C   ---CC00C
HVC-001  -----MEC   ---EEEEC
HVC-101  -----0EC   ---EEEEC

- = Open bus
0 = always 0
E = expansion port data
C = controller port data
M = famicom controller 2 microphone
Did I get something wrong?

Also added a few more options ("Do not reset PPU on console reset", "Disable palette reads", "Disable OAMADDR bug emulation") and implemented a guess at what might be the PAL OAM behavior for scanlines 261+. The console-specific input ports are more or less the only thing left to implement I think.

EDIT: Fixed mistake in HVC-101 $4016 info
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189942)
Quote:
Code:
HVC-101  ---00-EC   ---EEEEC

I thought it was this:
Code:
HVC-101  -----0EC   ---EEEEC
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189956)
Why did you think that? According to the wiki, Sour is correct I think?
And of course you can mod the AV Famicom's second controller port so that it has all pins that the NES has.

Not sure if you can mod controller port I for $4016.3 and $4016.4 as well though. Only game that I heard is using them is the unlicenced game Chiller. It allows to use two Zappers using both NES controller ports. And Tepple's controller detecting program that can detect about any kind of input device in any port.
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189960)
At the very least, for the AllPads test to detect the HVC-101 (Family Computer + 0 or 1 dogbone), it needs to be:
HVC-101 -----0EC ---EEEEC

This also makes Mesen match the results given for the HVC-101 here: https://forums.nesdev.com/viewtopic.php ... 71#p183871
1P: 40 B8 40 B8
2P: 40 A0 40 A0

If using:
HVC-101 ---00-EC ---EEEEC

Then it always detects it as NES-101:
1P: 40 A4 40 A4
2P: 40 A0 40 A0

So it looks like tepples is correct?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189980)
So then the wiki must be wrong. Where did Tepples get this information from though if not from the wiki?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189981)
I got the info from making a test ROM, whose source code is available, and having other members run it. What wiki page needs to be corrected?
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#189982)
Before Tepples wrote his test ROM, I could have sworn I had seen some reason to conclude that the HVC-101 and NES-101 had the same open-bus behavior on reads from $4016. Evidently not!
Re: PPUMASK emphasize bits on NTSC and PAL
by on (#190003)
Hehe good thing he made that test ROM.

tepples wrote:
I got the info from making a test ROM, whose source code is available, and having other members run it. What wiki page needs to be corrected?

Oh I see, it's just the test results from your test program.

The incorrect part I know of is this one:
Quote:
Famicom $4016 and Top-loading NES $4016:
7 bit 0
---- ----
OOOx xMFD
|||| ||||
|||| |||+- Player 1 serial controller data
|||| ||+-- If connected to expansion port (and available), player 3 serial controller data (0 otherwise)
|||| |+--- Microphone in controller 2 on traditional Famicom, open bus on AV Famicom and top-loader
|||+-+---- Open bus on traditional Famicom, all 0s on AV Famicom and top-loader
+++------- Open bus

Here it says that the Microphone bit is open bus on AV Famicom, and D3 & D4 are allways 0.