Hopefully someone can find this useful.
http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=49345&gonew=1
http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=49345&gonew=1
Quote:
Frequency of the quartz resonator: MCLK = 26.601712 MHz
CPU speed: MCLK/15 = 1.77344746666... 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.
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.
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.
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.
Quote:
...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.
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?
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?
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)
"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)
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
Help me, please. Why VINT/VSLEEP = 20/51 ?
Marty has assumed this timings
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:
//.......
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,
//.......
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
Hi, all!
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)
Quote:
Nestopia “Dendy-mode” still remain some glitches (all roms are NTSC)
We think VBLANK/VSLEEP timings were found not correctly enough.
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)
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.
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.
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.
Quote:
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:
- Set up a sprite 0 hit on line 232
- Wait for sprite 0 bit to be set, and set $4011=$3F
- Wait for vblank, and set $4011=$7F
- 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.
Quote:
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:
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
// 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)
Quote:
v.1.38 changes:
- PPU power/reset timing and register states.
- Misc IRQ/NMI/BRK/DMA special-case behavior.
- PPU power/reset timing and register states.
- Misc IRQ/NMI/BRK/DMA special-case behavior.
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
Rigol DS1052E: VBLANK+NMI (Zoom-in)
***
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
SLF2_Synchro
***
Can someone fix nestopia140src according these tests?
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
Rigol DS1052E: VBLANK+NMI (Zoom-in)
***
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
SLF2_Synchro
***
Can someone fix nestopia140src according these tests?
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.
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.
http://www.fileden.com/files/2012/4/10/ ... rascope.7z
You can zoom pictures.
Instructions inside.
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.
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.
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.
(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.
krzysiobal wrote:
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.
(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.
Can you clarify which Dizzy game you're talking about? There's three Dizzy games on the NES: "Fantastic Adventures of Dizzy", "Dizzy the Adventurer" and Quattro Adventure's "Treasure Island Dizzy". Sounds like you're most likely referring to "Fantastic Adventures of Dizzy".
Codemasters put region detection into their games, so when the game is run on an official NTSC or PAL NES, it detects which model it is, and adjusts the timed code appropriately. But this fails on clone hardware that doesn't use the same timing, so it might think it's running on an original PAL NES when it isn't.
When I try the Dizzy games on Nintendulator in Dendy mode, they use the wrong timing (they think they're running on a PAL NES), but seem to work well enough. They don't crash when you pause or die.
And Asterix fails in Nintendulator when running in Dendy mode. Since Dendy Mode is simulating a long pre-vblank time, and a short vblank time. Asterix still thinks it's running on a PAL NES, and does all its long graphics transfers during the short vblank time, which fails.
So if the clone console runs Asterix correctly, it has completely different rules regarding Vblank time than the Dendy. I'm not sure whether it counts as a Dendy clone or not.
I could probably guess what the timing rules are from screenshots or videos showing some glitches.
Sorry! I mean Dizzy Adventurer.
The Fantastic Adventures of Dizzy work great (except some minor glitches a few scanlines before the status bar and just before the start, when the piece of paper rollovers - my TV lost horizontal synchronization for a second)
The Fantastic Adventures of Dizzy work great (except some minor glitches a few scanlines before the status bar and just before the start, when the piece of paper rollovers - my TV lost horizontal synchronization for a second)
And sorry againa about asterix. It ofcourse runs perfectly on NES and is flickering at pegasus!
The standard Dendy turbo-controller toggle every frame, like this:
Thanks HardWareMan for researches.
Thanks HardWareMan for researches.
Does it toggles using LATCH or it has an independent oscillator?
If it toggles with latch, SMB3 and Tetris won't run. Those use controller rereading: SMB3 because it plays drums on channel 5, Tetris probably because it uses the same library.
We don't know about this now, but will try to discover it.
I think I've seen one these hybrid consoles here.
UA6527 is a NTSC CPU chip which needs 21Mhz to work properly. A console using it combined with a PAL PPU will need two crystals, one for each part. Because I needed the one I had here to be NTSC (well I wanted it to be PAL-M but that's an 60hz PAL system).
I had the UA6538 chip replaced with a UA6548 (The UMC chip which is specific for 60Hz PAL-M TV system used in Brazil) and removed the 26mhz oscillator. I kept the UA6527 chip and had both chips run from 21Mhz. That effectively made it into a NTSC like clone.
Sadly it's been more than 10 years now I've done that I don't remember the details.
UA6527 is a NTSC CPU chip which needs 21Mhz to work properly. A console using it combined with a PAL PPU will need two crystals, one for each part. Because I needed the one I had here to be NTSC (well I wanted it to be PAL-M but that's an 60hz PAL system).
I had the UA6538 chip replaced with a UA6548 (The UMC chip which is specific for 60Hz PAL-M TV system used in Brazil) and removed the 26mhz oscillator. I kept the UA6527 chip and had both chips run from 21Mhz. That effectively made it into a NTSC like clone.
Sadly it's been more than 10 years now I've done that I don't remember the details.
l_oliveira wrote:
UA6527 is a NTSC CPU chip which needs 21Mhz to work properly.
Nope. UA6527 uses 26MHz as masterclock and internal divider by 15 (not 12 as in pure NTSC chip).
HardWareMan wrote:
l_oliveira wrote:
UA6527 is a NTSC CPU chip which needs 21Mhz to work properly.
Nope. UA6527 uses 26MHz as masterclock and internal divider by 15 (not 12 as in pure NTSC chip).
Funny I have a lot of them here (from asian clones) and they used UA6527 + UA6528. These run from 21mhz clock and behave as Famicom (duty cycle bug apply and DPCM sucks if the chip is made before 1990) ...
Here, UMC chips were more common than the Korean TA-02/TA-03 pair of chips.
I don't have a working camera atm but I am 100000% sure the UA6527 is a NTSC chip and requires 21mhz to operate.
After writing half of this post I looked on the internet and found this picture which was enlightening :
Notice the "P" after the code of the chip. Perhaps that's why we were so strong on our arguments ? I never ever seen a UA6527P chip here.
My chips look exactly like that but they're missing the "P" from their code. And the only PAL "Dendy-like" PPU I have here (UMC 2A02E) has the newer "UMC" logo in it (similar to the logo on the NOAC QFP chip) the PAL "Dendy-like" CPU (2A03E) has "USC" printed on it but is obviously an UMC part as well.
The PAL UMC chips I have are exactly what you described, by the way.
Hmm. Perhaps.
* * *
Indeed. I almost forgot about my NTSC clone. It use 6527 CPU (PAL has 6527Р) and 6528 PPU (PAL has 6538Р), quartz 21.47727MHz (PAL has 26.601712MHz).
* * *
Indeed. I almost forgot about my NTSC clone. It use 6527 CPU (PAL has 6527Р) and 6528 PPU (PAL has 6538Р), quartz 21.47727MHz (PAL has 26.601712MHz).
Isn't UA6538P (I've never seen that one) for SECAM based TVs ? I know UA6528P will be for regular PAL-B/G/I TVs. It's the kind of PAL PPU I have here.
Nope. UA6538P are PAL. But there are SECAM clone (please notice - NTSC CPU!):
PPU is UM6558. It has 8bit CD port (Color Data?). The result dot color index goes from CD port to SECAM coder UM6559. Notice that PPU in DIP48 in order to have enough pins. And this clone has pallete issues. For example look at Spiderman screenshots (SECAM on left):
PPU is UM6558. It has 8bit CD port (Color Data?). The result dot color index goes from CD port to SECAM coder UM6559. Notice that PPU in DIP48 in order to have enough pins. And this clone has pallete issues. For example look at Spiderman screenshots (SECAM on left):
CPU says UM6557... Which again I have never seen before. Wow you made me want a Dendy now !
Think about it, a few logic chips (latches and control logic) and resistors (R2R ladder) and a UA6558 will become a RGB PPU !
Think about it, a few logic chips (latches and control logic) and resistors (R2R ladder) and a UA6558 will become a RGB PPU !
I have a loose board with two clock oscillator chips. Since I am using a Dendy-like PAL UMC CPU, I am feeding it 27.000 mhz (roundest clock which is close enough to the original frequency) in a socket for a slight overclock and a NTSC-like clone PPU chip clocked at 21mhz.
Works great. Only games that don't like it are the usual NTSC games that give problems on the Dendy.
Since I'm with a 60hz PPU instead of the 50hz PPUs Dendy has, extra oddities might apply ...
I don't know how games optimized for the Dendy would behave on the weird configuration I built here because I have none to test ... lol
(edited for improved readability)
Works great. Only games that don't like it are the usual NTSC games that give problems on the Dendy.
Since I'm with a 60hz PPU instead of the 50hz PPUs Dendy has, extra oddities might apply ...
I don't know how games optimized for the Dendy would behave on the weird configuration I built here because I have none to test ... lol
(edited for improved readability)
I've made a table of diffs. between Dendy and NES/FC. Is this table correct and enough?
The table based on #nesdevwiki:
http://wiki.nesdev.com/w/index.php/Clock_rate
http://wiki.nesdev.com/w/index.php/NES_ ... _system.29
The table based on #nesdevwiki:
http://wiki.nesdev.com/w/index.php/Clock_rate
http://wiki.nesdev.com/w/index.php/NES_ ... _system.29