aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--README.md21
-rw-r--r--scroll/README.md23
2 files changed, 29 insertions, 15 deletions
diff --git a/README.md b/README.md
index 17a24a6..5c4e800 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,10 @@
-Examples for the Famicom/NES. These examples are not full blown games nor
-standalone projects. Rather, they should be seen as learning material and
-experiments. If you want to check out standalone projects that I have written,
-check out [this list](#other-projects).
+Hacking the Famicom/NES just for the fun of it :)
+
+This repository contains a set of examples and experiments which target the
+Famicom/NES. These examples are not full blown games nor standalone projects.
+Rather, they should be seen as learning material and experiments. If you want to
+check out standalone projects that I have written, check out the list on [Other
+projects](#other-projects).
## Build
@@ -17,7 +20,7 @@ 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
some examples have nothing to show for other than updating some values on the
-NES memory. A safe bet is to go with either
+Famicom/NES memory. A safe bet is to go with either
[fceux](https://fceux.com/web/home.html) or
[Mesen](https://github.com/SourMesen/Mesen2/), which provide tools like RAM
watchers or a full debugger.
@@ -26,10 +29,10 @@ watchers or a full debugger.
The examples are distributed like this:
-- [basics](./basics/README.md): simple examples which cover basic stuff for NES
- development. These examples are self-contained and supposed to be read by
- absolute newcomers. The description for each example is covered by an initial
- comment on each file.
+- [basics](./basics/README.md): simple examples which cover basic stuff for
+ Famicom/NES development. These examples are self-contained and supposed to be
+ read by absolute newcomers. The description for each example is covered by an
+ initial comment on each file.
- [space](./space/README.md): example in which you can move a spaceship with
subpixel movement and shoot bullets. Consider this an evolution from the
`basics/sprite.s` and `basics/input.s` examples. That is, we are no longer
diff --git a/scroll/README.md b/scroll/README.md
index e179d62..7f7c319 100644
--- a/scroll/README.md
+++ b/scroll/README.md
@@ -32,12 +32,23 @@ two cases:
It's easy to miss these points, but from a PPU perspective (and hence from the
perspective of a programmer interfacing with the PPU), it really makes sense.
All in all, the scroll register is relative to whatever base nametable is set on
-the control register.
-
-Overall, this example looks rather simplistic but some games used this
-technique. For example, in Dropzone it was used to perform some effects on the
-title screen. Hence, performing a simple scroll between two nametables is not
-just for learning purposes, it was also used in real life games.
+the control register. Note that games that scrolled diagonally like Super Mario
+Bros. 3 and Kirby's Adventure did not need to do this, since they were
+constantly wrapping on the same nametable. This is a more advanced topic, but it
+boils down to:
+
+1. Setup horizontal mirroring so we can scroll vertically (i.e. contrary to the
+ rest of examples from here).
+2. Mask out the leftmost 8 pixels (see bit 2 in the [PPU Mask
+ register](https://www.nesdev.org/wiki/PPU_registers#PPUMASK)).
+3. The "next" column will be put on the first one, which is always hidden by
+ step 2 and will only be visible when moving the PPU scroll register.
+
+Coming back to this first example, though, the approach being used here looks
+rather simplistic. That being said, some games used this technique. For example,
+in Dropzone it was used to perform some effects on the title screen. Hence,
+performing a simple scroll between two nametables is not just for learning
+purposes, it was also used in real life games.
## Scrolling multiple screens to the right