Visual 2C02

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

Moderator: Moderators

User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: Visual 2C02

Post by mikejmoffitt »

Bregalad wrote:This sure looks very interesting, but how am I supposed to use this ?

@mikejomffit : The NES PPU does not have RGB output, and it was never meant to have any. The output signal is composite by the very nature of how the NES palette works, and it can't be otherwise.
I understand this. However, the R2C03+ series that was designed to have RGB output by means of the color look-up table can't be a far cry from the design of the 2C02. With the chip de-capped and more thoroughly understood, would re-implementing this capability be out of the question?
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Visual 2C02

Post by Quietust »

I've just updated the Visual 2C02 to reset at the very beginning of scanline 260 (by running it to scanline 260 over the course of about an hour, saving its state, and then changing the Reset button to just load that state instead) and also fixed a bug in the VRAM address T->V reload logic (missing buried contact). During this process, I've confirmed several details:

1. When you reset the PPU, it's at the first visible scanline (i.e. scanline 0), and it's not until the PPU reaches the first pre-render scanline (scanline 261, also known as "scanline -1" in numerous emulators) that it becomes possible to write to most of the I/O registers.
2. The "T->V (horizontal bits only)" transfer during each scanline (including the prerender one) happens at pixel 257, as previously observed.
3. The previously observed "T->V (all bits)" at cycle 304 isn't exactly correct - what's really happening is that the PPU copies the non-horizontal bits from T->V during every pixel from 280 through 304 inclusive (which happens to correspond to the HBlank pulse).
4. Reading/writing $2007 appears to start the I/O one pixel after the CPU read/write cycle finishes.
5. Writing $2004 appears to push the actual data into SPR-RAM one pixel after the CPU write cycle finishes and increment the address 1 cycle later. It isn't clear exactly when the memory controller latches the value to be written, but it's probably at the beginning of the CPU's write cycle, so going faster than the 2A03's sprite DMA would probably fail.
6. The above pixel numbers are actually off by 1 compared to the cycle numbers we currently know for the rendering process - a typical scanline appears to go as follows:

0 - junk (latched address $1000 but did nothing)
1-2 - read nametable byte of 3rd tile
3-4 - read attribute table byte of 3rd tile
5-6 - read pattern table byte of 3rd tile
7-8 - read pattern table byte of 3rd tile
9-16 - fetch 4th tile
17-24 - etc.
...
249-256 - fetch 34th tile
257-264 - fetch 1st sprite, resetting the horizontal scroll bits in the VRAM address
265-272 - fetch 2nd sprite
273-280 - fetch 3rd sprite, starting HBlank at the 2nd cycle of the final read
...
304-312 - fetch 7th sprite, ending HBlank at the 2nd cycle of the first read
313-320 - fetch 8th sprite
321-328 - fetch 1st tile (next scanline)
329-336 - fetch 2nd tile (next scanline)
337-338 - read nametable byte of 3rd tile
339-340 - read nametable byte of 3rd tile

The entire chip uses a 2-phase clock where the 1st phase is what updates the H/V counters and actually starts external memory accesses (it's when ALE|/RD|/WR get activated) and the second phase is what triggers changes in the video signal (e.g. hblank starts halfway through cycle 280 and ends halfway through cycle 305). When the CPU and PPU clocks are properly "synchronized", memory accesses from the CPU (which take 3 pixels to complete) will be noticed by the PPU at the beginning of the second pixel (which probably explains the difference between the above pixel numbers and the previously known cycle numbers), while reads don't actually sample their data until the very end of the 3rd pixel (according to some testing with the Visual 2A03).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Visual 2C02

Post by Bregalad »

This is all very initeresting things !

I must admit I am still not yet familiar with observing transistors on a die, especially considering this is old technology which I think uses exclusively NMOS transistors (no PMOS) which is extremely weird. If anyone could explain me basically how this works or point me to some explanation it would be great.

I know it's nothing new, but it's funny how the PPU actually fetches 34 tiles when only 33 can be displayed. It's also funny to see how they did the colour DRAM with plain capacitors. The caps seem even smaller than transistors which is very surprising to me.

PS : Do you guys remember this old demo which says "Emulation might never be perfect, if you agree press start" ? Well not only this demo did ironically not run properly on the real hardware, but also it was wrong, emulation might be perfect.
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

OAM:

Image
(clickable)

including:
- OAM fetch and control logic
- OAM I/O buffer
- OAM RAS/CAS
- OAM DRAM

I identified some control lines, which may help.

Some PPU simulation here :
http://code.google.com/p/breaks/source/ ... RP2C02/SRC
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Visual 2C02

Post by Bregalad »

Is is me, or OAM is actually SRAM, not DRAM as previously doccumented ?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Visual 2C02

Post by tokumaru »

Bregalad wrote:emulation might be perfect.
...and slow! XD
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

Both palette RAM and OAM are using pair of transistors, forming dynamic bi-stable latch. So this is obviously DRAM.
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Re: Visual 2C02

Post by kyuusaku »

org: I think you have the OAM row/word line's inverted, the rightmost line is high when all row bits are high, so shouldn't it be 31?
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

Yup, I'll update circuit tomorrow )

Originally it was in correct order, but at some moment they got inverted :mrgreen:

(I think it was after I wrote OAM RAS simulator: http://code.google.com/p/breaks/source/ ... /SRC/OAM.c and started to examine RAS outputs)
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Visual 2C02

Post by Quietust »

org wrote:Both palette RAM and OAM are using pair of transistors, forming dynamic bi-stable latch. So this is obviously DRAM.
Specifically, each memory cell consists of two transistors which have one terminal connected to GND and the other terminal connected to the opposite transistor's gate - applying voltage to one side causes the other side to be pulled down to GND. There's no positive feedback between them, though - the voltage simply floats within the gate and needs to be refreshed every so often by isolating the bus, precharging it, then exposing one column of cells to the bus so that it boosts the "high" side closer to VCC (while the "low" side simply sucks the charge into GND).

If it were SRAM, there would be two inverters feeding into each other, which manifests itself (in NMOS) as 4 transistors (2 of which are just pull-up resistors) - most of the registers on the chip are implemented as "dynamic latches", which are effectively inverter loops with an extra transistor+selector in the middle so that it can be reloaded with an external value (i.e. from CPU write) instead of itself.
kyuusaku wrote:org: I think you have the OAM row/word line's inverted, the rightmost line is high when all row bits are high, so shouldn't it be 31?
The OAM0-7 (but not OAM8) lines feeding into the row/column decoders are inverted from the actual SPR-RAM address register - the far right "row" of memory is indeed "row 0" (in that it's the one that gets contains the values at SPR-RAM addresses $00-$07). However, the address lines themselves are not only inverted, but they are also backwards - the column decoder at the top takes A0-A2+A8 (not A5-A8) and the row decoder in the middle takes A3-A7 (not A0-A4), all organized from bottom to top (i.e. OAM5/6/7/8 are actually A0/A1/A2/A8 and OAM0/1/2/3/4 are actualy A7/A6/A5/A4/A3).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Re: Visual 2C02

Post by kyuusaku »

This might help:

Image

Edits:
Kind of funny that OAM and palette RAM make up 60% of the transistors.

I've auto-captured the NOT and NOR gates, 1151 of them. Useful? I'll attach them anyway...
The first element is the output net/node, the rest are inputs.
Attachments
not-nor gates.txt
(28.16 KiB) Downloaded 256 times
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Visual 2C02

Post by Quietust »

I appear to have run into a bug in ChipSim, and it's probably the same one that was causing bizarre glitches in the Visual 2A03's triangle channel. Whenever I attempt to write to $2005 or $2006, the toggle always clears itself when the write starts, seemingly because transistors are being turned on and off in the wrong order. I have an idea as to how I can fix it, but I'm not sure if it'll work.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Re: Visual 2C02

Post by kyuusaku »

Anyone have any ideas on how to group transistors for comprehensible textual output? I've refined the node (guess I can call it "node", eww) organization so I can walk through the schematic and fairly easily transcribe it to paper, since my netbook doesn't really have the screen space, but that gets old really fast when you have to write down and match node numbers.

Or know a schematic capture program with a simple design/symbol format that can beautify ratsnest output?

Blah, I wish I didn't notice this thread, oh how work and chores have suffered >_< I'm more interested in the schematic side of things but I even tried my hand at a simulator >_< >_< The design is solid, in theory, since it implements iterative (uniform for now) propagation. If anything it'll be friendlier than Visual6502's at <200 lines.
User avatar
org
Posts: 155
Joined: Tue Aug 07, 2012 12:27 pm

Re: Visual 2C02

Post by org »

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)

Then I save it as PNG, cut some part and double the scale (original picture still too small to draw transistors).
Then I start to draw it piece by piece:
http://breaknes.com/files/PPU/OAM.zip

Ctrl-C -> Ctrl-V really helps to me, there are too many regular structures on the chip )

I tried to restore circuit from the node list, but its a mess.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Visual 2C02

Post by Quietust »

From the information I've gotten on the Visual 6502 mailing list, it sounds like these timing glitches I'm running into will need to be handled on a case-by-case basis (the Visual 6502 and 6800 seemingly also had this problem and presumably had to be hand-tweaked) - I've reordered the transistors in the $2005/$2006 toggle and it seems to be working correctly now.

In the process of checking that, I've also confirmed several additional useful bits in the simulator:
1. Palette RAM works correctly - I've successfully written and verified a string of 00s (came back as 00), a string of FFs (came back as 3F), and an incrementing sequence 00-1F (which came back as 10,01,02,03,14,05,06,07,18,09,0a,0b,1c,0d,0e,0f,10,11,12,13,14,15,16,17,18,19,1a,1b,1c,1d,1e,1f, just as expected).

2. The video signal generator also seems to be working correctly - I measured the timing of all the various regions listed on the wiki page, and they matched 100% (though, for some reason, the "pulse" sometimes came out with the "left border" color - maybe it doesn't always show up?), and I also confirmed that the "active" region actually starts at "pixel" 4 (the second cycle of the 3rd tile's attribute read), which might be important for proper grayscale/emphasis timing.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Post Reply