Hi, nesdev!
I've contacted to
http://zeptobars.ru/en/ project about half-year ago.
I gave to them some chips for decapsulation, and now we have first results.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Chips:
RP2A03H - Famicom AV "rev H" CPU
RP2C02H-0 - Famicom AV "rev H" PPU
RP2C07-0 -
French version PAL NES PPU
(PPU itself output is standard composite signal, but finally converted to RGB by special decoder on NES mainboard)
Red/green emphasis bits are swapped.
UMC UA6527P - Hybrid ("Dendy") CPU made by "UMC". I know it has better DPCM, timbre and overall sound quality than TA-03NP1, but has 25%<->50% duty cycles swapped
UMC UA6538 - Hybrid ("Dendy") PPU made by "UMC". I've confirmed red/green emphasis swap on it. It has more saturated palette than TA02-NP-6538 and RP2C07-0.
TA-03NP1-6527P - Hybrid ("Dendy") CPU made by "TA". I know it has worse timbre and buggy DPCM than UMC UA6527P, but has right dutycycles
TA-02NP-6538 - Hybrid ("Dendy") PPU made by "TA". It has red/green emphasis bits also swapped, as well as RP2C07-0 and UA6538.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
First photos of UMC UA6538 PPU:
METAL LAYER:
http://s.zeptobars.ru/UMC-UA6538-HD.jpgIf everything is clear with the current view, and it can be properly reversed, zeptobars will remove metallization layer and go ahead to the polysilicon.
Awesome! I want to know the difference between that chips.
The metal image for that PPU is a bit blurry compared to the image I used for Visual 2C02, but hopefully it should be good enough for tracing, especially since the "core" of the chip seems to be an almost exact clone of the RP2C02, with differences being mostly in the interconnects and the pin drivers.
Quietust wrote:
The metal image for that PPU is a bit blurry compared to the image I used for Visual 2C02, but hopefully it should be good enough for tracing, especially since the "core" of the chip seems to be an almost exact clone of the RP2C02, with differences being mostly in the interconnects and the pin drivers.
Since further steps couldn't be undone, they guy who's doing the work needs absolute approval and confirmation. Your post is one, right?
I found some stitching errors :
But anyway this image looks suitable for reversing to me
org wrote:
I found some stitching errors :
That is exactly what I was afraid of. Can you show where on the die you've found this?
Google wrote:
Forbidden That’s all we know.
I've dug up the roots - all the rivers flocking to
TXC corporation:
Seems TXC "developed" first clone-chips itself in late 80s, and it was:
MG-P-501 (CPU)
photo1MG-P-502 (PPU)
photo2I need to find these chips for testing, and make 100% sure about hybrid or ntsc timings they have.
I know that some MicroGenius consoles was pure NTSC (6527+65
28), but some have (6527
P+65
38) hybrids.
TXC also developed original games, like
Journey to the West (Asia) (Unl)I'm waiting for original RP2C07-0 to decap it too.
Piroxilin just confirmed red\green emphasis bits
swap on TA-02NP 6538.
So, it has same behaviour as RP2C07 and UMC version of hybrid PPU (UA6538).
I guessed famiclone chips was RP2C07 copied, + timings adjusted to be NTSC/PAL hybrid.
I've also confirmed emphasis bits swap on
RP2C07-0
I'm interested in seeing what the RP2A03H differences are.
Sure, but we need 2C07 first:
http://www.qmtpro.com/~nes/chipimages/#rp2c07Quote:
The Visual6502 project has one of these chips depackaged, but no plans to delayer or photograph it have been announced.
And i'm personally interested to find differences between "Dendy" and official NES.
Timings of NTSC/PAL hybrid famiclones are unique. We need to do good research.
Out of curiosity, what method are you using to stitch the individual images?
The various chip scans done by Visual6502 seem pretty clean, and as I understand they were mostly "stitched automatically by Christian Sattler in the UK, using Autopano-sift-C and custom code".
Visual 6502 stitches are probably done in the UK to work around the University of British Columbia's US patent on
SIFT, the scale-invariant feature transform.
RP2C07 will be next. Very thanks to
Rumata, who sent me this chip. Here is preferred decap order:
Code:
1. UA6538 - dendy/hybrid PPU ("UMC") (in progress)
2. RP2C07-0 - NES PAL PPU
3. UA6527P - dendy/hybrid CPU ("UMC")
4. TA-02NP - dendy/hybrid PPU ("TA")
5. TA-03NP1 - dendy/hybrid CPU ("TA")
6. RP2C02H-0 - Famicom AV PPU rev.H
7. RP2A03H - Famicom AV CPU rev.H
Famicom AV chips are in the end of list, because i think they are almost identical to "G"-revision already traced.
So, i missed only NES PAL CPU (RP2A07), because don't have it.
Thanks for the priority list.
Is there a plan to decap the unrevised 2A03 and 2C02 chips to see where the CPU/PPU changes between the recalled square-button Famicoms and the more common later revisions lie?
Siliconpr0n.org actually has a decapped (but not delayered) unrevised RP2A03, and quite a few differences have been identified, most notably the lack of looped noise (which is because the circuitry wasn't even there at all) and a bunch of disconnected mystery logic at the top-right corner of the chip (where the G revision has its giant test pattern).
I wonder what that big mystery blob is... It's still connected to the data bus, even if all the rest of the connections have been broken.
I attempted to trace it out (which was a bit tricky for the lower layers) and uploaded a simulator of it
here - if you can figure it out, then by all means post your findings.
This is a tangent...
It seems to be buggy; the data bus drivers's logic seems to be inverted from what it should be. Makes it hard to figure out what's going on... (Node 42 is "do not drive NES-internal data bus", but it's low (true/drivers enabled) whenever R/W=write or φ2=0. ... which is the wrong sense for the structure that exists.
Is there a convention for naming nodes? Especially in the cases of
- A = not B = not not C?
- D = not E and F = not E?
Anyway, I think it's an M2-based IRQ source... Node 20 appears indicates when all 24 latches have the same value. (Can't tell if 0 or 1). Nodes 75, 108, 141, 172, 209, 247, 278, 24, 76, 109, 142, 173, 210, 248, 279, 27, 77, 110, 143, 174, 211, 249, 280, and 307 appear to be ripple-carry outputs.
The 24-bit counter was intended to be both readable and writeable. Reads from $4017 seem to reload the counter. There seems to be some functionality to disable (or force?) reads from $4016 (what?).
Here's some nodenames: '/a0':317, '/a1':318, '+enable':276, 'NORenable_clk1':321, wraddr0:26, wraddr1:38, wraddr2:41, '+irq':843, '/irq_2':839, '/d0':858, '/d1':787, '/d2':672, '/d3':653, '/d4':583, '/d5':515, '/d6':452, '/d7':384, '_d0':290, '_d1':260, '_d2':224, '_d3':188, '_d4':147, '_d5':119, '_d6':85, '_d7':55, 'd0o':287, 'd1o':256, 'd2o':219, 'd3o':187, 'd4o':155, 'd5o':114, 'd6o':90, 'd7o':54, 'databus/oe':42, 'databus+oe':780, 'databus/oe_2':252, 'w/r':722, '/clk1':756, 'clk1_2':214, 'r/w_2':217, '/a0_2':239, 'a0_2':230, '/a1_2':688, 'a1_2':663, 'd0_pullup_ext':807, 'd0_pulldown_ext':300, wraddr3_2:203, wraddr2_2:202, wraddr1_2:204, wraddr0_2:205, '/wraddr3':30, '/wraddr2':39, '/wraddr1':35, '/wraddr0':32, 'wraddr0_2':852
> So, i missed only NES PAL CPU (RP2A07), because don't have it.
I have a RP2A07 (and RP2C07-0) that you can get. Just PM me an address where to send it if you want (The pins are cut so I don't have much use for them anyway)
> The various chip scans done by Visual6502 seem pretty clean, and as I understand they were mostly "stitched automatically by Christian Sattler in the UK, using Autopano-sift-C and custom code".
I can forward an email to Christian if you want help with some stitching. I can't promise that he'll respond though
Btw, if anyone wants to run some tests on a square button famicom (to verify some behavior or whatever) I have one here with pcb revision 3 and revision less cpu & ppu.
Quietust wrote:
Out of curiosity, what method are you using to stitch the individual images?
The various chip scans done by Visual6502 seem pretty clean, and as I understand they were mostly "stitched automatically by Christian Sattler in the UK, using Autopano-sift-C and custom code".
Talked to them few years back, We are using similar stitching tech, but they use automated stage while I am still on manual.
Anyway, original PAL NES PPU (RP2C07-0) will be next on priority list.
I want to ask community: what simply mappers need to decap high-priority,
maybe MMC3A, MMC3B and MMC3C?
I'm having a very hard time finding whether any of these count as both "common" and "high priority". I can only think of things that would be deemed "points of curiosity" for the common ASIC mappers:
* MMC3: As far as we know, the two variants of the MMC3B are identical to the MMC3A and MMC3C — I wouldn't expect to find an interesting difference there. I think the only big question in my mind would be discovering the niggling details of how Nintendo implemented the PPUA12 edge detection.
* Namco's 108/109/118/119 are hopefully not too hard to find? It'd be interesting to figure out what causes the hazard is that Naruko identified when writing to $0000-$1FFF while executing from $8000-$9FFF.
* MMC1: I'd be idly curious to know how they implemented the MMC1 only paying attention to the first write of a RMW instruction.
* VRC2 and/or clones? Could be interesting to see what the SPI microwire interface looks like.
And then there's various rarer parts that have bigger question marks:
* Namco's 163: Could be interesting to see what the wavetable synthesizer DAC and logic look like. If you get a copy of
独眼竜政宗 = Dokuganryuu Masamune there's a bonus chip-on-board (the one immediately above the copper label "60-12") that's doing something Very Weird, not just being a bonus RAM that's used instead of the normal 163 RAM, but seemingly somehow disabling the normal 163 RAM?
* How exactly does RAMBO-1's IRQ work?
* why does
Irem's G-101 have
so many pins?
The one I most care about is the VRC7.
Technically one has already been decapped but I'm still waiting for a decoding of the instrument ROM, which I understand requires some sort of chemical staining process to make visible?
https://forums.nesdev.com/viewtopic.php?f=9&t=12260
Oh, another random one:
Taito's X1-017 (i.e. mapper 82) is connected to the NES's /IRQ line, but no game uses IRQs. It'd be idly interesting to see if (and how) the IRQ hardware is broken, or how one could be triggered.
I've purchased Madara (VRC6b) and Lagrange Point (VRC7) from ebay.
So, i need to buy PAL NES CPU (RP2A07) and FDS (RP2C33)
for help this project:
https://www.qmtpro.com/~nes/chipimages/
It would be nice to look at UM6561 also. I know that some people don't like these NES-on-a-chip, but actually it is just further development of UA6527 and UA6538. For example, it is interesting how switching between PAL and NTSC is done in these chips.
I agree, but we still wait man who does decapsulation work