Difference between revisions of "User:Eighty5cacao/misc/NES"
(→Overclocking methods: This post contains a dead link to a GitHub repository. Rewording is TODO.)
(→Overclocking methods: This post contains a dead link to a GitHub repository. Rewording is TODO.)
Latest revision as of 07:20, 24 January 2020
- 1 NESdev wiki
- 2 Unofficial opcodes
- 3 Digression: Bad mappers
- 4 MMC3 IRQs
- 5 "Great" minds think alike
- 6 Emulators
- 7 TASVideos comparison of NES emulator accuracy
- 8 MMC2 and PRG RAM
- 9 Drag's palette generator
- 10 Enhancement ideas
- 11 References
"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
- 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.
|Nestopia bug needs more testing|
Please disregard this content until I remove this note
Additionally, here's something I first noticed in an older official Nestopia version (1.38?) in which MMC6 battery-backed saves are not properly cleared within a session and can corrupt configuration data:
Steps to reproduce:
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
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
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.
I'd like to dispute the flagging of 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.
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)
- 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 (; 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
We need a list of games (if any) that are verified to use the "extra" colors of the 2C04.
JY Company mapper
INES Mapper 090 should probably be moved to "JY Company"; INES Mapper 209 and INES Mapper 211 should then be redirected there, as the original mapper 90 article already explains adequately what mappers 209 and 211 are for. Of course, the resulting "JY Company" article would need some tweaks to its lede. (Do I understand correctly that it's deprecated to have permastub mapper articles under INES-number titles when a company name and/or ASIC designation is known?) Also, in the interest of factual accuracy, 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.
Re : $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?
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:
- 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.
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? 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.)
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)
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
What does Tower & Shaft have to do with the Mineshaft family's origin?
- The official name of "acNES" might be QFC
This assumes that the "FC" part of "QFC" stands for Famicom. (any other ideas?)
The message "The DISP SW is JAPAN MODE now but this GAME is NES version" may or may not be relevant to the NES emulator. As mentioned at the top of the TCRF article's talk page, there is a corresponding message "The DISP SW isn't JAPAN MODE now but this GAME is JAPAN version"; either may result from the use of region hacks together with the codes for debug mode.
bsneshigan currently includes NES emulation ("bnes")
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
tvpassfailbecause 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
- Nestopia should be able to pass
- 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
- 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
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.
Drag's palette generator
Please restore the "Scale" clipping style; I felt it was a good compromise between Darken and Desaturate. (You may create an "
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)
are some is one alternative method s 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:
- 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–quality tradeoff, and (D)PCM would still play faster than on an authentic unmodified console.)
- 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.
|Sloppy musings on video buffering|
[...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.)
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):
|Sloppy failed ideas|
For a console of any region, run the CPU core at some integer multiple of its normal NTSC speed, while everything else (APU, M2 signal on cartridge connector, PPU) has its normal speed. Breakage of region detection could be worked around by not applying the overclocking for the first few frames.
(solution: need to explicitly modify mappers instead of dividing the physical M2 signal)
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.
Finally, consider (TODO) the implications of "overclocking" by modifying instruction timings; see for example 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?
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.
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.