As topic said, now I have three UM6558 and UM6559 (russia dendy clone )
But there is no any datasheet or pinout data on UM6558
Attachment:
QQ图片20170226105916.jpg [ 68.88 KiB | Viewed 4108 times ]
I found some pinout data on the Russian BBS, but there was not much help. Their data are in conflict......
Are you in SECAM land?
viewtopic.php?p=100870#p100870 implies that the UM6559 part won't be useful otherwise ...
lidnariq wrote:
Are you in SECAM land?
https://forums.nesdev.com/viewtopic.php ... 70#p100870 implies that the UM6559 part won't be useful otherwise ...
nope. im chinese , recnetly , i found these chipset in other topics, and mentioned this can be modifyed to rgbs singal output.
but I can't find the UM6558 data only , UM6559 Already found !
HardWareMan might be able/willing to help you, whenever he stops by again. Maybe.
Otherwise, all I can do is suggest how you would reverse-engineer the pinout using a multimeter. I wouldn't be surprised if the pinout is almost the same as the
2C02's, just with the extra eight pins at the bottom forming the color data bus.
As you've probably already found, it looks like there's a serious design flaw with the colors $1E, $2E, $3E, $1F, $2F, and $3F not being black.
lidnariq wrote:
HardWareMan might be able/willing to help you, whenever he stops by again. Maybe.
Otherwise, all I can do is suggest how you would reverse-engineer the pinout using a multimeter. I wouldn't be surprised if the pinout is almost the same as the
2C02's, just with the extra eight pins at the bottom forming the color data bus.
As you've probably already found, it looks like there's a serious design flaw with the colors $1E, $2E, $3E, $1F, $2F, and $3F not being black.
ah , thank you for your reply.
I have already used the resistance value to analyze its pinout,
Combined with the real PCB picture found it really and 2c02 or 6528/6538 differents.
I have noticed its palette problem, but I think this is not a big problem..
The biggest problem is that CPLD PPU is not easy to buy in China, then FPGA PPU does not have a chassis that looks good.
a VS arcade 2C03 and too expensive, only UM6558 / 6559 chipset each set only 50 CNY , It is an almost the cheapest solution of famicom rgbs mod...
Attachment:
QQ截图20170228133044.png [ 24.21 KiB | Viewed 4022 times ]
chipset x 3 = including demosteic shipping fee = ca.18USD$
bestmmk wrote:
I have already used the resistance value to analyze its pinout,
Combined with the real PCB picture found it really and 2c02 or 6528/6538 differents.
I'm not clear: have you figured this out? or do you still need help?
lidnariq wrote:
bestmmk wrote:
I have already used the resistance value to analyze its pinout,
Combined with the real PCB picture found it really and 2c02 or 6528/6538 differents.
I'm not clear: have you figured this out? or do you still need help?
NO _(:з)∠)_ i just already found VCC and GND , and some pin linked with cpu, but i also need help
it's better to find the datasheet for UM6558 ,
If find it can be used directly
in other, I found these in the Russian Forum
1)UM6558 AND UM6538 DIFFERENT ,
Attachment:
11823009.png [ 446.77 KiB | Viewed 3989 times ]
I guess it may be similar to UM6538, but I don't understand the text of the picture
2)REAL MACHINE PCB PICTURE FROM DENDY CLONE
Attachment:
2664831.jpg [ 1.48 MiB | Viewed 3989 times ]
Attachment:
w_5e52a477.jpg [ 1.19 MiB | Viewed 3989 times ]
I'm still looking at this picture. But there's a lot of doubt...
3)UM6559 Application diagram and pinout
Attachment:
7b04edccbed8.gif [ 51.21 KiB | Viewed 3989 times ]
Attachment:
f96cf9dc702d.gif [ 50.84 KiB | Viewed 3989 times ]
and finally , i find the um6559 in russian forum. it's high-reso scan, total 2pages
In the image with nominal pinout of the 6558, those are the instructions to replace a 6558 with a 6538.
So, undoing it ... the lines about 10, 11, 12, and 13 say that, unlike the 2C02 or UA6538, the pin order is not CPUA2, CPUA1, CPUA0, /PPUCE, but instead /PPUCE, CPUA2, CPUA1, CPUA0.
The little red text similarly says that pins 18, 19, 20 are (in order) +5, the master clock, and /VBL
The only thing that's not clear is what pins 29 (labeled as 21) and 30 (labeled as 22) need to become.
I've seen a vague insinuation somewhere else that some pin controls whether the UM6558 emits 60Hz or 50Hz video.
lidnariq wrote:
In the image with nominal pinout of the 6558, those are the instructions to replace a 6558 with a 6538.
So, undoing it ... the lines about 10, 11, 12, and 13 say that, unlike the 2C02 or UA6538, the pin order is not CPUA2, CPUA1, CPUA0, /PPUCE, but instead /PPUCE, CPUA2, CPUA1, CPUA0.
The little red text similarly says that pins 18, 19, 20 are (in order) +5, the master clock, and /VBL
The only thing that's not clear is what pins 29 (labeled as 21) and 30 (labeled as 22) need to become.
I've seen a vague insinuation somewhere else that some pin controls whether the UM6558 emits 60Hz or 50Hz video.
the um6558 may need a separate oscillator , or common use NTSC oscillator , i think NTSC (21.4772) oscillator and SCEAM (21.3125) oscillator are closer.
Now I have a HVC-CPU-07 PCB , I will start this test, I have 3 PPU and the 3 chance _(:з)∠)_
dont close the topic , There will be a final result in recent weeks
Where did they get UM6559 datasheets from? These are unavailable in the whole internet, but looks like official ones.
in a russian forum but I forgot where it was _(:з)∠)_
Attachment:
um6558.PNG [ 42.56 KiB | Viewed 3867 times ]
hereis pinout! finally i finished!
it tested by 孙大师(a.k.a master) and confirmed it works with paltte problem。
Maybe you can put some CPLD logic between UM6558/UM6559 on CD0-7 lines, which changes problematic dot colours in the fly to the correct ones, that don't cause troubles?
I have to admit I'm really curious what the contents of the ColorData bus are, for no good reason.
lidnariq wrote:
I have to admit I'm really curious what the contents of the ColorData bus are, for no good reason.
CD0-CD7 should be color data of graphics. This requires a logical analysis. If the palette problem is corrected, it will be of great value
krzysiobal wrote:
Maybe you can put some CPLD logic between UM6558/UM6559 on CD0-7 lines, which changes problematic dot colours in the fly to the correct ones, that don't cause troubles?
Haha, I think so too. In fact, it's too hard for me, I need more help, but now the situation has surprised me . Only a few people in China know the existence of this chipset.
bestmmk wrote:
CD0-CD7 should be color data of graphics. This requires a logical analysis. If the palette problem is corrected, it will be of great value
Well, sure. I was curious about the specifics.
krzysiobal wrote:
Maybe you can put some CPLD logic between UM6558/UM6559 on CD0-7 lines, which changes problematic dot colours in the fly to the correct ones, that don't cause troubles?
It looks like it's only 8 bits wide input and output ... I bet you could just use a fast ROM. After all, we can easily get 70ns ROMs, and it's a ~1/(186ns) pixel clock...
I have done exactly this, put a GAL between the colour bus output of UM6558 and the input of UM6559.
In fact it was only necessary to generate new CD4 and CD5 signals. These are the luminance pins of the colour bus output and are in the same format as the colour registers.
CD0 - CD3 are the hue pins of the colour bus output and they are inverted with respect to the colour registers, so software colour 00 (dark grey) is colour 0F in the hardware interface between the two chips.
This inversion makes the hardware colours more intuitive, because hardware colour 00 (software colour 0F) is black and hardware colour 3F (software colour 30) is white.
The hardware palette puts
8 blacks at 00, 10, 20, 30, 01, 11, 21, 31
the darker greys at 02, 12, 22, 32 (02 is software colour 0D which is blacker than black in PAL/NTSC)
the colours at 03-0E, 13-1E, 23-2E, 33-3E
the lighter greys at 0F, 1F, 2F, 3F.
Attachment:
Photo 10-04-2017, 12 58 02.jpg [ 1.31 MiB | Viewed 3629 times ]
Some pictures of Battle City running on the modified Dendy SECAM. This game is a good test because it uses a dark grey colour (software colour 00, hardware colour 0F) which is rendered as black by the standard Dendy SECAM.
Attachment:
Photo 10-04-2017, 12 44 24.jpg [ 3.32 MiB | Viewed 3628 times ]
Attachment:
Photo 10-04-2017, 12 45 44.jpg [ 2.24 MiB | Viewed 3628 times ]
Attachment:
Photo 10-04-2017, 12 55 07.jpg [ 2.67 MiB | Viewed 3628 times ]
The GAL maps the hardware colours output by the UM6558 onto the following values for driving the UM6559. These are hardware colour numbers, so the first four bits (hue) are inverted with respect to the colour registers.
Blacks
00, 10, 20, 30 -> 00, 00, 00, 00
01, 11, 21, 31 -> 01, 01, 01, 01
Dark greys
02, 12, 22, 32 -> 02, 02, 12, 22
Colours stay the same
Light greys
0F, 1F, 2F, 3F -> 1F, 2F, 3F, 3F
That's so cool! Thank you for sharing!
Do you know what the top two bits of the 8-bit CD bus carry?
The unknown bits aren't emphasis, are they?
Unless they're somehow serialized (perhaps sending only R or B on alternating scanlines) I don't know how...
One of the bits is probably sync, too.
The Dendy SECAM doesn't support colour emphasis bits at all, neither in composite SECAM nor in RGB.
CD6 and CD7 turn out not to be very exciting. CD6, pin 9 of UM6559, is a positive logic version of composite sync (pin 8 is negative logic composite sync) and CD7, pin 10 of UM6559, is a negative logic version of frame sync.
I've made two videos which show the Dendy SECAM composite and RGB palettes after the GAL modification has been applied. There are still some problems with the two palettes.
In RGB, the problem is that the colours do not have equal luminance (brightness) across colours 1 - C. For example, blue (2) is too dark and yellow (8) is too light. This is because the RGB values are not matrixed from a constant Y value and varying R-Y and B-Y values (as they are in PAL/NTSC), but are generated by a simple DAC scheme which does not attempt to preserve constant luminance. Any of the palettes in the NESRGB board look better than the UM6559 RGB colours.
In composite SECAM, the colours do have equal luminance but a different problem occurs with the darkest colours 01 - 0C and the lightest colours 31 - 3C. The UM6559 only generates 4 luminance levels. Colours 01 - 0C have the same luminance as black and 31 - 3C have the same luminance as white.
This means that patterns using the darkest colours on a black background will look very indistinct, because there are no luminance transitions at the colour boundaries. Only chrominance information changes, and this is carried in very low resolution.
I just put two and two together and realized that you could replace the UM6559 with a ROM, since all you want is RGB output.
While an 8-bit ROM would only afford R3G3B2, multiple ROMs could be combined to produce a higher-precision "ROMDAC".
Additionally, you could then add an 74'138 and a 3(or more) bit latch to capture writes to PPU $2001, and use those extra latched bits to add emphasis bit support.
I've been working on modifications to improve the SECAM output, because I want to see what a (good) SECAM Dendy would be like.
For RGB, you could use ROMs or possibly the GALs I am using. A GAL16V8 has 8 outputs so two of these will give you 16 outputs. R5G5B5 will give 32768 possible colours, from which the 52 or 54 NES colours can be chosen. Emphasis will require more electronics like you suggest.