2 Copy edited (e.g. ref. <http://en.wikipedia.org/wiki/Random-access_memory>). [(its = possessive, it's = "it is" or "it has". See for example <http://www.wikihow.com/Use-Its-and-It%27s>.)]
source | link

Other answers cover your question pretty well at an abstract level (Hardwarehardware), but having actual experience with the GBA in particular I figured a more detailed explanation may be worth while.

The GBA had many drawing modes and settings which could be used to control how the graphics processor interpreted the video ramRAM, but one thing was inescapable: the frame rate. The graphic processor was drawing to the screen in a nearly (more on this below) constant loop. (This is likely the most relevant bit for your question.) It

It would draw one line at a time taking a very short break between each. After drawing the last line for the frame it would take a break roughly equal to the time it takes to draw 30 lines. Then start again. The timing of each line, and the timing of each frame were all predetermined and set in stone. In a lot of ways the graphics processor was really the master of that system and you needed to write your games around it'sits behavior, because it willwould continue doing what it doesdid whether you were ready or not.

Roughly 75-80% of the time it was actively pushing to the screen. What frame rates could you accomplish if you were doing the same?

That 80% of the time was also what the CPU had to process user input, calculate game state, and load sprites/tiles to areas of VRAM that were currently off screen (or at least not included in the current line being drawn).

The 20% between frames, was all the CPU had to tweak video settings or ramRAM that would impact the whole next frame.  

At the end of each line, the graphics processor would send a line sync interrupt to the CPU. This interrupt could be used to tweak settings on a few sprites, or a few background layers (this is how you can get an effect like a conical spotlight, by changing the size and location of one of the rectangular masks between each line drawn. As far as the hardware is concerned all those regions are rectangular.). You have to be careful to keep these updates small and finish before the graphic processor starts drawing the next line or you can get ugly results. Any time spent processing these interrupts also cut into that 80% of the CPUsCPU's processing time..  .

For games that got the most out of this system, neither the CPU nor the graphic processor ever took a real break,break; each were chasing the other around the loop updating what the other wasn't currently looking at.

Other answers cover your question pretty well at an abstract level (Hardware) but having actual experience with the GBA in particular I figured a more detailed explanation may be worth while.

The GBA had many drawing modes and settings which could be used to control how the graphics processor interpreted the video ram, but one thing was inescapable: the frame rate. The graphic processor was drawing to the screen in a nearly (more on this below) constant loop. (This is likely the most relevant bit for your question.) It would draw one line at a time taking a very short break between each. After drawing the last line for the frame it would take a break roughly equal to the time it takes to draw 30 lines. Then start again. The timing of each line, and the timing of each frame were all predetermined and set in stone. In a lot of ways the graphics processor was really the master of that system and you needed to write your games around it's behavior, because it will continue doing what it does whether you were ready or not.

Roughly 75-80% of the time it was actively pushing to the screen. What frame rates could you accomplish if you were doing the same?

That 80% of the time was also what the CPU had to process user input, calculate game state, and load sprites/tiles to areas of VRAM that were currently off screen (or at least not included in the current line being drawn).

The 20% between frames, was all the CPU had to tweak video settings or ram that would impact the whole next frame.  

At the end of each line, the graphics processor would send a line sync interrupt to the CPU. This interrupt could be used to tweak settings on a few sprites, or a few background layers (this is how you can get an effect like a conical spotlight, by changing the size and location of one of the rectangular masks between each line drawn. As far as the hardware is concerned all those regions are rectangular) You have to be careful to keep these updates small and finish before graphic processor starts drawing the next line or you can get ugly results. Any time spent processing these interrupts also cut into that 80% of the CPUs processing time..  

For games that got the most out of this system, neither the CPU nor the graphic processor ever took a real break, each were chasing the other around the loop updating what the other wasn't currently looking at.

Other answers cover your question pretty well at an abstract level (hardware), but having actual experience with the GBA in particular I figured a more detailed explanation may be worth while.

The GBA had many drawing modes and settings which could be used to control how the graphics processor interpreted the video RAM, but one thing was inescapable: the frame rate. The graphic processor was drawing to the screen in a nearly (more on this below) constant loop. (This is likely the most relevant bit for your question.)

It would draw one line at a time taking a very short break between each. After drawing the last line for the frame it would take a break roughly equal to the time it takes to draw 30 lines. Then start again. The timing of each line, and the timing of each frame were all predetermined and set in stone. In a lot of ways the graphics processor was really the master of that system and you needed to write your games around its behavior, because it would continue doing what it did whether you were ready or not.

Roughly 75-80% of the time it was actively pushing to the screen. What frame rates could you accomplish if you were doing the same?

That 80% of the time was also what the CPU had to process user input, calculate game state, and load sprites/tiles to areas of VRAM that were currently off screen (or at least not included in the current line being drawn).

The 20% between frames, was all the CPU had to tweak video settings or RAM that would impact the whole next frame.

At the end of each line, the graphics processor would send a line sync interrupt to the CPU. This interrupt could be used to tweak settings on a few sprites, or a few background layers (this is how you can get an effect like a conical spotlight, by changing the size and location of one of the rectangular masks between each line drawn. As far as the hardware is concerned all those regions are rectangular.). You have to be careful to keep these updates small and finish before the graphic processor starts drawing the next line or you can get ugly results. Any time spent processing these interrupts also cut into that 80% of the CPU's processing time...

For games that got the most out of this system, neither the CPU nor the graphic processor ever took a real break; each were chasing the other around the loop updating what the other wasn't currently looking at.

1
source | link

Other answers cover your question pretty well at an abstract level (Hardware) but having actual experience with the GBA in particular I figured a more detailed explanation may be worth while.

The GBA had many drawing modes and settings which could be used to control how the graphics processor interpreted the video ram, but one thing was inescapable: the frame rate. The graphic processor was drawing to the screen in a nearly (more on this below) constant loop. (This is likely the most relevant bit for your question.) It would draw one line at a time taking a very short break between each. After drawing the last line for the frame it would take a break roughly equal to the time it takes to draw 30 lines. Then start again. The timing of each line, and the timing of each frame were all predetermined and set in stone. In a lot of ways the graphics processor was really the master of that system and you needed to write your games around it's behavior, because it will continue doing what it does whether you were ready or not.

Roughly 75-80% of the time it was actively pushing to the screen. What frame rates could you accomplish if you were doing the same?

That 80% of the time was also what the CPU had to process user input, calculate game state, and load sprites/tiles to areas of VRAM that were currently off screen (or at least not included in the current line being drawn).

The 20% between frames, was all the CPU had to tweak video settings or ram that would impact the whole next frame.

At the end of each line, the graphics processor would send a line sync interrupt to the CPU. This interrupt could be used to tweak settings on a few sprites, or a few background layers (this is how you can get an effect like a conical spotlight, by changing the size and location of one of the rectangular masks between each line drawn. As far as the hardware is concerned all those regions are rectangular) You have to be careful to keep these updates small and finish before graphic processor starts drawing the next line or you can get ugly results. Any time spent processing these interrupts also cut into that 80% of the CPUs processing time..

For games that got the most out of this system, neither the CPU nor the graphic processor ever took a real break, each were chasing the other around the loop updating what the other wasn't currently looking at.