UMC UA6528 = Ricoh 2C02E, not G?

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

Moderator: Moderators

User avatar
zoinknoise
Posts: 50
Joined: Fri Mar 04, 2016 9:43 am
Location: Ice Cream Island

UMC UA6528 = Ricoh 2C02E, not G?

Post by zoinknoise »

i made an interesting observation recently... i came into possession of a toploader with a bad PPU, it was toast. (white and gray blobs on the screen instead of sprites and backgrounds)

i figured the cheapest and most convenient way to repair it was to order one of the old UMC clone chips, which you can still get as new old stock on Aliexpress. i used this page on the wiki to pin down the exact part number i needed for my NTSC toploader. the description says that the UMC UA6528 is a clone of the Ricoh RP2C02G. perfect!

when the chips arrived, i ran some tests with Micro Machines, the only game i know of that actually exposes whether the PPU is revision E or G. this game was obviously written for the rev. G and never tested with earlier chips. look at this:
2c02g.png
2C02E.png
ua6528.png
(sorry for the crude photos of my Trinitron but my toploader is unmodded, and i'm not equipped to capture an RF signal.)

notice how only the 2C02G is without any glitches.

is it possible that the UA6528 is, in fact, a clone of the RP2C02E, not G? i am not a programmer so i don't know how to dig into this further, but i wanted to share what i did find.

(i also noticed, and i think it even comes across in the photos also, that the UMC part has *very* slightly more saturated color. i don't think the palette is actually different, the chip is just putting out a slightly hotter analog signal. obviously you'd never notice this unless you were comparing like i did. but i digress.)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by lidnariq »

The relevant difference between the 2C02E (and earlier) and the 2C02G is that the former doesn't permit the user to read OAM (or the current palette?). Palette readback is slow enough to use that I don't know of any games that use it, and Micro Machines is one of the very few that rely on OAM evaluation reads to achieve perfect raster synchronization.

I'll update my page on the wiki to incorporate your findings. Sorry it was misleading.
User avatar
zoinknoise
Posts: 50
Joined: Fri Mar 04, 2016 9:43 am
Location: Ice Cream Island

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by zoinknoise »

lidnariq wrote: Fri Jul 31, 2020 5:27 pm I'll update my page on the wiki to incorporate your findings. Sorry it was misleading.
not at all! even if i knew beforehand it was a clone of rev. E, i would have still bought it. i don't have any spare 2C02G's and even a junk NES console to steal the chip out of would have been more expensive.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by tokumaru »

Super Cars is another game that relies on being able to spy the sprite evaluation pattern in order to synchronize with the PPU.
User avatar
zoinknoise
Posts: 50
Joined: Fri Mar 04, 2016 9:43 am
Location: Ice Cream Island

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by zoinknoise »

tokumaru wrote: Fri Jul 31, 2020 8:00 pm Super Cars is another game that relies on being able to spy the sprite evaluation pattern in order to synchronize with the PPU.
i will check out that one, surprised it's a licensed title...

i was assuming that all licensed NES/Fami games were designed for the 2C02E.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by Pokun »

The developers of that game probably wasn't aware of the pre-2C02G differences, and Nintendo apparently didn't stop all games with compatibility problems like this.
User avatar
zoinknoise
Posts: 50
Joined: Fri Mar 04, 2016 9:43 am
Location: Ice Cream Island

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by zoinknoise »

hmm... okay, i made myself a copy of Super Cars and just did a race. i don't see anything obviously glitchy like the menus in Micro Machines. in fact, all i can find on the wiki is that Super Cars uses an unofficial CPU opcode, but nothing PPU related.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by tokumaru »

IIRC, Super Cars uses it to time that gray section at the top of the screen, supposedly masking off scrolling glitches. I don't remember what happens exactly when OAM reading doesn't work, but I imagine that the gray bar either flickers or vanishes altogether...
User avatar
zoinknoise
Posts: 50
Joined: Fri Mar 04, 2016 9:43 am
Location: Ice Cream Island

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by zoinknoise »

tokumaru wrote: Sat Aug 01, 2020 2:42 pm IIRC, Super Cars uses it to time that gray section at the top of the screen, supposedly masking off scrolling glitches.
ah! well, i did see that. the overscan area at the top glitches like crazy while the game is in motion, but tbh i can't really call it a "glitch" since i am not supposed to be able to see it (my TV has very little overscan) and TONS of NES games have glitching near the edges of the screen. :mrgreen:
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by lidnariq »

Super Cars seems to be using it as a way to detect when rendering starts: there's a loop at $CB6B that waits for the contents to no longer be the first byte of OAM.

Without it, the top 16 scanlines are a jittery mess and often with the wrong scroll value; with it, the top 16 scanlines are a nice clean solid grey. (Mesen makes this easy to test, calling it "Disable PPU $2004 reads")
User avatar
zoinknoise
Posts: 50
Joined: Fri Mar 04, 2016 9:43 am
Location: Ice Cream Island

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by zoinknoise »

lidnariq wrote: Sat Aug 01, 2020 6:43 pm Super Cars seems to be using it as a way to detect when rendering starts: there's a loop at $CB6B that waits for the contents to no longer be the first byte of OAM.

Without it, the top 16 scanlines are a jittery mess and often with the wrong scroll value; with it, the top 16 scanlines are a nice clean solid grey. (Mesen makes this easy to test, calling it "Disable PPU $2004 reads")
is Mesen like, the current most accurate NES emulator? :| i've lost track at this point.

also lidnariq, would you like a UA6528 to do some testing with? i bought 5 of them, don't need them all. it would be nice to see how close it really is to the RP2C02E and you clearly know your stuff.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by lidnariq »

zoinknoise wrote: Sat Aug 01, 2020 7:27 pm is Mesen like, the current most accurate NES emulator? :| i've lost track at this point.
Top-tier, at least. Certainly has a lot of really nice debugging tools.
also lidnariq, would you like a UA6528 to do some testing with?
Uh ... sure? I guess? Not clear what I might learn from it. But I do at least have a NES-001 with a socketed PPU.

We have a die shot of the PAL-B UA6538 over here, and it looks similar to the photos of the 2C02G and 2C04 (equivalent to rev B or C)
User avatar
zoinknoise
Posts: 50
Joined: Fri Mar 04, 2016 9:43 am
Location: Ice Cream Island

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by zoinknoise »

lidnariq wrote: Sat Aug 01, 2020 7:42 pm I do at least have a NES-001 with a socketed PPU.
don't tell me you've had a burned-out PPU also... that would be spooky... :shock:
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by lidnariq »

Oh, no. I intended to design my own NESRGB/HDNES thing but only got as far as socketing the PPU.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: UMC UA6528 = Ricoh 2C02E, not G?

Post by Ben Boldt »

lidnariq wrote: Sat Aug 01, 2020 9:17 pm Oh, no. I intended to design my own NESRGB/HDNES thing but only got as far as socketing the PPU.
OMG please do, let's make it open source! It could support VTxx color tables too! I would help any way I can.

A prime example is the open source RGB adapter for N64 from borti4938:

https://github.com/borti4938

Based on Tim Worthington's shared info:

http://members.optusnet.com.au/eviltim/ ... 64rgb.html


My handywork:
IMG_1863.JPG
IMG_1874.JPG

Of course that is a lot simpler than what would need to be done for the NES but I totally support the idea doing these things not-for-profit and offering pre-built things for some cost. These guys have the right idea.
Post Reply