GARTHWILSON wrote:
...That's considerably better than cassette quality which got pretty good by the time it was replaced in households by CDs...

I was abit of an audiophile in my earlier years. I remember using the metal (CrO2?) cassettes for compatible cassette players and remember being very pleased with the sound quality when copying from CD and comparing the two...

So, it can be up to the user what to do internally. The user will just have to abide by the pin assignments for the outputs. I just need to be concerned with the necessary external components for those outputs. Looking at a Xilinx datasheet for a delta-sigma DAC core it shows a simple RC filter. It points out to use a 1% resistor. So I'll just need to add a resistor and a capacitor for each channel. This datasheet also recommends LVTTL for IOSTANDARD, and 24ma for DRIVE. Now what values to choose. I see formula's on page 8...

I think what I'll do is use pins, the same pins used in machine tooled sockets, and space them for a 1/4W resistor. Will space the cap's the same way.

The gameduino board uses 4k and 10nF parts. See schematics

1% resistors seem overkill. The worst that can happen with a 5% resistor is that the volume is slightly higher or lower, which can be fixed by having a volume control in the code (which you'll probably want anyway).

Ok. I'll still use the socket pins so the user can achieve whatever cutoff they want. That gameduino's cutoff is around 4KHz if I've calculated it right. Most likely it uses 8 bits or less resolution at low oversampling rate which would demand a cutoff at such a low frequency, even though it's only 6dB down @16KHz.
That Delta-Sigma Core allows values of 2 to 16 bits, which would change the resistor/capacitor values appreciably.
Also, The FMax of the internal global clock tree (BUFGMUX) (according to Table 47 on pg. 49 of DS162) using -3 speed grade of Spartan 6 can go up to 400MHz.
Now what kind of resolution are we talking about?? Maybe a simple filter that is -3dB @30KHz.

There is no way in hell all those IC's, along with the very necessary connectors, would fit on 1 3.8" x 2.5" board, and my earlier comment about "I will sacrifice nothing" still stands... I won't sacrifice anything, but for this PRIMARY board, I can only fit the 2 SDRAM's, separate 2.5V 1A VReg's for each SDRAM, FPGA, FPGA Prom, JTAG & program/reset buttons, POR, Video IC, Audio/Video Out connectors and a PS2 Keyboard connector.

I'm working on a board interconnect system, so multiple 3.8" x 2.5" boards can be stacked in any order and still function.

Other boards: possibly an IDE interface, USB interface for mouse, other USB master/slave IO (i.e. memory sticks etc.), ethernet, stereo 16-bit sound board with extended memory. Most of which should and can be left up to interested parties.

EDIT: Added PS2 connector to primary board.

I tried my Spartan-3 board, with 50MHz delta-sigma, and an RC filter similar to gameduino (3.9k and 10nF). The fairly low roll-off frequency isn't a big problem, because you can compensate that to some degree with a pre-emphasis filter inside the FPGA, which increases the amplitude of the higher frequencies. In practice this means you can get a fairly flat frequency response up to 10 kHz.

Despite the filter, I can still hear some artefacts when I crank up the volume, and play 0.1Hz sine waves. You can hear clicking and beeping as the modulation changes. With a higher cut-off frequency, those artefacts will only get worse. Ideally, you'd need a higher order filter.

For fairly loud mid-range tones, the sound is pretty good. Of course, at 200+ MHz, it will only get better.

Another trick that I could try is to use the tri-state output of the FPGA, which effectively gives you 1.6 bits instead of 1. The only problem is that the logic is a bit trickier. Another possibility, if you still have the pins, is to use 2 pins per channel, by using 2 different resistors, and a capacitor. By picking the right resistor ratio, and using tri-state outputs, that gives you 3 bits of resolution. At that point, the SNR will probably be dominated by Vcc noise.

EDIT: several small updates to sprite engine, and another prototype video.

Arlet wrote:
...Another possibility, if you still have the pins, is to use 2 pins per channel, by using 2 different resistors, and a capacitor. By picking the right resistor ratio, and using tri-state outputs, that gives you 3 bits of resolution. At that point, the SNR will probably be dominated by Vcc noise...

Sounds interesting, not sure how many pins will be free yet...

I need to get a grip on the SDRAM controllers first. This is what I am picturing: 2 very distinct SDRAM controllers for each of the 16Mx16 IC's: 1 geared for random access (I have planned for the maximum current draw of ~285mA, due to the worst type of refresh, by having a 3.3V 1A Voltage Regulator for each memory device), and 1 geared for the video pixel refresh/sprite data. These SDRAM's are rated for 167MHz operation, they are in stock...

Arlet wrote:
...EDIT: several small updates to sprite engine, and another prototype video.

Only thing left is the Y memory pointers for the sprites? Nice work!... Curiosity, how are you calculating the 55fps? The background looks nice, 16 bits RGB? 5-6-5?

EDIT: was incorrect voltage/current for sdram

If you can fit two separate ones, that would be nice. Since everything is 16 bit, you don't have to worry about the upper/lower byte enables. Don't skimp on the decoupling caps with all those high speed wires! I'd recommend 0603 ceramics close to each pin.



The 55 fps is my VGA controller refresh rate that I generate myself, and everything is redrawn at every frame. The CPU uses the vertical blank interval to move the sprites. The TFT panel is RGB-666, but I only use 5 bits per color, plus 1 bit reserved for transparency, so I can fit a pixel in a 16 bit word.

Been wrestling with several things this morning, networked printer, computer problems. But I finally got it sorted out after 'wasting' 3 hours of my time. Was able to print some things and check them over...

There are 39 signal pins on each SDRAM. Assuming a common CLK, a total of 77 pins of the FPGA would have to be utilized.
Banks 0, 2 & 3 each have 26 I/O pins, total = 78 pins.

Bank 1 has 24 I/O pins + 1 leftover pin, gives 25 free I/O.

What if those 25 pins were used for an interface that would present a linear address to the 32M x 16 memory? Thereby making 1 Spartan 6 a memory controller.

Not sure what you mean here. What kind of device is going to be attached to this ? And don't you need those I/Os for your other devices (video/audio/extension port) ?

Maybe 2 independent SDRAMs is a bit too much.

By the way, the CKE pin could be tied to Vcc, and the DQML+DQMH pins could be tied together if you don't care about byte addressing. That saves 2 pins per SDRAM.

2 independent SDRAM's may indeed be too much for this small FPGA. But let's hash this out before we give up...

I was thinking of dedicating 1 Spartan 6 as a memory controller, since the pins are so sparse for our needs.
Another Spartan 6 would contain the cpu and control the video IC and the memory controller.

I see. How about this option: make a board with 1 Spartan-6, including a single SDRAM, plus video/audio/etc + extension connector.

This board can already be used as a stand-alone board, by sharing the single SDRAM between CPU and video. If you like more performance, plug in an add-on board with another Spartan-6 + SDRAM (or SRAM), and a high-speed interconnect. This could even be the same board.

Ok 1 SDRAM it is for the main board...

Check out this Texas Instruments IC. It's got the same composite and S-video outputs, NTSC and PAL as the CS4954. In addition, it has 16-bit digital in. Also, it has overscan compensation, in order for higher resolutions to be displayed on ordinary TV sets.

This IC was made in 1998 and they're still making it for $16.72ea which is a good sign. Looking for app note...

The TI chip deserves a good look, but I would prefer the 8 bits mode anyway, to save pins. The overscan feature isn't really useful in our case. It's just as easy to generate the correct PAL/NTSC resolution in the FPGA, which would probably result in a better picture quality, while requiring a lower bandwidth.

Ah, heh. So you are not in favor of the CS4954 now either? Going the gameduino route?

No, I still want to use the CS4954/TVP6000C, so the FPGA only has to send digital data. But, it's easy for the FPGA to send exactly the right number of data bytes for NTSC/PAL resolution, instead of sending VGA resolution, and have the TVP6000C scale it down.