Fix relative links in Markdown docs

README.md

@@ -19,7 +19,7 @@ It is generated from the man pages found in this repository.
 The source code of the website itself is on GitHub as well under the repository
 [rgbds-www](https://github.com/gbdev/rgbds-www).
 
-If you want to contribute or maintain RGBDS, please read [our contribution guide](docs/CONTRIBUTING.md).
+If you want to contribute or maintain RGBDS, please read [our contribution guide](/docs/CONTRIBUTING.md).
 If you have questions regarding the code, its organization, etc. you can find the maintainers
 [on the GBDev community channels](https://gbdev.io/chat) or via mail at `rgbds at gbdev dot io`.
 

docs/ARCHITECTURE.md

@@ -208,7 +208,7 @@ These files have been copied ("vendored") from external authors and adapted for
   Grammar for the RGBASM assembly language, which Bison preprocesses into a [LALR(1) parser](https://en.wikipedia.org/wiki/LALR_parser).  
   The Bison-generated parser calls `yylex` (defined in `lexer.cpp`) to get the next token, and calls `yywrap` (defined in `fstack.cpp`) when the current context is out of tokens and returns `EOF`.
 - **`rpn.cpp`:**  
-  `Expression` methods and data related to "[RPN](https://en.wikipedia.org/wiki/Reverse_Polish_notation)" expressions. When a numeric expression is parsed, if its value cannot be calculated at assembly time, it is built up into a buffer of RPN-encoded operations to do so at link time by RGBLINK. The valid RPN operations are defined in [man/rgbds.5](man/rgbds.5).
+  `Expression` methods and data related to "[RPN](https://en.wikipedia.org/wiki/Reverse_Polish_notation)" expressions. When a numeric expression is parsed, if its value cannot be calculated at assembly time, it is built up into a buffer of RPN-encoded operations to do so at link time by RGBLINK. The valid RPN operations are defined in [man/rgbds.5](/man/rgbds.5).
 - **`section.cpp`:**  
   Functions and data related to `SECTION`s.  
   This file *owns* the `Section`s in its `sections` collection. It also maintains various static pointers to those sections, including the `currentSection`, `currentLoadSection`, and `sectionStack` (which is affected by `PUSHS` and `POPS` directives). (Note that sections cannot be deleted.)
@@ -283,7 +283,7 @@ These files have been copied ("vendored") from external authors and adapted for
   Functions and data related to outputting ROM files (with `-o/--output`), symbol files (with `-n/--sym`), and map files (with `-m/--map`).  
   This file *references* some `Symbol`s and `Section`s, in collections that keep them sorted by address and name, which allows the symbol and map output to be in order.
 - **`patch.cpp`:**  
-  Functions and data related to "[RPN](https://en.wikipedia.org/wiki/Reverse_Polish_notation)" expression patches read from the object files, including the ones for `ASSERT` conditions. After sections have been assigned specific locations, the RPN patches can have their values calculated and applied to the ROM. The valid RPN operations are defined in [man/rgbds.5](man/rgbds.5).  
+  Functions and data related to "[RPN](https://en.wikipedia.org/wiki/Reverse_Polish_notation)" expression patches read from the object files, including the ones for `ASSERT` conditions. After sections have been assigned specific locations, the RPN patches can have their values calculated and applied to the ROM. The valid RPN operations are defined in [man/rgbds.5](/man/rgbds.5).  
   This file *owns* the `Assertion`s in its `assertions` collection, and the `RPNStackEntry`s in its `rpnStack` collection.
 - **`script.y`:**  
   Grammar for the linker script language, which Bison preprocesses into a [LALR(1) parser](https://en.wikipedia.org/wiki/LALR_parser).  

docs/CONTRIBUTING.md

@@ -36,7 +36,7 @@ implement it yourself, you can always contribute to RGBDS with your own code.
 ## Contributing code
 
 Thank you! Code contributions are the most appreciated.
-You can find a description of the project's layout in [`ARCHITECTURE.md`](ARCHITECTURE.md).
+You can find a description of the project's layout in [`ARCHITECTURE.md`](/ARCHITECTURE.md).
 
 If you want to contribute with your own code, whether it is to fix a current
 issue or to add something that nobody had requested, you should first consider
@@ -264,7 +264,7 @@ docker push ghcr.io/gbdev/rgbds:master
 
 ## Publishing a new release
 
-Please refer to [`RELEASE.md`](RELEASE.md).
+Please refer to [`RELEASE.md`](/RELEASE.md).
 
 ## Closing remarks
 

docs/RELEASE.md

@@ -6,23 +6,24 @@ GitHub.
 1. Update the following files, then commit and push.
    You can use <code>git commit -m "Release <i>&lt;version&gt;</i>"</code> and `git push origin master`.
 
-   - [include/version.hpp](include/version.hpp): set appropriate values for `PACKAGE_VERSION_MAJOR`,
+   - [include/version.hpp](/include/version.hpp): set appropriate values for `PACKAGE_VERSION_MAJOR`,
      `PACKAGE_VERSION_MINOR`, `PACKAGE_VERSION_PATCH`, and `PACKAGE_VERSION_RC`.
      **Only** define `PACKAGE_VERSION_RC` if you are publishing a release candidate!
-   - [Dockerfile](Dockerfile): update `ARG version`.
+   - [Dockerfile](/Dockerfile): update `ARG version`.
-   - [test/external/*.cfg](test/external): update test dependency commits
+   - [test/external/\*.cfg](/test/external): update test dependency commits
      (preferably, use the latest available).
-   - [man/\*](man/): update dates and authors.
+   - [man/\*](/man/): update dates and authors.
 
 2. Create a Git tag formatted as <code>v<i>&lt;MAJOR&gt;</i>.<i>&lt;MINOR&gt;</i>.<i>&lt;PATCH&gt;</i></code>,
    or <code>v<i>&lt;MAJOR&gt;</i>.<i>&lt;MINOR&gt;</i>.<i>&lt;PATCH&gt;</i>-rc<i>&lt;RC&gt;</i></code>
    for a release candidate. <code><i>MAJOR</i></code>, <code><i>MINOR</i></code>,
    <code><i>PATCH</i></code>, and <code><i>RC</i></code> should match their values from
-   [include/version.hpp](include/version.hpp). You can use <code>git tag <i>&lt;tag&gt;</i></code>.
+   [include/version.hpp](/include/version.hpp). You can use <code>git tag <i>&lt;tag&gt;</i></code>.
 
 3. Push the tag to GitHub. You can use <code>git push origin <i>&lt;tag&gt;</i></code>.
 
-   GitHub Actions will run the [create-release-artifacts.yaml](.github/workflows/create-release-artifacts.yaml)
+   GitHub Actions will run the
+   [create-release-artifacts.yml](/.github/workflows/create-release-artifacts.yml)
    workflow to detect the tag starting with "`v[0-9]`" and automatically do the following:
 
    1. Build 32-bit and 64-bit RGBDS binaries for Windows with `cmake`.
@@ -38,7 +39,7 @@ GitHub.
       procedure. You can use <code>git push --delete origin <i>&lt;tag&gt;</i></code> and
       <code>git tag --delete <i>&lt;tag&gt;</i></code>.
 
-4. GitHub Actions will run the [create-release-docs.yml](.github/workflows/create-release-docs.yml)
+4. GitHub Actions will run the [create-release-docs.yml](/.github/workflows/create-release-docs.yml)
    workflow to add the release documentation to [rgbds-www](https://github.com/gbdev/rgbds-www).
 
    This is not done automatically for prereleases, since we do not normally publish documentation