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

From Pin Eight
Jump to: navigation, search
(Categories to create: inclusion of 60 was a mistake (it is a reset-based mapper); what I meant needs rechecking)
(NES 2.0 submappers: deprecating "no advisory statement" as mentioned on talk; also remove useless VRC2/4 garbage)
Line 52: Line 52:
  
 
=== [[nesdev:NES 2.0 submappers|NES 2.0 submappers]] ===
 
=== [[nesdev:NES 2.0 submappers|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 submapper 0 SHOULD NOT be defined as such for any mapper whose proposal does not already designate it as invalid (this includes MMC3 [see below] and excludes VRC2/4). Instead, submapper 0 should be a clearly-defined default that does the right thing for a majority of existing dumps (not including those known to need a different submapper).
 +
 +
iNES 1.0 format already expresses "no advisory" statement; this deprecates "no advisory statement" along with iNES 1.0.
 
{{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''? ([http://wiki.nesdev.com/w/index.php?title=INES_Mapper_155&diff=9380&oldid=7959 Resolved?])
*It isn't clear which major mapper number(s) should be used for the [[nesdev:NES 2.0 submappers#021, 023, 025: VRC4|VRC4]] variants. Is the major mapper for each board required to be the same as in iNES? Or should multiple major mappers be accepted to describe a given board as long as the submapper is valid? (That is, should 21.9, 23.9, and 25.9 all be accepted as VRC4a, with the emulator optionally displaying a warning message when the major mapper is not as expected? Or is the emulator required to accept only 21.9 and hard-reject the others?)
+
*Trivial: "corresponds is" in the VRC2/4 section must be a typo.
**Trivial: "corresponds is" 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 of the possible submappers don't describe verified real configurations<!-- no pun intended --> either. Additional bits can be allocated to describe the fixed mirroring behavior of T[EF]ROM if desired.
 
*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 of the possible submappers don't describe verified real configurations<!-- no pun intended --> either. Additional bits can be allocated to describe the fixed mirroring behavior of T[EF]ROM if desired.

Revision as of 20:55, 12 December 2014

Active issues

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

Uchuu Keibitai SDF uses MMC5 audio for sound effects. Speaking about that profile, 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?

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?)
    • Mappers using only the address bus (58, 174, 200, 201, 231 - subcat of the above)

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 submapper 0 SHOULD NOT be defined as such for any mapper whose proposal does not already designate it as invalid (this includes MMC3 [see below] and excludes VRC2/4). Instead, submapper 0 should be a clearly-defined default that does the right thing for a majority of existing dumps (not including those known to need a different submapper).

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

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 of the possible submappers don't describe verified real configurations either. Additional bits can be allocated to describe the fixed mirroring behavior of T[EF]ROM if desired.

Colour-emphasis games

  • Super Lion King (tcrf, wikia) and some[?] versions of Aladdin (unlicensed, by Super Game) use the red emphasis bit on the entire screen, but some Dendy consoles swap the functions of the red and green bits. (See Dendy Chronicles episodes #5 and 6 respectively)
  • Rampart (J) (nescartdb:2200) provides a menu option to set the emphasis bits to be either all on or all off.
  • Rampart (U) (nescartdb:122) uses [TODO: specify] to highlight the score banners in 2-player mode (see e.g. [1]; TODO verify)
  • Mystery Quest (U) (nescartdb:380; do other regional variants exist?) briefly flashes the red bit when the player character takes damage ([2]; TODO verify with an emulator)
  • Thexder (J) (nescartdb:3456): see above description for Mystery Quest (TODO verify this too)

2C04 palette

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

JY Company mapper

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?

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?

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

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.

  • What is "overlay H" for Nestopia? Is it a platform-specific component? (It is mentioned here, and I seem to recall that "R. Belmont" focuses on Unix-like OSes.)
    • 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/iNES 2.0?
  • 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?f=9&t=9392, http://forums.nesdev.com/viewtopic.php?p=130478#p130478

Drag's palette generator

References