"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 looking at nescartdb:4595 (Uchuu Keibitai SDF) - bootgod should consider:
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: Prerequisites:
Steps to reproduce:
Actual results:
Expected results:
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 |
All these should be considered dubious
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.
Resolved invalid |
---|
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?)
We need a list of games (if any) that are verified to use the "extra" colors of the 2C04.
Resolved |
---|
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 [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.
Does any other company's mapper contain a scanline IRQ counter clocked by 170 transitions of PPU /RD?
Is it verified that J.Y. 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:
I disagree with this move and the precedent it established, for the following reasons:
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.
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?
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)
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?
Caveats |
---|
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. |
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.
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.volumes
(but not apu_mixer
)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.
Request withdrawn |
---|
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)
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.
To produce an NTSC-compatible output, emulate a Dendy console in which the following modifications have been made:
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.
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.
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.
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.