that explains it... Now I see on your image... Yep, black wire is ground. +5v I'm probably not going to wire as the XRGB-mini doesn't need it as far as I know. Yes I bridged the J3 jumper to let the NESRGB get powered from the Twin itself.Elrinth wrote:@eightbitminiboss:
ok thanx!
The black cable, is that the GND in your case?
Where would you connect the +5V from the nesrgb to the twin fami's boards?
I saw that J3 on the NESRGB needed soldering (shorting) if you were supposed to take power from famicom/nes. Is that right? It looks like you done so on your pic aswell.
I went ahead and installed the 12ns SRAM that was mistakenly identified as the SRAM from the original batch. I did this on both of my nesrgb boards. The one in my front loader works perfectly. The nesrgb in my Famicom has some graphical glitches but I doubt that the 12ns SRAM is the problem. Installing the nesrgb in an original Famicom is a lot messier than on any other Nintendo consoles.markfrizb wrote:Can anyone confirm that the original SRAM and/or the SRAM Tim later said was the *correct one -- that both work or just one or ????
I'm thinking I'm just going to replace my SRAM but I bought the first ones that came up in discussion (the 12ns speed I think). And I think the 15ns one is what should have been used/bought. Do I need to buy the different ones or use what I have now?
must've screwed something up. the led will not light up. i probably destroyed something.Elrinth wrote:did you get any NESRGB voltage regulator in your package by chance? because I didn't. am I supposed to have gotten a NES RGB voltage regulator mini board?eightbitminiboss wrote:Remember that pins 14-17 on the PPU are connected to the ground plane of the board and will require more care in desoldering. I did not heed this warning and ended up toasting my board because of it.
Anyways, here's my resulting WIP with my Twin, another one is in the mail....
Here's what I got:
* nesrgb board
* 2 small screws
* s-video output
* s-video tiny board for the output
* rgb output
* rgb tiny board for the output
* 4 x up n down pins for ppu
* 2 x for only down pins for ppu
* 1 x for dual socked pins for ppu
* 1 x twin fami below board swapper thingie
* 1 x audio thingie
* 1 x scart dual cable to rgb + audio
according to jeppen he got a NESRGB voltage regulator, am I missing this item?
http://shmups.system11.org/viewtopic.ph ... start=1410
guess I'll call it a night since I don't know what I'm supposed to do now.
Top loaders don't have a fuse.SNKNostalgia wrote: I have a NES Toploader handy here with a dead fuse and another Front loader at my parents house stored somewhere. Will the Toploader PPU work in the Front loader with or without the RGB board at least.
game-tech.us wrote:Tim emailed me and has sent a blaster my way, so it should be here next week.
Tim has set me up as the Indiana and Michigan contact for ppl wanting to send their board to someone else to flash, but i'm simply not ready to start doing it. I need the blaster and some time to make sure I do it right before I have ppl send them my way. Once i'm ready there's no reason it has to be only IN and MI ppl, the shipping cost will be the same for anyone in the US and I believe Tim is taking care of the shipping costs.
I was thinking the same.CkRtech wrote:I suppose one issue now is that it appears that the software we are flashing is still in testing. The NESRGB POF 1.1 was the first revision, and now 1.2 is in testing. I am concerned about the issues ApolloBoy has experienced.
If anyone was planning on mailing a board to someone else to flash or mailing off a Blaster as part of "pass the blaster," you may want to hold off until everything has been tested a bit more. You may end up with a board with POF 1.1 when you are really going to need something like 1.4.
Well, the black and white PPU composite when a palette is selected sounds pretty normal. I think the NESRGB needs this black and white PPU output to calculate some of the information needed to produce the RGB image. Of course, those screenshots of the NESRGB's video output are definitely not normalVoultar wrote:Hey, it could always be worse..
Goonies II never looked so good. There is a definite problem with my board. PPU composite only works if I don't short any of the pads for palette selection, If I do short those pads, the image is black and white.
Encoded composite, S-Video, and RGB are all a bust. (See above pic)
. Which palette is that? Does it do this for all 3 palettes? It's not an FPGA, it's a CPLD.leonk wrote:Heck, is it even possible to dump and FPGA.. I strongly doubt it.
RegalSin wrote:America also needs less Pale and Char Coal looking people and more Tan skinned people since tthis will eliminate the diffrence between dark and light.
That was a big "if" and it looks as though they are not.Vigormortis wrote:If results are identical, what criteria do you suppose are left for determining the superior solution?
Even though my USB blaster should be coming in tomorrow morning, given that 1.1 and 1.2 are both giving some issues, I just said fuck it and installed the 12ns SRAM replacement I ordered when this first came out. I don't have the time to test it extensively right now, but I did boot up a bunch of games and they all appeared to be working perfectly. So for right now that definitely appears to be the superior fix. Thanks for confirming that it works beforehand, Vigormortis.Vigormortis wrote:I went ahead and installed the 12ns SRAM that was mistakenly identified as the SRAM from the original batch. I did this on both of my nesrgb boards. The one in my front loader works perfectly. The nesrgb in my Famicom has some graphical glitches but I doubt that the 12ns SRAM is the problem. Installing the nesrgb in an original Famicom is a lot messier than on any other Nintendo consoles.markfrizb wrote:Can anyone confirm that the original SRAM and/or the SRAM Tim later said was the *correct one -- that both work or just one or ????
I'm thinking I'm just going to replace my SRAM but I bought the first ones that came up in discussion (the 12ns speed I think). And I think the 15ns one is what should have been used/bought. Do I need to buy the different ones or use what I have now?
You can read out the flash memory of this device in the same way you would from a microcontroller. A traditional FPGA contains no data and requires another device to program it every time it starts up.leonk wrote:Heck, is it even possible to dump and FPGA.. I strongly doubt it.
Technically, it is in fact a FPGA with a built in flash memory pretending to be an over size CPLD. The data sheet calls it a CPLD. I prefer to avoid the issue entirely.ApolloBoy wrote:It's not an FPGA, it's a CPLD.
In 1.2 i had a strange line on the left side of the mega man 4 intro scene with the city exploding, that is gone in version 1.3.viletim wrote:Version 1.3 POF download
I spent a few hours poking it with a CRO probe this evening and I'm pretty sure I've found the source of the trouble. Please test this version.
Voultar wrote:
I hope Tim responds to the bombardment of E-mails I've sent him concerning this faulty NESRGB.. I would really like to get it exchanged already..
ninn wrote:Voultar wrote:
I hope Tim responds to the bombardment of E-mails I've sent him concerning this faulty NESRGB.. I would really like to get it exchanged already..
Customer service must be a horror on those DIY Kits - people will blame the creator for every fault, even if they broke it their own.
I would imagine. It's a good thing that I didn't break it on my own, and that I'm not casting blame on Tim. I can't hold him accountable for defects that occur on the assembly line, that isn't his fault. Tim doesn't solder and/or assemble these boards himself, ya know. Vigormortis wrote:Well, the black and white PPU composite when a palette is selected sounds pretty normal. I think the NESRGB needs this black and white PPU output to calculate some of the information needed to produce the RGB image. Of course, those screenshots of the NESRGB's video output are definitely not normalVoultar wrote:Hey, it could always be worse..
Goonies II never looked so good. There is a definite problem with my board. PPU composite only works if I don't short any of the pads for palette selection, If I do short those pads, the image is black and white.
Encoded composite, S-Video, and RGB are all a bust. (See above pic)
I don't think there's any problem with your board. PPU composite only works in passthrough mode (i.e. no palette is selected). If a palette is selected, then the NESRGB is basically using the PPU as a 'slave' IC to perform some operations, and thus you won't get correct operation out of the composite connections.Voultar wrote:Vigormortis wrote:Well, the black and white PPU composite when a palette is selected sounds pretty normal. I think the NESRGB needs this black and white PPU output to calculate some of the information needed to produce the RGB image. Of course, those screenshots of the NESRGB's video output are definitely not normalVoultar wrote:Hey, it could always be worse..
Goonies II never looked so good. There is a definite problem with my board. PPU composite only works if I don't short any of the pads for palette selection, If I do short those pads, the image is black and white.
Encoded composite, S-Video, and RGB are all a bust. (See above pic)
Aye, it's the same effect for all palettes. And I believe you're correct. When a palette isn't selected, the NESRGB board is acting only as a pass-thru device, and composite coming from the PPU is perfectly fine while working in pass-thru state. That tells me that the connections between the NES Mainboard, PPU, and NESRGB board are sound. There's an issue somewhere on the board.
viletim, on nesdev forums wrote: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.
darcagn wrote: I don't think there's any problem with your board. PPU composite only works in passthrough mode (i.e. no palette is selected). If a palette is selected, then the NESRGB is basically using the PPU as a 'slave' IC to perform some operations, and thus you won't get correct operation out of the composite connections.
When you attempt to use composite out, you are seeing the result of the NESRGB board using the PPU as a slave for this operation:viletim, on nesdev forums wrote: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.
That is good newsApolloBoy wrote:Just tested the 1.3 software and it works great! So far I have yet to encounter any kind of glitch.
Oh, that is great news. I will have to flash 1.3 at some point today.ApolloBoy wrote:Just tested the 1.3 software and it works great! So far I have yet to encounter any kind of glitch.
One thing interesting about the jumper settings is that open/shorted is not consistent between NTSC and PAL.Voultar wrote:Check out my original post.
The problem that I'm experiencing is with the encoded outputs (S-video, Composite). I have already mentioned that the Composite PPU output is fine while the NESRGB is operating as a pass-thru device. That is an indication that the problem (whatever it might be) is something in the NESRGB circuitry, and not a communication issue between the NES Mainboard, NESRGB, and PPU.
So it isn't a matter of "short everything for PAL, and open everything for NTSC." The luma trap frequency is different. So it may have been easy to glance at just one of these lines and assume that each jumper should be the same based on encoding desired, but that isn't true.(From the pinout sheet) wrote: 3: Jumper J7 selects PPU type. Open for NTSC PPU. Short for PAL PPU.
4: Jumper J4 selects encoded video format. Open for NTSC. Short for PAL. This should agree with J7.
5. Jumper J5 selects luma trap frequency for encoded composite video. Open for PAL, short for NTSC.
It's no problem, I appreciate the insight. Sometimes it's the simplest thing that causes the most catastrophic problems.CkRtech wrote:Oh, that is great news. I will have to flash 1.3 at some point today.ApolloBoy wrote:Just tested the 1.3 software and it works great! So far I have yet to encounter any kind of glitch.
One thing interesting about the jumper settings is that open/shorted is not consistent between NTSC and PAL.Voultar wrote:Check out my original post.
The problem that I'm experiencing is with the encoded outputs (S-video, Composite). I have already mentioned that the Composite PPU output is fine while the NESRGB is operating as a pass-thru device. That is an indication that the problem (whatever it might be) is something in the NESRGB circuitry, and not a communication issue between the NES Mainboard, NESRGB, and PPU.
So it isn't a matter of "short everything for PAL, and open everything for NTSC." The luma trap frequency is different. So it may have been easy to glance at just one of these lines and assume that each jumper should be the same based on encoding desired, but that isn't true.(From the pinout sheet) wrote: 3: Jumper J7 selects PPU type. Open for NTSC PPU. Short for PAL PPU.
4: Jumper J4 selects encoded video format. Open for NTSC. Short for PAL. This should agree with J7.
5. Jumper J5 selects luma trap frequency for encoded composite video. Open for PAL, short for NTSC.
I guess this is my long way of asking if these three requirements agree with your board. (Please forgive me if you already mentioned this before)
