Do we need to create "Category:Mappers with more than 8 KiB CHR RAM" on nesdev wiki?
This post by Chris Covell mentions the existence of Nibbles in the OneStation 35-in-1
- 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)
|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 needs further testing to determine whether the bug is still present & how accurately I have remembered the steps to reproduce
What evidence do we have, if any, that Nintendo's lot-check policy included a strict prohibition on all unofficial opcodes?
I can think of three commercial games that use them:
- Puzznic (all regions) uses DOP (SKB), specifically opcode $89 — I remember testing all regional variants as well as a few copies from pirate multicarts — but why? There is no 65C02 (or any 6502-family CPU at all) in the arcade version. Next TODO is to compare development staff between the NES and PC Engine versions. The point of the TASVideos discussion seems to be that BizHawk was mistakenly emulating $89 as a single-byte NOP
- Beauty and the Beast (E) uses a different SKB ($80) (source: puNES 0.20 changelog)
- Super Cars (U) uses LAX
- Aladdin (E) uses SLO — this is the official release, as opposed to various pirate originals
Admittedly, I do not have reliable sources for any of this; only in the case of Puzznic do I have confidence that the dump is good, for the reason stated.
Are any of the SKB uses clockslides?
Puzznic doesn't do any raster splits, so it is more likely Beauty and the Beast that uses a clockslide, if at all.
If one really needed a clockslide with no side effects, one could adapt the aforementioned example to use unofficial opcodes as follows:
which, if executed from the first byte, disassembles as:
SKB #$80 SKB #$80 SKB #$80 SKB #$80 SKB #$80 SKB #$80 IGN $EA
or from the second byte:
SKB #$80 SKB #$80 SKB #$80 SKB #$80 SKB #$80 SKB #$04 NOP
Of course, any encodings of
However, as neither game is known to execute any unofficial opcodes besides
|RESOLVED WONTFIX: see talk|
nesdev:CPU unofficial opcodes refers to SKB and SKW as "NOP"; should this be fixed?
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.)
Again, I feel the statement about lot check is questionable (NB: it has already been amended) - 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)
"Great" minds think alike
What does Tower & Shaft have to do with the Mineshaft family's origin?
- BizHawk (multiple systems, intended primarily for tool-assisted speedrunning)
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.
- 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
tvpassfailbecause 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.
Really,IMO they should not be running this test until they routinely encode video files that contain the NTSC filter.
- 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/iNES 2.0?
- 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.
- http://forums.nesdev.com/viewtopic.php?f=9&t=9392 seems to resolve this adequately