Chameleon-AVR Nurve Networks, Chameleon-AVR Datasheet - Page 180

• Manufacturer Part Number: Chameleon-AVR
• Description: MCU, MPU & DSP Development Tools AVR8 & PROPELLER DEV SYSTEM (SBC)
• Manufacturer: Nurve Networks

Specifications of Chameleon-AVR

• Processor To Be Evaluated: AVR 328P
• Data Bus Width: 8 bit
• Interface Type: USB, VGA, PS/2, I2C, ISP, SPI
• Operating Supply Voltage: 3.3 V, 5 V
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

© 2009 NURVE NETWORKS LLC “Exploring the Chameleon AVR 8-Bit”
Referring to the table, the highest "safe" value to use for brightness/luma is 6 and the lowest "safe" value is 3, so keep
your luma in the range of [3,6] when using chroma, otherwise, the system won’t have enough freedom to encode the color
signal modulation since a +-1 modulates your luma signal and you don’t want it going out of range. The color format is not
something I made up, but a direct result of the underlying Propeller video hardware’s color format that it needs to process
pixels, so we are stuck with it. However, other than the out of range luma values, and the color modulation bit, its a fairly
common way to encode color on 8/16-bit graphics hardware. They rarely use RGB.
Tile Map Review
That about sums up the tile engine design. The physical tile map on the screen always displays 32x24 characters. You
can define larger virtual tile maps for scrolling that are 32, 64, 128, 256 wide, any height. Each tile is 2-bytes representing
the tile index (character) and the palette to use for the tile (4 colors). Each tile bitmap is 8x8 pixels, each pixel 2-bits. Each
2-bit code refers to 1 of 4 colors in the “palette” for that tile.
The tile engine supports course scrolling by changing the pointer to the start of the current tile map, or page flipping by
moving the pointer an entire tile map length. The engine also supports “smooth” scrolling in the vertical direction with the
vertical scroll register (0..7). The tile maps, tile bitmaps and palettes are all in memory and can be access by reading their
base address memory locations and then writing memory. This is done via the register interface (which we will discuss in
a moment). Finally, you can control the top and bottom overscan color of the NTSC screen with a 8-bit register for each.
That’s about all there is to it, but this tile engine is more than enough to write 90% of the games from the 90’s on 8/16-bit
machines!!!
22.1.1 GFX Driver Register Interface
Before jumping into the header file contents overview, I want to re-enforce that all communications to the GFX driver are
thru a set of “virtual” registers. These registers can be read/written (in most cases) and each register usually has a bit of
code that “executes” the read/write and does what needs to be done to any low level variables or data structures in the
ASM video driver itself. Thus, much of the functionality of the register interface isn’t directly built into the driver, but
created via code, the driver, and other added elements to give the user an “interface” that is more robust.
22.2 Header File Contents Overview
Since the GFX driver is a special case, I want to re-enforce that its worth reviewing the Propeller side driver as well, so
you can see what’s really going on. We are only going to cover the C/AVR side of things here, but all these registers,
functions, API, etc. are all handled at some point on the Propeller running the enhanced graphics driver for NTSC tile
graphics. With that in mind, let’s crack open the C/C++ header file named: CHAM_AVR_GFX_DRV_V010.h and see
180