Video/sprites for the 65org16 Dev. board

[ElEctric_EyE]

So if I have changed this in the sdramif module

Code: Select all

wire sel_sdram = (AB[31:28] == 4'ha);

.
The 16MB worth of SDRAM can be accessed from $A000_0000 to $A0FF_FFFF?

[ElEctric_EyE]

Arlet, I think your video modules would work very well with the idea for using a 48-pin QFP triple 16-bit video DAC in order to interface V1.2 Devboard to a VGA type monitor (minus the CS4954 module), instead of a composite /SVideo output. This setup would provide for a much clearer picture and take advantage of that cheap SDRAM with higher resolutions. This may require a separate CPLD to do the video work, in order to keep the FPGA up to speed with resolutions up to 1280x1024. Typically approaching 75MHz pixel clock rates?
What do you think? or anyone?
I am eager to start V1.2 of the Devboard here in a few months!

[Arlet]

ElEctric_EyE wrote:

So if I have changed this in the sdramif module

Code: Select all

wire sel_sdram = (AB[31:28] == 4'ha);

.
The 16MB worth of SDRAM can be accessed from $A000_0000 to $A0FF_FFFF?

Yes. Oh, and don't forget to attach the RDY signal to the CPU.

[Arlet]

ElEctric_EyE wrote:

Arlet, I think your video modules would work very well with the idea for using a 48-pin QFP triple 16-bit video DAC in order to interface V1.2 Devboard to a VGA type monitor (minus the CS4954 module), instead of a composite /SVideo output.

Are you talking about 3x16 bit color ? It's certainly possible, but I think it's a bit overkill. I don't think any of the consumer type VGA monitors go beyond 3x8 bit internally, so the extra bits would just be discarded.

Have you already looked at DACs and see what's available ?

As to the bandwidth: 1280x1024x75 is about 100 MHz pixel clock. With your current board, that would only let you get 16 bit per pixel, and wouldn't leave any time for the CPU to access the SDRAM, and no time for sprites. Even with wider SDRAM, you'd still have no bandwidth left for CPU/sprite access.

[ElEctric_EyE]

The only line not connected is the wr_ack from the SDRAMIF module...

I'm looking at a 140MHz version of the ADV7125. I plan to have a 6.5ns synchronous RAM onboard too, for experimentation, probably the 2Mx18 version...

I meant a 5-6-5 type 16-bit interface, not triple 16-bit DAC's, sorry. So, the low 3-bits of red, low 2-bits of green, and low 3-bits of blue DAC's won't be used.

I could settle for 800x600 or even 800x480. Must have the sprites!

Not sure if I can get to it tonight, more likely tomorrow night, but I'll try writing to the video portion of the SDRAM next.

[Arlet]

ElEctric_EyE wrote:

I meant a 5-6-5 type 16-bit interface, not triple 16-bit DAC's, sorry. So, the low 3-bits of red, low 2-bits of green, and low 3-bits of blue DAC's won't be used.

If you have enough pins, I would recommend hooking up all the 8 bits per color. That way you still have the option of adding more colors, or use a 8 bit palette, or do gamma correction.

Quote:

I could settle for 800x600 or even 800x480. Must have the sprites!

Ok, the advantage of the FPGA is that you can always change the resolution/color depth/refresh frequency, even dynamically if you want.

[ElEctric_EyE]

I got back to testing the graphics. It appears to be working, the screen is black when writing all zero's. One interesting observation: I enabled hstretch and I get a greyscale pattern from border to border. Some of the pixels appear to be blinking. This was before I wrote to the video SDRAM. After writing all zero's the screen within the green borders has no blinking pixels, except for maybe 4 green pixels on the very top left where it looks like maybe the border timing is creeping in just a tiny bit. I still must fix the 'no border' issue on the bottom.

EDIT: I must also add, after enabling hstretch, my design did not meet timing, but I programmed the FPGA anyway. This may account for what I'm seeing. I'll run it through smartXplorer again...

[ElEctric_EyE]

In the future I won't bother to post results unless the design meets timing. It's no problem for smatXplorer to find a solution that works at 100MHz, but I must run it everytime, even for the slightest change in the design, even a simple value change for the border. Changing 'height' to 100 is better for NTSC.

So, for another, more controlled, test I wrote values $00 to $FF to the first line only ($A000_0000-$A000_00FF), and I see black pixels on the left merging to green pixels on the right.

[Arlet]

The gray scale pattern is probably due to the fact that the hstretch implementation is broken in that version. I have a new version of the cs4954 module, but that no longer works with the bitmap module. Instead of the bitmap module, I'm using the sprite module, but the sprite module is still 8 bit, and needs to be modified for 16 bit access. Also, the sprite sizes aren't yet programmable.

For now, the easiest is probably to set hstretch back to 0, and modify the bitmap module to use a width of 512.

[ElEctric_EyE]

Arlet wrote:

...Also, the sprite sizes aren't yet programmable.

For now, the easiest is probably to set hstretch back to 0, and modify the bitmap module to use a width of 512.

I would imagine for your display generator to have bitmap graphics along with sprites, you would have to have programmable sized sprites. The largest sprite would be the screen resolution itself, with the other smaller sprites moving inside?

I got rid of the hstretch code. Trying to set width (display area) to 255 (actually 512? pixels) makes it too large for the display area. There's no border on the right side. Still experimenting...

[Arlet]

ElEctric_EyE wrote:

I would imagine for your display generator to have bitmap graphics along with sprites, you would have to have programmable sized sprites. The largest sprite would be the screen resolution itself, with the other smaller sprites moving inside?

Correct. Or you could have the background made out of several large sprites, even partially overlapping. Of course, the ultimate limitation is memory bandwidth. The fact that the TV output is fairly low resolution helps a lot. With a high resolution VGA screen, you run out of bandwidth fast.