gbdev
diff --git a/‎src/SUMMARY.md‎
Lines changed: 2 additions & 0 deletions b/‎src/SUMMARY.md‎
Lines changed: 2 additions & 0 deletions
diff --git a/‎src/part2/functions.md‎
Lines changed: 65 additions & 0 deletions b/‎src/part2/functions.md‎
Lines changed: 65 additions & 0 deletions
diff --git a/‎src/part2/input.md‎
Lines changed: 31 additions & 0 deletions b/‎src/part2/input.md‎
Lines changed: 31 additions & 0 deletions
@@ -25,6 +25,8 @@
 
 - [Getting started](part2/getting-started.md)
 - [Objects](part2/objects.md)
+- [Functions](part2/functions.md)
+- [Input](part2/input.md)
 - [Work in progress](part2/wip.md)
 
 # Part Ⅲ — Our second game
 
@@ -0,0 +1,65 @@
+# Functions
+
+So far, we have only written a single "flow" of code, but we can already spot some snippets that look redundant.
+Let's use **functions** to "factor out" code!
+
+For example, in three places, we are copying chunks of memory around.
+Let's write a function below the `jp Main`, and let's call it `Memcpy`, like [the similar C function](https://man7.org/linux/man-pages/man3/memcpy.3.html):
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/functions/main.asm:memcpy}}
+{{#include ../../unbricked/functions/main.asm:memcpy}}
+```
+
+The new `ret` instruction should immediately catch our eye.
+It is, unsurprisingly, what makes execution *return* to where the function was *called* from.
+Importantly, many languages have a definite "end" to a function: in C or Rust, that's the closing brace `}`; in Pascal or Lua, the keyword `end`, and so on; the function implicitly returns when execution reaches its end.
+However, **this is not the case in assembly**, so you must remember to add a `ret` instruction at the end of the function to return from it!
+Otherwise, the results are unpredictable.
+
+Notice the comment above the function, explaining which registers it takes as input.
+This comment is important so that you know how to interface with the function; assembly has no formal parameters, so comments explaining them are even more important than with other languages.
+We'll see more of those as we progress.
+
+There are three places in the initialization code where we can use the `Memcpy` function.
+Find each of these copy loops and replace them with a call to `Memcpy`; for this, we use the `call` instruction.
+The registers serve as parameters to the function, so we'll leave them as-is.
+
+<div class="table-wrapper"><table><thead><tr><th>Before</th><th>After</th></tr></thead><tbody><tr><td>
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/getting-started/main.asm:copy_tiles}}
+{{#include ../../unbricked/getting-started/main.asm:copy_tiles}}
+```
+
+</td><td>
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/functions/main.asm:copy_tiles}}
+{{#include ../../unbricked/functions/main.asm:copy_tiles}}
+```
+
+</td></tr><tr><td>
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/getting-started/main.asm:copy_map}}
+{{#include ../../unbricked/getting-started/main.asm:copy_map}}
+```
+
+</td><td>
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/functions/main.asm:copy_map}}
+{{#include ../../unbricked/functions/main.asm:copy_map}}
+```
+
+</td></tr><tr><td>
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/objects/main.asm:copy-paddle}}
+{{#include ../../unbricked/objects/main.asm:copy-paddle}}
+```
+
+</td><td>
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/functions/main.asm:copy_paddle}}
+{{#include ../../unbricked/functions/main.asm:copy_paddle}}
+```
+
+</td></tr></tbody></table></div>
+
+In the next chapter, we'll write another function, this time to read player input.
@@ -0,0 +1,31 @@
+# Input
+
+We have the building blocks of a game here, but we're still lacking player input.
+A game that plays itself isn't very much fun, so let's fix that.
+
+Paste this code below your `Main` loop.
+Like `Memcpy`, this is a function that can be reused from different places, using the `call` instruction.
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/input/main.asm:input-routine}}
+{{#include ../../unbricked/input/main.asm:input-routine}}
+```
+
+Unfortunately, reading input on the Game Boy is fairly involved (as you can see!), and it would be quite difficult to explain what this function does right now.
+So, I ask that you make an exception, and trust me that this function *does* read input.
+Alright? Good!
+
+Now that we know how to use functions, let's call the `UpdateKeys` function in our main loop to read user input.
+`UpdateKeys` writes the held buttons to a location in memory that we called `wCurKeys`, which we can read from after the function returns.
+Because of this, we only need to call `UpdateKeys` once per frame.
+
+This is important, because not only is it faster to reload the inputs that we've already processed, but it also means that we will always act on the same inputs, even if the player presses or releases a button mid-frame.
+
+We're going to use the `and` opcode, which we can use to set the zero flag (`z`) to the value of the bit.
+We can use this along with the `PADF` constants in hardware.inc to read a particular key.
+
+```rgbasm,linenos,start={{#line_no_of "" ../../unbricked/input/main.asm:main}}
+{{#include ../../unbricked/input/main.asm:main}}
+```
+
+Now, if you compile the project, you should be able to move the paddle left and right using the d-pad!!
+Hooray, we have the beginnings of a game!