nesdev.org

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:

There's info that actual Dendy PPU does nothing after scanline 240

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

Corruption is resulting visibly in crashing when it tries to save to config or changing a ROM

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.

Bregalad wrote: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.

rainwarrior wrote: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".

https://sourceforge.net/p/fceultra/code/3108/
Added option to swap bytes in charge of duty cycles, a bug present on some Dendy models.

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