Dendy clones

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Dendy clones

Post by koitsu » Thu Apr 16, 2009 10:59 am

Hopefully someone can find this useful.

http://www.bannister.org/forums/ubbthre ... 45&gonew=1

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Apr 16, 2009 12:06 pm

Frequency of the quartz resonator: MCLK = 26.601712 MHz
CPU speed: MCLK/15 = 1.77344746666... MHz
So they did the frequency divider the right way (/15), not the cheap way (/16) that Nintendo chose for the 2A07. That would appear to make it compatible with NTSC cycle-timed code, except for things like (IIRC) Balloon Fight that rely on NMI-to-draw timing instead of sprite 0 or PPU timing and would get tripped up by the extra 50 lines of vblank.

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Sat Apr 18, 2009 5:42 am

Dendy was a hardware clone of the Nintendo Famicom. It was released in early 1990s by Steepler company.
Hardware were assembled in Taiwan.
Since no officially licensed version of the NES was ever released in ex-USSR,
the Dendy was easily the most popular video game console of its time in that setting,
and enjoyed a degree of fame roughly equivalent to that experienced by the NES/Famicom in North America and Japan.

We learnt definitely that in the first models of Dendy as well as in many Asian famiclones they used CPU “6527P” and PPU “6538”.
These chips most probably were clones of the original Ricoh-chips and were manufactured by:
UMC (United Microelectronics Corp.): UA6527P, UA6538
Hitachi(?): HA6527P, HA6538
Toshiba(?): TA6527P (aka TA-03NP1), TA6538 (aka TA-02NP)

Hardware gallery
After 1993 there appeared “Dendy-on-1-chip” based on UMC UM6561
Their matching with games were worse than the original ones based on 6527P/6538.

-some stuff-
my dendy-steepler gallery
HardWareMan's hi-quality audiorecords from TA6527P-chip (U,J-games, NTSC pitch / PAL speed):
Dendy-TA6527P-Samples (stereo, audiochannels are separated)

So, "Dendy" is very qualitative famiclone oriented to good compatibility with NTSC-Famicom cartridges.
Perhaps, somebody from the guru will become interested in the "6527P/6538"-based famiclones.
We need to know exact dendy timings for improvement Nestopia dendy-mode. We would be glad to your help.
...except for things like (IIRC) Balloon Fight...
Balloon Fight (U,J) works correctly on Dendy.
Battletoads/BTDD (U,J) works with small glitches on title screen. PAL NES has *real* glitches with NTSC Battletoads/BtDD.
Last edited by Eugene.S on Sat Aug 18, 2012 5:38 am, edited 31 times in total.

ccovell
Posts: 1015
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Post by ccovell » Sun Apr 19, 2009 3:53 am

Some very interesting information, Eugene!

But I seriously doubt that those chips are made by the "real" Hitachi and Toshiba. They are generically-named clones coming from the usual places, China or Taiwan.

The first Dendy system picture that you linked to is the same design as the Micro Genius IQ-501. Is this the original design of the Dendy?

Finally, does the word "Dendy" have any sort of meaning?

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Sun Apr 19, 2009 5:41 am

Hi, Chris! I like your awesome cmc'80-s demo ;)

"Dendy" is a name of the elephant-baby.
About design: Dendy-steepler was released in four versions - Classic, Classic II, Junior, Junior II/IVp (1990 - 1996).

I don't know precisely about "real" Hitachi and Toshiba-chips.
The Taiwan UMC UA6527P/UA6538-chips are real. UM6561 (NoaC) also developed by UMC.
Dendy, MicroGenius & Pegasus have an identical hardware (UA6527P, UA6538) and timing speed (26.601712 Mhz Xtal /15 div.).
I assume these famiclones were assembled at Taiwan factories as different labels.
"Dendy" it's a brand for Russia and ex-USSR republics.
"Micro Genius" it's a brand for PAL-Asian region, Pegasus - for Poland, etc.

Dendy allows to receive correct DPCM-sound of NTSC-games running on 50 FPS: TEST (1.63 mb)
Last edited by Eugene.S on Thu Aug 16, 2012 9:21 am, edited 26 times in total.

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Tue Apr 21, 2009 6:42 am

Nestopia's “Dendy-mode” still remain some glitches (all roms are NTSC)
We think VBLANK/VSLEEP timings were found not correctly enough.

_fragments from NstBase.hpp:
Dendy CPU Speed = 26.601712 / 15 = 1.773447467 Mhz
Dendy PPU Speed = 26.601712 / 5 = 5.3203424 Mhz
CPU clock speed / PPU clock speed = 1/3

Code: Select all

//.......
CPU_RP2A03_CC = 12,
CPU_RP2A07_CC = 16,
CPU_DENDY_CC  = 15
//.......
PPU_RP2C02_CC  = 4,
//.......		
PPU_RP2C02_VACTIVE   = 240,
PPU_RP2C02_VSLEEP    = 1,
PPU_RP2C02_VINT      = 20,
PPU_RP2C02_VDUMMY    = 1,
//.......			
PPU_RP2C07_CC        = 5,
//.......
PPU_RP2C07_VACTIVE   = 240,
PPU_RP2C07_VSLEEP    = 1,
PPU_RP2C07_VINT      = 70,
PPU_RP2C07_VDUMMY    = 1,
//.......			
PPU_DENDY_CC         = 5,
//.......
PPU_DENDY_VACTIVE    = 240,
PPU_DENDY_VSLEEP     = 51,
PPU_DENDY_VINT       = 20,
PPU_DENDY_VDUMMY     = 1,
//.......			
Help me, please. Why VINT/VSLEEP = 20/51 ?
Marty has assumed this timings
Last edited by Eugene.S on Thu Aug 16, 2012 9:46 am, edited 4 times in total.

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Mon Dec 07, 2009 11:23 am

Hi, all!
Nestopia “Dendy-mode” still remain some glitches (all roms are NTSC)
We think VBLANK/VSLEEP timings were found not correctly enough.
Hmm... 20/51 (Vint/Vsleep) timings most likely is true value.
I've compiled the old version "nestopia 1.36 with modified PAL-mode". ROMs are free of nst1.40's glitches.
I don't know where an error in Nestopia 1.40...
download Nst1.36/37dendy (Vint/Vsl=20/51)
Last edited by Eugene.S on Thu Aug 16, 2012 9:05 am, edited 15 times in total.

User avatar
Dwedit
Posts: 4354
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Dec 07, 2009 5:27 pm

Roms are free of glitches when you add the extra scanlines to the end before vblank starts, but is this what the actual hardware does?

Also, Codemasters games auto-detect whether they are running on NTSC or PAL. They detect PAL, and use code timed for that system, which fails on Dendy emulation mode.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Dec 07, 2009 5:54 pm

Dwedit wrote:Roms are free of glitches when you add the extra scanlines to the end before vblank starts
In other words, firing NMI at line 291.
but is this what the actual hardware does?
If I can confirm that someone has a PowerPak or other devcart and the appropriate famiclone, I may write some test ROMs that let the user use a PC sound card as a makeshift ghetto oscilloscope to test hypotheses like this. Pseudocode as follows:
  1. Set up a sprite 0 hit on line 232
  2. Wait for sprite 0 bit to be set, and set $4011=$3F
  3. Wait for vblank, and set $4011=$7F
  4. Wait for sprite 0 to become clear, and set $4011=$00
On an NES, this would generate a waveform on the audio pin with a fundamental frequency 60.1 or 50.0 Hz. Even after filtering of output, the waveform would have two noticeable upward transitions near the bottom of the frame (one 9 lines before vblank, one at vblank) and one downward transition at the top of the frame. The relative timing of these transitions would make it easy to see whether a given PAL famiclone fires NMI at line 291.

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Thu Dec 10, 2009 12:33 pm

Roms are free of glitches when you add the extra scanlines to the end before vblank starts, but is this what the actual hardware does?
Most likely the hardware does it.

If Vint/Vsleep values = 70/1 there are many glitches which are not present on real dendy. Battletoads & DD hangs, it shouldn't be
If Vint/Vsleep values = 20/51 then all game-glitches are very similar to hardware. *Last updated 10.12.09*

I've compiled some versions of NEStopia (1.36-1.40)
and changed their PAL-mode according to Dendy-timings

Code: Select all

fragments of NstBase.hpp (NstCpu.hpp & NstPpu.hpp under version 1.37)
// fixing PAL(RP2A07) divider to dendy CPU(UA6527P) divider
{
 RP2A03_CC = 12,
 RP2A07_CC = 15
};

// fixing timings according to dendy PPU(UA6538)
   RP2C07_VACTIVE   = 240,
   RP2C07_VSLEEP    = 51,
   RP2C07_VINT      = 20,
   RP2C07_VDUMMY    = 1,

Fragments of NstApu.cpp
// fixing DMC rates according to NTSC-table
   
{
  0x1AC * Cpu::MC_DIV_PAL,
  0x17C * Cpu::MC_DIV_PAL,
  0x154 * Cpu::MC_DIV_PAL,
  0x140 * Cpu::MC_DIV_PAL,
  0x11E * Cpu::MC_DIV_PAL,
  0x0FE * Cpu::MC_DIV_PAL,
  0x0E2 * Cpu::MC_DIV_PAL,
  0x0D6 * Cpu::MC_DIV_PAL,
  0x0BE * Cpu::MC_DIV_PAL,
  0x0A0 * Cpu::MC_DIV_PAL,
  0x08E * Cpu::MC_DIV_PAL,
  0x080 * Cpu::MC_DIV_PAL,
  0x06A * Cpu::MC_DIV_PAL,
  0x054 * Cpu::MC_DIV_PAL,
  0x048 * Cpu::MC_DIV_PAL,
  0x036 * Cpu::MC_DIV_PAL
}

// end
But strange glitches appear since version 1.38 and above:
http://img18.imageshack.us/gal.php?g=otherb.png (20/51)
below v1.38 these glitches aren't present (very similar to hardware):
http://img265.imageshack.us/gal.php?g=b ... ragonu.png (20/51)
v.1.38 changes:
- PPU power/reset timing and register states.
- Misc IRQ/NMI/BRK/DMA special-case behavior.
Last edited by Eugene.S on Thu Aug 16, 2012 9:06 am, edited 2 times in total.

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Sun Dec 13, 2009 2:02 am

HardWareMan:
30 lines before vertical synchronization impulse
3 lines vertical syncrhonization impulse
40 lines after vertical synchronization impulse
NMI starts at 19th line after vertical synchronization impulse
NMI ends at end of 24th line after vertical synchronization impulse
NMI has duration: ~5,8 lines

Rigol DS1052E: VBLANK+NMI
Image
Rigol DS1052E: VBLANK+NMI (Zoom-in)
Image
***
15 - front horizontal blank and retrace
84 - scanline
6 - back horizontal blank
8 - horizontal synchronization impulse
Total: ~113 CPU cycles per whole scanline.

Scanline+F2
Image
SLF2_Synchro
Image
***
Can someone fix nestopia140src according these tests?
Last edited by Eugene.S on Thu Aug 16, 2012 9:07 am, edited 1 time in total.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Dec 14, 2009 5:44 pm

In other words, the extra 50 or so lines happen between the end of the picture and NMI. So to get the most out of a Dendy's vblank time, you need to turn rendering off early using sprite 0, DMC IRQ, or a mapper IRQ.

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Fri Dec 18, 2009 5:45 am

New PPU-tests + old tests (Ultrascope + *.wfm-Sources), 12 MB
http://www.fileden.com/files/2012/4/10/ ... rascope.7z
You can zoom pictures.
Instructions inside.
Last edited by Eugene.S on Thu Aug 16, 2012 9:10 am, edited 1 time in total.

User avatar
Eugene.S
Posts: 296
Joined: Sat Apr 18, 2009 4:36 am
Location: Russia (UTC+3)
Contact:

Post by Eugene.S » Sat Feb 05, 2011 5:19 am

Quietust has answered my letter:
http://www.qmtpro.com/~nes/nintendulator/

February 3, 2011

Nintendulator's region handling support has been overhauled, and provisional support for the "Dendy" NTSC/PAL hybrid has been added.
Additionally, partial widescreen support has been added to fullscreen mode - based on your primary monitor's current resolution, Nintendulator will try to use one of several appropriate fullscreen resolutions to prevent the image from being stretched horizontally, falling back to 640x480 if none of them work.

Image
Last edited by Eugene.S on Sat Aug 18, 2012 5:40 am, edited 1 time in total.

krzysiobal
Posts: 759
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Post by krzysiobal » Thu Apr 26, 2012 5:58 am

Don't forget about Polish consolles, called PEGASUS
(there were 3 revisions of it, the first one with UA6527P/UA6538, the second one with UM6561 and the third one with glob-top).

I have this one and a programmable cart, so I can make some tests if you wish.

The most interesting fact with them is that the game: Dizzy Adventures crashes when the player pauses the game or loses life. This happens on my console with UA6561!
The bugs on title screen of Battle Toads and Double Dragon are also true.

In the contrary, the Asterix game, which is really buggy on NES works pefect on PEGASUS.

Post Reply