Visual 2C02

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

Moderator: Moderators

dfrechet
Posts: 10
Joined: Mon Mar 29, 2010 9:19 pm

Re: Visual 2C02

Post by dfrechet »

org wrote:That's how I'm doing it ) At first I trace all layers of high resolution die photos:
http://breaknes.com/files/PPU/2C02G.zip
(since I dont have delayered images I took diffusion layer from Quietust site, other layers are traced by myself)
Original die photos can be found here:
http://uxul.org/~noname/visual6502/RP2C02G/aligned/view
http://uxul.org/~noname/visual6502/RP2C02G/aligned
http://uxul.org/~noname/visual6502/RP2C02G
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Re: Visual 2C02

Post by kyuusaku »

Here's an updated data set. It's in the most efficient format I can think of.

[node name, pulled up, [[driver's gate node, driver's opposite node]]]

Just eval() and dump lines into pull-up and driver dictionaries.

Each of the drivers are implied transistors. Since the redundancy in the previous data sets was confusing I tied each transistor to a single node, meaning there are lots of nodes without any drivers. Due to transmission gates there isn't a way to know which node to give the transistor to, so it's claimed first come first served, which doesn't always yield convenient results.

I purged the OAM and palette RAM cells since they took up 4560 of the 8773 nodes. The hard-earned cell nodes are listed for reference...
Attachments
pal nets.txt
(1.97 KiB) Downloaded 185 times
oam nets.txt
(24.75 KiB) Downloaded 173 times
simple nets.txt
(251.35 KiB) Downloaded 168 times
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Visual 2C02

Post by Quietust »

A few minor updates:
1. I found and fixed a few missing vias, both located near some of the sprite logic; any gate lists you've made should probably be regenerated. Specifically, nodes 755 (connected to t4167) and 10662 (connected to t6212) should now be node 2 (i.e. GND).
2. I also reordered a few transistors in the secondary OAM address counter (so that it increments properly during the "initialization" that takes place during the first 64 pixels of each scanline).
3. I've identified a few more areas of interest - the secondary OAM address counter mentioned above (and the signal which selects between it and "primary" OAM), part of the sprite logic (a pair of shift registers up at the top which are fed from D0-D7 or D7-D0 based on the horizontal flip bit), and the location of the $2007 write buffer: open bus. Yes, that's right - when you write to $2007 to store data in VRAM, the actual byte you wrote sits on the internal I/O data bus for a few cycles before going out to the data pins, so writing to another register too soon (less than 3 CPU cycles later) will cause that value to be overwritten.

I've also identified some more stuff that doesn't simulate properly:
1. Sprite evaluation - when it tries to increment to "next sprite", it occasionally skips over a whole bunch of them, likely because some of the transistors connected to the clock lines are triggering in the wrong order (e.g. PCLK0 goes low and PCLK1 goes high [or vice-versa], there's a brief instant where both are high which causes things to glitch). I'm not sure I know how to solve this.
2. Writing to $2007 - for some reason, the "open bus" value is decaying after about 1 pixel instead of remaining indefinitely (on a real PPU, it lasts a significant amount of time), most likely due to a similar clock glitch, and the result is that the bottom 8 bits of the VRAM address end up getting written instead. If you insert an immediate write of the same value to $2002, then it'll get written properly.

[edit]

Just spotted and fixed another error in the logic for sprite #6 (2nd from the left) which was hardwiring one of its outputs to VCC (and also creating a short between VCC and GND that the netlist generator somehow missed).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Visual 2C02

Post by tokumaru »

Quietust wrote:Yes, that's right - when you write to $2007 to store data in VRAM, the actual byte you wrote sits on the internal I/O data bus for a few cycles before going out to the data pins, so writing to another register too soon (less than 3 CPU cycles later) will cause that value to be overwritten.
That sure trashes our hopes of ever implementing a DMA feature that writes to $2007 as fast as the sprite DMA writes to $2004, doesn't it?

Well, 3 cycles is still better than 6 (LDA #$XX STA $2007), 7 (LDA $XX STA $2007), or 8 (LDA $XXXX, X STA $2007), which are currently the fastest ways to write to VRAM.
User avatar
HardWareMan
Posts: 209
Joined: Mon Jan 01, 2007 11:12 am

Re: Visual 2C02

Post by HardWareMan »

People, could someone convert those transistor based schemes into standard logic ones? I want to make functional copy of PPU in CPLD with non composite output. The big idea is get functional correct copy of PPU with component output (YPbPr). Because i think RGB is not correct output for NES/FAMICOM PPU and component YPbPr much closer to YUV. Thus PbPr will formed from number of color phase and Y from luma and sync. Does anyone ever think about this?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Visual 2C02

Post by lidnariq »

HardWareMan wrote:People, could someone convert those transistor based schemes into standard logic ones? I want to make functional copy of PPU in CPLD with non composite output. The big idea is get functional correct copy of PPU with component output (YPbPr). Because i think RGB is not correct output for NES/FAMICOM PPU and component YPbPr much closer to YUV. Thus PbPr will formed from number of color phase and Y from luma and sync. Does anyone ever think about this?
Many times.

There's actually enough information in the 2C02's output to completely reconstruct the original color data, all 9 bits of it. The parts for it are even fairly affordable.

I think the real modern problem is that very few modern televisions do the right thing with a 240p signal, and upscaling the output is kind of a pain. But to add insult to injury, even if we added an upscaler, I don't know how many televisions will do the right thing (by which I mean "not add latency") for 480p input.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Visual 2C02

Post by tokumaru »

lidnariq wrote:There's actually enough information in the 2C02's output to completely reconstruct the original color data, all 9 bits of it.
Even considering that the color emphasis bits appear to have sub-pixel resolution? I don't remember the details, but I think blargg discovered this a while ago.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Visual 2C02

Post by tepples »

When I described this technique, I hadn't considered emphasis.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Visual 2C02

Post by lidnariq »

tokumaru wrote:
lidnariq wrote:There's actually enough information in the 2C02's output to completely reconstruct the original color data, all 9 bits of it.
Even considering that the color emphasis bits appear to have sub-pixel resolution? I don't remember the details, but I think blargg discovered this a while ago.
Ok, not subpixel. But that's 2C07 only, and I was under the impression (because of how much slower the CPU was) you couldn't consistently align it to one pixel, so as long as it's acceptable to snap emphasis to pixel boundaries it should still be doable.
tepples wrote:When I described this technique, I hadn't considered emphasis.
Yeah, I sat down and generated a lookup table of all pixel-long=8-sample sequences; there are 425 of them for every single combination of color and emphasis. An extra counter is required to keep track of phase, because of the fpart(341×2÷3) and so colors $31 and $35 and $39 can produce the exact same 8-sample sequence. Several colors are indistinguishable once allowing for -30dBFS noise; e.g. color $10 with red emphasis quantizes as the same as color $32 with all emphasis bits set.
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

I found that bottom-left piece of PPU is actually sprite FIFO:

http://code.google.com/p/breaks/wiki/PPU_OAM_FIFO

Some information on russian, Google translate helps you :D
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Visual 2C02

Post by Quietust »

Yes, that's one of the things I spotted yesterday:
Quietust wrote:part of the sprite logic (a pair of shift registers up at the top which are fed from D0-D7 or D7-D0 based on the horizontal flip bit)
I also confirmed that the far-right column is for the first sprite and the far left column is for the 8th sprite, based on the priority logic directly above them.

Also, the bit at the very bottom-right of that area is the $2007 read buffer (D0-D2 on the bottom, a gap, and then D3-D7 at the top).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

OAM FIFO circuit:
Image

Small circuit on upper-right corner of FIFO is acutally sprite H-inversion logic.

Ah, and a weird tangle on the top is some kind of sprite color selector, which select pixel color in case more than single sprite hit the spot.
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

Ugh, just noticed I have wrong FIFO order :mrgreen: Nevermind )
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Visual 2C02

Post by Quietust »

org wrote:Small circuit on upper-right corner of FIFO is acutally sprite H-inversion logic.
Yep, that's the bit I was referring to in my previous post.
org wrote:Ah, and a weird tangle on the top is some kind of sprite color selector, which select pixel color in case more than single sprite hit the spot.
That's actually how I determined that sprite 0 is on the right and sprite 7 is on the left - the one on the far left requires not only for sprite 7 to be outputting a visible pixel but also for sprites 6-0 to not be outputting a visible pixel, while the one on the far right just has the check for itself (and also has some additional logic to activate sprite 0 hit).

I noticed you pointed out an "oddity" in the middle of the H position counter where the carry input for bit 5 is actually bits 0 thru 4 ANDed together (actually the inverted bits 0-4 NORed together) rather than the carry output for bit 4; I observed this same thing in the master H/V counters at the top of the chip, and I can only assume that it was some sort of protection from timing glitches.

It'd also be nice if you could match up some of the signals you've named with node numbers in Visual2C02 so I can add them to nodenames.js and make it easier for others to trace signals around.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

I can only assume that it was some sort of protection from timing glitches.
I'm calling this thingy: "a twist". Look how these sort of counter work (on H/V example) :

Code: Select all

iterations:
0: H=0 V=0
1: H=478 V=479
2: H=478 V=479
3: H=32 V=32
4: H=32 V=32
5: H=446 V=447
6: H=446 V=447
7: H=64 V=64
8: H=64 V=64
9: H=414 V=415
10: H=414 V=415
11: H=96 V=96
12: H=96 V=96
13: H=382 V=383
14: H=382 V=383
15: H=128 V=128
16: H=128 V=128
17: H=350 V=351
18: H=350 V=351
19: H=160 V=160
20: H=160 V=160
21: H=318 V=319
22: H=318 V=319
23: H=192 V=192
24: H=192 V=192
25: H=286 V=287
26: H=286 V=287
27: H=224 V=224
28: H=224 V=224
29: H=254 V=255
30: H=254 V=255
31: H=256 V=256
32: H=256 V=256
33: H=222 V=223
34: H=222 V=223
35: H=288 V=288
36: H=288 V=288
37: H=190 V=191
38: H=190 V=191
39: H=320 V=320
40: H=320 V=320
41: H=158 V=159
42: H=158 V=159
43: H=352 V=352
44: H=352 V=352
45: H=126 V=127
46: H=126 V=127
47: H=384 V=384
48: H=384 V=384
49: H=94 V=95
50: H=94 V=95
51: H=416 V=416
52: H=416 V=416
53: H=62 V=63
54: H=62 V=63
55: H=448 V=448
56: H=448 V=448
57: H=30 V=31
58: H=30 V=31
59: H=480 V=480
60: H=480 V=480
61: H=510 V=511
62: H=510 V=511
It'd also be nice if you could match up some of the signals you've named with node numbers in Visual2C02 so I can add them to nodenames.js
I'm afraid I can overlap you changes. If you send me fresh nodenames.js, I'll update it and send it back. I'm in skype.
Post Reply