What's new
why not including RGB in the design

this PCB should have supported RGB from day fucking one

I don't see the point of this board

I think the point of this was to just do a straight, repo of the original mobo. It's useful from a preservation standpoint and it's also useful as a foundational starting point for people who want to do customization with other built-in functionality.

Now if you want to do something like a built in RGB or a JAMMA Edge you have the files for the core Nintendo stuff already done and it's just a matter of forking the design and adding your desired enhancements.

From a simple documentation standpoint maybe by being able to see all of the connections in the original system and better understand how they work is a good way to come up with new mods or otherchanges to the design down the road.

Maybe this isn't super useful from a "I want to use this to play Nintendo games" standpoint but I see it as extremely valuable from a knowledge/preservation standpoint and a jumping off point for new and interesting Nintendo-based hardware.
 
Oh, absolutely. I was just thinking out loud that currently getting a PCB made out of it - as it is - brings nothing to the table for me. But yeah, great work from the guy that made it.
 
twistedsymphony is correct, putting out a majorly improved PCB with RGB and such wasn't really the point, the point was documentation, and preservation of the original design, and to make it available to anyone who wanted to make their own custom designs, or to learn something new from the materials, or for those that just wanted to make use of it as is.

Unfortunately I don't have the time and energy to throw at R&D for an open source RGB mod these days, despite that being one thing I really want to do.

Regarding cases, I'm not sure if it's what you're looking for, but a guy that goes by Retrocution has made something that's a stand of sorts that showcases the PCB while allowing you to play it: https://twitter.com/_RETROCUTION/status/1250333915128025088?s=20
And I believe the intent is to put it on thingiverse so people can print their own.

Anyway, I appreciate the discussion and feedback!
 
I think the point of this was to just do a straight, repo of the original mobo
But that isn't possible without the removal of existing/working CPU/PPU from an original console.
So I don't think its "fair" to refer to this as "reproduction" no.

If you are gutting a NES for its case, pulling its CPU/PPU for an alternative implemnetation why not include RGB?
Sure I can see not adding the JAMMA edge, that's super nith just to us... But RGB? WTF.
 
Unfortunately I don't have the time and energy to throw at R&D for an open source RGB mod
Yea super unfortunate because I feel that is what's keeping this board from attaining true greatness/legendary status.
Not trying to rub it in, lord knows I'm not stepping up to this challenge. But stand by that criticism I do.

Look at it this way... Why would anyone buy Tim's RGB kit if this PCB preformed that function?
After all it requires you to also pull the PPU, so what's adding/pulling the CPU at the same time?
If no functional difference between this PCB and a "real" NES existed I can think of NONE/NO reason.
 
Last edited by a moderator:
But that isn't possible without the removal of existing/working CPU/PPU from an original console.
it's a reproduction of the BARE PCB, nothing more...

the guys not making and selling these... it's information. it's like if I showed you a picture of a NES to say "here's what it looks like" and you complain that you can't play games on a picture.
 
Well, for me a reason would be just to build it, having clean sockets for everything, and using high quality components. And then just leaving it on a shelf... I would be happy just with the clone CPU/PPU mentioned on the github page, maybe with FPGA replacements in the future.
 
Did you guys know prior to this there wasn't actually a complete or accurate set of schematics for the NES ?

Think of it more as a "reference design"
 
NESessity was independently developed by Low Budget, it's not related to my work.
So two different persons worked on the same thing at the same time?
What a waste of time and energy! Unfortunately not uncommon, people seem to like to redo what others have done rather than doing something new,

Anyway, thanks @Redherring32 for your contribution to the community. :thumbsup:
 
Would love to build one with RGB PPU. I wonder how difficult it would be to take the cpu/ppu from the NES mister core and make a small ppu & cpu fpga adapter pcb? small 5v compatible fpgas might be hard to find? Lattice maybe has some but they dont have any free designsoftware that I can find.

found the UniversalPPU on github but that was alot more complicated than I thought it had to be :/.
 
Last edited:
For anyone else interested in restoring or a reproduction system using the opentendo, I found this (WIP) power board: https://github.com/mspinksosu/NES-Power-Board
It's not functional yet so it seems you'll need an original rf/power board in the meantime.
Also some of you may find this build interesting:
View: https://youtu.be/FpJ06KvhN0E

At 20:15 he shows a print he did of the aforementioned power board and discusses some of its issues.
 
Not really. Actually the RGB mod isn't that complicated, I have studied it a bit. All colour bits are easy to sniff and externalise, the only tricky one is the one used to define background/sprite. The workaround is intercepting data and use only white for sprites internally in the PPU and only black for background. Then you can easily recreate the missing bit by comparing video output level generated by the PPU.
The solution offered by Tim Worthington is more complex because it also provides audio and video amplification, s-video, composite video encoded from the generated RGB signals, extra user palettes,etc.
I bought a Famicom recently and was wondering about this...

https://wiki.nesdev.com/w/index.php/PPU_pin_out_and_signal_description

I assume "master" mode is the default for NES games, to write palette indices to EXT0-EXT3. Is that only the background data? Or is it just missing the highest palette index bit?

So your hack is to grab the palette data and write black/white into the internal palette, and then combine the palette index with sprite/bg info from the analog output, and map it through an external palette?

Alternatively, as you get the clock value that the PPU derives its internal timings from, I'm wondering if some kind of simplified NTSC/PAL decoder would be possible to derive digital YUV values you could re-map into RGB.
 
Last edited:
You need to intercept palette data, store it aside in a small RAM and feed the PPU with white ($20 or $30) or black instead ($xf).
You then get the palette index from EXT0-EXT3 but you have no clue if you have to look in the sprite or background table. Comparing the video signal level gives you the answer.
 
Back
Top