diff options
| -rw-r--r-- | README.md | 16 | ||||
| -rw-r--r-- | basics/README.md | 4 | ||||
| -rw-r--r-- | scroll/include/globals.s | 2 |
3 files changed, 11 insertions, 11 deletions
@@ -13,9 +13,9 @@ available in the `out` directory. Before doing that, though, you will need a compiler for the 6502 platform. A good option is [cc65](https://github.com/cc65/cc65), which is available on all major platforms, and if you are feeling adventurous you can check out -[nasm](https://github.com/mssola/tools.nes). By default the Makefile uses `cc65` -but if you want to use another compiler you can pass the `CC65` and `CCOPTS` -variables to the Makefile. +[nasm](https://git.mssola.com/nes/tools.nes). By default the Makefile uses +`cc65` but if you want to use another compiler you can pass the `CC65` and +`CCOPTS` variables to the Makefile. After that, it's recommended that you run the ROMs with an emulator with debugging support or at least some form of memory visualization. This is because @@ -45,11 +45,11 @@ The examples are distributed like this: ## Other projects -- Full games: [jetpac.nes](https://github.com/mssola/jetpac.nes). -- Libraries: [list.nes](https://github.com/mssola/list.nes). -- Misc: [Advent of Code 2023](https://github.com/mssola/aoc2023.nes). -- Tooling: [tools.nes](https://github.com/mssola/tools.nes). -- [Code style](https://github.com/mssola/style.nes) that I'm trying to follow here. +- Full games: [jetpac.nes](https://git.mssola.com/nes/jetpac.nes). +- Libraries: [list.nes](https://git.mssola.com/nes/list.nes). +- Misc: [Advent of Code 2023](https://git.mssola.com/nes/aoc2023.nes). +- Tooling: [tools.nes](https://git.mssola.com/nes/tools.nes). +- [Code style](https://git.mssola.com/nes/style.nes) that I'm trying to follow here. ## License diff --git a/basics/README.md b/basics/README.md index 3ffb285..61f33a8 100644 --- a/basics/README.md +++ b/basics/README.md @@ -54,7 +54,7 @@ aware about the priorities of your game: the player's convenience. 2. Is there a way to lay out the OAM memory in a way in which we always get the proper results without having to re-arrange objects on the OAM? Imagine a - very simple game such as [jetpac.nes](https://github.com/mssola/jetpac.nes), + very simple game such as [jetpac.nes](https://git.mssola.com/nes/jetpac.nes), in which we know in advance the slots for enemies, bonuses, etc. ## Showing a sprite through CHR-RAM instead of CHR-ROM @@ -84,7 +84,7 @@ have the foundations for `chr-ram.s`, which will use one of the banks for the assets, and then upon initialization move it to RAM. The result is the same as with `sprite.s`, but the goal of this example is to appreciate the technique and understand when it's useful. - + ## Persisting memory Another area explored here is a way to persist data across runs. This was diff --git a/scroll/include/globals.s b/scroll/include/globals.s index 87a93ea..e659201 100644 --- a/scroll/include/globals.s +++ b/scroll/include/globals.s @@ -1,7 +1,7 @@ ;; Global variables used throughout the code base. .scope Globals ;;; - ;; Argument values as defined in https://github.com/mssola/style.nes. Note + ;; Argument values as defined in https://git.mssola.com/nes/style.nes. Note ;; that these variables can also be used as temporary variables. zp_arg0 = $90 zp_arg1 = $91 |