It is currently Mon Sep 25, 2017 6:23 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 144 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 10  Next
Author Message
PostPosted: Sat Jan 12, 2013 6:27 pm 
Offline

Joined: Sat Jan 12, 2013 5:15 pm
Posts: 1
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.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 8:37 pm 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 572
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
You got some great ideas !
Nice to see you here too !

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 10:50 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
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.

Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 12:08 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2949
Location: Tampere, Finland
viletim wrote:
...

Bingo.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jan 14, 2013 3:17 pm 
Offline
User avatar

Joined: Mon Aug 16, 2010 4:48 am
Posts: 183
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.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2013 6:03 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2013 9:06 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6183
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2013 9:13 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2013 12:36 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2949
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Tue Jan 15, 2013 12:56 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2013 1:27 am 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
Noise level audio output NES can be estimated here. Taken from this Dendy mod of Famicom:
Image
Stereo AV mod of this Famicom:
ImageImageImage


Top
 Profile  
 
PostPosted: Tue Jan 15, 2013 1:29 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 572
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
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.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Tue Jan 15, 2013 5:00 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10014
Location: Rio de Janeiro - Brazil
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!

Quote:
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.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2013 6:32 am 
Offline
User avatar

Joined: Mon Aug 16, 2010 4:48 am
Posts: 183
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?


Top
 Profile  
 
PostPosted: Tue Jan 15, 2013 7:48 pm 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 144 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 10  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group