nesdev.parodius.com

[jwdonal]

Are there any vendors that you can buy a 21.47727MHz oscillator from? I can find some vendors that have 21.47727MHz *crystals*...but no oscillators. And I don't want to have to make an RC-network in order to get an oscillator unless I absolutely have to.



Anyone know where I can buy one (or a few)?

Thanks!

Jonathon

[kyuusaku]

This is why FPGA have DLL!

A) Most boards come with a 50 MHz: 50 * 3 / 7 = 21.429 MHz (<0.3% slow)
B) Use a very common 14.318 MHz: 14.318 * 3 / 2 = 21.477 MHz
C) Use a somewhat common 3.579 MHz: 3.579 * 6 = 21.477 MHz

[jwdonal]

It's not that simple. In Xilinx devices the DCMs (what you're calling a DLL) and PLLs are restricted to certain minimum/maximum input/output clock frequencies. You are also restricted to certain M / N values based on those frequencies. In my case with my particular boards it is not possible to achieve a really good approximation of the 21.47727MHz rate of the original NES.

Also, using a device primitive to generate the clock is not what I really want since it makes my code architecture/device specific. I want the appropriate oscillator frequency coming right into the FPGA and then just some generic clock divider logic that can be used on any device. This will keep my code the most portable.

So with that said, anyone know where I can buy one still? I was thinking if all else failed I could buy an NES online and steal the oscillator from it. But I don't know if the NES used an all in one oscillator or if it used a crystal with additional on-board analog components to create the oscillator. Does anyone know which it is?

Pz!

Jonathon

[kyuusaku]

It's not that big of an issue, which devices by Xilinx, Altera and Lattice CAN'T handle simple integer multiplication? I really don't see what it has to do with code portability, for each board you target, you still need to specify hardware constraints; think of clock generation as another constraint. As you can see 21.477 MHz oscillators are just not sustainable, so this is really the best option. I use 14.318 MHz oscillators since after being used in the IBM PC, they aren't going away.

The NES has a discrete crystal oscillator, so that won't be much use. 14.318 MHz osc I'm tellin' ya!

[jwdonal]

[kyuusaku]

Which chip and osc. frequency are you currently using?

[jwdonal]

Virtex-5 LXT

2 onboard oscillators available: 100MHz and 25MHz

There is also 1 open oscillator socket (which is what I wanted to put the 21.47727MHz oscillator in).

[kyuusaku]

That minimum seems crazy, most of the time it's a couple MHz. Also, if the minimum frequency is 32 MHz, you can't DCM the 25 MHz osc? At the very least you could use use your 100 MHz: 100 / 14 * 3 = 21.43 MHz. It's not exact, but SIGNIFICANTLY more accurate than PC emulators and not perceivable anyway.

[jwdonal]

Ok, so I went back and looked in the datasheet for the V5 to be sure I had the correct min input freq. The min I specified is correct. I also ran the architecture clocking wizard to see if it would let me specify anything less than 32 - it would not.

!HOWEVER! In looking at the extremely fine print in the datasheet I found that there is a "special" mode that you can put the DCM into which will allow for a minimum input clock freq of 1MHz! I have never used this mode before so I never knew about it until now. I'm used to designing for 100MHz+ systems at my job so I never had to use this mode. A concern I have however is that this mode does not allow you to utilize the clock feedback loop of the DCM which is used to help with real-time adjustments to clock skew/phase shifts. I'm going to give it a shot anyway and see what happens. First, I will try it using the 25MHz osc, then if that works fine I guess I will be on my way to buying a 14.318MHz osc! This will be really cool if this works!

I'm very glad we had this discussion! It seems I still learn something new almost every day about these Xilinx devices and I've been using them for over 8 years!

[jwdonal]

So it turns out kyuusaku is The Man! I swapped out my 100M osc for a 25M osc and my NES clocking is now much more accurate!!

With 100M the best I could get was:
DCM Output = 44MHz
2A03 = 44M / 24 = 1.83 MHz (~2.23% faster than original NES)
2C02 = 44M / 8 = 5.50 MHz (~2.23% faster than original NES)

With 25M I've got:
DCM Output = 21.4286 MHz
2A03 = 21.4286M / 12 = 1.786 MHz (~0.227% slower)
2C02 = 21.4286M / 4 = 5.357 MHz (~0.227% slower)

As you can see the 25M option is MUCH better!! Nice little upgrade!

I am still sacrificing the clock feedback correction loop but it doesn't seem to matter from what I can tell so far - this is certainly only because I am clocking at such low rates though. I will need to check the timing analyzer output but I've been playing my NES for a while now with a bunch of different games at this new frequency and it seems fine. If there were any major timing issues I probably would have seen it by now.

I'm not even sure that I will bother getting the 14.318M osc cause the 25M option is already so close. If I purchased a 14.318M osc I could get the following:

DCM Output = 21.477 MHz
2A03 = 21.477M / 12 = 1.789 MHz (~0.001% slower)
2C02 = 21.477M / 4 = 5.369 MHz (~0.001% slower)

Anyway, thanks again for the help kyuusaku!

Jonathon

[tepples]

[kyuusaku]

This is true, but the frequency is RGB/YCbCr palette-safe.

[tepples]

[kyuusaku]

I don't see why NTSC simulation couldn't be synthesized in hardware.

[tepples]