Difference between revisions of "User:Eighty5cacao/misc/NES"

From Pin Eight
Jump to: navigation, search
(Overclocking methods: clarify the goal of the only valid method)
(Digression: Bad mappers: more about preferring the lowest plane)
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== <span id="Active_issues"><span id="Unsorted_issues">NESdev wiki</span></span> ==
 
== <span id="Active_issues"><span id="Unsorted_issues">NESdev wiki</span></span> ==
  
[http://wiki.nesdev.com/w/index.php?title=Mirroring&diff=10673&oldid=10667 "diagonal mirroring does not solve attribute glitches"]&nbsp;&ndash; elaborate please? Obviously it is glitch-free for horizontal or vertical scrolling aligned with the nametables, but perhaps Rainwarrior was trying to say that for a general case where the screen overlaps all four nametable regions, it becomes as bad as single-screen mirroring. This is just my quick-and-dirty guess; it needs to be verified with a worked example of free scrolling over diagonally-mirrored nametables, to demonstrate where the name-/attribute table writes go as the screen position covers relevant cases. A test ROM would be nice.<br />Would 3-screen diagonal mirroring be any better? (The code complexity might not actually be worth it, though.)
+
[https://wiki.nesdev.com/w/index.php?title=Mirroring&diff=10673&oldid=10667 "diagonal mirroring does not solve attribute glitches"]&nbsp;&ndash; elaborate please? Obviously it is glitch-free for horizontal or vertical scrolling aligned with the nametables, but perhaps Rainwarrior was trying to say that for a general case where the screen overlaps all four nametable regions, it becomes as bad as single-screen mirroring. This is just my quick-and-dirty guess; it needs to be verified with a worked example of free scrolling over diagonally-mirrored nametables, to demonstrate where the name-/attribute table writes go as the screen position covers relevant cases. A test ROM would be nice.<br />Would 3-screen diagonal mirroring be any better? (The code complexity might not actually be worth it, though.)
  
[http://forums.nesdev.com/viewtopic.php?p=80345#p80345 This post by Chris Covell] mentions the existence of Nibbles in the OneStation 35-in-1
+
[https://forums.nesdev.com/viewtopic.php?p=80345#p80345 This post by Chris Covell] mentions the existence of Nibbles in the OneStation 35-in-1
  
 
Noticed while lookig at [[nescartdb:4595]] (Uchuu Keibitai SDF) - bootgod should consider:
 
Noticed while lookig at [[nescartdb:4595]] (Uchuu Keibitai SDF) - bootgod should consider:
Line 45: Line 45:
 
*In step 8, Nestopia starts with no error
 
*In step 8, Nestopia starts with no error
  
The issue in http://forums.nesdev.com/viewtopic.php?f=3&t=14205 might share some relevant code paths, but no issue of configuration corruption was mentioned there.
+
[https://forums.nesdev.com/viewtopic.php?f=3&t=14205 This issue] might share some relevant code paths, but no issue of configuration corruption was mentioned there.
  
 
''This needs further testing to determine whether the bug is still present & how accurately I have remembered the steps to reproduce''
 
''This needs further testing to determine whether the bug is still present & how accurately I have remembered the steps to reproduce''
Line 52: Line 52:
 
All these should be considered dubious
 
All these should be considered dubious
  
*Mappers with PRG ROM in $6000-7FFF (NROM-368, JY Company [all variants of 90/209/211], FME-7, SMB2J pirate)
+
*Mappers with PRG ROM in $6000-7FFF (NROM-368, J.Y. Company [all variants], FME-7, SMB2J pirate)
 
*Mappers with PRG RAM outside $6000-7FFF (MMC5, FDS, only create the category if another example exists)
 
*Mappers with PRG RAM outside $6000-7FFF (MMC5, FDS, only create the category if another example exists)
 
*Mappers with register bits in the address bus ([[nesdev:INES Mapper 168|Racermate]], etc.; needs better name?)
 
*Mappers with register bits in the address bus ([[nesdev:INES Mapper 168|Racermate]], etc.; needs better name?)
**Mappers using only the address bus ([[nesdev:INES Mapper 058|58]], [[nesdev:INES Mapper 061|61]], [[nesdev:INES Mapper 174|174]], [[nesdev:INES Mapper 200|200]], [[nesdev:INES Mapper 201|201]], [[nesdev:INES Mapper 231|231]], [[nesdev:INES Mapper 242|242]], [[nesdev:INES Mapper 250|250 ''if Nintendulator is correct'']] - subcat of the above)
+
**Mappers using only the address bus ([[nesdev:INES Mapper 058|58]], [[nesdev:INES Mapper 061|61]], [[nesdev:INES Mapper 174|174]], [[nesdev:INES Mapper 200|200]], [[nesdev:INES Mapper 201|201]], [[nesdev:INES Mapper 231|231]], [[nesdev:INES Mapper 235|235]], [[nesdev:INES Mapper 242|242]], [[nesdev:INES Mapper 250|250 ''if Nintendulator is correct'']] - subcat of the above)
 
*VRC-like pirate mappers (should probably drop the word "pirate" for consistency with "MMC3-like mappers"; in both cases the meaning is sufficiently clear from context)
 
*VRC-like pirate mappers (should probably drop the word "pirate" for consistency with "MMC3-like mappers"; in both cases the meaning is sufficiently clear from context)
 
*Not in NesCartDB
 
*Not in NesCartDB
 +
*Mappers with registers overlaying PRG RAM (e.g. [[nesdev:NES 2.0 Mapper 395|NES 2.0 Mapper 395]])
  
 
=== [[nesdev:NES 2.0 submappers|NES 2.0 submappers]] ===
 
=== [[nesdev:NES 2.0 submappers|NES 2.0 submappers]] ===
Line 66: Line 67:
 
"iNES 1" format already expresses "no advisory statement"; this deprecates "no advisory statement" along with iNES 1.
 
"iNES 1" format already expresses "no advisory statement"; this deprecates "no advisory statement" along with iNES 1.
 
{{spoiler box|1=I'd like to dispute the flagging of [[nesdev:NES 2.0 submappers#001: MMC1|MMC1]] as stable: By my (admittedly limited) understanding of the second-to-last item, the intent of having submappers at all was the exact opposite, to deprecate mapper 155 in favor of a submapper of 1.|type=Resolved invalid}}
 
{{spoiler box|1=I'd like to dispute the flagging of [[nesdev:NES 2.0 submappers#001: MMC1|MMC1]] as stable: By my (admittedly limited) understanding of the second-to-last item, the intent of having submappers at all was the exact opposite, to deprecate mapper 155 in favor of a submapper of 1.|type=Resolved invalid}}
But on a related note: Is mapper 155 intended to be used for all games released exclusively with MMC1A chips, or only games that specifically depend on MMC1A ''behavior''? ([http://wiki.nesdev.com/w/index.php?title=INES_Mapper_155&diff=9380&oldid=7959 Resolved?])
+
But on a related note: Is mapper 155 intended to be used for all games released exclusively with MMC1A chips, or only games that specifically depend on MMC1A ''behavior''? ([https://wiki.nesdev.com/w/index.php?title=INES_Mapper_155&diff=9380&oldid=7959 Resolved?])
 
*Trivial: "corresponds is" in the VRC2/4 section must be a typo.
 
*Trivial: "corresponds is" in the VRC2/4 section must be a typo.
 
*If someone created a homebrew game on a 1-screen mirroring variant of [[nesdev:INES Mapper 180|backwards UxROM]], what NES 2.0 mapper number would fit this best? If the mirroring register were identical to that of [[nesdev:INES Mapper 071#Mirroring ($8000-$9FFF)|Camerica BF9097]], could this be shoehorned into a submapper of an existing major mapper, or would we need a new major mapper? (If not, we'd probably define a new major mapper regardless.)
 
*If someone created a homebrew game on a 1-screen mirroring variant of [[nesdev:INES Mapper 180|backwards UxROM]], what NES 2.0 mapper number would fit this best? If the mirroring register were identical to that of [[nesdev:INES Mapper 071#Mirroring ($8000-$9FFF)|Camerica BF9097]], could this be shoehorned into a submapper of an existing major mapper, or would we need a new major mapper? (If not, we'd probably define a new major mapper regardless.)
*Regarding [[nesdev:NES 2.0 submappers#004: MMC3|MMC3]], it is probably desirable to have at least four submappers, where one bit indicates the behavior for latch 0, and the other bit indicates rising or falling edge. This means that one submapper will describe an ASIC that isn't known to exist (like MC-ACC but with the opposite latch-0 behavior), but this isn't a problem. Compare the VRC4 proposal, where most possible submappers don't describe verified real configurations<!-- no pun intended --> either. Additional bits can be allocated to distinguish MMC6 and to describe the fixed mirroring behavior of T[EF]ROM if desired. ([[{{TALKPAGENAME}}#MC-ACC|See talk]])
+
*Regarding [[nesdev:NES 2.0 submappers#004: MMC3|MMC3]], it is probably desirable to have at least four submappers, where one bit indicates the behavior for latch 0, and the other bit indicates rising or falling edge. This means that one submapper will describe an ASIC that isn't known to exist (like MC-ACC but with the opposite latch-0 behavior), but this isn't a problem. Compare the VRC4 proposal, where most possible submappers don't describe verified real configurations<!-- no pun intended --> either. Additional bits can be allocated to distinguish MMC6 and to describe the fixed mirroring behavior of T[EF]ROM if desired. ([[{{TALKPAGENAME}}#MC-ACC|On hold indefinitely; see talk]])
  
 
=== [[nesdev:Colour-emphasis games|Colour-emphasis games]] ===
 
=== [[nesdev:Colour-emphasis games|Colour-emphasis games]] ===
Line 86: Line 87:
 
Also, in the interest of factual accuracy, [[nesdev:Category:Mappers with ROM nametables|Category:Mappers with ROM nametables]] should remain in use specifically on ''INES Mapper 209'' and ''211'' even once they are redirects, rather than categorizing the merged "JY Company" article as such.|type=Resolved}}
 
Also, in the interest of factual accuracy, [[nesdev:Category:Mappers with ROM nametables|Category:Mappers with ROM nametables]] should remain in use specifically on ''INES Mapper 209'' and ''211'' even once they are redirects, rather than categorizing the merged "JY Company" article as such.|type=Resolved}}
  
Re [http://forums.nesdev.com/viewtopic.php?f=3&t=12614#p144780]: $5000 is most likely a DIP switch. FCEU(X) probably implemented it as a reset counter only because, unlike Nestopia, they didn't want to bother implementing an UI for DIP switches.
+
Re [https://forums.nesdev.com/viewtopic.php?f=3&t=12614#p144780]: $5000 is most likely a DIP switch. FCEU(X) probably implemented it as a reset counter only because, unlike Nestopia, they didn't want to bother implementing an UI for DIP switches.
 
==== Compared with MMC5 ====
 
==== Compared with MMC5 ====
Does any other company's mapper contain a scanline IRQ counter [[nesdev:Talk:JY Company#PPU read IRQ mode|clocked by 170 transitions of PPU /RD]]? How do we know that MMC5's IRQ counter doesn't do that? (The obvious answer, which I'm not expert enough to judge/verify, is that a divide-by-170 would take more silicon space than the logic that detects the dummy nametable reads. At any rate, any investigation should be documented publicly.)
+
Does any other company's mapper contain a scanline IRQ counter [[nesdev:Talk:JY Company#PPU read IRQ mode|clocked by 170 transitions of PPU /RD]]?<!-- How do we know that MMC5's IRQ counter doesn't do that? (The obvious answer, which I'm not expert enough to judge/verify, is that a divide-by-170 would take more silicon space than the logic that detects the dummy nametable reads. At any rate, any investigation should be documented publicly.) -->
  
 
Is it verified that JY Company's multiplier always takes 8 cycles?  
 
Is it verified that JY Company's multiplier always takes 8 cycles?  
Line 102: Line 103:
  
 
==== [[nesdev:Special:PrefixIndex/UNIF/|"Namespace"]] ====
 
==== [[nesdev:Special:PrefixIndex/UNIF/|"Namespace"]] ====
I disagree with [http://wiki.nesdev.com/w/index.php?title=Special%3ALog&type=move&user=&page=UNL-DripGame&year=&month=-1 this move] and the precedent it established, for the following reasons:
+
I disagree with [https://wiki.nesdev.com/w/index.php?title=Special%3ALog&type=move&user=&page=UNL-DripGame&year=&month=-1 this move] and the precedent it established, for the following reasons:
 
#The MediaWiki software calls that a "subpage," not a "namespace."
 
#The MediaWiki software calls that a "subpage," not a "namespace."
 
#The idea of "reduc[ing] clutter" in the main namespace is entirely pointless, given that mappers, pinouts, homebrew projects etc. have been allowed to coexist in the main namespace with only categories to distinguish them. To follow this convention would create additional hassle to move an article if an NES 2.0 mapper number is defined for a pirate or homebrew mapper that was formerly UNIF-only.
 
#The idea of "reduc[ing] clutter" in the main namespace is entirely pointless, given that mappers, pinouts, homebrew projects etc. have been allowed to coexist in the main namespace with only categories to distinguish them. To follow this convention would create additional hassle to move an article if an NES 2.0 mapper number is defined for a pirate or homebrew mapper that was formerly UNIF-only.
Line 118: Line 119:
  
 
== Digression: Bad mappers ==
 
== Digression: Bad mappers ==
The problem [http://forums.nesdev.com/viewtopic.php?p=88500#p88500 with the ''Gradius II'' hack mentioned here] is that [[nesdev:INES Mapper 025|iNES mapper 025]] is among several iNES mappers not accepted by Nestopia; it recognizes (unmodified versions of) games using certain Konami mappers using a database; IIRC soft-patching works fine, but hard-patching does not for obvious reasons.
+
The problem [https://forums.nesdev.com/viewtopic.php?p=88500#p88500 with the ''Gradius II'' hack mentioned here] is that [[nesdev:INES Mapper 025|iNES mapper 025]] is among several iNES mappers not accepted by Nestopia; it recognizes (unmodified versions of) games using certain Konami mappers using a database; IIRC soft-patching works fine, but hard-patching does not for obvious reasons.
  
 
Should the "Bad iNES Mappers" category on nesdevwiki have a subcategory "INES mappers deprecated by Nestopia"?  
 
Should the "Bad iNES Mappers" category on nesdevwiki have a subcategory "INES mappers deprecated by Nestopia"?  
Do we need to create "File:Mfr icon Konami Bad.png" for the [[nesdev:Mapper|mapper]] table?
+
Do we need to create "File:Mfr icon Konami Bad.png" for the [[nesdev:Mapper|mapper]] table?  
 +
Or perhaps bad status should be (indicated by a strikethrough? and) orthogonal to manufacturer information
  
 
<sup>Exact quote from the Nestopia 1.38 changelog: "Mappers 21, 23, 25 and 185 no longer supported using plain iNES files because of format restrictions." That is, ROMs whose headers specify these mappers are rejected if not recognized by Nestopia's internal database of hashes. (Note that mapper 22 is not deprecated because it is not similarly ambiguous.)</sup>
 
<sup>Exact quote from the Nestopia 1.38 changelog: "Mappers 21, 23, 25 and 185 no longer supported using plain iNES files because of format restrictions." That is, ROMs whose headers specify these mappers are rejected if not recognized by Nestopia's internal database of hashes. (Note that mapper 22 is not deprecated because it is not similarly ambiguous.)</sup>
 +
 +
For mapper assignments found to be duplicated between planes 0 and 1, why was the plane 0 assignment not always chosen as final?
  
 
==[[nesdev:MMC3|MMC3]] IRQs==
 
==[[nesdev:MMC3|MMC3]] IRQs==
 
I feel that a statement about lot check that once appeared in [[nesdev:MMC3#Variants]] is questionable. I seem to recall that [[nescartdb:249|Star Trek: 25th Anniversary]] and [[nescartdb:1702|My Life My Love: Boku no Yume: Watashi no Negai]] depend on the newer revision's behavior in some way (TODO: details. Nestopia's changelog mentions ''Star Trek: 25th Anniversary'' at version 1.30)
 
I feel that a statement about lot check that once appeared in [[nesdev:MMC3#Variants]] is questionable. I seem to recall that [[nescartdb:249|Star Trek: 25th Anniversary]] and [[nescartdb:1702|My Life My Love: Boku no Yume: Watashi no Negai]] depend on the newer revision's behavior in some way (TODO: details. Nestopia's changelog mentions ''Star Trek: 25th Anniversary'' at version 1.30)
 
===New issues===
 
===New issues===
[http://forums.nesdev.com/viewtopic.php?f=9&t=10933 Felix the Cat supposedly depends on MMC3A behavior], but [[nescartdb:685|NesCartDB shows US and PAL releases using MMC3C]]. TODO: Check what Nestopia's database does for this game, what mirroring the game uses during gameplay, and whether it does anything tricky like using IRQs to "skip" the scroll past nametable space used by the status bar (cf. Krusty's Fun House)
+
[https://forums.nesdev.com/viewtopic.php?f=9&t=10933 Felix the Cat supposedly depends on MMC3A behavior], but [[nescartdb:685|NesCartDB shows US and PAL releases using MMC3C]]. TODO: Check what Nestopia's database does for this game, what mirroring the game uses during gameplay, and whether it does anything tricky like using IRQs to "skip" the scroll past nametable space used by the status bar (cf. Krusty's Fun House)
  
 
=="Great" minds think alike==
 
=="Great" minds think alike==
Line 148: Line 152:
 
sloppiness alert, as usual. I know I really should register for the TASVideos forums in order to bring up these issues, but I'm busy at the moment.
 
sloppiness alert, as usual. I know I really should register for the TASVideos forums in order to bring up these issues, but I'm busy at the moment.
 
*NTSC filter issues:
 
*NTSC filter issues:
**Nestopia ''should'' be able to pass <code>tvpassfail</code> because it has an NTSC filter at least on Windows. Was it listed as failing because the build tested lacks said filter? Did somebody consider the filter not to be accurate enough? Or is the problem with the aspect ratio (which is supported via the "TV Aspect" setting)? Note that the sample video is from Bisqwit's NTSC filter as implemented in nesemu1, but it seems within reason of what can be achieved by tweaking blargg's filter (Nestopia). Someone should record from real hardware as a comparison.
+
**Nestopia ''should'' be able to pass <code>tvpassfail</code> because it has an NTSC filter at least on Windows. Was it listed as failing because the build tested lacks said filter, or perhaps simply because it is not enabled by default? Did somebody consider the filter not to be accurate enough? Or is the problem with the aspect ratio (which is supported via the "TV Aspect" setting)? Note that the sample video is from Bisqwit's NTSC filter as implemented in nesemu1, but it seems within reason of what can be achieved by tweaking blargg's filter (Nestopia). Someone should record from real hardware as a comparison.
 
**Similarly for puNES
 
**Similarly for puNES
 
*Testing methodology for APU volume tests needs to be explained/reconsidered better. I need to find the NESdev post in which you (Tepples) said that Nestopia's noise channel is too loud - yet it is listed as passing <code>volumes</code> (but not <code>apu_mixer</code><!-- TODO: more specific -->)
 
*Testing methodology for APU volume tests needs to be explained/reconsidered better. I need to find the NESdev post in which you (Tepples) said that Nestopia's noise channel is too loud - yet it is listed as passing <code>volumes</code> (but not <code>apu_mixer</code><!-- TODO: more specific -->)
Line 157: Line 161:
  
 
== MMC2 and PRG RAM ==
 
== MMC2 and PRG RAM ==
The PlayChoice-10 version of ''Mike Tyson's Punch-Out!!'' has battery-backed PRG RAM, as mentioned in the [https://github.com/mamedev/mame/blob/master/src/mame/drivers/playch10.cpp MAME source] and [http://forums.nesdev.com/viewtopic.php?f=9&t=9392 this forum thread].<!-- todo: explain more, what lines specifically -->
+
The PlayChoice-10 version of ''Mike Tyson's Punch-Out!!'' has battery-backed PRG RAM, as mentioned in the [https://github.com/mamedev/mame/blob/master/src/mame/drivers/playch10.cpp MAME source] and [https://forums.nesdev.com/viewtopic.php?f=9&t=9392 this forum thread].<!-- todo: explain more, what lines specifically -->
  
 
I remember someone posting a PCB photo on the NESdev forums several years ago. I never managed to find the thread again, and the image itself would almost certainly be dead now.
 
I remember someone posting a PCB photo on the NESdev forums several years ago. I never managed to find the thread again, and the image itself would almost certainly be dead now.
Line 183: Line 187:
 
To produce an NTSC-compatible output, emulate a Dendy console in which the following modifications have been made:
 
To produce an NTSC-compatible output, emulate a Dendy console in which the following modifications have been made:
 
#The master crystal has been sped up so as to produce the same frame rate as the 2C02 in the NTSC NES.
 
#The master crystal has been sped up so as to produce the same frame rate as the 2C02 in the NTSC NES.
#An audio DSP runs a time-stretching algorithm to undo the ''pitch'' change that results from (1). (Disadvantage: latency&ndash;quality tradeoff, and (D)PCM would still play ''faster'' than on an authentic unmodified console.)
+
#An audio DSP runs a [[wikipedia:Audio time-scale/pitch modification|time-stretching algorithm]] to undo the ''pitch'' change that results from (1). (Disadvantage: latency&ndash;quality tradeoff, and (D)PCM would still play ''faster'' than on an authentic unmodified console.)
#The conceptual equivalent of NESRGB has been installed, to fix the chroma-encoding breakage from (1).
+
#The conceptual equivalent of NESRGB or Hi-Def NES has been installed, to fix the video-signal noncompliance that results from (1).
 +
 
 +
The buffer size for the pitch stretching is not tied solely to the alteration in frame length; it should be tuned for the desired compromise between latency and quality. Admittedly, this leaves the method with no clear advantage over the Hi-Def NES method.
 +
{{spoiler box|1=[...buffer a full frame of] video (TODO: my intention is to compare it with the FCEUX extra-scanline approach, but the wording is currently oversimplified. In particular, a reimplementation of extra scanlines might only need to buffer a number of scanlines equal to the difference between the overclocked and normal frames, as Kevin Horton's Hi-Def NES board does when scaling NES video up to 720p, 960p, or 1080p.)|type=[[User:Eighty5cacao/sloppy|Sloppy]] musings on video buffering}}
  
 
I emphasize that this is intended for an original famiclone or emulator; physically overclocking a real Dendy in this manner would likely damage it.
 
I emphasize that this is intended for an original famiclone or emulator; physically overclocking a real Dendy in this manner would likely damage it.
Line 199: Line 206:
  
 
even crazier idea (don't think too much about it yet): 2x OC master crystal; only allow NMI to fire on every other frame, hoping that the game does not use any other timing source (need audio DSP, NESRGB, blah blah. hope the video display device supports 120Hz, even though a well-behaved game would still only update at ~60Hz under this scheme)
 
even crazier idea (don't think too much about it yet): 2x OC master crystal; only allow NMI to fire on every other frame, hoping that the game does not use any other timing source (need audio DSP, NESRGB, blah blah. hope the video display device supports 120Hz, even though a well-behaved game would still only update at ~60Hz under this scheme)
 +
 +
  
 
also, to make the "extra emulated scanlines per frame" idea more hardware-implementable, for the special case of a 2x factor: instead of having the added dummy scanlines all in one clump, interleave them with the regular lines (1 active, 1 dummy, repeat through the active frame). Apply a one-scanline buffer to allow the pixels to be scanned out at the normal rate. Note, no change in the real-time length of vblank, but it should probably still get a fair share of the added lines.<br />
 
also, to make the "extra emulated scanlines per frame" idea more hardware-implementable, for the special case of a 2x factor: instead of having the added dummy scanlines all in one clump, interleave them with the regular lines (1 active, 1 dummy, repeat through the active frame). Apply a one-scanline buffer to allow the pixels to be scanned out at the normal rate. Note, no change in the real-time length of vblank, but it should probably still get a fair share of the added lines.<br />
Line 205: Line 214:
 
Don't freak out; let me find the fatal flaws by doing my own homework - in particular, I need to look into what existing emulators do, especially in relation to audio.<br />
 
Don't freak out; let me find the fatal flaws by doing my own homework - in particular, I need to look into what existing emulators do, especially in relation to audio.<br />
 
The more important problem is what the PPU should do during "dummy" scanlines that are inside the active frame; halting it by taking it off the bus would break register reads and writes, for example. The PPU would need to be explicitly modified to automatically "disable" all rendering in the usual way on such lines.<br />
 
The more important problem is what the PPU should do during "dummy" scanlines that are inside the active frame; halting it by taking it off the bus would break register reads and writes, for example. The PPU would need to be explicitly modified to automatically "disable" all rendering in the usual way on such lines.<br />
Whatever we do, M2-timed mapper IRQs would ''unfixably'' break if the dummy scanlines are inside the visible frame, because that effectively disrupts the relation of CPU to visible PPU cycles.|type=[[User:Eighty5cacao/sloppy|Sloppy]] failed ideas}}
+
In a hardware implementation, M2-timed mapper IRQs would break if the dummy scanlines are inside the visible frame, because that effectively disrupts the relation of CPU to visible PPU cycles. This is ''unfixable'' for the same reason as the idea at the top of this box: The base console does not generate (and therefore the cartridge connector does not support) separate M2-for-address-decoding and M2-for-mapper-IRQ signals. An emulator implementation could work around this, also halting the APU during the added scanlines, but those are physically impossible in hardware without additional audio/video buffering.
 +
 
 +
 
 +
 
 +
Finally, consider (TODO) the implications of "overclocking" by modifying instruction timings; see for example [https://forums.nesdev.com/viewtopic.php?f=3&t=14567 this NESdev forum discussion about a modified Nestopia build]. I suggest that an implementation should avoid modifying the timing of NOPs, but I don't think that would really help compatibility that much. Although this could in principle be implemented in an FPGA famiclone, would it fail to work with real cartridges due to ROM/RAM chip speeds and/or the aforementioned M2 problem?|type=[[User:Eighty5cacao/sloppy|Sloppy]] failed ideas}}
 +
TODO: Examine [http://tasvideos.org/forum/viewtopic.php?p=438266#438266 the FCEUX extra-scanline implementation]. If I understand said forum post right, it means that the APU is paused during extra scanlines and that a $4011 write cancels any (pending) extra scanlines for the current frame. If this is as simple as described, it would make the overclocking less effective for any game that routinely writes $4011 when starting DPCM samples. It would be better to apply the same sample-start logic that one would use for [[nesdev:Enhancement#Pop reduction|pop reduction]]. The overclocking would be ''totally'' ineffective for a game such as ''Gauntlet II'' that does raster-timed $4011 playback (todo: verify this), but that's a discussion for later.
 +
 
 +
=== Audio enhancements ===
 +
 
 +
==== <span id="Octave_effect">Second- and fourth-harmonic generation</span> ====
 +
A perfect square wave (50% duty cycle) or triangle wave contains only odd harmonics. To make the NES sound a ''bit'' more like a PC Engine by filling in the [[wikipedia:Singly and doubly even|singly-even]] harmonics, one could [[wikipedia:Octave effect|add the suitably-scaled output from a second copy of the APU]] in which the pulse, triangle, and noise units are clocked at twice the normal frequency while DMC is unaffected. In a square or sawtooth wave, the amplitudes of the harmonics decay as 1/f, while in a triangle wave, the amplitudes of the harmonics decay as 1/f<sup>2</sup>. Perhaps a nice compromise between these scaling laws would be to use a power of 3/2; that is, the frequency-doubled sound would contribute 2<sup>-3/2</sup> times the amplitude of the original sound, and a linear combination of .739 * original + .261 * doubled would avoid introducing any new clipping.
 +
 
 +
The process could be extended to doubly- (but not quadruply-) even harmonics at four times the frequency. Frequency-response and performance considerations probably rule out further doubling. To best replicate what a hardware implementation would do, the frequency doubling should take place before any low- and high-pass filtering; that is, both the normal and doubled signals should have the same band limitation in relation to the final mixed output.
  
=== Second- and fourth-harmonic generation ===
+
==== <span id="Miscellaneous_audio">Pop reduction features</span> ====
A perfect square wave (50% duty cycle) or triangle wave contains only odd harmonics. To fill in the [[wikipedia:Singly and doubly even|singly-even]] harmonics, one could add the (suitably scaled) output from a second copy of the APU in which the pulse, triangle, and noise units are clocked at twice the normal frequency while DMC is unaffected; similarly for doubly- (but not quadruply-) even harmonics at four times the frequency. Frequency-response and performance considerations probably rule out further doubling.
+
An implementation of pop reduction should provide the option to attenuate the pops by half (or any specified fraction) rather than just all or nothing.
  
 
== References ==
 
== References ==
 
<references />
 
<references />

Latest revision as of 18:31, 8 July 2020

NESdev wiki

"diagonal mirroring does not solve attribute glitches" – elaborate please? Obviously it is glitch-free for horizontal or vertical scrolling aligned with the nametables, but perhaps Rainwarrior was trying to say that for a general case where the screen overlaps all four nametable regions, it becomes as bad as single-screen mirroring. This is just my quick-and-dirty guess; it needs to be verified with a worked example of free scrolling over diagonally-mirrored nametables, to demonstrate where the name-/attribute table writes go as the screen position covers relevant cases. A test ROM would be nice.
Would 3-screen diagonal mirroring be any better? (The code complexity might not actually be worth it, though.)

This post by Chris Covell mentions the existence of Nibbles in the OneStation 35-in-1

Noticed while lookig at nescartdb:4595 (Uchuu Keibitai SDF) - bootgod should consider:

  • Not using blinking text on the site: note that Firefox 23 has chosen to stop supporting blinking text[1]
  • Relaxing the verification requirement when all of the following conditions are met (I am not saying that any apply in this case):
    • The dumper provides proof that s/he is using an operating system incompatible with the current release of the CopyNES client, as well as an explanation of why s/he is unable to mail the cartridge to bootgod
    • The dumper provides a description (with photographs) of the dumping setup s/he is using
    • The ROM image matches that recognized by No-Intro (or other reliable database...specify?)
    • The game is known for certain to have only one revision (it isn't possible to determine this in an automated manner)

At least one pirate DDR clone (Hot Dance 2000, incorrectly known as "Dance 2000" in GoodNES) is an oversize AxROM, but this doesn't count as "during the NES's commercial era" for obvious reasons.

INES Mapper 045 is described as if it supports PRG RAM; does it really? Does a game on the multicart use PRG RAM?

The karaoke application Golden KTV is an oversize UxROM with 1 megabyte of PRG ROM and thus 6 banking bits. According to CaH4e3, it depends on absence of bus conflicts. Therefore, FCEU-mm/FCEUX "correct" the mapper number to 71; I feel that this does not make as much sense as a heuristic that disables bus-conflict emulation for all oversize UxROM images.

Categories to create

All these should be considered dubious

  • Mappers with PRG ROM in $6000-7FFF (NROM-368, J.Y. Company [all variants], FME-7, SMB2J pirate)
  • Mappers with PRG RAM outside $6000-7FFF (MMC5, FDS, only create the category if another example exists)
  • Mappers with register bits in the address bus (Racermate, etc.; needs better name?)
  • VRC-like pirate mappers (should probably drop the word "pirate" for consistency with "MMC3-like mappers"; in both cases the meaning is sufficiently clear from context)
  • Not in NesCartDB
  • Mappers with registers overlaying PRG RAM (e.g. NES 2.0 Mapper 395)

NES 2.0 submappers

I am of the opinion that there is no valid reason for "no advisory statement" to be made for new dumps nor for new homebrews, and therefore any mapper's submapper 0 SHOULD NOT be defined as such in any new or developing proposal. Therefore, my MMC3 proposal (below) differs from Lidnariq's, but I have no objection to the VRC2/4 proposal.

Generally, each mapper's submapper 0 should be a clearly-defined default that does the right thing for a majority of existing dumps (not including those verified to need a separate submapper).

"iNES 1" format already expresses "no advisory statement"; this deprecates "no advisory statement" along with iNES 1.

But on a related note: Is mapper 155 intended to be used for all games released exclusively with MMC1A chips, or only games that specifically depend on MMC1A behavior? (Resolved?)

  • Trivial: "corresponds is" in the VRC2/4 section must be a typo.
  • If someone created a homebrew game on a 1-screen mirroring variant of backwards UxROM, what NES 2.0 mapper number would fit this best? If the mirroring register were identical to that of Camerica BF9097, could this be shoehorned into a submapper of an existing major mapper, or would we need a new major mapper? (If not, we'd probably define a new major mapper regardless.)
  • Regarding MMC3, it is probably desirable to have at least four submappers, where one bit indicates the behavior for latch 0, and the other bit indicates rising or falling edge. This means that one submapper will describe an ASIC that isn't known to exist (like MC-ACC but with the opposite latch-0 behavior), but this isn't a problem. Compare the VRC4 proposal, where most possible submappers don't describe verified real configurations either. Additional bits can be allocated to distinguish MMC6 and to describe the fixed mirroring behavior of T[EF]ROM if desired. (On hold indefinitely; see talk)

Colour-emphasis games

  • Super Lion King (tcrf, wikia) uses the red emphasis bit on the entire screen (which becomes green on Dendy consoles)
  • Rampart (J) (nescartdb:2200) provides a menu option to set the emphasis bits to be either all on or all off.
  • Mystery Quest (U) (nescartdb:380; what about the FDS game it is ported from? do other regional variants exist?) briefly flashes the red bit when the player character takes damage ([1]; TODO verify with an emulator)
  • Thexder (J) (nescartdb:3456): see above description for Mystery Quest (TODO verify this too)
  • Mini Putt (J) (nescartdb:4684) uses various emphasis settings on the entire screen to indicate weather conditions; further description/verification needed

2C04 palette

We need a list of games (if any) that are verified to use the "extra" colors of the 2C04.

JY Company mapper

Re [2]: $5000 is most likely a DIP switch. FCEU(X) probably implemented it as a reset counter only because, unlike Nestopia, they didn't want to bother implementing an UI for DIP switches.

Compared with MMC5

Does any other company's mapper contain a scanline IRQ counter clocked by 170 transitions of PPU /RD?

Is it verified that JY Company's multiplier always takes 8 cycles? Is it verified (or even correct) that MMC5's multiplier always returns the product immediately? Might either of these actually take a variable number of cycles and return partial results when read early, like the SNES's multiplier?

UNIF

Deprecation

I am aware of at least two obstacles to a practical implementation of said deprecation:

  • CaH4e3 has been assigning UNIF mappers for just about all the pirate cartridges he recently dumped; I'm not aware that he has assigned any NES 2.0 mapper numbers nor implemented support for the same in FCEU-mm.
  • Quietust's "Drip" homebrew (UNL-DRIPGAME)

"Namespace"

I disagree with this move and the precedent it established, for the following reasons:

  1. The MediaWiki software calls that a "subpage," not a "namespace."
  2. The idea of "reduc[ing] clutter" in the main namespace is entirely pointless, given that mappers, pinouts, homebrew projects etc. have been allowed to coexist in the main namespace with only categories to distinguish them. To follow this convention would create additional hassle to move an article if an NES 2.0 mapper number is defined for a pirate or homebrew mapper that was formerly UNIF-only.

Unofficial opcodes

What evidence do we have, if any, that Nintendo's lot-check policy included a strict prohibition on all unofficial opcodes? A few licensed games late in the NES's life used them. See nesdev:CPU unofficial opcodes#Games using unofficial opcodes.

Clockslide

Are any of the uses of SKB opcodes clockslides? A CMP clockslide destroys the flags, but a $80 or $89 clockslide wouldn't need to. Puzznic (which uses SKB $89) doesn't do any raster splits, so it is more likely Beauty and the Beast (which uses SKB $80) that uses a clockslide, if at all.

Digression: Bad mappers

The problem with the Gradius II hack mentioned here is that iNES mapper 025 is among several iNES mappers not accepted by Nestopia; it recognizes (unmodified versions of) games using certain Konami mappers using a database; IIRC soft-patching works fine, but hard-patching does not for obvious reasons.

Should the "Bad iNES Mappers" category on nesdevwiki have a subcategory "INES mappers deprecated by Nestopia"? Do we need to create "File:Mfr icon Konami Bad.png" for the mapper table? Or perhaps bad status should be (indicated by a strikethrough? and) orthogonal to manufacturer information

Exact quote from the Nestopia 1.38 changelog: "Mappers 21, 23, 25 and 185 no longer supported using plain iNES files because of format restrictions." That is, ROMs whose headers specify these mappers are rejected if not recognized by Nestopia's internal database of hashes. (Note that mapper 22 is not deprecated because it is not similarly ambiguous.)

For mapper assignments found to be duplicated between planes 0 and 1, why was the plane 0 assignment not always chosen as final?

MMC3 IRQs

I feel that a statement about lot check that once appeared in nesdev:MMC3#Variants is questionable. I seem to recall that Star Trek: 25th Anniversary and My Life My Love: Boku no Yume: Watashi no Negai depend on the newer revision's behavior in some way (TODO: details. Nestopia's changelog mentions Star Trek: 25th Anniversary at version 1.30)

New issues

Felix the Cat supposedly depends on MMC3A behavior, but NesCartDB shows US and PAL releases using MMC3C. TODO: Check what Nestopia's database does for this game, what mirroring the game uses during gameplay, and whether it does anything tricky like using IRQs to "skip" the scroll past nametable space used by the status bar (cf. Krusty's Fun House)

"Great" minds think alike

It appears that some famiclone developers have made games similar to Mineshaft and Lawn Mower.

What does Tower & Shaft have to do with the Mineshaft family's origin?

Emulators

Commercial

  • The official name of "acNES" might be QFC

Other emulators

  • bsnes higan currently includes NES emulation ("bnes")

TASVideos comparison of NES emulator accuracy

sloppiness alert, as usual. I know I really should register for the TASVideos forums in order to bring up these issues, but I'm busy at the moment.

  • NTSC filter issues:
    • Nestopia should be able to pass tvpassfail because it has an NTSC filter at least on Windows. Was it listed as failing because the build tested lacks said filter, or perhaps simply because it is not enabled by default? Did somebody consider the filter not to be accurate enough? Or is the problem with the aspect ratio (which is supported via the "TV Aspect" setting)? Note that the sample video is from Bisqwit's NTSC filter as implemented in nesemu1, but it seems within reason of what can be achieved by tweaking blargg's filter (Nestopia). Someone should record from real hardware as a comparison.
    • Similarly for puNES
  • Testing methodology for APU volume tests needs to be explained/reconsidered better. I need to find the NESdev post in which you (Tepples) said that Nestopia's noise channel is too loud - yet it is listed as passing volumes (but not apu_mixer)
  • Power-up palette unavoidably varies between NES units
  • Clarify that only one of the MMC3A/B tests should pass on any emulator that does not use a database of game-specific settings/hacks
  • Any tests affected by ROM headers, such as iNES 1 headers misinterpreted as NES 2.0 or vice versa?
  • Should we point out unofficial Nestopia builds? (not for TASing obviously)

MMC2 and PRG RAM

The PlayChoice-10 version of Mike Tyson's Punch-Out!! has battery-backed PRG RAM, as mentioned in the MAME source and this forum thread.

I remember someone posting a PCB photo on the NESdev forums several years ago. I never managed to find the thread again, and the image itself would almost certainly be dead now.

The problem is that Nestopia's internal database seems to enforce absence of PRG RAM for that game, going against the wishes of the iNES header.

See also: http://forums.nesdev.com/viewtopic.php?p=130478#p130478

Drag's palette generator

Why isn't there configurable clipping handling for negative RGB values, as there is for values over 255?

Colorimetry settings should allow 4 decimal places: the default D65 white point needs this (TODO: provide citation that Adobe Photoshop allows such)

Enhancement ideas

Overclocking methods

Here are some is one alternative methods which I hope are is reasonably amenable to implementation in a famiclone or emulator while avoiding unreasonable game breakage.

Arbitrary tunability is a non-goal, unlike the existing "extra scanlines per frame" emulator implementation. Another non-goal is applicability to authentic consoles.

This could work:

To produce an NTSC-compatible output, emulate a Dendy console in which the following modifications have been made:

  1. The master crystal has been sped up so as to produce the same frame rate as the 2C02 in the NTSC NES.
  2. An audio DSP runs a time-stretching algorithm to undo the pitch change that results from (1). (Disadvantage: latency–quality tradeoff, and (D)PCM would still play faster than on an authentic unmodified console.)
  3. The conceptual equivalent of NESRGB or Hi-Def NES has been installed, to fix the video-signal noncompliance that results from (1).

The buffer size for the pitch stretching is not tied solely to the alteration in frame length; it should be tuned for the desired compromise between latency and quality. Admittedly, this leaves the method with no clear advantage over the Hi-Def NES method.

I emphasize that this is intended for an original famiclone or emulator; physically overclocking a real Dendy in this manner would likely damage it.

Region detection code would still see the system as a Dendy, as the CPU/PPU relationships have not been changed, only the master crystal. Where working around this is essential, one could bypass the overclocking (that is, emulate an unmodified 2A03/2C02 console) for the first few frames and then transfer the state to the modified console.

While these will NOT (see talk for explanation on the first part):

TODO: Examine the FCEUX extra-scanline implementation. If I understand said forum post right, it means that the APU is paused during extra scanlines and that a $4011 write cancels any (pending) extra scanlines for the current frame. If this is as simple as described, it would make the overclocking less effective for any game that routinely writes $4011 when starting DPCM samples. It would be better to apply the same sample-start logic that one would use for pop reduction. The overclocking would be totally ineffective for a game such as Gauntlet II that does raster-timed $4011 playback (todo: verify this), but that's a discussion for later.

Audio enhancements

Second- and fourth-harmonic generation

A perfect square wave (50% duty cycle) or triangle wave contains only odd harmonics. To make the NES sound a bit more like a PC Engine by filling in the singly-even harmonics, one could add the suitably-scaled output from a second copy of the APU in which the pulse, triangle, and noise units are clocked at twice the normal frequency while DMC is unaffected. In a square or sawtooth wave, the amplitudes of the harmonics decay as 1/f, while in a triangle wave, the amplitudes of the harmonics decay as 1/f2. Perhaps a nice compromise between these scaling laws would be to use a power of 3/2; that is, the frequency-doubled sound would contribute 2-3/2 times the amplitude of the original sound, and a linear combination of .739 * original + .261 * doubled would avoid introducing any new clipping.

The process could be extended to doubly- (but not quadruply-) even harmonics at four times the frequency. Frequency-response and performance considerations probably rule out further doubling. To best replicate what a hardware implementation would do, the frequency doubling should take place before any low- and high-pass filtering; that is, both the normal and doubled signals should have the same band limitation in relation to the final mixed output.

Pop reduction features

An implementation of pop reduction should provide the option to attenuate the pops by half (or any specified fraction) rather than just all or nothing.

References