mirror of
https://github.com/italicsjenga/gba.git
synced 2024-12-23 19:01:30 +11:00
capitalization
This commit is contained in:
parent
9a063983fb
commit
d690e696a4
|
@ -73,7 +73,7 @@ Bit 6 lets you adjust if the GBA should treat Object Character VRAM as being 2d
|
|||
around, so we'll be sure to have some extra diagrams in the chapter that deals
|
||||
with it.
|
||||
|
||||
Bit 7 forces the screen to stay in vblank as long as it's set. This allows the
|
||||
Bit 7 forces the screen to stay in VBlank as long as it's set. This allows the
|
||||
fastest use of the VRAM, Palette, and Object Attribute Memory. Obviously if you
|
||||
leave this on for too long the player will notice a blank screen, but it might
|
||||
be okay to use for a moment or two every once in a while.
|
||||
|
|
|
@ -2,10 +2,10 @@
|
|||
|
||||
The GBA's Video RAM is 96k stretching from `0x0600_0000` to `0x0601_7FFF`.
|
||||
|
||||
The Video RAM can only be accessed totally freely during a Vertical Blank
|
||||
(aka "vblank"). At other times, if the CPU tries to touch the same part of video
|
||||
memory as the display controller is accessing then the CPU gets bumped by a
|
||||
cycle to avoid a clash.
|
||||
The Video RAM can only be accessed totally freely during a Vertical Blank (aka
|
||||
"VBlank", though sometimes I forget and don't capitalize it properly). At other
|
||||
times, if the CPU tries to touch the same part of video memory as the display
|
||||
controller is accessing then the CPU gets bumped by a cycle to avoid a clash.
|
||||
|
||||
Annoyingly, VRAM can only be properly written to in 16 and 32 bit segments (same
|
||||
with PALRAM and OAM). If you try to write just an 8 bit segment, then both parts
|
||||
|
|
|
@ -99,11 +99,11 @@ their light cycle. Then we enter the core loop.
|
|||
|
||||
We read the keys for input, and then do as much as we can without touching video
|
||||
memory. Since we're using video memory as the place to store the player's light
|
||||
trail, we can't do much, we just update their position and wait for vblank to
|
||||
trail, we can't do much, we just update their position and wait for VBlank to
|
||||
start. The player will be a 2x2 square, so the arrows will move you 2 pixels per
|
||||
frame.
|
||||
|
||||
Once we're in vblank we check to see what kind of drawing we're doing. If the
|
||||
Once we're in VBlank we check to see what kind of drawing we're doing. If the
|
||||
player has gone out of bounds, we clear the screen, rotate their color, and then
|
||||
reset their position. Why rotate the color? Just because it's fun to have
|
||||
different colors.
|
||||
|
|
|
@ -23,9 +23,9 @@ So the way that display hardware actually displays each frame is that it moves a
|
|||
tiny pointer left to right across each pixel row one pixel at a time. When it's
|
||||
within the actual screen width (240px) it's drawing out those pixels. Then it
|
||||
goes _past_ the edge of the screen for 68px during a period known as the
|
||||
"horizontal blank" (hblank). Then it starts on the next row and does that loop
|
||||
"horizontal blank" (HBlank). Then it starts on the next row and does that loop
|
||||
over again. This happens for the whole screen height (160px) and then once again
|
||||
it goes past the last row for another 68px into a "vertical blank" (vblank)
|
||||
it goes past the last row for another 68px into a "vertical blank" (VBlank)
|
||||
period.
|
||||
|
||||
* One pixel is 4 CPU cycles
|
||||
|
@ -33,7 +33,7 @@ period.
|
|||
* VDraw is 150 scanlines, VBlank is 68 scanlines (280,896 cycles per full refresh)
|
||||
|
||||
Now you may remember some stuff from the display control register section where
|
||||
it was mentioned that some parts of memory are best accessed during vblank, and
|
||||
it was mentioned that some parts of memory are best accessed during VBlank, and
|
||||
also during hblank with a setting applied. These blanking periods are what was
|
||||
being talked about. At other times if you attempt to access video or object
|
||||
memory you (the CPU) might try touching the same memory that the display device
|
||||
|
@ -53,7 +53,7 @@ pub fn read_vcount() -> u16 {
|
|||
}
|
||||
```
|
||||
|
||||
Then we want two little helper functions to wait until vblank and vdraw.
|
||||
Then we want two little helper functions to wait until VBlank and vdraw.
|
||||
|
||||
```rust
|
||||
pub const SCREEN_HEIGHT: isize = 160;
|
||||
|
|
|
@ -193,7 +193,7 @@ the maximum sprites per scanline, so it's not default.</p>
|
|||
(off) or 1d (on). This particular control can be kinda tricky to wrap your head
|
||||
around, so we'll be sure to have some extra diagrams in the chapter that deals
|
||||
with it.</p>
|
||||
<p>Bit 7 forces the screen to stay in vblank as long as it's set. This allows the
|
||||
<p>Bit 7 forces the screen to stay in VBlank as long as it's set. This allows the
|
||||
fastest use of the VRAM, Palette, and Object Attribute Memory. Obviously if you
|
||||
leave this on for too long the player will notice a blank screen, but it might
|
||||
be okay to use for a moment or two every once in a while.</p>
|
||||
|
|
|
@ -138,10 +138,10 @@
|
|||
<main>
|
||||
<a class="header" href="#video-memory-intro" id="video-memory-intro"><h1>Video Memory Intro</h1></a>
|
||||
<p>The GBA's Video RAM is 96k stretching from <code>0x0600_0000</code> to <code>0x0601_7FFF</code>.</p>
|
||||
<p>The Video RAM can only be accessed totally freely during a Vertical Blank
|
||||
(aka "vblank"). At other times, if the CPU tries to touch the same part of video
|
||||
memory as the display controller is accessing then the CPU gets bumped by a
|
||||
cycle to avoid a clash.</p>
|
||||
<p>The Video RAM can only be accessed totally freely during a Vertical Blank (aka
|
||||
"VBlank", though sometimes I forget and don't capitalize it properly). At other
|
||||
times, if the CPU tries to touch the same part of video memory as the display
|
||||
controller is accessing then the CPU gets bumped by a cycle to avoid a clash.</p>
|
||||
<p>Annoyingly, VRAM can only be properly written to in 16 and 32 bit segments (same
|
||||
with PALRAM and OAM). If you try to write just an 8 bit segment, then both parts
|
||||
of the 16 bit segment get the same value written to them. In other words, if you
|
||||
|
|
|
@ -138,7 +138,7 @@
|
|||
<main>
|
||||
<a class="header" href="#ch-2-user-input" id="ch-2-user-input"><h1>Ch 2: User Input</h1></a>
|
||||
<p>It's all well and good to draw three pixels, but they don't do anything yet. We
|
||||
want them to to something, and for that we need to get some input from the user.</p>
|
||||
want them to do something, and for that we need to get some input from the user.</p>
|
||||
<p>The GBA, as I'm sure you know, has an arrow pad, A and B, L and R, Start and
|
||||
Select. That's a little more than the NES/GB/CGB had, and a little less than the
|
||||
SNES had. As you can guess, we get key state info from an IO register.</p>
|
||||
|
@ -146,7 +146,7 @@ SNES had. As you can guess, we get key state info from an IO register.</p>
|
|||
modern computer or console you do this with vsync info from the GPU and Monitor,
|
||||
and on the GBA we'll be using vsync info from an IO register that tracks what
|
||||
the display hardware is doing.</p>
|
||||
<p>As a way to apply our knowledge We'll make a simply "light cycle" game where
|
||||
<p>As a way to apply our knowledge We'll make a simple "light cycle" game where
|
||||
your dot leaves a trail behind them and you die if you go off the screen or if
|
||||
you touch your own trail. We just make a copy of <code>hello2.rs</code> named
|
||||
<code>light_cycle.rs</code> and then fill it in as we go through the chapter. Normally you
|
||||
|
|
|
@ -225,10 +225,10 @@ fn main(_argc: isize, _argv: *const *const u8) -> isize {
|
|||
their light cycle. Then we enter the core loop.</p>
|
||||
<p>We read the keys for input, and then do as much as we can without touching video
|
||||
memory. Since we're using video memory as the place to store the player's light
|
||||
trail, we can't do much, we just update their position and wait for vblank to
|
||||
trail, we can't do much, we just update their position and wait for VBlank to
|
||||
start. The player will be a 2x2 square, so the arrows will move you 2 pixels per
|
||||
frame.</p>
|
||||
<p>Once we're in vblank we check to see what kind of drawing we're doing. If the
|
||||
<p>Once we're in VBlank we check to see what kind of drawing we're doing. If the
|
||||
player has gone out of bounds, we clear the screen, rotate their color, and then
|
||||
reset their position. Why rotate the color? Just because it's fun to have
|
||||
different colors.</p>
|
||||
|
|
|
@ -139,7 +139,7 @@
|
|||
<a class="header" href="#the-key-input-register" id="the-key-input-register"><h1>The Key Input Register</h1></a>
|
||||
<p>The Key Input Register is our next IO register. Its shorthand name is
|
||||
<a href="http://problemkaputt.de/gbatek.htm#gbakeypadinput">KEYINPUT</a> and it's a <code>u16</code>
|
||||
at <code>0x4000130</code>. The entire register is obviosuly read only, you can't tell the
|
||||
at <code>0x4000130</code>. The entire register is obviously read only, you can't tell the
|
||||
GBA what buttons are pressed.</p>
|
||||
<p>Each button is exactly one bit:</p>
|
||||
<table><thead><tr><th align="center"> Bit </th><th align="center"> Button </th></tr></thead><tbody>
|
||||
|
|
|
@ -160,9 +160,9 @@ BIOS calls yet, so we'll do the basic thing for now and then upgrade later.</li>
|
|||
tiny pointer left to right across each pixel row one pixel at a time. When it's
|
||||
within the actual screen width (240px) it's drawing out those pixels. Then it
|
||||
goes <em>past</em> the edge of the screen for 68px during a period known as the
|
||||
"horizontal blank" (hblank). Then it starts on the next row and does that loop
|
||||
"horizontal blank" (HBlank). Then it starts on the next row and does that loop
|
||||
over again. This happens for the whole screen height (160px) and then once again
|
||||
it goes past the last row for another 68px into a "vertical blank" (vblank)
|
||||
it goes past the last row for another 68px into a "vertical blank" (VBlank)
|
||||
period.</p>
|
||||
<ul>
|
||||
<li>One pixel is 4 CPU cycles</li>
|
||||
|
@ -170,7 +170,7 @@ period.</p>
|
|||
<li>VDraw is 150 scanlines, VBlank is 68 scanlines (280,896 cycles per full refresh)</li>
|
||||
</ul>
|
||||
<p>Now you may remember some stuff from the display control register section where
|
||||
it was mentioned that some parts of memory are best accessed during vblank, and
|
||||
it was mentioned that some parts of memory are best accessed during VBlank, and
|
||||
also during hblank with a setting applied. These blanking periods are what was
|
||||
being talked about. At other times if you attempt to access video or object
|
||||
memory you (the CPU) might try touching the same memory that the display device
|
||||
|
@ -189,7 +189,7 @@ pub fn read_vcount() -> u16 {
|
|||
unsafe { VCOUNT.read_volatile() }
|
||||
}
|
||||
#}</code></pre></pre>
|
||||
<p>Then we want two little helper functions to wait until vblank and vdraw.</p>
|
||||
<p>Then we want two little helper functions to wait until VBlank and vdraw.</p>
|
||||
<pre><pre class="playpen"><code class="language-rust">
|
||||
# #![allow(unused_variables)]
|
||||
#fn main() {
|
||||
|
|
|
@ -556,7 +556,7 @@ the maximum sprites per scanline, so it's not default.</p>
|
|||
(off) or 1d (on). This particular control can be kinda tricky to wrap your head
|
||||
around, so we'll be sure to have some extra diagrams in the chapter that deals
|
||||
with it.</p>
|
||||
<p>Bit 7 forces the screen to stay in vblank as long as it's set. This allows the
|
||||
<p>Bit 7 forces the screen to stay in VBlank as long as it's set. This allows the
|
||||
fastest use of the VRAM, Palette, and Object Attribute Memory. Obviously if you
|
||||
leave this on for too long the player will notice a blank screen, but it might
|
||||
be okay to use for a moment or two every once in a while.</p>
|
||||
|
@ -588,10 +588,10 @@ nothing else special.</p>
|
|||
newtyping as we attempt a <code>hello2</code> program.</p>
|
||||
<a class="header" href="#video-memory-intro" id="video-memory-intro"><h1>Video Memory Intro</h1></a>
|
||||
<p>The GBA's Video RAM is 96k stretching from <code>0x0600_0000</code> to <code>0x0601_7FFF</code>.</p>
|
||||
<p>The Video RAM can only be accessed totally freely during a Vertical Blank
|
||||
(aka "vblank"). At other times, if the CPU tries to touch the same part of video
|
||||
memory as the display controller is accessing then the CPU gets bumped by a
|
||||
cycle to avoid a clash.</p>
|
||||
<p>The Video RAM can only be accessed totally freely during a Vertical Blank (aka
|
||||
"VBlank", though sometimes I forget and don't capitalize it properly). At other
|
||||
times, if the CPU tries to touch the same part of video memory as the display
|
||||
controller is accessing then the CPU gets bumped by a cycle to avoid a clash.</p>
|
||||
<p>Annoyingly, VRAM can only be properly written to in 16 and 32 bit segments (same
|
||||
with PALRAM and OAM). If you try to write just an 8 bit segment, then both parts
|
||||
of the 16 bit segment get the same value written to them. In other words, if you
|
||||
|
@ -787,7 +787,7 @@ other elements all labeled and sorted out for you. Still, for educational
|
|||
purposes it's often best to do it yourself at least once.</p>
|
||||
<a class="header" href="#ch-2-user-input" id="ch-2-user-input"><h1>Ch 2: User Input</h1></a>
|
||||
<p>It's all well and good to draw three pixels, but they don't do anything yet. We
|
||||
want them to to something, and for that we need to get some input from the user.</p>
|
||||
want them to do something, and for that we need to get some input from the user.</p>
|
||||
<p>The GBA, as I'm sure you know, has an arrow pad, A and B, L and R, Start and
|
||||
Select. That's a little more than the NES/GB/CGB had, and a little less than the
|
||||
SNES had. As you can guess, we get key state info from an IO register.</p>
|
||||
|
@ -795,7 +795,7 @@ SNES had. As you can guess, we get key state info from an IO register.</p>
|
|||
modern computer or console you do this with vsync info from the GPU and Monitor,
|
||||
and on the GBA we'll be using vsync info from an IO register that tracks what
|
||||
the display hardware is doing.</p>
|
||||
<p>As a way to apply our knowledge We'll make a simply "light cycle" game where
|
||||
<p>As a way to apply our knowledge We'll make a simple "light cycle" game where
|
||||
your dot leaves a trail behind them and you die if you go off the screen or if
|
||||
you touch your own trail. We just make a copy of <code>hello2.rs</code> named
|
||||
<code>light_cycle.rs</code> and then fill it in as we go through the chapter. Normally you
|
||||
|
@ -806,7 +806,7 @@ organized" for the long term.</p>
|
|||
<a class="header" href="#the-key-input-register" id="the-key-input-register"><h1>The Key Input Register</h1></a>
|
||||
<p>The Key Input Register is our next IO register. Its shorthand name is
|
||||
<a href="http://problemkaputt.de/gbatek.htm#gbakeypadinput">KEYINPUT</a> and it's a <code>u16</code>
|
||||
at <code>0x4000130</code>. The entire register is obviosuly read only, you can't tell the
|
||||
at <code>0x4000130</code>. The entire register is obviously read only, you can't tell the
|
||||
GBA what buttons are pressed.</p>
|
||||
<p>Each button is exactly one bit:</p>
|
||||
<table><thead><tr><th align="center"> Bit </th><th align="center"> Button </th></tr></thead><tbody>
|
||||
|
@ -1024,9 +1024,9 @@ BIOS calls yet, so we'll do the basic thing for now and then upgrade later.</li>
|
|||
tiny pointer left to right across each pixel row one pixel at a time. When it's
|
||||
within the actual screen width (240px) it's drawing out those pixels. Then it
|
||||
goes <em>past</em> the edge of the screen for 68px during a period known as the
|
||||
"horizontal blank" (hblank). Then it starts on the next row and does that loop
|
||||
"horizontal blank" (HBlank). Then it starts on the next row and does that loop
|
||||
over again. This happens for the whole screen height (160px) and then once again
|
||||
it goes past the last row for another 68px into a "vertical blank" (vblank)
|
||||
it goes past the last row for another 68px into a "vertical blank" (VBlank)
|
||||
period.</p>
|
||||
<ul>
|
||||
<li>One pixel is 4 CPU cycles</li>
|
||||
|
@ -1034,7 +1034,7 @@ period.</p>
|
|||
<li>VDraw is 150 scanlines, VBlank is 68 scanlines (280,896 cycles per full refresh)</li>
|
||||
</ul>
|
||||
<p>Now you may remember some stuff from the display control register section where
|
||||
it was mentioned that some parts of memory are best accessed during vblank, and
|
||||
it was mentioned that some parts of memory are best accessed during VBlank, and
|
||||
also during hblank with a setting applied. These blanking periods are what was
|
||||
being talked about. At other times if you attempt to access video or object
|
||||
memory you (the CPU) might try touching the same memory that the display device
|
||||
|
@ -1053,7 +1053,7 @@ pub fn read_vcount() -> u16 {
|
|||
unsafe { VCOUNT.read_volatile() }
|
||||
}
|
||||
#}</code></pre></pre>
|
||||
<p>Then we want two little helper functions to wait until vblank and vdraw.</p>
|
||||
<p>Then we want two little helper functions to wait until VBlank and vdraw.</p>
|
||||
<pre><pre class="playpen"><code class="language-rust">
|
||||
# #![allow(unused_variables)]
|
||||
#fn main() {
|
||||
|
@ -1158,10 +1158,10 @@ fn main(_argc: isize, _argv: *const *const u8) -> isize {
|
|||
their light cycle. Then we enter the core loop.</p>
|
||||
<p>We read the keys for input, and then do as much as we can without touching video
|
||||
memory. Since we're using video memory as the place to store the player's light
|
||||
trail, we can't do much, we just update their position and wait for vblank to
|
||||
trail, we can't do much, we just update their position and wait for VBlank to
|
||||
start. The player will be a 2x2 square, so the arrows will move you 2 pixels per
|
||||
frame.</p>
|
||||
<p>Once we're in vblank we check to see what kind of drawing we're doing. If the
|
||||
<p>Once we're in VBlank we check to see what kind of drawing we're doing. If the
|
||||
player has gone out of bounds, we clear the screen, rotate their color, and then
|
||||
reset their position. Why rotate the color? Just because it's fun to have
|
||||
different colors.</p>
|
||||
|
|
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue