Consistently link to the latest RGBDS docs

src/part1/assembly.md

@@ -117,7 +117,7 @@ Before the first `SECTION` directive, there is no "active" section, and thus gen
 
 The new section's name is "`Header`".
 Section names can contain any characters (and even be empty, if you want), and must be unique[^sect_name].
-The `ROM0` keyword indicates which "memory type" the section belongs to ([here is a list](https://rgbds.gbdev.io/docs/v0.5.2/rgbasm.5#SECTIONS)).
+The `ROM0` keyword indicates which "memory type" the section belongs to ([here is a list](https://rgbds.gbdev.io/docs/rgbasm.5#SECTIONS)).
 We will discuss them in Part Ⅱ.
 
 The `[$100]` part is more interesting, in that it is unique to this section.

src/part1/memory.md

@@ -80,7 +80,7 @@ The curious reader will naturally ask, "What about the remaining 7776 bytes? Wha
 Okay, memory addresses are nice, but you can't possibly expect me to keep track of all these addresses manually, right??
 Well, fear not, for we have labels!
 
-Labels are [symbols](https://rgbds.gbdev.io/docs/v0.5.1/rgbasm.5#SYMBOLS) which basically allow attaching a name to a byte of memory.
+Labels are [symbols](https://rgbds.gbdev.io/docs/rgbasm.5#SYMBOLS) which basically allow attaching a name to a byte of memory.
 A label is declared like at line {{#line_no_of "^\s*EntryPoint:" ../assets/hello-world.asm}} (`EntryPoint:`): at the beginning of the line, write the label's name, followed by a colon, and it will refer to the byte right after itself.
 So, for example, `EntryPoint` refers to the `ld a, 0` right below it (more accurately, the first byte of that instruction, but we will get there when we get there).
 

src/part2/bcd.md

@@ -48,7 +48,7 @@ So far so good, but what if the score was 9 and we add 1? The processor thinks i
 `%00001001` + `%00000001` = `%00001010` = `$A`
 
 That's a hexadecimal representation of 10, and we need to adjust it to become decimal. `DAA` or "Decimal Adjust after Addition," does just that.
-After executing `DAA` our accumulator will be adjusted from `%00001010` to `%00010000`; a 1 in the left nibble and a 0 in the right one. `DAA`'s exact behaviour is described [here](https://rgbds.gbdev.io/docs/master/gbz80.7#DAA).
+After executing `DAA` our accumulator will be adjusted from `%00001010` to `%00010000`; a 1 in the left nibble and a 0 in the right one. `DAA`'s exact behaviour is described [here](https://rgbds.gbdev.io/docs/gbz80.7#DAA).
 
 But why do we increment A using `ADD 1` when `INC A` does the same but is more efficient? That's because `DAA` evaluates the carry flag (see the linked description), but unlike `ADD`, `INC` does not affect that flag. So if the carry flag was still set from a previous operation<!-- note: this cannot happen right now, since IncreaseScorePackedBCD is only ever called after CP set the zero flag, which excludes setting the carry flag -->, `DAA` would add 60 points.
 

src/part2/getting-started.md

@@ -99,7 +99,7 @@ Each character defines a single pixel, intuitively from left to right; it must b
 
 :::tip
 
-If the character selection isn't to your liking, you can use [RGBASM's `-g` option](https://rgbds.gbdev.io/docs/v0.5.2/rgbasm.1#g) or [`OPT g`](https://rgbds.gbdev.io/docs/v0.5.2/rgbasm.5/#Changing_options_while_assembling) to pick others.
+If the character selection isn't to your liking, you can use [RGBASM's `-g` option](https://rgbds.gbdev.io/docs/rgbasm.1#g) or [`OPT g`](https://rgbds.gbdev.io/docs/rgbasm.5/#Changing_options_while_assembling) to pick others.
 For example, `rgbasm -g '.xXO' (...)` or `OPT g.xXO` would swap the four characters to `.`, `x`, `X`, and `O` respectively.
 
 :::

src/part3/project-structure.md

@@ -73,9 +73,9 @@ These images were originally created in Aseprite. The original templates are als
 
 > The **`rgbgfx`** program converts PNG images into data suitable for display on the Game Boy and Game Boy Color, or vice-versa.
 >
-> The main function of **`rgbgfx`** is to divide the input PNG into 8×8 pixel *[squares](https://rgbds.gbdev.io/docs/v0.6.1/rgbgfx.1#squares)*, convert each of those squares into 1bpp or 2bpp tile data, and save all of the tile data in a file. It also has options to generate a tile map, attribute map, and/or palette set as well; more on that and how the conversion process can be tweaked below.
+> The main function of **`rgbgfx`** is to divide the input PNG into 8×8 pixel *[squares](https://rgbds.gbdev.io/docs/rgbgfx.1#squares)*, convert each of those squares into 1bpp or 2bpp tile data, and save all of the tile data in a file. It also has options to generate a tile map, attribute map, and/or palette set as well; more on that and how the conversion process can be tweaked below.
 
-RGBGFX can be found here: [https://rgbds.gbdev.io/docs/v0.6.1/rgbgfx.1](https://rgbds.gbdev.io/docs/v0.6.1/rgbgfx.1)
+RGBGFX can be found here: [https://rgbds.gbdev.io/docs/rgbgfx.1](https://rgbds.gbdev.io/docs/rgbgfx.1)
 
 We'll use it to convert all of our graphics to .2bpp, and .tilemap formats (binary files)
 
@@ -98,7 +98,7 @@ From there, INCBIN commands are used to store reference the binary tile data.
 
 :::tip Including binary files
 
-You probably have some graphics, level data, etc. you'd like to include. Use **`INCBIN`** to include a raw binary file as it is. If the file isn't found in the current directory, the include-path list passed to [rgbasm(1)](https://rgbds.gbdev.io/docs/v0.6.1/rgbasm.1) (see the **`-i`** option) on the command line will be searched.
+You probably have some graphics, level data, etc. you'd like to include. Use **`INCBIN`** to include a raw binary file as it is. If the file isn't found in the current directory, the include-path list passed to [rgbasm(1)](https://rgbds.gbdev.io/docs/rgbasm.1) (see the **`-i`** option) on the command line will be searched.
 
 ```
 INCBIN "titlepic.bin"
@@ -113,7 +113,7 @@ INCBIN "data.bin",78,256
 
 The length argument is optional. If only the start position is specified, the bytes from the start position until the end of the file will be included.
 
-See also: [Including binary files - RGBASM documentation](https://rgbds.gbdev.io/docs/v0.6.1/rgbasm.5#Including_binary_files)
+See also: [Including binary files - RGBASM documentation](https://rgbds.gbdev.io/docs/rgbasm.5#Including_binary_data_files)
 
 :::