Yet another RGB modded PAL N64

VREF only "needs" to be connected to one VDD (VCC) point, it's an input on the JTAG adapter to dermine the target's acceptable voltage level. (VREF is optional, since 5V won't harm the CPLD.)

INIT is also optional, AFAIK it just forces registers to be reset to their initial state.

All VDD (VCC) should be wired together to 3.3V, and all should be bypassed with 100 nF and/or 10 nF capacitors.

You need ISE, with a WebPack (free) license.

---

Personally if I were to build this DAC I would use a bigger CPLD. Viletim's logic here: http://members.optusnet.com.au/eviltim/n64rgb/n64rgb.png shifts out RGB subpixels as soon as they are available, leading R, G and B to be slightly offset from eachother. I assume he realizes this and is doing it because of CPLD constraints--there aren't enough registers to allow everything to update synchronously which would yield the best picture.

 

Thank you very much for your help. I'll draw up a schematic of the connection to the programmer so I'm sure I got it all right. As far as I can understand you say that VREF only determines the correct voltage? Which means that I have to supply the 3.3V when programming the chip from elsewhere?

What are your thoughts on the ICs I ordered? Are the just a smaller version of the ones used by the thread starter, or should I order different ones?

 

I installed the 15GB package from Xilinx's webpage and registered for a free WebPACK licence. Now the programmer lights up when I plug it in. So far so good

It installed quite a few programs, but which one do I use with my programmer?

 

iMPACT is what you use for programming. I *think* you can use the JEDEC file Viletim put on his site with it. If iMPACT doesn't take JEDECs (they're a very old generic format) you'll have to reimplement the design in the Project Navigator.

 

Awesome. Using EDIT > Add Device > Add Xilinx Device > rgbdac.jed gives me the following:


That looks pretty promising. I'm guessing I just need to connect to the IC, program and then verify it afterwards and I should be done. Is that correct?

Trying to initialize chain I get the following errors:


I have the Xilinx programmer connected to my PC, but nothing connected to the programmer. So I'm hoping that these error messages are just an indication that no programmable IC is detected.

So the IC has to be powered externally for me to program it? Is that correct? I have an Arcade power supply with 3.3V I could use for that. The setup will then look something like this. Please verify that this is correct:


And I'm still not sure that I have the correct ICs

 

Looks good.

Yes it has to be externally powered since JTAG is typically done in-system; you couldn't expect the programmer to power the entire system the CPLD is in, plus there could be consequences for ignoring the system's power-up specs.

BTW you should really put a 100 nF on *each* VDD pin, not just one for them all (which will do nothing). It should be as close to the pin as possible.

 

So I remove the one near the power supply and add three near each of the VDD pins of the IC and connect the other end of these to the nearest GND?

Just got 1000 560ohm resistors today in the mail, as well as 20 sockets for the ICs. Of course these are too big as well, but I just need to order the right sized ICs next time I do this mod. For now I'll just solder the small chips in place even though it will be time consuming.

EDIT: Are these the right sized chips:
http://www.ebay.co.uk/itm/XILINX-XC...al_Components_Supplies_ET&hash=item3cc2a8925f

 

Those are the same package used in the original website.

However, the QFP would be smaller if you made your own board for it.

 

Aha so the difference between the two types are QFP and PLCC.

http://en.wikipedia.org/wiki/Quad_Flat_Package

Thanks. Now I'm confident that the ones I already have are good enough. In the future I'll probably use the PLCC ones.

 

Can these chips be reprogrammed?

I can see that it's the same type as the old Dreamcast modchips, and I may have a friend who can sell me some of those.

 

Got the Dreamcast chips from a friend of mine today. Looks like I managed to erase the chips and reprogram them with the code Of course I can't be certain it works since I don't have the mod built for the consoles yet, but all three chips I programmed ended up with a checksum of 7f29, so at least they are all the same. Thank you very much for all your help.

http://s40.beta.photobucket.com/use...0008C25BB3F0B_zps90373b63.jpg.html?sort=3&o=0

 

I did the mod today and it works
Unfortunately it's not as sharp as I had hoped and there is some noticeable flickering in the image. It's like a wavelike pattern moving up the screen at high speed.

Can I do anything to improve these issues? The RGB cable I'm using is an original Super Famicom, if I remember correctly it has 75ohm resistors and 220uF caps on the RGB lines.
I have to admit that I only used one 100nF cap just like the schematics said. Would it help the flickering if I used three instead, one next to each VDD pin on the socket?





EDIT: Using the XRGB-mini: Framemeister to display this on my Plasma screen. This usually produces a much sharper image from other consoles.

 

Not quite as sharp as my PVM displays the "standard" mod for the earlier N64s for sure.

 

I have never seen the old mod in person. But from what I've heard it should be pretty sharp. Of course there are too many N64 games with horrible softness filters, but I think the letters in Sin and Punishment should be pretty sharp. S-video might actually look a bit sharper than this RGB mod, but I didn't compare them directly.

 

- Your PAL RGB cable can't be used... It's incompatible with everything but the PAL SNES! To get it to work you need to remove the shunt (to ground) 75 ohm resistors because they are dragging the signal down. That's probably the reason for the flickering. With this DAC there isn't a DC offset so you don't need the series 220 uF capacitors and the signal will be a bit cleaner without them.

- Like I said earlier the CPLD logic itself doesn't update pixels synchronously, it will never be truly sharp for this reason alone.

- The output impedance of the R2R DACs are 280 ohms, this more or less correctly divides with the 75 ohm in the display to 0.7 V, but it ignores source termination so there will be some signal reflection. Probably marginal but it's still a possibility.

- R2R DACs in general, and especially your construction on perfboard will have extremely poor noise, ground quality and parasitic figures--all of which blur and distort the signal. I recently built a similar DAC on perfboard and analyzed it and there's some *really* bad signal ringing.

- Yes decoupling every VDD is the correct thing to do.. You should get them closer than in your picture to be more effective, wiring directly to the VDD pin is a good idea. 10 nF is probably technically more effective than 100 nF for such a fast part, but honestly it's not your problem here; better decoupling probably won't improve the picture sharpness, but it will improve the signal noise and improve the CPLD's logical reliability.

 

So I should just get a RGB cable with no internal components at all. Just straight through RGB and sync?
Don't want to resolder my SFC cable since I use it for my SNES, but I needed to order another one anyway.

But considering my limited resources, is there anything I could do to make the construction on the board work better? It's seated between the aluminium heatsink which is connected to ground, that shouldn't hurt, right?

I'm installing RGB DACs in two more N64s, so I can try using three 100nF caps on the next one and see if that makes a difference I don't think I have any 10nFs though :/

 

Sounds like that is what Calpis is suggesting. The SCART cable I use has 220uF capacitors in it and 75ohm resistors wired on each of the RGB lines inside my N64 but I'm not using the replacement DAC.

Could be worse places to put it like next to a noisy transformer. I would imagine the only way to improve over perfboard is a properly designed and built PCB.

 

Hehe I thought that would be the solution. That's a little out of my league for now

No soldering time today, but perhaps tomorrow I can see if I can remove that flickering using the suggestions posted here

 

Yup, that's the only kind of RGB cable that should exist. The PAL RGB cable is specifically constructed to be incompatible with other equipment. It should never have existed.

You could do point-to-point wiring like Viletim in his pictures, but that's difficult and takes up lots of space. Basically no matter what R2R DACs are going to be problematic, the only benefit to them is that they're quite accurate. You could try making a binary-weighted DAC, which are fast, but for 7 bits it will be difficult with the standard resistor values. The only alternative is to buy a DAC chip...

Are you using an amplifier or pulling RGB right off the DAC chip? Either way I don't think it's a good cable to use, but with an amplifier it wastes a lot of current.

 

But it's not PAL. It's the original Japanese Super Famicom RGB cable. I just rewired the RGB21 pinout to our SCART standard.