Last visit was: Wed Dec 01, 2021 5:49 pm
It is currently Wed Dec 01, 2021 5:49 pm



 [ 70 posts ]  Go to page 1, 2, 3, 4, 5  Next
 Sprite / Cursor Controllers 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
Reading some recent posts about the V9958 video chip, I thought I’d mention my rtfSpriteController.v component circuit which makes use of a little more up-to-date technology. I’ve used it for sprite display on VGA/XGA monitors. It offers higher color resolution for sprites (256 or 32k colors) and limited alpha blending functionality. Sprite size (x,y) may be controlled as long the sprite uses less than the size of a block ram (2kB).
It may differ from sprite controllers like the V9958 or 6567 in that it makes use of a block ram for each sprite image so that the image data may be read in parallel at time of display rather than in sequence during horizontal blanking. The parallel accessed block ram offers much higher bandwidth in order to support higher color resolution. Sprite image data may be loaded programmatically or via DMA.
The controller is currently being updated to support 32 sprites (It previously had a limit of 14). There are no restrictions on the number of sprites displayed in a scanline. Note that as high color resolution sprites are supported there is no need to stack sprites together to achieve more colors. This means each sprite is equal to more than the typical sprite of earlier controller chips which often support only a single color.
The controller synchronizes to externally applied hsync, and vsync signals and allows up to 12 bits for each of the X, Y co-ordinates. The controller doesn’t really care what the VGA/XGA resolution is. The sprite controller has RGB input and output busses and is intended to overlay a backdrop generator.

http://github.com/robfinch/Cores/blob/m ... ntroller.v

_________________
Robert Finch http://www.finitron.ca


Sun Jan 25, 2015 8:14 am WWW
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
[removed due to user inquiry]


Wed Jan 28, 2015 5:11 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
A poor photo of 32 sprites displayed ontop of a text screen. The sprites are 32k color and the image is just random data. All 32 sprites could be displayed on the same scan line. The sprites are displayed at a high resolution and are 36x28 pixels in size (that can be altered programmatically).

Attachment:
sprites2.jpg


You do not have the required permissions to view the files attached to this post.

_________________
Robert Finch http://www.finitron.ca


Sun Feb 08, 2015 4:30 pm WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
I started another video controller which is going to support text/ graphics and sprites all in one controller. Similar to the VIC-II (6567 chip).
640x384 by 8 bpp graphics, 10x 40x25 pixel sprites.
80x48 text mode.
The controller will use main memory rather than specially dedicated ram.

_________________
Robert Finch http://www.finitron.ca


Wed Oct 25, 2017 2:20 am WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
Hi Rob, have you been following the thread over on 6502.org? There might be a few interesting ideas in there.
I've got plenty of ideas that don't fit the TTL topic of the thread so am saving them for a thread of there own, either here or over at 6502.org.

I have a design in mind targeting multiplexed SRAM on an external bus so we might be heading down a similar path, it could be fun. :)


Wed Oct 25, 2017 9:45 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
Quote:
Hi Rob, have you been following the thread over on 6502.org? There might be a few interesting ideas in there.

Yes. I find it interesting. I've been following along silently.

Although similar to a 6567 the core may not be 65xx compatible. I've simplified it by removing multi-color mode and extended color mode and going with a straight 8bpp for everything. It simplifies the color selection and pixel shifting. The other color modes were present in the 6567 because of the limited amount of memory available.
The higher video resolution means that more bits are required for coordinates.

The video memory access requires at least a 32 bit data bus, possibly 64 bit. So that multiple pixels can be read at once. 8, 8bit pixels would fit nicely into 64 bits for bitmapped mode. (The processor could use a narrower bus).
I'm starting with the ram accessed at an 80MHz rate. I hope to reduce this to 40MHz (the dot clock rate) or slower so that ordinary sram can be used. The "main memory" would currently be block ram in an FPGA shared with the processing core.

I've managed to get external 10 ns sram working in a pipelined fashion at 50 MHz before so it should be doable.
With a 640x384 screen (1/4 1280x768) 240kB ram required per screen. 512kB sram would be enough for two screens plus sprite data. Sprite data is 1kB per sprite.

_________________
Robert Finch http://www.finitron.ca


Wed Oct 25, 2017 10:26 am WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
Quote:
Hi Rob, have you been following the thread over on 6502.org? There might be a few interesting ideas in there.

Yes. I find it interesting. I've been following along silently.

Although similar to a 6567 the core may not be 65xx compatible. I've simplified it by removing multi-color mode and extended color mode and going with a straight 8bpp for everything. It simplifies the color selection and pixel shifting. The other color modes were present in the 6567 because of the limited amount of memory available.
The higher video resolution means that more bits are required for coordinates.

The video memory access requires at least a 32 bit data bus, possibly 64 bit. So that multiple pixels can be read at once. 8, 8bit pixels would fit nicely into 64 bits for bitmapped mode. (The processor could use a narrower bus).
I'm starting with the ram accessed at an 80MHz rate. I hope to reduce this to 40MHz (the dot clock rate) or slower so that ordinary sram can be used. The "main memory" would currently be block ram in an FPGA shared with the processing core.

I've managed to get external 10 ns sram working in a pipelined fashion at 50 MHz before so it should be doable.
With a 640x384 screen (1/4 1280x768) 240kB ram required per screen. 512kB sram would be enough for two screens plus sprite data. Sprite data is 1kB per sprite.


The board I'm playing with has 16 Bit wide 10ns SRAM so I was considering using the lower 8 Bits for colour and the upper 8 Bits for various control attributes, extended sprite width, etc.


Wed Oct 25, 2017 10:56 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
Quote:
The board I'm playing with has 16 Bit wide 10ns SRAM so I was considering using the lower 8 Bits for colour and the upper 8 Bits for various control attributes, extended sprite width, etc.

What board are you using ?
Could you use an FPGA internal memory for some things ? It might ease up on bandwidth requirements.

It occurs to me that full 256 color sprites are likely wasteful of memory bandwidth. It might be better to limit the number of different colors that a sprite can be and use the memory bandwidth to support more sprites. Using 2 bits per pixel would allow three colors plus transparent. Rather than share the multi-colors as in the VIC-II, each sprite would then have it’s own colour palette (3 entry) to expand the 2 bits to 8 bits.
Changing the sprite size to 48x42 from 40x25 would allow an even multiple of 32 bits (96 bits horizontal data). A 48x42 sprite is double the horizontal and vertical resolution of the VIC-II sprites. Which might be handy if translating graphics.
I switched the timing generator to a 640x400, 70Hz mode with 25MHz clock. It's not a standard mode, so I hope it works.
Because the sprite display is priority logic it’s a cascaded logic level for each sprite that could be displayed. So it’s desirable to keep the number of sprites to a small number.

_________________
Robert Finch http://www.finitron.ca


Thu Oct 26, 2017 10:18 pm WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
What board are you using ?
Could you use an FPGA internal memory for some things ? It might ease up on bandwidth requirements.

At the moment, I'm just using an Altera Cyclone II ep2c20 based board. I picked 3 them up at a good price a few years back.
https://ae01.alicdn.com/kf/UT8C6CeXeXXXXagOFbXA.jpg <--An image from the original ad.

I do have other boards I can play with, there is a contraption I made with a Spartan3 500E and 2MB 10ns SRAM, also a DE0 Nano (Cylclone IV), a Spartan6 LX45
and a couple LX16's that arrived in the mail a few days ago. A good price on the LX16's but SDRAM only. https://www.aliexpress.com/item/-/32801899786.html

I think there might be just enough blockram on the ep2c20 to have a bit of fun. Everything is in block ram at the moment, though I'll probably spin off a lower
resolution version using external SRAM at a some point just to see how far I can go with the restriction.

Quote:
It occurs to me that full 256 color sprites are likely wasteful of memory bandwidth. It might be better to limit the number of different colors that a sprite can be and use the memory bandwidth to support more sprites. Using 2 bits per pixel would allow three colors plus transparent. Rather than share the multi-colors as in the VIC-II, each sprite would then have it’s own colour palette (3 entry) to expand the 2 bits to 8 bits.
Changing the sprite size to 48x42 from 40x25 would allow an even multiple of 32 bits (96 bits horizontal data). A 48x42 sprite is double the horizontal and vertical resolution of the VIC-II sprites. Which might be handy if translating graphics.
I switched the timing generator to a 640x400, 70Hz mode with 25MHz clock. It's not a standard mode, so I hope it works.
Because the sprite display is priority logic it’s a cascaded logic level for each sprite that could be displayed. So it’s desirable to keep the number of sprites to a small number.

If you overlay multiple 2Bit colour sprites on top of each other, lower colours could show through transparent sections of the sprites above to give you more colours. The extension of this is to design for it so you can attach sprites to an overlaying group and derive either a palette or direct RGB from the combined bits, 3 sprites could give you either 64 colours of raw RRGGBB or a 64 colour palette. Moving the first sprite could move the group. If you find displays that don't work with 640x400, you could try 1280x800 and discard the LSB of your horizontal and vertical counters for a pixel rate (and ram access) of half the pixel clock. 1280x800 is still nonstandard (I think some MACs might use it) but it's more common than 640x400 so more displays may support it.


Fri Oct 27, 2017 12:20 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
I've posted the current code/docs on opencores.org under the rtfTextController project in video cores. It's called FT_VIC.v. It's not been even synthesized yet so there's bound to be lots of errors, but I think the gist of it is done.

_________________
Robert Finch http://www.finitron.ca


Sun Oct 29, 2017 1:35 pm WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
I am wondering why the sprite address pointers in the VIC-II chip are stored in memory at the end of the screen memory rather than being stored in the register file ?
Is there a good reason to do this ? It's always struck me as a little strange.
There could be fewer bus accesses if the sprite pointers were stored in a register file.

_________________
Robert Finch http://www.finitron.ca


Mon Oct 30, 2017 11:28 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
I'm travelling in a circle back towards the original sprite controller design in terms of thinking.

An issue that arose is the buffering of sprite display data during the horizontal blank time. A scanline of sprite data has to be copied from memory to a scanline buffer for display. The buffer is a 192 bit wide register, loaded during the blanking interval, and shifted out at the sprite's display location. The next step in the buffer evolution is use a block ram to replace the wide register. The dual port block ram is maybe more efficient than using a wide register with multiplexers. The third step is to realize, hey, if a block ram is used, why copy the data at all ? Why not just use the increased size of the block ram itself to hold multiple scanlines of data ? The block ram could hold the entire image of the sprite.
Hey wait a sec, that's how the original rtfSpriteController works.

_________________
Robert Finch http://www.finitron.ca


Tue Oct 31, 2017 9:38 pm WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
Got gas for the car tonight.

I am toying with the idea of “improving” the DMA capabilities of the sprite controller. Currently DMA is software triggered. There is no DMA unless a trigger bit is set in a DMA register by software. It might also be useful to trigger an automatic DMA operation at a given scan line. DMA also loads the entire sprite buffer. In some circumstances this could be wasting memory bandwidth. Loading the entire buffer is 1024 words. If the sprite is only 24x21 say, then only 252 memory words need to be loaded. So I’m thinking of adding a DMA count limit register to the design. With a limit register there would also be control over the destination word written in the sprite buffer. These changes could fit into a single register for each sprite. (10 bits destination word, 10 bit count limit, and 12 bit triggering scan line = 32 bits).

On the other hand I’m trying to avoid a controller so complex that nobody can understand it.

Currently, in the video system there is an independent component which is a raster interrupt controller. This component generates interrupts at specified scan lines. I wonder if it could be modified to generate hardware DMA requests as well as interrupt requests. The sprite controller could rely on this component to generate software interrupts which would then trigger the DMA. Rather than incorporating the scanline testing into the sprite controller.

_________________
Robert Finch http://www.finitron.ca


Sun Nov 05, 2017 3:13 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1531
Location: Canada
I’m writing yet another display controller that handles sprites or blits in a slightly different fashion. The display resolution is a fixed 640x512 window in an 800x600 VGA mode. The controller makes use of dual ported block ram (768k by 10 bits) for a frame buffer rather than main memory. Display output is RGB333. There will be no contention for the memory between the update and display hardware. Thus display updates can run at full speed. The controller will perform memory to memory DMA’s to copy sprite images to the displayed ram. The DMA is software triggered allowing the painter’s algorithm to be used. The controller should be able to handle 64 full color sprites each composed of up to 1k pixels. The sprites can be any size up to 1k pixels. So a 512 wide by 2 pixels high sprite is possible. Any number of sprites can be on the same display line. The controller is also to support text output acceleration for simple char bitmaps. 8x8 char bitmaps are copied by the controller to display memory. All that software has to do is set the character code and attributes for display in a buffer, then the display controller takes care of the necessary blit operation. While the display controller is performing a blit operation it can’t do anything else so there is a queue for characters to be displayed. This allows a small string of text to be sent to the controller without having to wait for it to finish.

I have it almost working after only a few hours of play. It displays characters on-screen but they are flipped horizontally.

_________________
Robert Finch http://www.finitron.ca


Sun Nov 26, 2017 4:15 am WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
Ignore this post, I think I was looking at the wrong section in my code for the solution. I shouldn't post on no sleep.
Skip to the next post unless this makes any kind of sense.


robfinch wrote:
I have it almost working after only a few hours of play. It displays characters on-screen but they are flipped horizontally.


I'm not sure if this is relevant to your design, but if your char generator is using the lowest 3 bits of the horizontal counter, they'll need to be inverted.

Excuse the VHDL notation.

You may have something like:
hcount(2 DOWNTO 0)

Flip things the right way around with:
NOT hcount(2 DOWNTO 0)


Last edited by Cray Ze on Sun Nov 26, 2017 5:50 am, edited 2 times in total.



Sun Nov 26, 2017 5:08 am
 [ 70 posts ]  Go to page 1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software