gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > my understanding of this tutorial

#56801 - mesh - Tue Oct 11, 2005 5:45 pm

I have been lurking this forum for about a month now and this is my first post. I have read the beginners faq and am currently working through various tutorials for gba development. I would really appreciate it if someone could check my understanding of the following code. Just to see if I am on the right track. I have a beginners understanding of the C language but, have only been programming for Windows (console), and Allegro. Programming for new hardware is a new and exciting undertaking for me. Anyway, here is the code that I have commented as to how I understand it:

Code:
#include "gba.h"

int main()
{
     u16 x;
          //define x as an unsigned short variable//

     SetMode(MODE_3 | BG2_ENABLE);
                 //gives us the binary: 0000010000000011
                //ex. 0000010000000000 + 0000000000000011 = above   
               //also sets the value at pointer REG_DISPCNT to
              //0000010000000011
             //setting the pointer to this binary number enables Video Mode 3
            //and BG mode 2 (the only BG mode available in Video Mode 3)
     
     for(x=0; x<(240*160); x++)
                //loop through all addresses in pointer (pointers can be
               // indexed like arrays) FrontBuffer[x]
              //starting at FrontBuffer[0]
     {
     FrontBuffer[x]=RGB(31, 0, 0);
                  // Change the RGB value of the pixel located at
                 //FrontBuffer[x] to red
                //RGB = 11111 00000 00000
               //this is only a 15bit value (the 16th bit is ignored)
              //this 16 bit value is stored in two 8bit addresses starting at
             //0x6000000
     }
     return 0;
            // since main() is supposed to return an int we return 0 to let it
           //know everything executed properly
}


The above code comes from the tutorial here.

The only thing I am confused about is that the author said that the 16bit RGB value is stored in two 8bit addresses. It looks to me like if the code loops through all addresses and gives each a value of RGB then how does the compiler know to submit the value every two addresses. Ex. the first value will be stored at 8bit address 0x6000000 and 0x6000001. The next loop iteration, according to the author, will store the RGB value at 0x6000002 and 0x6000003 etc. But according to the code (from what I understand) won't the value be stored at every address and not every other address?

I know this is probably a stupid question and I probably will look back on it and think "Why did I ask this?..." but I am just a little confused about it. Anyway thanks for taking time to read the question and any help will be greatly appreciated.

#56805 - poslundc - Tue Oct 11, 2005 6:26 pm

mesh wrote:
The only thing I am confused about is that the author said that the 16bit RGB value is stored in two 8bit addresses. It looks to me like if the code loops through all addresses and gives each a value of RGB then how does the compiler know to submit the value every two addresses. Ex. the first value will be stored at 8bit address 0x6000000 and 0x6000001. The next loop iteration, according to the author, will store the RGB value at 0x6000002 and 0x6000003 etc. But according to the code (from what I understand) won't the value be stored at every address and not every other address?


The C language uses data types to determine how many bits "wide" an index into an array is.

On the GBA (as well as most modern platforms), a "short int" (or just "short") is a 16-bit wide variable. Your "gba.h" will have this typedefed as u16 and s16 for unsigned and signed versions.

If you look at the declaration of FrontBuffer, it probably looks something similar to this:

u16 *FrontBuffer = (u16 *)0x06000000;

or perhaps:

#define FrontBuffer ((u16 *)0x06000000)

Either way, the u16 data-type associated with the declaration of FrontBuffer tells the compiler that it needs to access the array 2 bytes at a time.

The only thing you ought to change is that your main() function should never terminate, as GBA programs don't actually "end" ever... there is no operating system for them to return to. (The effect here will that your program will keep resetting really, really quickly.)

What you want to do instead is drop into an infinite loop - while (1); will do just fine. Normally in this while loop is where you would do your game processing, and wait for VBlank to occur in it so that the loop processes once per frame.

Dan.

#56828 - mesh - Tue Oct 11, 2005 9:11 pm

Dan,

Thank you for the very clear answer. Yes you are correct about the FrontBuffer being defined as a 16 bit in one of the header files. *hits head with hand* guess I really should have realised that.

Obviously registers, manipulation of pointers to memory addresses, and values at those addresses are key to gba programming. Unfortunately most C books I have read don't go into such great detail about those subjects (at least the books at the local bookstores).

As for the While(1) loop, I understand and will implement it as you suggested.

Do you have any other information with regards to the VBlank. This is a new concept and I havn't really found much (basic) information on it.

Thanks again for your help.

#56834 - poslundc - Tue Oct 11, 2005 9:45 pm

Cearn's TONC tutorial has a graphics introduction page that explains the VDraw/VBlank phases and how to sync your program to them.

Most C books are geared towards programming on a computer with an operating system to interface between your program and the hardware, and therefore don't go into great detail on the kinds of things you need to know to work with a memory-mapped hardware interface like the one the GBA uses. Best advice is to study up on pointers and learn all you can from tutorials and sample code.

Dan.

#56838 - mesh - Tue Oct 11, 2005 9:56 pm

Thanks for the links Dan. I will also see if I can find more information on
"genral programming for memory mapped hardware" or "how memory mapped hardware works".
Nice keywords for me to search with.

Thanks.