mirror of
https://github.com/italicsjenga/gba.git
synced 2024-12-25 11:41:30 +11:00
427 lines
25 KiB
HTML
427 lines
25 KiB
HTML
<!DOCTYPE HTML>
|
|
<html lang="en" class="sidebar-visible no-js">
|
|
<head>
|
|
<!-- Book generated using mdBook -->
|
|
<meta charset="UTF-8">
|
|
<title>GBA Memory Mapping - Rust GBA Guide</title>
|
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|
<meta name="description" content="">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<meta name="theme-color" content="#ffffff" />
|
|
|
|
<link rel="shortcut icon" href="../favicon.png">
|
|
<link rel="stylesheet" href="../css/variables.css">
|
|
<link rel="stylesheet" href="../css/general.css">
|
|
<link rel="stylesheet" href="../css/chrome.css">
|
|
<link rel="stylesheet" href="../css/print.css" media="print">
|
|
|
|
<!-- Fonts -->
|
|
<link rel="stylesheet" href="../FontAwesome/css/font-awesome.css">
|
|
<link href="https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800" rel="stylesheet" type="text/css">
|
|
<link href="https://fonts.googleapis.com/css?family=Source+Code+Pro:500" rel="stylesheet" type="text/css">
|
|
|
|
<!-- Highlight.js Stylesheets -->
|
|
<link rel="stylesheet" href="../highlight.css">
|
|
<link rel="stylesheet" href="../tomorrow-night.css">
|
|
<link rel="stylesheet" href="../ayu-highlight.css">
|
|
|
|
<!-- Custom theme stylesheets -->
|
|
|
|
|
|
|
|
</head>
|
|
<body class="light">
|
|
<!-- Provide site root to javascript -->
|
|
<script type="text/javascript">var path_to_root = "../";</script>
|
|
|
|
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
|
<script type="text/javascript">
|
|
try {
|
|
var theme = localStorage.getItem('mdbook-theme');
|
|
var sidebar = localStorage.getItem('mdbook-sidebar');
|
|
|
|
if (theme.startsWith('"') && theme.endsWith('"')) {
|
|
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
|
}
|
|
|
|
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
|
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
|
}
|
|
} catch (e) { }
|
|
</script>
|
|
|
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|
<script type="text/javascript">
|
|
var theme;
|
|
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
|
if (theme === null || theme === undefined) { theme = 'light'; }
|
|
document.body.className = theme;
|
|
document.querySelector('html').className = theme + ' js';
|
|
</script>
|
|
|
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|
<script type="text/javascript">
|
|
var html = document.querySelector('html');
|
|
var sidebar = 'hidden';
|
|
if (document.body.clientWidth >= 1080) {
|
|
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
|
sidebar = sidebar || 'visible';
|
|
}
|
|
html.classList.remove('sidebar-visible');
|
|
html.classList.add("sidebar-" + sidebar);
|
|
</script>
|
|
|
|
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
|
<ol class="chapter"><li><a href="../introduction.html"><strong aria-hidden="true">1.</strong> Introduction</a></li><li><a href="../ch00/index.html"><strong aria-hidden="true">2.</strong> Ch 0: Development Setup</a></li><li><a href="../ch01/index.html"><strong aria-hidden="true">3.</strong> Ch 1: Hello GBA</a></li><li><ol class="section"><li><a href="../ch01/hello1.html"><strong aria-hidden="true">3.1.</strong> hello1</a></li><li><a href="../ch01/volatile.html"><strong aria-hidden="true">3.2.</strong> Volatile</a></li><li><a href="../ch01/io_registers.html"><strong aria-hidden="true">3.3.</strong> IO Registers</a></li><li><a href="../ch01/the_display_control_register.html"><strong aria-hidden="true">3.4.</strong> The Display Control Register</a></li><li><a href="../ch01/video_memory_intro.html"><strong aria-hidden="true">3.5.</strong> Video Memory Intro</a></li><li><a href="../ch01/hello2.html"><strong aria-hidden="true">3.6.</strong> hello2</a></li></ol></li><li><a href="../ch02/index.html"><strong aria-hidden="true">4.</strong> Ch 2: User Input</a></li><li><ol class="section"><li><a href="../ch02/the_key_input_register.html"><strong aria-hidden="true">4.1.</strong> The Key Input Register</a></li><li><a href="../ch02/the_vcount_register.html"><strong aria-hidden="true">4.2.</strong> The VCount Register</a></li><li><a href="../ch02/light_cycle.html"><strong aria-hidden="true">4.3.</strong> light_cycle</a></li></ol></li><li><a href="../ch03/index.html"><strong aria-hidden="true">5.</strong> Ch 3: Memory and Objects</a></li><li><ol class="section"><li><a href="../ch03/gba_memory_mapping.html" class="active"><strong aria-hidden="true">5.1.</strong> GBA Memory Mapping</a></li><li><a href="../ch03/tile_data.html"><strong aria-hidden="true">5.2.</strong> Tile Data</a></li><li><a href="../ch03/regular_backgrounds.html"><strong aria-hidden="true">5.3.</strong> Regular Backgrounds</a></li><li><a href="../ch03/regular_objects.html"><strong aria-hidden="true">5.4.</strong> Regular Objects</a></li><li><a href="../ch03/gba_rng.html"><strong aria-hidden="true">5.5.</strong> GBA RNG</a></li><li><a href="../ch03/memory_game.html"><strong aria-hidden="true">5.6.</strong> memory_game</a></li></ol></li></ol>
|
|
</nav>
|
|
|
|
<div id="page-wrapper" class="page-wrapper">
|
|
|
|
<div class="page">
|
|
|
|
<div id="menu-bar" class="menu-bar">
|
|
<div id="menu-bar-sticky-container">
|
|
<div class="left-buttons">
|
|
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
|
<i class="fa fa-bars"></i>
|
|
</button>
|
|
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
|
<i class="fa fa-paint-brush"></i>
|
|
</button>
|
|
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
|
<li role="none"><button role="menuitem" class="theme" id="light">Light <span class="default">(default)</span></button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
|
</ul>
|
|
|
|
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
|
<i class="fa fa-search"></i>
|
|
</button>
|
|
|
|
</div>
|
|
|
|
<h1 class="menu-title">Rust GBA Guide</h1>
|
|
|
|
<div class="right-buttons">
|
|
<a href="../print.html" title="Print this book" aria-label="Print this book">
|
|
<i id="print-button" class="fa fa-print"></i>
|
|
</a>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
<div id="search-wrapper" class="hidden">
|
|
<form id="searchbar-outer" class="searchbar-outer">
|
|
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
|
</form>
|
|
<div id="searchresults-outer" class="searchresults-outer hidden">
|
|
<div id="searchresults-header" class="searchresults-header"></div>
|
|
<ul id="searchresults">
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
|
<script type="text/javascript">
|
|
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
|
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
|
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
|
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
|
});
|
|
</script>
|
|
|
|
<div id="content" class="content">
|
|
<main>
|
|
<a class="header" href="#gba-memory-mapping" id="gba-memory-mapping"><h1>GBA Memory Mapping</h1></a>
|
|
<p>The <a href="http://problemkaputt.de/gbatek.htm#gbamemorymap">GBA Memory Map</a> has
|
|
several memory portions to it, each with their own little differences. Most of
|
|
the memory has pre-determined use according to the hardware, but there is also
|
|
space for games to use as a scratch pad in whatever way the game sees fit.</p>
|
|
<p>The memory ranges listed here are <em>inclusive</em>, so they end with a lot of F's
|
|
and E's.</p>
|
|
<p>We've talked about volatile memory before, but just as a reminder I'll say that
|
|
all of the memory we'll talk about here should be accessed using volatile with
|
|
two exceptions:</p>
|
|
<ol>
|
|
<li>Work RAM (both internal and external) can be used normally, and if the
|
|
compiler is able to totally elide some reads and writes that's okay.</li>
|
|
<li>However, if you set aside any space in Work RAM where an interrupt will
|
|
communicate with the main program then that specific location will have to
|
|
keep using volatile access, since the compiler never knows when an interrupt
|
|
will actually happen.</li>
|
|
</ol>
|
|
<a class="header" href="#bios--system-rom" id="bios--system-rom"><h2>BIOS / System ROM</h2></a>
|
|
<ul>
|
|
<li><code>0x0</code> to <code>0x3FFF</code> (16k)</li>
|
|
</ul>
|
|
<p>This is special memory for the BIOS. It is "read-only", but even then it's only
|
|
accessible when the program counter is pointing into the BIOS region. At all
|
|
other times you get a <a href="http://problemkaputt.de/gbatek.htm#gbaunpredictablethings">garbage
|
|
value</a> back when you
|
|
try to read out of the BIOS.</p>
|
|
<a class="header" href="#external-work-ram--ewram" id="external-work-ram--ewram"><h2>External Work RAM / EWRAM</h2></a>
|
|
<ul>
|
|
<li><code>0x2000000</code> to <code>0x203FFFF</code> (256k)</li>
|
|
</ul>
|
|
<p>This is a big pile of space, the use of which is up to each game. However, the
|
|
external work ram has only a 16-bit bus (if you read/write a 32-bit value it
|
|
silently breaks it up into two 16-bit operations) and also 2 wait cycles (extra
|
|
CPU cycles that you have to expend <em>per 16-bit bus use</em>).</p>
|
|
<p>It's most helpful to think of EWRAM as slower, distant memory, similar to the
|
|
"heap" in a normal application. You can take the time to go store something
|
|
within EWRAM, or to load it out of EWRAM, but if you've got several operations
|
|
to do in a row and you're worried about time you should pull that value into
|
|
local memory, work on your local copy, and then push it back out to EWRAM.</p>
|
|
<a class="header" href="#internal-work-ram--iwram" id="internal-work-ram--iwram"><h2>Internal Work RAM / IWRAM</h2></a>
|
|
<ul>
|
|
<li><code>0x3000000</code> to <code>0x3007FFF</code> (32k)</li>
|
|
</ul>
|
|
<p>This is a smaller pile of space, but it has a 32-bit bus and no wait.</p>
|
|
<p>By default, <code>0x3007F00</code> to <code>0x3007FFF</code> is reserved for interrupt and BIOS use.
|
|
The rest of it is totally up to you. The user's stack space starts at
|
|
<code>0x3007F00</code> and proceeds <em>down</em> from there. For best results you should probably
|
|
start at <code>0x3000000</code> and then go upwards. Under normal use it's unlikely that
|
|
the two memory regions will crash into each other.</p>
|
|
<a class="header" href="#io-registers" id="io-registers"><h2>IO Registers</h2></a>
|
|
<ul>
|
|
<li><code>0x4000000</code> to <code>0x40003FE</code></li>
|
|
</ul>
|
|
<p>We've touched upon a few of these so far, and we'll get to more later. At the
|
|
moment it is enough to say that, as you might have guessed, all of them live in
|
|
this region. Each individual register is a <code>u16</code> or <code>u32</code> and they control all
|
|
sorts of things. We'll actually be talking about some more of them in this very
|
|
chapter, because that's how we'll control some of the background and object
|
|
stuff.</p>
|
|
<a class="header" href="#palette-ram--palram" id="palette-ram--palram"><h2>Palette RAM / PALRAM</h2></a>
|
|
<ul>
|
|
<li><code>0x5000000</code> to <code>0x50003FF</code> (1k)</li>
|
|
</ul>
|
|
<p>Palette RAM has a 16-bit bus, which isn't really a problem because it
|
|
conceptually just holds <code>u16</code> values. There's no automatic wait state, but if
|
|
you try to access the same location that the display controller is accessing you
|
|
get bumped by 1 cycle. Since the display controller can use the palette ram any
|
|
number of times per scanline it's basically impossible to predict if you'll have
|
|
to do a wait or not during VDraw. During VBlank you won't have any wait of
|
|
course.</p>
|
|
<p>PALRAM is among the memory where there's weirdness if you try to write just one
|
|
byte: if you try to write just 1 byte, it writes that byte into <em>both</em> parts of
|
|
the larger 16-bit location. This doesn't really affect us much with PALRAM,
|
|
because palette values are all supposed to be <code>u16</code> anyway.</p>
|
|
<p>The palette memory actually contains not one, but <em>two</em> sets of palettes. First
|
|
there's 256 entries for the background palette data (starting at <code>0x5000000</code>),
|
|
and then there's 256 entries for object palette data (starting at <code>0x5000200</code>).</p>
|
|
<p>The GBA also has two modes for palette access: 8-bits-per-pixel (8bpp) and
|
|
4-bits-per-pixel (4bpp).</p>
|
|
<ul>
|
|
<li>In 8bpp mode an 8-bit palette index value within a background or sprite
|
|
simply indexes directly into the 256 slots for that type of thing.</li>
|
|
<li>In 4bpp mode a 4-bit palette index value within a background or sprite
|
|
specifies an index within a particular "palbank" (16 palette entries each),
|
|
and then a <em>separate</em> setting outside of the graphical data determines which
|
|
palbank is to be used for that background or object (the screen entry data for
|
|
backgrounds, and the object attributes for objects).</li>
|
|
</ul>
|
|
<a class="header" href="#transparency" id="transparency"><h3>Transparency</h3></a>
|
|
<p>When a pixel within a background or object specifies index 0 as its palette
|
|
entry it is treated as a transparent pixel. This means that in 8bpp mode there's
|
|
only 255 actual color options (0 being transparent), and in 4bpp mode there's
|
|
only 15 actual color options available within each palbank (the 0th entry of
|
|
<em>each</em> palbank is transparent).</p>
|
|
<p>Individual backgrounds, and individual objects, each determine if they're 4bpp
|
|
or 8bpp separately, so a given overall palette slot might map to a used color in
|
|
8bpp and an unused/transparent color in 4bpp. If you're a palette wizard.</p>
|
|
<p>Palette slot 0 of the overall background palette is used to determine the
|
|
"backdrop" color. That's the color you see if no background or object ends up
|
|
being rendered within a given pixel.</p>
|
|
<p>Since display mode 3 and display mode 5 don't use the palette, they cannot
|
|
benefit from transparency.</p>
|
|
<a class="header" href="#video-ram--vram" id="video-ram--vram"><h2>Video RAM / VRAM</h2></a>
|
|
<ul>
|
|
<li><code>0x6000000</code> to <code>0x6017FFF</code> (96k)</li>
|
|
</ul>
|
|
<p>We've used this before! VRAM has a 16-bit bus and no wait. However, the same as
|
|
with PALRAM, the "you might have to wait if the display controller is looking at
|
|
it" rule applies here.</p>
|
|
<p>Unfortunately there's not much more exact detail that can be given about VRAM.
|
|
The use of the memory depends on the video mode that you're using.</p>
|
|
<p>One general detail of note is that you can't write individual bytes to any part
|
|
of VRAM. Depending on mode and location, you'll either get your bytes doubled
|
|
into both the upper and lower parts of the 16-bit location targeted, or you
|
|
won't even affect the memory. This usually isn't a big deal, except in two
|
|
situations:</p>
|
|
<ul>
|
|
<li>In Mode 4, if you want to change just 1 pixel, you'll have to be very careful
|
|
to read the old <code>u16</code>, overwrite just the byte you wanted to change, and then
|
|
write that back.</li>
|
|
<li>In any display mode, avoid using <code>memcopy</code> to place things into VRAM.
|
|
It's written to be byte oriented, and only does 32-bit transfers under select
|
|
conditions. The rest of the time it'll copy one byte at a time and you'll get
|
|
either garbage or nothing at all.</li>
|
|
</ul>
|
|
<a class="header" href="#object-attribute-memory--oam" id="object-attribute-memory--oam"><h2>Object Attribute Memory / OAM</h2></a>
|
|
<ul>
|
|
<li><code>0x7000000</code> to <code>0x70003FF</code> (1k)</li>
|
|
</ul>
|
|
<p>The Object Attribute Memory has a 32-bit bus and no default wait, but suffers
|
|
from the "you might have to wait if the display controller is looking at it"
|
|
rule. You cannot write individual bytes to OAM at all, but that's not really a
|
|
problem because all the fields of the data types within OAM are either <code>i16</code> or
|
|
<code>u16</code> anyway.</p>
|
|
<p>Object attribute memory is the wildest yet: it conceptually contains two types
|
|
of things, but they're <em>interlaced</em> with each other all the way through.</p>
|
|
<p>Now, <a href="http://problemkaputt.de/gbatek.htm#lcdobjoamattributes">GBATEK</a> and
|
|
<a href="https://www.cs.rit.edu/%7Etjh8300/CowBite/CowBiteSpec.htm#OAM%20(sprites)">CowByte</a>
|
|
doesn't quite give names to the two data types here.
|
|
<a href="https://www.coranac.com/tonc/text/regobj.htm#sec-oam">TONC</a> calls them
|
|
<code>OBJ_ATTR</code> and <code>OBJ_AFFINE</code>, but we'll be giving them names fitting with the
|
|
Rust naming convention. Just know that if you try to talk about it with others
|
|
they might not be using the same names. In Rust terms their layout would look
|
|
like this:</p>
|
|
<pre><pre class="playpen"><code class="language-rust">
|
|
# #![allow(unused_variables)]
|
|
#fn main() {
|
|
#[repr(C)]
|
|
pub struct ObjectAttributes {
|
|
attr0: u16,
|
|
attr1: u16,
|
|
attr2: u16,
|
|
filler: i16,
|
|
}
|
|
|
|
#[repr(C)]
|
|
pub struct AffineMatrix {
|
|
filler0: [u16; 3],
|
|
pa: i16,
|
|
filler1: [u16; 3],
|
|
pb: i16,
|
|
filler2: [u16; 3],
|
|
pc: i16,
|
|
filler3: [u16; 3],
|
|
pd: i16,
|
|
}
|
|
#}</code></pre></pre>
|
|
<p>(Note: the <code>#[repr(C)]</code> part just means that Rust must lay out the data exactly
|
|
in the order we specify, which otherwise it is not required to do).</p>
|
|
<p>So, we've got 1024 bytes in OAM and each <code>ObjectAttributes</code> value is 8 bytes, so
|
|
naturally we can support up to 128 objects.</p>
|
|
<p><em>At the same time</em>, we've got 1024 bytes in OAM and each <code>AffineMatrix</code> is 32
|
|
bytes, so we can have 32 of them.</p>
|
|
<p>But, as I said, these things are all <em>interlaced</em> with each other. See how
|
|
there's "filler" fields in each struct? If we imagine the OAM as being just an
|
|
array of one type or the other, indexes 0/1/2/3 of the <code>ObjectAttributes</code> array
|
|
would line up with index 0 of the <code>AffineMatrix</code> array. It's kinda weird, but
|
|
that's just how it works. When we setup functions to read and write these values
|
|
we'll have to be careful with how we do it. We probably <em>won't</em> want to use
|
|
those representations above, at least not with the <code>AffineMatrix</code> type, because
|
|
they're quite wasteful if you want to store just object attributes or just
|
|
affine matrices.</p>
|
|
<a class="header" href="#game-pak-rom--flash-rom" id="game-pak-rom--flash-rom"><h2>Game Pak ROM / Flash ROM</h2></a>
|
|
<ul>
|
|
<li><code>0x8000000</code> to <code>0x9FFFFFF</code> (wait 0)</li>
|
|
<li><code>0xA000000</code> to <code>0xBFFFFFF</code> (wait 1)</li>
|
|
<li><code>0xC000000</code> to <code>0xDFFFFFF</code> (wait 2)</li>
|
|
<li>Max of 32Mb</li>
|
|
</ul>
|
|
<p>These portions of the memory are less fixed, because they depend on the precise
|
|
details of the game pak you've inserted into the GBA. In general, they connect
|
|
to the game pak ROM and/or Flash memory, using a 16-bit bus. The ROM is
|
|
read-only, but the Flash memory (if any) allows writes.</p>
|
|
<p>The game pak ROM is listed as being in three sections, but it's actually the
|
|
same memory being effectively mirrored into three different locations. The
|
|
mirror that you choose to access the game pak through affects which wait state
|
|
setting it uses (configured via IO register of course). Unfortunately, the
|
|
details come down more to the game pak hardware that you load your game onto
|
|
than anything else, so there's not much I can say right here. We'll eventually
|
|
talk about it more later when I'm forced to do the boring thing and just cover
|
|
all the IO registers that aren't covered anywhere else.</p>
|
|
<p>One thing of note is the way that the 16-bit bus affects us: the instructions to
|
|
execute are coming through the same bus as the rest of the game data, so we want
|
|
them to be as compact as possible. The ARM chip in the GBA supports two
|
|
different instruction sets, "thumb" and "non-thumb". The thumb mode instructions
|
|
are 16-bit, so they can each be loaded one at a time, and the non-thumb
|
|
instructions are 32-bit, so we're at a penalty if we execute them directly out
|
|
of the game pak. However, some things will demand that we use non-thumb code, so
|
|
we'll have to deal with that eventually. It's possible to switch between modes,
|
|
but it's a pain to keep track of what mode you're in because there's not
|
|
currently support for it in Rust itself (perhaps some day). So we'll stick with
|
|
thumb code as much as we possibly can, that's why our target profile for our
|
|
builds starts with <code>thumbv4</code>.</p>
|
|
<a class="header" href="#game-pak-sram" id="game-pak-sram"><h2>Game Pak SRAM</h2></a>
|
|
<ul>
|
|
<li><code>0xE000000</code> to <code>0xE00FFFF</code> (64k)</li>
|
|
</ul>
|
|
<p>The game pak SRAM has an 8-bit bus. Why did Pokémon always take so long to save?
|
|
Saving the whole game one byte at a time is why. The SRAM also has some amount
|
|
of wait, but as with the ROM, the details depend on your game pak hardware (and
|
|
also as with ROM, you can adjust the settings with an IO register, should you
|
|
need to).</p>
|
|
<p>One thing to note about the SRAM is that the GBA has a Direct Memory Access
|
|
(DMA) feature that can be used for bulk memory movements in some cases, but the
|
|
DMA <em>cannot</em> access the SRAM region. You really are stuck reading and writing
|
|
one byte at a time when you're using the SRAM.</p>
|
|
|
|
</main>
|
|
|
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|
<!-- Mobile navigation buttons -->
|
|
|
|
<a rel="prev" href="../ch03/index.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|
<i class="fa fa-angle-left"></i>
|
|
</a>
|
|
|
|
|
|
|
|
<a rel="next" href="../ch03/tile_data.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|
<i class="fa fa-angle-right"></i>
|
|
</a>
|
|
|
|
|
|
<div style="clear: both"></div>
|
|
</nav>
|
|
</div>
|
|
</div>
|
|
|
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|
|
|
<a href="../ch03/index.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|
<i class="fa fa-angle-left"></i>
|
|
</a>
|
|
|
|
|
|
|
|
<a href="../ch03/tile_data.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|
<i class="fa fa-angle-right"></i>
|
|
</a>
|
|
|
|
</nav>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<script src="../elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="../mark.min.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="../searcher.js" type="text/javascript" charset="utf-8"></script>
|
|
|
|
|
|
<script src="../clipboard.min.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="../highlight.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="../book.js" type="text/javascript" charset="utf-8"></script>
|
|
|
|
<!-- Custom JS scripts -->
|
|
|
|
|
|
|
|
|
|
</body>
|
|
</html>
|