FAQ - Frequently Asked Questions

Q: How much FLASH does the driver need?

A: The AVGA platform is highly customizable and designed to occupy as little flash as possible, depending on configuration. Tileset is stored within FLASH and can be accessed by the driver directly, not necessary to copy it to RAM. For example: Native tile size is 8x8 (32 bytes) and you are using 128 tiles in your game. So you need 128 x 32 = 4096 bytes. All the memory spaces are mapped with driver_mmap(...) function.

Q: How much RAM does the driver need?

A: The system needs RAM space in two groups: 1. The reference table size is directly related to resolution and defined in config_screen.h. For example: you want 19x24 tiles on the screen. The size is 19 x 24 = 456 bytes. 2. The RAMmap is used for mapping tile graphics to RAM, by overlay util for example. You can specify in config_screen.h how many ramblocks are available for the system. For Example: you want to code an arkanoid clone. You will draw the ball with overlay to achieve smooth movement. The ball size is 8x8. Native tile size is also 8x8 (32 bytes). So you need at least 4 ramblocks. Thus the RAMmap size is 32 x 4 = 128 bytes. All the memory spaces are mapped with driver_mmap(...) function.

Q: Why dont you use 8 bits per pixel to do 256 colors?

A: The AVR Pacman, which this project originated from was 4bpp. Altough it'd be possible to do more colors, i decided to keep it this way, because of the following reasons:

1. For 8bpp, i would have to prolong the pixel period, causing significant resolution loss. I wanted the resolution to be highest as possible, to benefit from the fast RISC ALU as much as I can, rather than enabling more colors. This site is made of 16 colors.

2. All on-chip graphics would be double in size. The aim of AVGA, since I released it in 2006, was to be a GAME platform. The AVR nature is always limited by the FLASH and RAM size. So for single-chip game console based on AVRs - it is essential to make video engine and all graphics to occupy as little flash and ram as possible. This enables to implement on AVR a complex, playable video game, like Super Mario or Commander Keen. Not just a nice, full color demonstration.

Q: Would it be possible to use a lookup palette instead of hard wired colors?

A: Graphics driver must alternate the video port each 5 machine cycles, i.e. "out" instruction with new pixel data must be executed with this period. This leaves 4 ticks between each two pixels - 32 ticks per one tile. During this period, there's _really_ lot of work to do. Each pixel data must be fetched from memory to a register before shifting it out at right time, we must read the reference table, compute the corresponding bitmap line address for indirect addressing in the tileset; even decide which tile to get from RAM or FLASH. It was the hardest time coding this part, like writing a potery. Additional indirect addressing before each pixel would mean at least 4 more clock cycles per pixel. So the answer is simple: Yes, it is possible, but it would degrade the horizontal resolution by two or more.

Q: Why is the resolution for a VGA monitor much lower than for PAL or NTSC TV ?

A: The composite video signal timings are much more suitable because of the frame interlacing. For example: VGA frame (60Hz, 480 lines) gives almost twice the pixel rate then an interlaced PAL frame (50Hz, 288 lines).

Q: How many tiles can I draw by overlay?

A: Consider the screen as a chessboard with DRIVER_WIDTH x DRIVER_HEIGHT fields. The field (tile) size is for example 8x8. You need as many ramblocks as fields the image you are drawing will cover. For example: when drawing one tile by overlay - in our case image sized 8x8, you need 4 ramblocks in the worst case. The amount of available ramblocks is set in config_screen.h.

Q: What is the next possible crystal frequency?

A: There are no special frequencies required. You can make up any resolution you want by adjusting the cpu clock when considering 5 cycles per pixel. All screen adjusting can be made by modifiing config_screen.h. The only limitation is number of lines: 256 per a window. Total scan line period mus not exceed the Active picture area and total number of lines cannot be greater than native number of lines in your video standard (PAL: 288 lines, NTSC: 240 lines), of course.

Q: Can i use interrupts in my game design?

A: No. This would cause serious errors in sync pattern and pixel stream.

Q: Is there something like overlay_draw which reads the source image from RAM?

A: No. There is no reason for this in such tiny environment.

Q: How to tell the system that i changed the clock frequency?

A: Compile the project with -DF_CPU=x where x is your frequency in Hz. In AVR studio, set your frequency under Project->Configuration Options menu.

Q: Why dont you make the driver to generate composite video?

A: Though it is possible, the AVR would have to run at least 1.5x faster to maintain current resolution, and the clock freq would have to be a multiply of color subcarrier frequency. Use a RGB-to-composite video converter.

Q: There is a slight jitter in my picture. Is it normal?

A: Probably the line timer sync macro is not correctly configured. See config_hw.h.

Q: How can i switch between PAL/NTSC in runtime?

A: Just call video_init(PAL) or video_init(NTSC). Make sure that your resolution fits both the standards! Total scan line period must not exceed Active picture period value for both signals.