User talk:Eighty5cacao/misc/NES

From Pin Eight
Jump to: navigation, search

Previous discussions:

SKB in Puzznic[edit]

I should probably have read a few posts down on that TASVideos thread: The operand of the SKB is 00 (which rules out a clockslide), and executing NOP BRK there causes screen shaking. Do we need to specifically mention this somewhere? --Eighty5cacao (talk) 03:29, 6 January 2014 (UTC)

Resolved --Eighty5cacao (talk) 00:05, 7 January 2014 (UTC)

Deprecated mapper 1.3[edit]

About the deprecation of mapper 1.3 in favor of 155: I've been using "deprecation" to refer to something that emulators SHOULD support but new releases SHOULD NOT use. For example, emulators SHOULD support 1.3, but dumps SHOULD be released as mapper 155. Would it be worthwhile for me to introduce {{RFC 2119}} on --Tepples (talk) 21:12, 18 January 2014 (UTC)

It looks like you already did, and I have no objection. (In the future, if you do not need further information to proceed with a NESdev wiki edit, and it is sufficiently obvious from a glance at RC what is going on, a talkpage post isn't necessary.) --Eighty5cacao (talk) 22:12, 18 January 2014 (UTC)

Categories for creation[edit]

"Mappers with large PRG RAM" I can understand, because that requires logic in the mapper for 1. decoding $6000-$7FFF to a second memory and 2. controlling the upper PRG address lines when that memory is decoded. FME-7, MMC1, and MMC5 qualify; MMC3 does not because its PRG logic sets bank bits high as if the address were $E000-$FFFF. As you may have seen in nesdev:RC, population of that one has begun. Likewise "Mappers with ROM nametables" would work because it requires decoding $2000-$2FFF to CIRAM or CHR ROM. "Mappers with large CHR RAM", on the other hand, doesn't appear so notable because any CHR ROM mapper can bankswitch a RAM in that socket just as easily, and NES 2.0's CHR RAM size field is made for this. If you meant things like CPROM, Oeka Kids, and RacerMate where even a pre-NES 2.0 header should imply more than 8 KiB, perhaps a better name is in order. --Tepples (talk) 05:22, 21 January 2014 (UTC)

I did specifically mean CHR RAM, and I hadn't thought at all how NES 2.0 related to all this. I'm fine with your WONTFIX vote on that one. "Mappers with ROM nametables" is meant to contain at least VRC6 and JY Company's mapper (it refers only to capability, not to actual use by commercial games; this is the same logic that supports the WONTFIX). --Eighty5cacao (talk) 06:34, 21 January 2014 (UTC)
As for mappers "like CPROM, Oeka Kids, and RacerMate where even a pre-NES 2.0 header should imply more than 8 KiB," that should probably be documented on a regular article rather than a category. I don't have an opinion as to which article, though. --Eighty5cacao (talk) 06:39, 22 January 2014 (UTC)
On second thought, if you really want that to be a category, might "Mappers requiring large CHR memory" be a suitable name? --Eighty5cacao (talk) 00:52, 20 March 2014 (UTC)

No-Intro's inclusion criteria[edit]

From the user page: "and not qualifying for No-Intro's inclusion criteria". I see no detailed criteria on their website. It does list "fakes" and "hacked/unofficial stuff" in opposition to "original licensed cartridges", yet there's a record for Klax for NES, which isn't licensed by Nintendo. Nor is there any form to register for the forum or for people without a forum account to contact the site's administrators. Now that the nineties are over, how are people supposed to find out what games they have time for? --Tepples (talk) 15:48, 19 March 2014 (UTC)

I was assuming the criteria were mainly the availability of a physical cartridge to (re)dump, similar to BootGod's database. This has nothing to do with it being a "pirate" game, other than the inherent rarity of most (Asian) pirate-original games compared to licensed games. I never bothered to investigate what the criteria actually were; all I had in mind was that the No-Intro set I found lacked this game and many other pirate originals.
But that is all beside the point, which is to note that an oversize AxROM exists but shouldn't be mentioned in that NESdev wiki article as an example "during the NES's commercial lifespan." --Eighty5cacao (talk) 16:48, 19 March 2014 (UTC) (+ 21:23, 18 May 2014 (UTC))
I was mostly worried about Klax yes and Battle Kid no, despite that I own a cartridge of both. Or is it the 5 year rule that I saw somewhere on the forums? --Tepples (talk) 20:52, 19 March 2014 (UTC)
No-Intro's Genesis database does appear to include Pier Solar and the Super Fighter Team releases. Hmmm... --Eighty5cacao (talk) 00:49, 20 March 2014 (UTC)


I'm aware that the latch-0 behavior has been found to match MMC3C, but I still favor allocating two bits of submappers (with all four values valid), in case some pirate game is found that depends on "falling-edge MMC3A" behavior but can otherwise be emulated within the standard MMC3 family. (This is purely hypothetical; I do not have a specific example.) --Eighty5cacao (talk) 21:46, 2 May 2014 (UTC)

I'm inclined to agree given how the IRQ works in RAMBO-1. --Tepples (talk) 13:38, 3 May 2014 (UTC)
While looking for an example that I misremembered as being a pirate mapper, I found that Taito TC0690 also appears to watch for falling edges of A12, given that said page also mentions a 4-cycle delay. (Did Disch really mean CPU cycles, or could it be a typo for PPU cycles? This needs clarification.) I admit that most pirate mappers have not been fully investigated in this respect, though. --Eighty5cacao (talk) 04:13, 4 May 2014 (UTC)

Bump. Please compare my original suggestion to kevtris's proposal as described by Lidnariq, which isn't quite as orthogonal. (To clarify my own suggestion: In the event that a game does not require one specific behavior, prefer MMC3C behavior.) --Eighty5cacao (talk) 03:59, 16 August 2014 (UTC)

To clarify further:
(ED: Since kevtris's proposal has already been accepted, my proposal is unactionable until such time as the creation of a "NES 3.0" format provides an opportunity to modify the submapper assignments further. Eighty5cacao (talk) 04:53, 9 August 2015 (UTC) + 18:25, 24 March 2016 (UTC))
Bit 0: 0=generate IRQ on every scanline when latch holds 0, 1=generate IRQ only when latch is changed to 0
Bit 1: 0=clock counter on rising edges of A12, 1=falling edges
In the event that any of the bits are "don't care," use 0.
Thus MMC3C = 0, MMC3A = 1, MC-ACC = 2 (assuming that a game actually depends on a particular behavior). What are the arguments for and against having a "no advisory statement" status, as opposed to logging warnings if the ROM is not in a database of good-dumped commercial games and writes 0 to $C000, regardless of submapper? --Eighty5cacao (talk) 19:24, 16 August 2014 (UTC) (+ 04:43, 23 August 2014 (UTC))
In general, unless there is ambiguity, it seems that the use of "iNES 1" format is satisfactory to express "no advisory statement." When an image does need to use NES 2.0 format to resolve ambiguity, it should still be covered by a warn-by-default policy, which makes a "no advisory statement" submapper wasteful. --Eighty5cacao (talk) 20:43, 5 October 2014 (UTC) (+ 02:05, 14 October 2014 (UTC))

Digression: NES vs. Game Boy[edit]

In response to:

"I'm under the impression that compared to NES games, far fewer popular Game Boy games other than Prehistorik Man's intro actually require high-precision timing because the Game Boy has an MMC5-class scanline counter built in."

Parodius uses mid-scanline effects to draw Vic Viper's lasers [1]. IIRC this applies only to the original DMG version, not the GBC version in one of the European Konami GB Collections. --Eighty5cacao (talk) 03:14, 30 May 2014 (UTC)

Mapper 60[edit]

nesdev:INES Mapper 174: "Similar mappers: 58, 60, 212, 231" (emphasis mine)

But how exactly is 60 related? The reset line isn't part of the address bus, if I understand right. 60 is designed to contain NROM-128 games (like 200), while 174 supports both NROM-128 and -256. Does that have something to do with it? --Eighty5cacao (talk) 20:44, 12 December 2014 (UTC)

User:Zzo38/Mapper B[edit]

To prevent future confusion by noobs, is it worth:

  • Editing that page to explicitly contain a sentence like, "The mapper number 670 would currently fall in the Supplementary Ideographic Plane, but this mapper conceptually belongs in the Supplementary Multilingual Plane"?
  • Reserving #670 as a "bad" mapper?

--Eighty5cacao (talk) 17:51, 29 March 2015 (UTC)


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

I don't see how that could possibly work. Cartridges need M2 to decode addresses in ranges inside $4020-$7FFF. They use this to determine when to enable WRAM and mapper ports. --Tepples (talk) 14:40, 20 June 2016 (UTC)

My apologies for not understanding that despite my regular NESdev reading. My concern was naturally about cycle-timed mapper IRQs. I suppose a famiclone implementation would have to load ROMs from SD card or conceptual equivalent rather than taking real cartridges; it would be of the type that uses FPGAs to emulate both the console itself and mappers, with the mappers being modified instead of anything in the core console.
I seem to remember that at least one of the VTxx OneBus famiclone models has a register-controllable option to multiply the CPU speed by 3 relative to the usual 2A03 (or Dendy?) speed, but I don't have the documentation handy. I don't know anything about the physical implementation, and the fact that it is a OneBus makes it less relevant here.
However, I intended that point to be about OCing a 2A03/2C02 which already (trivially) has the desired (2C02) frame rate, not a Dendy. I can see how a corrected implementation of "double speed" could be applied to a console of any region, though. Sorry for the confusing use of unordered list markup for the outer list. --Eighty5cacao (talk) 18:07, 20 June 2016 (UTC)
I just figured out how instruction timing modification could be made to work on a cartridge as long as the memory controller can distinguish RAM on the cart from a mapper. Run the CPU at double speed, and save bytes read from $8000+ as part of instructions to a cache. When accessing memory that isn't I-cached, add a wait state to sync to M2. When accessing memory space internal to the Control Deck ($0000-$401F), prefetch the next instruction byte if possible. Caching tight loops and prefetching during RAM access and internal operation should speed up several kinds of processing. After a mapper write, invalidate the instruction cache. Usually this means $8000+, but when running games using mapper ports at $6000-$7FFF (such as Urusei Yatsura: Lum's Wedding Bell using 87 and MMC3 multicarts containing Nintendo World Cup) or games that snoop PPU or APU writes (such as allegedly MMC5), it would need to also treat those addresses as mapper space. --Tepples (talk) 00:22, 15 December 2016 (UTC)