RGB output from composite PPU

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

Moderators: B00daW, Moderators

viletim
Posts: 1
Joined: Sat Jan 12, 2013 5:15 pm

Re: RGB output from composite PPU

Post by viletim » Sat Jan 12, 2013 6:27 pm

HardWareMan wrote:
thefox wrote:I'm using the EXT-pins of PPU. The only "emulated" part is the capturing of the PPU palette writes.
But HOW?! (C) Moss / The IT Crowd
Didn't EXT output displays only part of the information? Should be 5 bit color (4 bits of background and 4 bits of sprite), while the width of the EXT only 4 bits.
Image
And EXT shuold be enabled as output by writing to PPU control register, isn't it?
As I understand it, the palette data is written to the PPU's internal palette registers which CPU accesses via the address/data register pair (0x2006/0x2007). The palette contains 32 entries (bytes) - 16 for sprites and 16 for background. The EXT port is normally an input for pixel data (as palette indices) but can be set as an output by setting the appropriate bit in the PPU's control register (0x2000). Palette data can be collected by listening to the data data bus and 4 bits of pixel data can be had from the EXT port so long as it's set as an output. That's about 90% of the data required to create a picture. The only thing missing is the fifth bit of the pixel data. The background/sprite bit.

Have I got this right? I only found this thread yesterday and have since been reading about NES hardware from the Nesdev wiki and Nintendo's patent ( http://www1.cs.columbia.edu/~sedwards/p ... 1989tv.pdf ) which contains some excellent diagrams of the inner working of the PPU. I hadn't heard of this EXT port before!

If this is correct, we are only one bit away from easily creating RGB video from the available data. There is just one bit rattling around inside the PPU that needs to escape. The information does come out eventually in the form of the video signal. But it's not very practical to go sifting through that mess. You could digitise it and ask each pixel "are you background or sprite?" but that is far too much work...

Why not simply remove all the extraneous information from the video signal? I think this what the OP does with his PLD. He places it between the CPU and the PPU, collects up all the palette data but doesn't give it to the PPU. The PPU instead gets a special palette - the 16 sprite entries are all white and the 16 background entries are all black. The fifth pixel bit then plops right out where the video used to be! He uses a comparator (inside the PLD?) to turn it into a logic level and generates the video signal with all information.

User avatar
TmEE
Posts: 712
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: RGB output from composite PPU

Post by TmEE » Sat Jan 12, 2013 8:37 pm

You got some great ideas !
Nice to see you here too !

User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Re: RGB output from composite PPU

Post by kyuusaku » Sat Jan 12, 2013 10:50 pm

We know it isn't a comparator.

Short of some new exploitable HW discovery the key must be the priority multiplexer's propagation. The pixel's stabilization should be visible through the transparent latch, which can then be used to differentiate between background and sprite. Even if the multiplexer isn't reset each pixel the state can be synchronized to rendering. (Or if you absolutely had to you could detect the asymmetric propagation.)

Edit: ahhhhhh totally missed the intercepting PPU data part
Last edited by kyuusaku on Sun Jan 13, 2013 12:38 am, edited 2 times in total.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: RGB output from composite PPU

Post by thefox » Sun Jan 13, 2013 12:08 am

viletim wrote:...
Bingo.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
Drakon
Posts: 183
Joined: Mon Aug 16, 2010 4:48 am
Contact:

Re: RGB output from composite PPU

Post by Drakon » Mon Jan 14, 2013 3:17 pm

viletim wrote:As I understand it, the palette data is written to the PPU's internal palette registers which CPU accesses via the address/data register pair (0x2006/0x2007). The palette contains 32 entries (bytes) - 16 for sprites and 16 for background. The EXT port is normally an input for pixel data (as palette indices) but can be set as an output by setting the appropriate bit in the PPU's control register (0x2000). Palette data can be collected by listening to the data data bus and 4 bits of pixel data can be had from the EXT port so long as it's set as an output. That's about 90% of the data required to create a picture. The only thing missing is the fifth bit of the pixel data. The background/sprite bit.

Have I got this right? I only found this thread yesterday and have since been reading about NES hardware from the Nesdev wiki and Nintendo's patent ( http://www1.cs.columbia.edu/~sedwards/p ... 1989tv.pdf ) which contains some excellent diagrams of the inner working of the PPU. I hadn't heard of this EXT port before!

If this is correct, we are only one bit away from easily creating RGB video from the available data. There is just one bit rattling around inside the PPU that needs to escape. The information does come out eventually in the form of the video signal. But it's not very practical to go sifting through that mess. You could digitise it and ask each pixel "are you background or sprite?" but that is far too much work...

Why not simply remove all the extraneous information from the video signal? I think this what the OP does with his PLD. He places it between the CPU and the PPU, collects up all the palette data but doesn't give it to the PPU. The PPU instead gets a special palette - the 16 sprite entries are all white and the 16 background entries are all black. The fifth pixel bit then plops right out where the video used to be! He uses a comparator (inside the PLD?) to turn it into a logic level and generates the video signal with all information.
Strange how they made it difficult to get the 5th bit of data. That's pretty cool, if we're at that point then all that's left to do is decide what format(s) to output to. Would it be possible to get digital audio from a nes somehow? I don't think the cpu ever outputs digital audio data, but then again I didn't know the ppu can output its data digitally so who knows.

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Re: RGB output from composite PPU

Post by 3gengames » Mon Jan 14, 2013 6:03 pm

Nope, audio is just output via analogue, not much you can do about that. Although, it sounds best in mono straight from the NES, so it doesn't really matter. But still, any news on getting this turned in to a board? any guesses on a big/general price range? Would love to know these details and follow this projects development.

lidnariq
Posts: 8768
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: RGB output from composite PPU

Post by lidnariq » Mon Jan 14, 2013 9:06 pm

IMNSHO, it adds a little richness and doesn't sound bad iff the stereo separation is very slight. Maybe 3dB difference at max.

In a stupid augmentation way, if you have an upscaling HDMI output, it would be nifty to add full quadraphonic support (unfortunately, necessarily by emulating the APU).

In any case, itemizing this out: a non-upscaling version would need a fairly small PCB, a few sockets, a CPLD/FPGA with enough room for 192 bits of RAM and 13kbit of ROM. It looks like something like Lattice's cheapest FPGAs with level shifters might be the best call; they have enough memory to get you upscaling for free.

I'd probably give up on a "real" video DAC and just use a bunch of 5-bit R-2R DACs and opamp buffers—I can't find any "real" DACs that support the necessary bandwidth (11MS/s) for a remotely competitive price.

For connectors, VGA natively allows hotplug detection (pullup in the generator on ID0/pin 11, pulled to ground by the monitor), and for component RCA connectors are sold that allow hotplug detection. Looks like s-video's SOL for insert detection.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: RGB output from composite PPU

Post by blargg » Mon Jan 14, 2013 9:13 pm

Given that the low bit resolution of NES audio output, it wouldn't be hard to recover bit-perfect output from the NES. The only snag is that it runs at a 1.79 MHz sampling rate, so you'd need a video ADC to capture it. And there's not much you could do with it that would make sense; you'd either feed it back to a DAC, or downsample it to 44.1/48/96 kHz.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: RGB output from composite PPU

Post by thefox » Tue Jan 15, 2013 12:36 am

The NES audio output is fairly noisy though, I'm not sure where the noise originates but that could possibly be mitigated by tapping into the audio outputs.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: RGB output from composite PPU

Post by blargg » Tue Jan 15, 2013 12:56 am

Definitely you'd use the pair of audio outputs from the 2A03. I see that the mixing of those involves 12K and 20K resistors, fed to an amplifier made of an inverter, so it's somewhat high-impedance and thus the RCA output is noise prone. Plus the high-pass capacitor makes it much harder to decode the absolute DAC levels. Maybe what's wanted here is just a better audio output mixer/amplifier section, rather than recovery of the digital signal.

User avatar
HardWareMan
Posts: 206
Joined: Mon Jan 01, 2007 11:12 am

Re: RGB output from composite PPU

Post by HardWareMan » Tue Jan 15, 2013 1:27 am

Noise level audio output NES can be estimated here. Taken from this Dendy mod of Famicom:
Image
Stereo AV mod of this Famicom:
ImageImageImage

User avatar
TmEE
Posts: 712
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: RGB output from composite PPU

Post by TmEE » Tue Jan 15, 2013 1:29 am

Audio output from the CPU is clean, it gets noisy because the signal gets attenuated and runs all over the board and right next to the PPU at one point and that is where the audible noise comes in. (at least this is what is going on in my NES)

As for PPU EXT pins, now I know why I got funny colors in some places on my NES when I disconnected the EXT pins in preparation for possible future RGB PPU.

I only got excess of PAL PPUs, I could take some time and wire up a second PPU.

I would give second PPU a local 16KB block of RAM (or more with some banker). Address decoder should be easy to add there.

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: RGB output from composite PPU

Post by tokumaru » Tue Jan 15, 2013 5:00 am

TmEE wrote:I only got excess of PAL PPUs, I could take some time and wire up a second PPU.
It would be great if you did!
I would give second PPU a local 16KB block of RAM (or more with some banker). Address decoder should be easy to add there.
I guess the RAM could always be enabled, right? And you'd even get 4 name tables to work with.

User avatar
Drakon
Posts: 183
Joined: Mon Aug 16, 2010 4:48 am
Contact:

Re: RGB output from composite PPU

Post by Drakon » Tue Jan 15, 2013 6:32 am

HardWareMan wrote:Noise level audio output NES can be estimated here. Taken from this Dendy mod of Famicom:
Image
Stereo AV mod of this Famicom:
ImageImageImage
Looks like you removed the resistors that connect the audio signals to the onboard circuit and rebuilt the circuit on that rf box at the back. Does your circuit mix in pins 45 / 46 of the famicom cartridge slot so games with added audio chips still get the audio mixed in?

User avatar
HardWareMan
Posts: 206
Joined: Mon Jan 01, 2007 11:12 am

Re: RGB output from composite PPU

Post by HardWareMan » Tue Jan 15, 2013 7:48 pm

Drakon wrote:Does your circuit mix in pins 45 / 46 of the famicom cartridge slot so games with added audio chips still get the audio mixed in?
Yes, it does. And I also cut off #45 from internal circuit to prevent additional noise.

Post Reply