Yes! Nesdev rulz!! I'm learning a lot! And people here are polite.I'm kind of disappointed with the Brazilian forums...Unless there's some of them I had not come across, most are very superficial even for me that consider myself a rookie.

But back on topic: Were these tests somehow conclusive?Should I try to capture some videos of the clones?I think I should try to explain the audio bug more clearly...I'll look this back tomorrow.

I can verify that it does hang on reset on my Famicom, using a PowerPak or Everdrive N8 with a 72-60 pin adapter. It also has some minor visual artifacts / jumpy screen due to the known problem with $2004. These problems do not occur on my NES, precisely as expected. (In case it wasn't made clear already: this game was not released in Japan.)

I don't really see a necessity to seek out the original cart, though. All of the individual factors involved seem to be well understood. It's a very simple discrete mapper, and the effects involved aren't directly related to the mapper anyway.

Is there some expectation that what we know doesn't precisely describe the behaviour of the real cart already?

I mean, if someone has it on hand already, go ahead and test it if you like, but I don't think the potential for gained knowledge is very high.

I don't really see a necessity to seek out the original cart, though. [...] Is there some expectation that what we know doesn't precisely describe the behaviour of the real cart already?

The expectation is not among us as much as among people who don't know what they don't know. I wanted a way to make the misbehavior obvious enough for even the lowest common denominator who frequent YouTube: "I plug this cartridge into this console, and this bug happens." By designing a demonstration that uses all original parts that one could reasonably have encountered prior to 1997, when emulation started to take off, we eliminate cause for comments to the effect "You cheated; you used a flash cart and a Famicom." It's the same naivety that leads people to believe that use of the iNES container format in Virtual Console implies Nintendo copied games from infringing ROM sites.

Hrm, I was expecting that link to go to Donald Rumsfeld's "unknown unknowns" quote, but regardless: IMO there's not even a hint of an unknown here to investigate at this point.

I mean, if somebody really wants to own this game that's fine by me, but I'm just trying to suggest that we almost certainly have it nailed already. (If you feel like buying the game to prove that we have not, I'm not gonna stand in your way.)

tepples wrote:

It's the same naivety that leads people to believe that use of the iNES container format in Virtual Console implies Nintendo copied games from infringing ROM sites.

But you're the one questioning the legitimacy of the emulated version in this case. O_o?

Right now I personally am satisfied. There is no pressing need to reproduce the test with all original parts. But if we eventually make a video demonstrating this bug to the public, I'd prefer it be done with original parts to avoid the appearance of impropriety.

We know that the glitchy graphics occur on a rev E or earlier PPU. Early NES-001s used the rev E chips, so Micro Machines will show glitches on them. On my AV Famicom, pressing reset at anything other than during the racing will cause a glitchy static image and a crash. Sometimes pressing reset again will get out of the crash state, more often it won't. However, pressing reset on while racing will reset to the Codemasters logo reliably.

AFAIK, these signals are not directly available, but it is possible to detect a reset by observing the behavior of other signals. Some mappers do initialize their registers to known values while others don't... I believe the wiki has this information, doesn't it?

PowerPak and Everdrive N8 both rely on being able to detect reset.Mapper 31 requires power-on detection, but not reset.There's a suggestion that some MMC5 games have power-on expectations but I don't know if that's a reliable feature of the mapper.

There might be others, but the vast majority of mappers don't have any kind of power/reset initialization. Usually what I've found when I've tested them is random results (i.e. any state possible), but not evenly distributed.

I believe reset detection is done based on the M2 clock signal, which halts while reset is held? I don't know how mapper 31 detects power-on though, infiniteneslives implemented it.

PowerPak and Everdrive N8 both rely on being able to detect reset.Mapper 31 requires power-on detection, but not reset.There's a suggestion that some MMC5 games have power-on expectations but I don't know if that's a reliable feature of the mapper.

There might be others, but the vast majority of mappers don't have any kind of power/reset initialization. Usually what I've found when I've tested them is random results (i.e. any state possible), but not evenly distributed.

I believe reset detection is done based on the M2 clock signal, which halts while reset is held? I don't know how mapper 31 detects power-on though, infiniteneslives implemented it.

I noticed other games that fail on a soft reset. For instance, Bao Xiao San Guo.7z <Bao Xiao San Guo (Ch).nes> from GoodNES3.23b crashes with the following error in Nintendulator when reset during the intro:

Code:

Invalid opcode $CF (DCP) encountered at $8523

A hard reset works. But, as you suggest above, that might not reflect real hardware behavior.

Regarding the list of ROMs above, all of them appear to require a hard reset to properly start up, with one exception: Cvetnye Linii (Color Lines). That Dendy ROM gets stuck in a loop on reset. The reset address and the IRQ address are both $FF97. Consequentially, in my emulator, it keeps bouncing between the following 2 instructions:

Code:

00:FF97:58 CLI 00:FF98:A9 00 LDA #$00

According to the wiki, the APU Status register ($4015) is set to 0 on reset. This disables DMC interrupts. But, what about Frame Counter interrupts? Are they disabled on reset? That is what is causing my emulator to get stuck above.

According to the wiki, the APU Status register ($4015) is set to 0 on reset. This disables DMC interrupts. But, what about Frame Counter interrupts? Are they disabled on reset? That is what is causing my emulator to get stuck above.

It also says IRQ inhbit is set on reset, though, which should block it unless cleared by the software?

It resets to this address:

Code:

00:FF97:58 CLI

Edit: Is it possible that the Dendy resets the APU?

Edit 2: For the CPU Power Up State wiki page, was $4017 verified based on the behavior of the APU or did someone attempt to read from that register. Aside from $4015, all the APU registers are write-only.

Edit 3: No other emulator has issues resetting this Dendy ROM. I assume this is some bug in my emulator, but I can't pinpoint the issue. Any suggestions?

Now I wonder if the CIC circumvention hack could cause any damage whatsoever to an AV Famicom... I paid a lot of $$$ for mine (importing from Japan and paying 60% of price + shipping in taxes), so I'd really hate to screw it up.

Who is online

Users browsing this forum: No registered users and 8 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum