diff --git a/devkitpro-pacman.deb b/devkitpro-pacman.deb new file mode 100644 index 0000000..ad9aac7 Binary files /dev/null and b/devkitpro-pacman.deb differ diff --git a/docs/ch00/index.html b/docs/ch00/index.html index 7d13b49..2806b5e 100644 --- a/docs/ch00/index.html +++ b/docs/ch00/index.html @@ -165,10 +165,11 @@ reason, you'll still want devkitpro for the gbafix utility.

C:\devkitpro\tools\bin to be added to your PATH, depending on where you installed it to and such. -
  • On Linux you'll also want it to be added to your path, but if you're using -Linux I'll just assume you know how to do all that. I'm told that the default -installation path is /opt/devkitpro/devkitARM/bin, so look there first if -you didn't select some other place.
  • +
  • On Linux you can use pacman to get it, and the default install puts the stuff +in /opt/devkitpro/devkitARM/bin and /opt/devkitpro/tools/bin. If you need +help you can look in our repository's +.travis.yml +file to see exactly what our CI does.
  • Finally, you'll need cargo-xbuild. Just run cargo install cargo-xbuild and cargo will figure it all out for you.

    diff --git a/docs/ch03/gba_memory_mapping.html b/docs/ch03/gba_memory_mapping.html index 65649dc..566dd94 100644 --- a/docs/ch03/gba_memory_mapping.html +++ b/docs/ch03/gba_memory_mapping.html @@ -141,14 +141,14 @@ several memory portions to it, each with their own little differences. Most of the memory has pre-determined use according to the hardware, but there is also space for games to use as a scratch pad in whatever way the game sees fit.

    -

    The memory ranges listed here are inclusive, so they end with a lot of Fs -and Es.

    +

    The memory ranges listed here are inclusive, so they end with a lot of F's +and E's.

    We've talked about volatile memory before, but just as a reminder I'll say that -all of the memory we'll talk about here should be accessed with volatile with +all of the memory we'll talk about here should be accessed using volatile with two exceptions:

    1. Work RAM (both internal and external) can be used normally, and if the -compiler is able to totally elide any reads and writes that's okay.
    2. +compiler is able to totally elide some reads and writes that's okay.
    3. However, if you set aside any space in Work RAM where an interrupt will communicate with the main program then that specific location will have to keep using volatile access, since the compiler never knows when an interrupt @@ -171,13 +171,11 @@ try to read out of the BIOS.

      external work ram has only a 16-bit bus (if you read/write a 32-bit value it silently breaks it up into two 16-bit operations) and also 2 wait cycles (extra CPU cycles that you have to expend per 16-bit bus use).

      -

      In other words, we should think of EWRAM as if it was "heap space" in a normal -application. You can take the time to go store something within EWRAM, or to -load it out of EWRAM, but you should always avoid doing a critical computation -on values in EWRAM. It's a bit of a pain, but if you wanna be speedy and you -have more than just one manipulation that you want to do, you should pull the -value into a local variable, do all of your manipulations, and then push it back -out at the end.

      +

      It's most helpful to think of EWRAM as slower, distant memory, similar to the +"heap" in a normal application. You can take the time to go store something +within EWRAM, or to load it out of EWRAM, but if you've got several operations +to do in a row and you're worried about time you should pull that value into +local memory, work on your local copy, and then push it back out to EWRAM.

      Internal Work RAM / IWRAM