Nintendulator 0.980

Nintendulator 0.980
by on (#231540)
I noticed that there was a new official release on January 1, 2019. It's been 9 years since the last official release.

What's new in this version? Improved emulation accuracy? Does it pass more test ROMs?
Re: Nintendulator 0.980
by on (#231541)
Battleloads level 2 freezes:

Image
Re: Nintendulator 0.980
by on (#231542)
It's seems to be just an official release of the "unstable" (WIP) build. Compared to the previous "unstable" build, the Debugger adds counting the total number of cycles, and some addition regarding the range of the Arkanoid paddle. My NintendulatorNRS fork (recent build available here) has all that the previous "unstable" build had, some PPU/APU fixes that are relevant for test ROMs, Battletoads and Micro Machines (though I have to admit that I have not tried either recently), support for enhanced VT03/VT09/VT32 famiclones, Vs. Dual System, the current NES 2.0 additions, plus all NES 2.0 mappers that are on the wiki, and most-importantly: per-device configuration of buttons, not per-port.
Re: Nintendulator 0.980
by on (#231544)
zeroone wrote:
I noticed that there was a new official release on January 1, 2019. It's been 9 years since the last official release.

That's precisely why I released it.

zeroone wrote:
What's new in this version? Improved emulation accuracy? Does it pass more test ROMs?

As already noted, all of the stuff that had been added to 0.975 over the past 9 years - better NES 2.0 support (including in the header editor), Dendy timing, SNES Mouse support, some controller configuration fixes, some debugger improvements (breakpoints triggering on intermediate reads, PPU debugging being less slow, being able to properly trace code in ExRAM and the NSF player), support for larger amounts of PRG+CHR RAM, some emulation improvements (DMA timing fixes, branch timings with interrupts, some obscure PPU details), and about 30 new mappers.

It's been a rather long time since I've bothered running all of the various test ROMs, so there's probably some other obscure timing details I've missed which are causing Battletoads level 2 to randomly freeze - my previous experience with test ROMs has been that a lot of them just give pass/fail indicators without properly explaining why they failed, and frequently my attempts to fix one test just cause a dozen others to start failing.
Re: Nintendulator 0.980
by on (#231545)
I'll test out Battletoads level 2 in NintendulatorNRS when I get a chance. Is the source available for that branch? That link only includes the binary.

If NintendulatorNRS is more accurate, maybe it should be merged back into the original?
Re: Nintendulator 0.980
by on (#231546)
Source is available on request (PM), per GPL requirements.
Re: Nintendulator 0.980
by on (#231560)
Maybe better to rename "Hybrid" to "Dendy" mode?
to match same naming with another emulators (mesen, punes, fceux, bizhawk, nestopia, nintaco)
Only nintendulator name this timing as "Hybrid".
P.S:
first string of "readme.txt" is still "Nintendulator 0.970" in lastest stable 0.980 release.
Re: Nintendulator 0.980
by on (#231564)
Battletoads Level 2 does not freeze in Nintendulator-NRS.

However, common to both, The Jetsons, Cogswell Caper (J) has a shaky status bar and garbage on the Title screen.
Re: Nintendulator 0.980
by on (#231565)
The shaking thing is easy enough to remove; just delay the IRQ being raised by 4 CPU cycles, as the wiki describes.

What I cannot achieve however, as can no other emulator, is make the title screen in Jetsons correct and the in-game screen split in the Japanese version of Flintstones. Either one will be off by one scanline in all emulators. We have no real hardware video recording of the Japanese version of Jetsons, but we have one of the Japanese version of Flintstones, where it looks right, just like the U.S. version, and unlike all emulators. I can modify the scanline offset by one to make it look this way, but then Jetsons' title screen will be off by one scanline.

Edit: Mesen has game-specific behavior for Flintstones. Even with that, its screen split does not look right.
Re: Nintendulator 0.980
by on (#231581)
NewRisingSun wrote:
Edit: Mesen has game-specific behavior for Flintstones. Even with that, its screen split does not look right.
I had forgotten all about that one time I spent hours on that Flintstones game. FYI, the game also requires that writing to $C000 acknowledges the IRQ, otherwise one specific portion of a later stage in the game is bugged (the Wiki does not mention this, unsure if other emulators implement this or if it is correct, but it's the solution I found for a user-reported emulation bug at the time)

Not that I claim that my implementation is hardware-accurate in any way, but what do you see that's different about the screen split between the video and Mesen? I'm pretty sure that's the video I had originally used as a means of determining if the split looked correct or not (I'm probably blind, but I can't see any difference)

(And this thread already has nothing to do with its original topic...)
Re: Nintendulator 0.980
by on (#231589)
There is a clean black line above the status bar in the hardware video, whereas in Mesen, the line above the split shows a nametable that jumps left and right according to the current fine X scroll. (I am using the Mesen build from August 5th.)
Re: Nintendulator 0.980
by on (#231593)
NewRisingSun wrote:
There is a clean black line above the status bar in the hardware video, whereas in Mesen, the line above the split shows a nametable that jumps left and right according to the current fine X scroll. (I am using the Mesen build from August 5th.)
Ah, I figured it out. You're using a NES 2.0 rom, which overrides Mesen's game database. But this particular game-specific code relies on the game DB data setting the submapper number to 255 (which is impossible via the NES 2.0 headers) to alter the mapper's logic. So what you're seeing is what Flintstones looks like if played with the same settings at the Jetsons.
Re: Nintendulator 0.980
by on (#231594)
Ah, right. Yes, my entire ROM collection is in NES 2.0 format.

Well, I hope somebody with a Japanese Jetsons cart show a video capture of its title screen, so we know whether we really need a game-specific hack, or if Jetsons is allowed to look a little off.
Re: Nintendulator 0.980
by on (#231597)
Eugene.S wrote:
Maybe better to rename "Hybrid" to "Dendy" mode?
to match same naming with another emulators (mesen, punes, fceux, bizhawk, nestopia, nintaco)
Only nintendulator name this timing as "Hybrid".

Of the emulators you listed above, Nestopia was the first one to add "Dendy" mode back in 2008, while I added it in early 2011 as "Hybrid" (because I didn't want to imply that it was specific to the Dendy); all of those other emulators added it later, and they chose to follow Nestopia's naming convention.

Eugene.S wrote:
P.S:
first string of "readme.txt" is still "Nintendulator 0.970" in lastest stable 0.980 release.

You saw nothing. *whistles innocently*
Re: Nintendulator 0.980
by on (#231598)
Yes, "Hybrid" mode is correct technically-speaking, but "Dendy" mode is most common name for this timing, it happens by historical reasons.
Most emulators marks it as dendy (including CPU/PPU variables names in source codes, etc).
Is it good or bad?... doesn't really matter for now. Too late to change all emulators sources.

Anyway, "Dendy-mode" sounds better than "Micro Genius-mode", or "PAL-Famiclone-with-NTSC-timing" or something like this.
Re: Nintendulator 0.980
by on (#231602)
Do any PAL famiclones have PAL NES timing? If not, "NTSC | PAL NES | PAL famiclone" could be an option.
Re: Nintendulator 0.980
by on (#231609)
True PAL Famiclones (with official PAL NES timings) exists, but they're very rare.
I know only one, it have:
Code:
UMC UA6540 (CPU)
UMC UA6541 (PPU)

PAL famiclones with dendy-like timings were more widespread
Code:
6527P+6538, TA-03NP1+TA-02NP, T1818P, UM6561(AF,BF,CF,F)-2

as well, as NTSC-famiclones
Code:
6527+6528, TA-03N+TA-02N, UM6561(AF,BF,CF,F)-1

CPU Revisions
PPU Revisions