ElEctric_EyE wrote:
Neat! Will your sprites have addressable control registers so they can be controlled from assembly? Like an X, Y, and control registers? How about memory pointers? I'll let you do the video if you would like. Sounds like you are deep into it already, and feel free to update on this thread anytime.
Yes, there is a 'sprite descriptor block' stored in a dual ported block RAM. The CPU gets access to one port, and the sprite engine access to the other port. It's a list of 512 words (one for each sprite), 32 bits each, of which 10 are used for the X coordinate, 9 bits for the Y coordinate, some bits for the memory pointer, and the rest for other properties, like palette, orientation and/or size.
Maximum sprites per scanline should be at least enough to cover the whole line if they're not overlapping, so 20 sprites @ 32 pixels each, or 40 sprites @ 16 pixels, but that all depends on the clock speed, memory bandwidth, screen resolution and pixel clock rate. These numbers are for my current design, using 640x480 TFT and 50 MHz memory, and full 16-bit color sprites and background. By lowering color depth, resolution, or increasing clock speed, these numbers get better.
As far as video interface, I was looking at this device:
Cirrus Logic CS4954 which generates PAL/NTSC composite, S-video and RGB outputs. My idea was to make something that can be hooked up to a TV, so you can make your own video games. Of course, an audio DAC would be required as well, but that can be a simple PWM output + filter/opamp.