How Video Modes Work: Difference between revisions

From Uzebox Wiki
Jump to navigation Jump to search
mNo edit summary
Line 3: Line 3:


==Reasoning==
==Reasoning==
The Uzebox has several video modes that are designed to capitalize on the systems capabilities and limitations. You might notice that Uzebox video modes can be quite different from other machines with similar capabilities. This is to be expected, because the Uzebox has radically different hardware! Most modes are tile based, as bitmap displays consume large amounts of memory. The advantage of tile based is that 1 byte can act as a pointer to ~64 bytes of flash memory, that is we can display ~64 bytes of visual data(in flash format that we have 64k of) using only ~1 byte(2 in certain modes) of actual ram(which we only have 4k of!). This allows full 8 bits per pixel display of 256 different colors at resolutions of 240x224 or greater, where a bitmap display cannot possibly achieve such a high combination of resolution and color depth due to limited ram(do the math, 1 byte per PIXEL!!). Tile based modes also save a lot of processing time, as we don't have to actually draw game worlds that consist of patterns individually to a buffer, but merely point VRAM at the right pre-calculated drawings. In general, the types of games we will do on Uzebox are retro style. Retro style games used tile based methods because that's what the hardware was based on. It is for these exact same reasons, even though their hardware was different. It is a very efficient blend to achieve good visual output with modest hardware resources. There are also some bitmap display methods that perform a compromise of color depth and resolution to provide the most useful possible bitmap display within ram limits. For the above reasons, they are not commonly used for games, though they are also quite interesting and can be useful for certain things.
The Uzebox has several video modes that are designed to capitalize on the systems capabilities and limitations. You might notice that Uzebox video modes can be quite different from other machines with similar capabilities. This is to be expected, because the Uzebox has radically different hardware! Most modes are tile based, as bitmap displays consume large amounts of memory. The advantage of tile based is that 1 byte can act as a pointer to ~64 bytes of flash memory, that is we can display ~64 bytes of visual data(in flash format that we have 64k of) using only ~1 byte(2 in certain modes) of actual ram(which we only have 4k of!). This allows full 8 bits per pixel display of 256 different colors at resolutions of 240x224 or greater, where a bitmap display cannot possibly achieve such a high combination of resolution and color depth due to limited ram(do the math, 1 byte per PIXEL!!). Tile based modes also save a lot of processing time, as we don't have to actually draw game worlds that consist mainly of repeating patterns individually to a buffer, but merely point VRAM at the right pre-calculated drawings. In general, the types of games we will do on Uzebox are retro style. Retro style games used tile based methods because that's what the hardware was based on. It is for these exact same reasons, even though their hardware was different. It is a very efficient blend to achieve good visual output with modest hardware resources. There are also some bitmap display modes that perform a compromise of color depth and resolution to provide the most useful possible bitmap display within ram limits. For the above reasons, they are not commonly used for games, though they are also quite interesting and can be useful for certain things.


==Software Acting As Hardware==
==Software Acting As Hardware==

Revision as of 01:14, 4 January 2012

Foundational Knowledge

To understand how the Uzebox generates a video signal, you must first comprehend what the television display expects before it will output. The standard Uzebox is designed to interface with televisions using the NTSC signal. This standard displays 60 frames a second drawn one horizontal line at a time, from top to bottom. For each horizontal line, there is a period before and after actual rendering begins known as a horizontal blanking period. During this time sound must be processed and updated, and preparations to draw the next line from the Uzebox memory must take place. This time period is very small, and like all video mode details, must have exact timing. If the time is off, the picture will shear, lose vertical lock, or other anomalous things because it does not meet the NTSC standard that the television is expecting. After each frame is drawn, there is a short time in between which is known as the vertical blank period. While outputting to the television there is no time to do anything else without generating a bad signal, so this vertical blank is the only place we can do any other kind of processing to update a game world. Vertical blank must last an exact length to avoid display problems, so an interrupt system will override any other processing taking place in order to maintain. I recommend further reading here: Video Generation

Reasoning

The Uzebox has several video modes that are designed to capitalize on the systems capabilities and limitations. You might notice that Uzebox video modes can be quite different from other machines with similar capabilities. This is to be expected, because the Uzebox has radically different hardware! Most modes are tile based, as bitmap displays consume large amounts of memory. The advantage of tile based is that 1 byte can act as a pointer to ~64 bytes of flash memory, that is we can display ~64 bytes of visual data(in flash format that we have 64k of) using only ~1 byte(2 in certain modes) of actual ram(which we only have 4k of!). This allows full 8 bits per pixel display of 256 different colors at resolutions of 240x224 or greater, where a bitmap display cannot possibly achieve such a high combination of resolution and color depth due to limited ram(do the math, 1 byte per PIXEL!!). Tile based modes also save a lot of processing time, as we don't have to actually draw game worlds that consist mainly of repeating patterns individually to a buffer, but merely point VRAM at the right pre-calculated drawings. In general, the types of games we will do on Uzebox are retro style. Retro style games used tile based methods because that's what the hardware was based on. It is for these exact same reasons, even though their hardware was different. It is a very efficient blend to achieve good visual output with modest hardware resources. There are also some bitmap display modes that perform a compromise of color depth and resolution to provide the most useful possible bitmap display within ram limits. For the above reasons, they are not commonly used for games, though they are also quite interesting and can be useful for certain things.

Software Acting As Hardware

There seems to be some confusion amongst aspiring Uzebox programmers, as to what the hardware supports for video output. Quite simply, the Uzebox supports anything that can calculated and output correctly in time to meet the NTSC standard. The Uzebox has no video chip, accelerator, or anything of that nature. The Uzebox literally outputs a byte that represents a color, for every pixel on the television display you see, straight out to the DAC pins. This happens at an extremely fast pace, as the NTSC signal speed is 3.58mhz. In the old days of 80's era 6502/z80/etc. computers, which are the most comparable to Uzebox, the machines also had to feed data at this speed. The processors were often not capable of completing even 1 instruction during the time the NTSC signal expects another pixel. So the processors could not directly deal with individual pixel elements, and instead needed to be able to deal with chunks of pixel elements(hence, tiles and sprites). This was accomplished by dedicated hardware that was specifically created for this purpose and nothing else. The Uzebox is exactly the opposite of this. To replace these complicated custom chips that were required back then, Uzebox does it with sheer processing speed! The ATmega644 operates at over 28mhz, which is drastically faster than the older processors(plus other technical superior things). This allows enough instructions to happen per pixel to directly instruct the television, instead of instructing custom hardware how to interface with the TV. It should be noted, this is not an over sight, nor is it lack of understanding that dedicated hardware could be made to do more. The whole novelty/particularity of the system is that is is just a small micro-controller doing things that used to require a whole complex circuit board! This way it is cheap, fun, and easy to build for hobbyists as well as creating an interesting development environment for games.

The best way to understand how the video is calculated by software is to look in the source code. You should acquire a copy of the kernel and look inside. You will see different video modes, and in each one there is a videomodeXcore.s(where X is mode number) which is the actual assembly language instructions that do the work. Let's quickly look at a snippet: //... lpm r16,Z+ out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 1 ld r18,Y+ ;load next tile # from VRAM

lpm r16,Z+ out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 2 mul r18,r19 ;tile*width*height

lpm r16,Z+ out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 3 cpi r18,RAM_TILES_COUNT ;is tile in RAM or ROM? (RAM tiles have indexes<RAM_TILES_COUNT) in r6,_SFR_IO_ADDR(SREG) ;save the carry flag

lpm r16,Z+ out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 4 brsh .+2 ;skip if next tile is in ROM movw r20,r4 ;load RAM title table address +row offset

lpm r16,Z+ out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 5 bst r6,SREG_C ;store carry state in T flag for later branch add r0,r20 ;add tile table address +row offset lsb

lpm r16,Z+ out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 6 adc r1,r21 ;add title table address +row offset msb dec r17 ;decrement tiles to draw on line


lpm r16,Z+ out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 7 lpm r16,Z+

breq end movw ZL,r0 ;copy next tile adress

out _SFR_IO_ADDR(DATA_PORT),r16 ;pixel 8 brtc romloop

rjmp .

There is even more code to handle frame timing, sound updating, etc, but this gives you and idea of what is being calculated to draw the right picture to the television. There is a lot of work done only by software, to negate the need for hardware.