NESRGB board available now

[keropi]

don't give up opt2not , just try to rework it after you have cooled off

I have another Q, is the C-SYNC (TTL) output from the NESRGB ready to be used ? I prefer to use c-sync instead of composite for sync, it leads to better results on lcd tvs...

and what's the deal with NESRGB's composite out? is it better than the stock famicomAV composite?
Sorry if these questions have been asked before, the thread is so big now that I didn't find any answers on this

[ApolloBoy]

I have another Q, is the C-SYNC (TTL) output from the NESRGB ready to be used ? I prefer to use c-sync instead of composite for sync, it leads to better results on lcd tvs...

I'm using composite sync for my Twin Fami and it works just fine.

and what's the deal with NESRGB's composite out? is it better than the stock famicomAV composite?

The encoded composite video (marked by the "V" solder pad) is a little better than the original composite output, you don't get any jailbars and of course whatever color palette you have selected also works through composite. I haven't tried the "PPUV" output since you have to switch the NESRGB off.

[eightbitminiboss]

I'm still on Luma for sync as I went through the other sync options while troubleshooting my issue until vigormortis helped me out with the +5v thing. Seems fine with it, but again, this is pre-flashing.

[keropi]

Ofcourse composite works fine as sync but c-sync is even better. And if you are in PAL-land where scart is the standard then c-sync is a better option.

btw I did not get any jailbars with the original famicom-av composite...

[Zets13]

I don't even know what to do now.

Did you double check to make sure all of the jumpers (the J's) on the NESRGB are properly left open or closed according to the signal output you want and whether or not you are powering it with an external regulator? Did you make sure to have a pallette selected? Those are some easy things to overlook.

[opt2not]

I don't even know what to do now.

Did you double check to make sure all of the jumpers (the J's) on the NESRGB are properly left open or closed according to the signal output you want and whether or not you are powering it with an external regulator? Did you make sure to have a pallette selected? Those are some easy things to overlook.

Yeah, I made sure the jumpers were set properly, and the pallette was selected. I was powering it with the external regulator too. I checked the voltage on the NESRGB and I was getting 5v there, so I assumed that it was powered correctly. All of that is moot now that I damaged the NESRGB pads. I could try jumping the connections to the PPU, but I can't even verify if the PPU is working nor can I extract it.

I'm going to sleep on it and think about what next to do tomorrow.

[pudrik]

The grey background bug technical report.

The bug has been there since the beginning. Of the first batch (100 units) I received no reports of problems that could be attributed to this. On the second batch many people complained that the background colour (at h'3f00') was always grey in many games.

I confirmed for myself that the bug only affected the background colour and only some (most) games. I suspected that the problem may be related to the RAM chip as I had substituted the part used in the original production for one which was faster and of a different brand. Swapping the RAM chip between a boards from the first and second batch showed that the bug moved with the RAM chip.

I decided to modify the logic in the PLD to use the a copy of the background colour byte stored in the PLD instead of the RAM chip. I did this and it appeared to solve the problem. This became version 1.1 POF. This was a quick solution that avoided the need to spend time on solving the root cause when I really needed time to deal with customers.

While this did solve the bug, it was reported by some ( a bit later) that when using version 1.1 the background colour can appear misaligned to the rest of the picture by a fraction of a pixel. I didn't think of this at time I made the modifications but it does make sense. During image rendering when the data is stored in two different places (RAM and PLD) if one of these is faster than the other by a significant amount it may be visible in the output video. From testing five boards from my stock I can only see a visible background shift on one of them. However, I don't have game Mega Man II which is what some were complaining about.

To get to the bottom of the real problem I started looking at the data on the bus. I noticed that games which suffered from the bug were writing to the palette registers on every frame, while those that did not were only writing the data once on the scene change. Here's a capture of the data from an affected game. It writes the whole 32 bytes to the palette every vertical blanking interval. Here's a trace from the RAM chip's /WE line during the palette write:


Zooming in, I noticed there was a short glitch some time after the last write of the block. Here's the event from the CRO. 1/yellow is the RAM's /WE, R/white is the PPU's /CE, and 2/cyan is A0. I would show A1 and A2 also, but this is only a dual channel CRO.


What's happening here? The RAM's /WE line may only go low when writing to the PPU data register and then only if the address register hold the location in range 3F00-3F1F. In the above picture, you see the last two writes to the data register, destined for palette area 3F1E and 3F1F. A0 is visible and is high, while A1 and A2 are also high (though not shown) so this is definitely to the data register.

A little while later a glitch is visible on the /WE line. The data on the bus is h'10' at this point (not shown) -- looking up the colour I find it is indeed grey. If you look at the A0 trace you will see it is low at the time of the glitch. This is not data meant for the data register (address 7), but instead it's meant for the address register (address 6).

What is happening is all events in the PLD are edge driven. Addressed latched on /CE fall, data on /CE rise. The address (I mean A0, A1, A2) is latched for every read/write to the PPU. Once the palette block is written it is still latched at the data register (address 7) then the game writes to the address register.... What is the logic for /WE then?

IF the latched address is in the palette area
AND the write is to the data register
THEN /WE = R/W or /CE

I added another condition that for /WE to be asserted the write must be to the data register according to the current values of A0, A1, A2 as well as the latched version (as this is a mix of edge and level logic). This eliminates the glitch and the problem of the corruption of the background colour byte. This is version 1.3 POF.

Here is a close up of the glitch while running version 1.0 POF.

Im not sure but this timing issue seems to be a little bit off on the Sharp Twin Famicom as the same palettes seem to be screwed up on alot of games and the problem is always the same sprites.

Ive Isolated the issue down to not being a PPU / CPU / VRAM related chip error as the same "chips" work on a famicom with the same NESRGB but not on the Sharp Twin Famicom
i also noticed that the Sharp Twin Famicom doesnt have a "fine tune" for the 21Mhz clock but removing the fine tune on the famicom didnt reproduce the same errors.

Dont know if this is something to concider but some NES / Famicom seem to have 15 ns and other 10 ns Sram chips, my famicom has mixed but works like it should while the Sharp have 15 ns

Anyway the problem reproduces itself in the same manor on all versions 1.0, 1.1, 1.2 and 1.3 on the Sharp so i gotta go and say that the Gate file still needs some fine tuning

And while we are talking about Logic how about adding a Decade counter on the 1 (or 2-3 for that matter) so you can remove the switch and have a push switch that cycles palette selection internaly instead?

[ninn]

You can use whatever switch you want to, - no need to modify the NESRGB Board for that...

[mufunyo]

Ofcourse composite works fine as sync but c-sync is even better. And if you are in PAL-land where scart is the standard then c-sync is a better option.

btw I did not get any jailbars with the original famicom-av composite...

Mind that CSYNC is 3-5Vpp while CVID is 1Vpp. Connecting CSYNC to SCART requires a 1K resistor; if you wire CSYNC directly, you're technically transmitting a 15KHz VGA signal, rather than SCART. Of course if you're only connecting to something like an XRGB, you can connect it like that directly, eliminating the need for a sync stripper (which extracts sync from CVID and boosts the voltage to TTL level).

[Voultar]

Im not sure but this timing issue seems to be a little bit off on the Sharp Twin Famicom as the same palettes seem to be screwed up on alot of games and the problem is always the same sprites.

Ive Isolated the issue down to not being a PPU / CPU / VRAM related chip error as the same "chips" work on a famicom with the same NESRGB but not on the Sharp Twin Famicom
i also noticed that the Sharp Twin Famicom doesnt have a "fine tune" for the 21Mhz clock but removing the fine tune on the famicom didnt reproduce the same errors.

Dont know if this is something to concider but some NES / Famicom seem to have 15 ns and other 10 ns Sram chips, my famicom has mixed but works like it should while the Sharp have 15 ns

Anyway the problem reproduces itself in the same manor on all versions 1.0, 1.1, 1.2 and 1.3 on the Sharp so i gotta go and say that the Gate file still needs some fine tuning

And while we are talking about Logic how about adding a Decade counter on the 1 (or 2-3 for that matter) so you can remove the switch and have a push switch that cycles palette selection internaly instead?

Can anyone else confirm the Twin Famicom abnormalities reported by pudrik? I believe there have been only a few Twin Famicom installs so far, and I intend to be doing this, shortly.

[McCracAttack]

I'm so dejected that I don't think I want to even try attempting to install the other one into my front-loader. Damn me for thinking I have the soldering skills to attempt this.

Sorry to hear you've had such a bad time with it. If you can stand to I'd recommend just shelving it for a couple of days and then come back to it with a clear head. I had a PC Engine RGB project that went sideways on me in much the same fashion and I'm having much better luck just working on it in small bursts here and there as I have the patience for it.

Also don't be too hard on yourself. These are 20+ year old electronics that we're re-jiggering do things they were never designed to do. It's no wonder they break sometimes.

[keropi]

Ofcourse composite works fine as sync but c-sync is even better. And if you are in PAL-land where scart is the standard then c-sync is a better option.

btw I did not get any jailbars with the original famicom-av composite...

Mind that CSYNC is 3-5Vpp while CVID is 1Vpp. Connecting CSYNC to SCART requires a 1K resistor; if you wire CSYNC directly, you're technically transmitting a 15KHz VGA signal, rather than SCART. Of course if you're only connecting to something like an XRGB, you can connect it like that directly, eliminating the need for a sync stripper (which extracts sync from CVID and boosts the voltage to TTL level).

thanks, didn't knew about the 1k resistor... will add it.
I don't have an x-rgb anymore, just crt and lcd tvs that have a scart-rgb input

edit: just found Tim's notes on the rgb cable: http://etim.net.au/nesrgb/rgb_connector.htm
it appears c-sync is ready to be used, without any extra components, am I correct?

[nesfreak]

Im not sure but this timing issue seems to be a little bit off on the Sharp Twin Famicom as the same palettes seem to be screwed up on alot of games and the problem is always the same sprites.

Ive Isolated the issue down to not being a PPU / CPU / VRAM related chip error as the same "chips" work on a famicom with the same NESRGB but not on the Sharp Twin Famicom
i also noticed that the Sharp Twin Famicom doesnt have a "fine tune" for the 21Mhz clock but removing the fine tune on the famicom didnt reproduce the same errors.

Dont know if this is something to concider but some NES / Famicom seem to have 15 ns and other 10 ns Sram chips, my famicom has mixed but works like it should while the Sharp have 15 ns

Anyway the problem reproduces itself in the same manor on all versions 1.0, 1.1, 1.2 and 1.3 on the Sharp so i gotta go and say that the Gate file still needs some fine tuning

And while we are talking about Logic how about adding a Decade counter on the 1 (or 2-3 for that matter) so you can remove the switch and have a push switch that cycles palette selection internaly instead?

Can anyone else confirm the Twin Famicom abnormalities reported by pudrik? I believe there have been only a few Twin Famicom installs so far, and I intend to be doing this, shortly.

Don't know if it matters, but pudrik has a Twin Famicom Turbo.

[mufunyo]

just found Tim's notes on the rgb cable: http://etim.net.au/nesrgb/rgb_connector.htm
it appears c-sync is ready to be used, without any extra components, am I correct?

Tim's notes don't appear to mention signal level. He says "TTL" (which in voltage terms is 3-5V) but that is too high for SCART. It probably won't damage anything, but the standard for SCART sync is -0.3v (composite video sits between 0 and +0.7v, and sync sits between 0 and -0.3v, making the total peak-to-peak voltage 1v). That is what the resistor is normally for. I don't have a NESRGB yet (I'm holding off for the newer revision with Famicom mixing circuit and hopefully custom palette support), so I have no idea what it outputs on the CSYNC pin. If it is 0.3v, then you can wire it directly. If it is 3.3v or 5v, you should lower it if you want to be SCART-compliant. But it will probably work without a resistor, either way.

[ApolloBoy]

Im not sure but this timing issue seems to be a little bit off on the Sharp Twin Famicom as the same palettes seem to be screwed up on alot of games and the problem is always the same sprites.

Ive Isolated the issue down to not being a PPU / CPU / VRAM related chip error as the same "chips" work on a famicom with the same NESRGB but not on the Sharp Twin Famicom
i also noticed that the Sharp Twin Famicom doesnt have a "fine tune" for the 21Mhz clock but removing the fine tune on the famicom didnt reproduce the same errors.

Dont know if this is something to concider but some NES / Famicom seem to have 15 ns and other 10 ns Sram chips, my famicom has mixed but works like it should while the Sharp have 15 ns

Anyway the problem reproduces itself in the same manor on all versions 1.0, 1.1, 1.2 and 1.3 on the Sharp so i gotta go and say that the Gate file still needs some fine tuning

And while we are talking about Logic how about adding a Decade counter on the 1 (or 2-3 for that matter) so you can remove the switch and have a push switch that cycles palette selection internaly instead?

Can anyone else confirm the Twin Famicom abnormalities reported by pudrik? I believe there have been only a few Twin Famicom installs so far, and I intend to be doing this, shortly.

I have no idea what he's talking about.

[Voultar]

Don't know if it matters, but pudrik has a Twin Famicom Turbo.

* Ahh, I didn't realize he had the AN-505 model. I'm curious to know for both AN-500 and AN-505 owner's who've installed the kit.

[ApolloBoy]

I have an AN-500R, no problems here.

[eightbitminiboss]

I have an AN-505, but I can't chime in because I'm waiting for USB blaster to be delivered. Dude mentioned sprites, but the games I've tested with the gray background, the sprites still look correct to me, if that is what he's talking about.

[Voultar]

I have an AN-505, but I can't chime in because I'm waiting for USB blaster to be delivered. Dude mentioned sprites, but the games I've tested with the gray background, the sprites still look correct to me, if that is what he's talking about.

My next purchase is going to be an AN-505.

I believe that the issue is isolated only to pudrik. Perhaps he can clarify by citing games he's having issues with, as well as a few screenshots.

[nesfreak]

I have an AN-505, but I can't chime in because I'm waiting for USB blaster to be delivered. Dude mentioned sprites, but the games I've tested with the gray background, the sprites still look correct to me, if that is what he's talking about.

My next purchase is going to be an AN-505.

I believe that the issue is isolated only to pudrik. Perhaps he can clarify by citing games he's having issues with, as well as a few screenshots.

We can't assume it is isolated only to pudrik since we have yet seen anyone else that is finished with his Twin Turbo, or am I wrong?

Also i think it's named AN-505-BK ?

[eightbitminiboss]

I have an AN-505, but I can't chime in because I'm waiting for USB blaster to be delivered. Dude mentioned sprites, but the games I've tested with the gray background, the sprites still look correct to me, if that is what he's talking about.

My next purchase is going to be an AN-505.

I believe that the issue is isolated only to pudrik. Perhaps he can clarify by citing games he's having issues with, as well as a few screenshots.

We can't assume it is isolated only to pudrik since we have yet seen anyone else that is finished with his Twin Turbo, or am I wrong?

Also i think it's named AN-505-BK ?

Last 2 letters are for colors.

AN-505-BK for Black which I have.

AN-505-RD for Red which shows up here and there.

[nesfreak]

Ah, didn't know that, makes sense tho =)

Hope you have better luck with yours eightbitminiboss, keep us posted.

[Jeppen]

I'm so dejected that I don't think I want to even try attempting to install the other one into my front-loader. Damn me for thinking I have the soldering skills to attempt this.

I don't even know what to do now.

My experience was that it was MUCH harder than I thought, of course due to lack of a proper desoldering technique.

Removing the PPU is the worst part, with no doubt.. EVER.

My feeling is that if you have a multimeter and know how to check the continuity, then you can definitely do this too. Everything can be repaired with an extra wire here and there, it won't look beautiful, but it will work.

Don't toss the towel until you placed a few pounds of C4 and detonated the NESRGB board.
If you already did that you might want to think about that towel.


I would definitely try to make sure that PPU is still ok, so my ***amateur advice*** (disclaimer) is to keep working on removing that to test it back in it's original place and in some what without soldering it down since you'll probably want to remove it afterwards again right

Though, I don't understand why it would be stuck in the NESRGB board?

[keropi]

just found Tim's notes on the rgb cable: http://etim.net.au/nesrgb/rgb_connector.htm
it appears c-sync is ready to be used, without any extra components, am I correct?

Tim's notes don't appear to mention signal level. He says "TTL" (which in voltage terms is 3-5V) but that is too high for SCART. It probably won't damage anything, but the standard for SCART sync is -0.3v (composite video sits between 0 and +0.7v, and sync sits between 0 and -0.3v, making the total peak-to-peak voltage 1v). That is what the resistor is normally for. I don't have a NESRGB yet (I'm holding off for the newer revision with Famicom mixing circuit and hopefully custom palette support), so I have no idea what it outputs on the CSYNC pin. If it is 0.3v, then you can wire it directly. If it is 3.3v or 5v, you should lower it if you want to be SCART-compliant. But it will probably work without a resistor, either way.

thanks again, I'll measure it when installed and then use the 1K resistor or not

[Zets13]

Yeah, I made sure the jumpers were set properly, and the pallette was selected. I was powering it with the external regulator too. I checked the voltage on the NESRGB and I was getting 5v there, so I assumed that it was powered correctly. All of that is moot now that I damaged the NESRGB pads. I could try jumping the connections to the PPU, but I can't even verify if the PPU is working nor can I extract it.

I'm going to sleep on it and think about what next to do tomorrow.

Well damn, hopefully you can get it working.

FWIW, to possibly make for easier PPU testing once you are able to get it out of the NESRGB, I put a socket on my AV Famicom board in the PPU spot (DIP socket), in addition to SIP socket from the adapter board into the NESRGB, and yet another DIP socket for the PPU on the NESRGB (so, I used one more socket than what was included with the NESRGB). I do not know how similar the toploader's construction is to the AV Famicom, but I was able to reassemble my AV Famicom and have the NESRGB working just fine despite all those sockets. It might save some trouble of having to do too much desoldering while trying to figure out what's going on with yours...

[mvsfan]

I still havent updated my 2 nesrgb boards. Im just going to wait for the patch that has worked out the bugs.

[thebert]

Anyone have any additional tips for desoldering those 4 pins of the ppu? I checked and triple checked that every other pin is completely free. I just cant seem to heat them all up at the same time to make it come loose. It gets hot in that section and it makes me nervous that i will burn out the ppu, if I try too long at one time. Any tips or success stories would be greatly appreciated!

[eightbitminiboss]

Anyone have any additional tips for desoldering those 4 pins of the ppu? I checked and triple checked that every other pin is completely free. I just cant seem to heat them all up at the same time to make it come loose. It gets hot in that section and it makes me nervous that i will burn out the ppu, if I try too long at one time. Any tips or success stories would be greatly appreciated!

Add more solder to the trouble pins. It'll heat up the older solder faster

[opt2not]

Thanks guys, I appreciate the pep-talk but I think I'm over my head with this, and frustrated enough that I'm going to send it off to a professional to help get it working.

Word of advice to those of you who're like me, with basic knowledge and skill with soldering -- get a proper desoldering iron. Don't rely on those suckers/braid and a soldering iron only... Unless you're super good at using them I guess.

[thebert]

Anyone have any additional tips for desoldering those 4 pins of the ppu? I checked and triple checked that every other pin is completely free. I just cant seem to heat them all up at the same time to make it come loose. It gets hot in that section and it makes me nervous that i will burn out the ppu, if I try too long at one time. Any tips or success stories would be greatly appreciated!

Add more solder to the trouble pins. It'll heat up the older solder faster

Do you mean on the top side too? I did try adding more underneath, but I feel like I'm having trouble keeping all of them hot. Like, I can get 2 or three hot, but then the 4th is already solid again...