Propeller Graphics Structure

Vega256

Hey Guys,

If you guys remember from my previous post 'Propeller as a Renderer', I am attempting to include the Propeller with my Intel 8088 microprocessor. The Propeller's purpose in this circuit is to interface with a television.

I have a question regarding the way that tile data should be stored in ROM. My CPU "bottleneck" is an 8-bit data bus. According to the HYDRA Manual, tile data is stored as an array of longs, which if I read correctly is equal to 32 bits. If each pixel requires 2 bits, could it be possible to store tile data as 4 bytes per tile?

ericball

The Propeller Video Generator is loaded via the WAITVID instruction, which loads the internal color palette register and the internal pixel shifter. The pixel shifter outputs one or two bits per pixel (depending on the VMODE setting), so 32 or 16 pixels per WAITVID (with the last pixel repeating indefinitely). The pixel value then selects one of the two/four 8 bit color values from the color palette register which are either sent directly to the output pins (VGA mode) or the composite/broadcast encoder (TV mode).

That it. All other abstractions (sprites, tiles, bitmaps, characters etc) are implemented by the video driver and translated down to WAITVID instructions and inputs. Because the Propeller has limited RAM (and, to a lesser extent, CPU time), it is common for Propeller video drivers to use a tile format. So the screen is broken up into tiles with each tile (16x16 or 16x32 for the standard TV.spin and VGA.spin) having the same color palette. But there's nothing to say that you couldn't create your own driver to meet your requirements.

Mike Green

Not quite.

The video hardware deals in longs. With 2 bits per pixel, you get 16 pixels per long with the color of each pixel chosen from one of 4 bytes selected from another long, also loaded into a hardware register. All the rest of the arranging of the video data is done by software. Because of the high speed required and the tight loops, a video tile normally consists of 32 successive longs, one for each scan line with 16 pixels per tile per line. It's possible to program other configurations, but time is of the essence and some configuations may just not be practical because of timing constraints. Don't bother asking about which ones are possible and which are not. There are too many possibilities.