What exactly is a VGA tile driver?

ElectricAye

I'm embarrassed to ask this question, but what exactly is a "tile driver"? Is it merely a way to place images on a screen or does it necessarily involve the movements of a cursor/mouse? If I just want text on a VGA, do I need to learn about tile drivers, or is text done by some other means? I'm trying to learn how to get VGA to work and, as you can probably tell by my question, I'm clueless at this stage.

thanks,
Mark

mctrivia

i am not sure but I beleive tile drivers refers to the method of breaking the screen up into larger chunks to reduce the amount of memory needed to store the screen image.

I am sure someone that knows can say for sure shortly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

SRLM

Just today I've tried out the TV_text, and it's really easy. Take a sample program (for example the compass or 3-axis accelerometer), look at how they use the code, and you can quickly and easily make some of your own. As far as I can tell, TV_text and VGA_Text are identical to the user.

potatohead

A "tile" driver partitions the display area into discrete elements. Each of these elements is really a pointer to the actual graphical content, thus the word "tile". The pointer can point to RAM or ROM, and in the VGA drivers, the built in character ROM is handy for displaying things on the screen, using only the HUB RAM necessary to manage the pointer.

Tiles defined in HUB ram can be as few, or as many as will fit, and present as a "happy middle" where display resolutions that would otherwise have individually addressable pixels exceed available RAM.

Because of how the propeller waitvid command works, tiles are generally 2 color, 4 color, or full-color (8 bits of color, for one byte per pixel).

This is the easiest kind of driver to both write and manage.

Sprites are not really possible on a tile display. Some hacks are available, such as maintaining a small RAM buffer where the contents of a tile and the sprite object can be combined during the blanking period, then written to the screen and manged such that the object appears to move freely between the tiles. Good for a cursor, not so good for multiple objects, or those that require unique colors apart from those permitted by the tile code.

Sprite drivers take many forms. The most common is a line driver, where one COG is responsible for reading a scan line worth of data and drawing the pixels to the screen, along with sync signals. That is the master cog. Other COGs then can build dynamic graphics, including sprites, and draw them into the line ram before the master cog needs them. In this way, multiple COGs can be doing the computation and masking of sprites necessary for multiple objects to appear on screen without artifacts. (artifacts being overlapping clearly seen, determining which object is in front and other things)

These drivers are generally more difficult and tend to be adapted to the display the user has in mind.

Another form is the "character mode" driver. This kind of driver uses a small screen ram to hold one screen full of character and maybe attribute values. The driver reads these and uses those values as an index to a character table stored in HUB memory. The 8x8 text drivers that do 40x24 lines are this kind of driver. So is AiGeneric. The number of definable shapes is limited to 256, and the number of colors most often seen is 2 colors per character. Think, Atari, C64, etc... style text mode graphics.

These drivers are nice because string values written directly to the screen ram, display as those character values directly, instead of having to go through one layer of abstraction as would be needed for a tile type driver with pointers instead of a screen memory.

Bitmap drivers are really easy! The screen memory is scanned sequentially, with each bit, or group of bits being a pixel. Problem with these is they take a lot of RAM.

A hybrid is where a tile driver sets all of it's pointers to sequential HUB memory locations to form a bitmap, but with more complex addressing. This is what the Parallax driver does. There are some simple linear addressing bitmap drivers to be found in the OBEX and Propeller Wiki.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

potatohead

There are some nice VGA drivers in the OBEX. If you use the Parallax ones, they are tile drivers. What you need to do, in order to get text on the screen, is take each character of your text, then compute the Propeller ROM offset according to it's value and the sequential storage of characters in the Propeller ROM, then decide which color it is. Propeller ROM characters are packed two to a tile, and your color settings determine which of them is shown.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

mctrivia

my driver for my LED display then would be a bitmap driver. My screen is only 60x14 though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

potatohead

I'm pretty sure OBC has his terminal driver for VGA up and running. A component of that will do VGA text.

--->Yep! That's a little tiny bitmap driver!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!