From Pin Eight
< User:Eighty5cacao‎ | misc
Revision as of 18:55, 20 June 2016 by Eighty5cacao (talk | contribs) (Enhancement ideas: misc. comments)
Jump to: navigation, search

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, JY Company [all variants of 90/209/211], 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

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. (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? 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 (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?



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)


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.


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?

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.)


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?



  • 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? 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)


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:

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:

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.)
  3. The conceptual equivalent of NESRGB has been installed, to fix the chroma-encoding breakage from (1).

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 this will NOT (see talk for explanation):

Second- and fourth-harmonic generation

A perfect square wave (50% duty cycle) or triangle wave contains only odd harmonics. To fill 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; similarly for doubly-even harmonics at four times the frequency.