I don't have sprite code yet for this board, but you can take a look at the code I made for a VGA TFT panel last year (from the YouTube demo). Here's the verilog.

I'm not sure the code is functional, because I was already trying to add a window layer as well, but it was very buggy. That's why this time, I'm restarting completely fresh on the window layer, and was going to add the sprites later. You can at least take a look. The sprite code was inspired by the Gameduino source. Be warned that the code is quite complex.

For your dev board, I have the following sources:
CS4954, sends 27 MHz clock, and pixel data, reads HSYNC/VSYNC signals. It's also responsible for the green border I have in all my pictures. You should probably start here.

SDRAM. SDRAM controller with single common R/W port.

SDRAM I/F. SDRAM interface for R/W CPU channel, and read-only video channel. Video has highest priority.

Graphics. Generates bitmap from SDRAM. Nice and small. Interfaces to CS4594 and SDRAM IF modules.

Code still needs extra comments and cleanups, so if you have any questions let me know. Edit: did some clean up on the CS4954 code.

Awesome!... I should have my I2C issue solved soon, then I can start experimenting with the CS4954 using your code as a basis. I would like to see if the CS4954 provides VGA compatible signals. The signals are there, but are they compatible? I intend to find out soon after...

On the topic of high video throughput: Even though we don't have the bandwidth for a whole screen buffer to be updated at a high rate, we probably have enough for a certain number of sprites to 'flip' through a memory lookup table. I guess the question will be how big are the sprites? and how many sprites are there?.

The whole video timing issue is, for the cpu to access video RAM without display interference we have to wait for hsync or vsync to be inactive at this point. But now we have 2 separate clocks it looks like from Arlet's Verilog. I am always amazed at how apparently simple video controllers appear to be, written in the Verilog language (CS4954 controller & some other video controllers I've seen). Not saying they're simple to develop, just that they look like a bunch of counters. I'm rambling, forgive, heh...

How big do you want them ? There's plenty of bandwidth available for big and colorful sprites, but the more sprites you want, the less memory bandwidth will be available to the CPU. It's all shared.

To display an image, we need to get a maximum of 720 pixels per scanline. At a 100 MHz clock, in a full burst, this would take 720/100 = 7.2 usec. This needs to be done every hsync period, which is 64 us long. Now, imagine you want to have a sprite that's 64 pixels wide, and partially transparent overlaying the background. In order to display that, we need to retrieve the same 720 background pixels, and also the 64 sprite pixels. To get the 64 sprite pixels from SDRAM, it would take another 64 cycle burst, plus some setup time, let's say 70 cycles total, or 0.7 usec. Now, if you want 10 sprites per scanline, each 64 pixels wide, it would take 10 times as long, so 7 usec for the sprites, and 7.2 usec for the background. That's about 25% of the total memory bandwidth, leaving 75% for the CPU. Of course, that's when every scanline has 10 sprites on it, which isn't very typical.

But maybe you don't want a plain background. Maybe you want a background, plus two transparent layers on top, each independently scrolled, plus 10x64 pixel sprites per scanline. That would take about 30 usec per scanline, or about half the available bandwidth. But even half the bandwidth here is a lot more than any legacy 6502 system ever had.

Correct. In legacy video controllers, the problem was that the video channel needs to retrieve data at exactly the right time to show the pixel on the screen. My first VGA controllers for Spartan-3 worked like that too, but it's a big pain, because everything needs to be timed exactly right, or you'll have wrong pixels, usually at the edge of the screen. For this project, I decided from the start that I would go with a block RAM to store a single scanline. Using the 27 MHz pixel clock, the data is read from the RAM at the right time, and it's up to some other module to make sure the RAM is written before the next scanline. This makes life a lot simpler. This first version uses 1 block RAM, so that means that the data has be written in the blanking time between two scanlines. If that time isn't enough, it's fairly simple to use 2 block RAMs. One displaying the current scanline, and the other one already filling up with the data for the next scanline. That gives you a full 64 usec to generate the data. At the end of the scanline, the two buffer are swapped.

True. In my experience, writing something in Verilog usually takes longer than you think, and when it's finally done, the result is a lot smaller than you think.

In this case, I use the CS4954 in master mode, so it will generate the HSYNC/VSYNC timing for us. This helps to save some logic, but it also makes it easy to switch between PAL and NTSC, because only the CS4954 needs to be reconfigured.

Don't forget you need to send a 27MHz clock to the CS4954 in order for the I2C bus to work. After that, I would recommend you start with the colorbars, as they only require the 27 MHz clock, and some I2C register programming.

In my last testing I was sending 27MHz (measured), and trying to enable the colorbars by send $01 to register $03.

Also, I don't think resetting the CS4954 will clear the devices' I2C address. I don't see any info in the datasheet on this, but I would imagine if one was going to use more than one device, they would have to retain their programming after power down. This is a similar issue I am facing with 3 DS1085 devices onboard. I must successfully reprogram 1 before soldering the next one...

I just changed the I2C ID on my board, and confirmed it was no longer responding to old ID. After a power cycle, the old ID ($00) worked again.

In order to get the color bar output, all I have to do is program the registers from table 4, and set the color bar bit in register 3.

Did you check the ACK bit on the scope ?

Thanks for checking that...
Ok, the DS1085 is different then, I just checked the datasheet. It stores the address in EEPROM and takes 10ms. There is actually a bit that let's one have the option to write to EEPROM so it can save the new value after power-up.

I was not looking at that table 4. Will check it out soon... What I did see was 27 cycles on the SCL line while observing the SDA line. No activity on SDA after the last cycle on SCL.

This is what I see on the scope when I write $01 to register $03.

Top trace is SCL, bottom trace is SDA.

And this is zoomed in on the first byte. Notice that the device pulls down the SDA during the 9th clock cycle to acknowledge the address.

I don't believe I was getting the acknowledge. I'll check this morning!

I just realized that I made a small change to the registers from table 4. I write the value $12 to register $00, instead of $01. With $01 the screen remains black.

Here's a copy of my bit file: main.bit. It should produce colorbars in NTSC format. On my PAL TV, I see them in B/W, which is what I would expect from the signal.

Edit: the bit file produces composite out. I haven't checked the other outputs, but it could be that they aren't working, because there are separate amplifiers and enable bits.

Right. I have enough info thanks to those waveforms you posted. I see the value $03, then the low for a write, then the ACK. I see the 3 ACK's. Now I understand I2C. It finally 'clicked'!

I don't see the ACK's on my board. I separated the short mentioned before. Troubleshooting... My SCL is right at 100kHz. I'm going to reflow the solder on the CS4954.

Did you try the bit file ? It will be a simple test to check for hardware problems. You've tried the other bit file before, the one that generated the screen with the blue border, and black/white bars in varying widths. Since that one worked, I wouldn't expect a hardware problem at this point.

Edit: if you want, you can also send me your bit files, and I'll try them on my board to see if they work.

Ah you're right. It should work.
I've tried getting an ACK from the 1 DS1085 I have on the bus too. Nothing. So I went back to the original 65Org16. Still nothing, and the waveforms look exactly like the DS1085 datasheet!

I will modify my program for the original 65Org16 to send the following values in a loop: $00,$03,$01. Right now it waits for a keypress from the PS2 keyboard to send the data while running C'mon on the TFT. Give me a few minutes.

The 'ifdef' statements! I just realized I had been copying and pasting the cpu.v verilog file from my testbench for simulation right into my project folder. This must be it. Sec...

EDIT: Clarified file as cpu.v

That wasn't it. Sorry. I have a another task to complete that will take a few hours.