FCEUX with Dendy-mode

Hi, nesdev.
http://tasvideos.org/forum/viewtopic.ph ... 911#357911
http://sourceforge.net/p/fceultra/bugs/629/

Maybe someone of you can help FCEUX developers to add Dendy-mode please?
Since NES.emu (the best iOS/Android NES emulator) based on fceux-2.2.3-svn code, will be nice if NES.emu will support dendy-mode too

*post is outdated. i have deleted it*

Somebody knows is it possible to make that debugger shows current pixel / scanline after each instruction?

So... I added this, with extensive help from DoomGuard and Eugene.S. All the switches and logic tweaks. But when I add PPU loops (scanlines) to match Dendy's, something gets corrupted in the code, though the very Dendy mode was reported to be quite accurate (for a start).

There's info that actual Dendy PPU does nothing after scanline 240, but all the rest elements keep running, resulting in known timings. But I don't know how to properly incorporate that info into code. Corruption is resulting visibly in crashing when it tries to save to config or changing a ROM (maybe more), and it's caused exactly by additional PPU loops/scanlines. No other Dendy logic addition breaks it.

Since I'm unable to advance, here's the patch for FCEUX:
http://sourceforge.net/projects/feos-ta ... h/download

And here's the modified PPU.cpp file for quick reference:
http://pastebin.com/5M2B3zFS
Lines 1788 and 2031 activate additional loops, for old and new PPUs. On both PPUs the games work as expected, but the code is wrong.

...? Oh yes, the build!
http://sourceforge.net/projects/feos-ta ... z/download

So, Dendy-mode work correct on both "old_ppu" and "new_ppu" modes at now.
We really need help of nesdev people to solve crashing problem (buffer overflow?) on windows.

I've small notes:

This is actual on fceux "old_ppu" mode.
I think fceux "new_ppu" mode and real dendy hardware does nothing after scanline 241

This crashing problem appears only on windows build. Linux/SDL build work good.
Maybe it can help you.

Welp, it appeared to have zero connection with Windows. It was overflowing the common video buffer (XBuf), and writes outside it were corrupting all sorts of variables, that then prevented config save and ROM switching, and whatnot.

Commit: https://sourceforge.net/p/fceultra/code/3107/

New build: https://sourceforge.net/projects/feos-t ... z/download

Huge thanks to Doomguard45, Eugene.S, HardWareMan and whoever participated in Dendy research.

Does the dendy have swapped duty cycle? I'd like to hear how games sounds with this bug turned on.

Yes, but not all models do. puNES and RockNES can emulate that feature bug. We discussed adding it to fceux, but it makes little sense to me.

It seems a pretty reasonable option to want if you are interested in emulating Dendy games.

You saying that is enough reason for me!
Stay tuned...

Note:

TA-03NP1-6527P chip is good,
UMC UA6527P have swapped 25<->50 duty cycles

viewtopic.php?p=85979#p85979

Yes, the key word was "option".

...and on some standard-NTSC famiclones too
RockNES has no PAL or Dendy modes, but can emulate swapped duty bug.
Zepper, we want PAL and Dendy

TODO: fix NSF player, it's broken on Dendy-mode

Thank you very much!
It's impressive to see how it can play NTSC games with raster effects just fine at 50 Hz without any software changes. I wish Nintendo had been able to pull out something like that... The official PAL NES is a travesty.

Indeed. It's funny how some pirates found a better way to convert the system to PAL than Nintendo itself did.

Gotta play devil's advocate here... the official PAL NES has a much longer Vblank time for drawing tiles and stuff, and that gets signaled by NMI itself, so games don't need to do trickery to get notified about the large pre-vblank time.

Yes, this is great for PAL-only stuff, but as I see it, the point of making the PAL console is creating a version of the hardware that works with TVs that are not NTSC, not create an upgraded version of the system with features that are incompatible with the original version. And the Dendy is much closer to the original NTSC NES.

Do you think Nintendo gave a flip about compatibility with other region software? Heck, Nintendo made two different CICs for PAL alone.

I don't think they made the timing so different on purpose, but I obviously can't say for sure. If they really wanted to screw up campatibility, they could do what they did to their RGB PPUs, which is scramble the palette and registers.

I wonder about the real need of emulating PAL and Dendy. For example, is someone coding for Dendy? To play a PAL or Dendy game exactly the same way its NTSC version does sound a waste of time. Indeed, that's me of course.

Dendy was designed only for run actual NTSC-games at 50FPS.
We like slower gamespeed and music tempo. It's nostalgia: link1 \ link2
Absolutely useless to make exclusive software\games special for dendy-mode.

Streemerz got written with NTSC/PAL/Dendy cross-compatibility in mind anyway. Try it in each mode, it will attempt to be the same game. Sound effects are one half-step too high in NTSC or Dendy mode, but besides that, music pitch, tempo and game speed are the same.

It's really nice, Dwedit.
I just want to say Zepper about "meaning of" Dendy-mode

Here's a few reasons, Zepper:

1. The Dendy was widespread, and well used. There are a lot of people who want to emulate these games the way they played them.
2. There is still a lot of Dendy hardware in use, so developers of new software would appreciate being able to test and debug for Dendy.
3. There are a few Dendy games (mostly bootleg hacks) that might be of interest to play.
4. There's not a lot of cost to implement Dendy mode in an existing NES emulator. The value vs cost ratio here is very good.

The best part about implementing Dendy mode is that you can create "Overclocked" mode just by setting the frame rate back to 60 FPS. Games notorious for lagging (such as Mega Man 3 or Armadillo) would lag a lot less if they had the extra dummy scanlines in a frame.
Obviously you adjust the sound pitch and stuff so it's normal NTSC sound pitch again, and not 6/5 faster, this includes the DMC channel too. DMC IRQs will break because frames are longer than usual.
The only real artifacts you hear in Dendy mode is the APU frame counter being counted more times per frame than usual, so frequency sweeps are exaggerated.

Really, a LOT. "Dendy-mode" is only euphonic name. A thousands of "NTSC/PAL hybrid" famiclones work on this timings.
They have different labels/names in CIS countries ("Dendy", "Lifa", "Kenga", "Subor", etc),
Eastern Europe (i know "Pegasus" in Poland) and Asian region ("MicroGenius" in Taiwan)

Many of them was based on bad and glitchy NOACs, like UM6561A, they fail some tests (like oam reading),
and have few game-compatibility issues (green tint, "prince of persia" glitches, swapped duty cycles, etc), but still keep "dendy" timings.
We do our tests only on good chips (first famiclones of early 90's have separate CPU and PPU, like Famicom).
They can pass many of nesdev tests and don't have nasty glitches, which NOACs have.

P.S. Sorry for my bad language. I'm not native english speaker.

Done in r3111.
https://sourceforge.net/p/fceultra/code/3111/log/

Is there something super important we're missing that could be added?


Can you elaborate on how to force it? Was it already done in some emulator? In fceux, there are desired framerate, ppu loop scanlines, and cpu speed, that were affected by dendy mode, cpu speed being almost the same as ntsc though, so it alone affects nothing.

With target fps at 60, 290 scanlines sounded broken, sped up.

I am not sure if this is related, but I've had problems for debugging my programs with this version of FCEUX. It mostly works, but sometimes it does not break when it should. I am not sure what causes this bug. I am breaking on reads from ROM, and sometimes it does not trigger, even though I am sure a particular address is read at some point.

So we were messing around A LOT with overclocking, and everything worked alright... except for DMC.

It seems, it's being written values directly by the game, and if it runs for 290 scanlines per frame, instead of 240, it runs too far with DMC samples too, and the next frame, the sample that it was writing gets cut and resumes from a wrong place.

It's writing samples to other channels too, but they have fixed notes per entire frame, so I just made it not increment the location in WaveHi during our dummy scanlines, and it works as expected. But with all that DMC/DMA stuff, I'm really stuck.

Can I stably reproduce it?

I think I've seen that bug in the regular versions of FCEUX.

Added dendy-mode for SDL in lastest r3134 svn