DS Modding Index - Touchups

pages/_en-US/ds-index/dsi-twl-firm.md

@@ -7,25 +7,14 @@ title: Nintendo DSi / Nintendo 3DS TWL_FIRM
 description: Information about the Nintendo DSi and the Nintendo 3DS's TWL_FIRM
 ---
 
-### Setting up CFW
-The main benefit of modding your DSi and 3DS families of systems is that you can unlock more possibilities with your consoles. Installing Custom Firmware is quite easy, and in most cases, all you need is a (micro)SD card. Here are the best of guides for you to follow, with step-by-step instructions:
-
-- [3DS Hacking Guide](https://3ds.hacks.guide)
-   - Lightning command: `mod 3ds`
-   - TWLHelper command: `guide 3ds`
-   - Kurisu command: `guide 3ds`
-- [DSi Hacking Guide](https://dsi.cfw.guide)
-   - Lightning command: `mod dsi`
-   - TWLHelper command: `guide dsi`
-   - Kurisu command: `guide dsi`
-
 ### CPU speeds
-The Nintendo DS shipped with a 67 MHz processor in 2004, and the Nintendo DSi shipped with a 133 MHz processor five years later. Most games of the Nintendo DS library were made before the Nintendo DSi came out, and as such the only processor available to them was 67 MHz. Some applications tied themselves to that clock speed and as a result, they will not work well with a higher clock speed. Most games, however, outperform the original with a higher clock speed.
 
-nds-bootstrap has TWL Clock Speed as an option, but it will not try to adjust the ROM to work properly with the higher clock speed. That's on the application itself, and applications not working with a higher clock speed is NOT a bug on the nds-bootstrap end.
+With the number of games that came out between the release of the first Nintendo DS to the release of the Nintendo DSi, most were coded to support only the former's clock speed without keeping in mind that one day, the title could be used in an environment not intended. As such, when running these games under the higher clock speed provided by the DSi (133 MHz), numerous glitches could occur, whether minor (such as screen tearing) or gamebreaking (not being able to see anything after sleep mode usage). By default, Nintendo locks these older titles to run under their intended environment (67 MHz) but by utilizing an alternative loader (such as TWiLight Menu++'s Slot-1 Launcher or nds-bootstrap), the lock is removed and it is up to the game (not our implementation) to keep up.
+
+For the titles that can keep up (whether thanks to nds-bootstrap patches or natively), these higher speeds are beneficial for loading times as well as lessen the amount of slowdown in-game. These options are not intended to be used with games that would be broken, and TWiLight Menu++ comes with a blacklist for any game that is known to be broken. Keep in mind that anything which remains broken is due to a fault in how the game was programmed and not a result of the way we remove the lock.
 
 ### Nintendo DSi Menu
-In version 1.4.0, RSA signatures in the DS Game Card whitelist aren't verified. This is a vulnerability that can be exploited, and it allows you to take access over the ARM9 processor. It requires version 1.4.0 (it was patched in future versions and didn't exist in prior versions) and a flashcard with a modified ROM.
+In version 1.4.0, RSA signatures in the DS Game Card whitelist aren't verified. This is a vulnerability that can be exploited to gain control over the ARM9 processor. It requires version 1.4.0 (it was patched in future versions and didn't exist in prior versions) and a flashcard with a modified ROM.
 
 There is also a known glitch in the way the Nintendo DSi Menu calculates free space that can can cause an error when using the menu not from the original NAND, for more information see [hiyaCFW FAQ & Troubleshooting](../hiyacfw/faq#the-free-space-bug).
 
@@ -45,4 +34,4 @@ A `pit.bin` file is used in order to load images. However, the header size at of
 The second bootstage of the Nintendo DSi loads launcher's "title.tmd" into memory. However, they do not specify a file size limit check, meaning that the first 80k bytes are loaded into RAM while the rest can be a custom payload. This is the basis of Unlaunch exploit.
 
 ### RTCom
-RTCom is the use of the 3DS's RTC to allow the ARM7 and ARM11 CPUs to communicate with each other, even while in TWL_FIRM. This allows 3DS features to be used while in DS(i) mode. This includes the circle pad's analog input, enabling widescreen, and having gyro support. Currently, the only public DS homebrew that make use of RTCom is certain builds of GBARunner2 that have support for the 3DS's gyro feature. To enable RTCom, you will need to use [TWPatch](https://gbatemp.net/threads/542694/).
+RTCom is the use of the 3DS's RTC to allow the ARM7 and ARM11 CPUs to communicate with each other, to enable additional features introduced in the Nintendo 3DS while in TWL_FIRM. These featured include remapping the circle pad to the touch screen, stretching the top screen display (allowing widescreen) and gyro support (currently only implemented in specific GBARunner2 builds) Enabling this requires [TWPatch](https://gbatemp.net/threads/542694/).

pages/_en-US/ds-index/retail-roms.md

@@ -40,24 +40,14 @@ You can spot a game that uses DMA in no$gba by enabling the DMA log on ARM9. A D
 - For example: `DMA2: 04100010 023C18C0 AF000001`
 
 ### Action Replay cheats
-Action Replay cheat codes are codes that allow you to make low-level programmable changes in the memory region of your favorite game(s). These changes range from simple value tweaks to extremely advanced ASM tweaks, both of which can alter the experience of the game(s) being played altogether.
+Cheat codes allow one to set low-level programmable changes in the memory, defined at the beginning of gameplay. These changes range from simple value tweaks to extremely advanced ASM tweaks, both of which can alter the experience of the game(s) being played altogether.
 
-Flashcards can take advantage of cheat codes by using cheat databases. Cheat functionality is integrated within the flashcard kernel respectively. The following kernels can utilize cheats:
-- Wood R4 (`usrcheat.dat`)
-- YSMenu (`usrcheat.dat`)
+These codes are typically packaged into single file databases, meant to contain cheats for every game. The one we recommend using is [DeadSkullzJr's NDS Cheat Database](https://gbatemp.net/threads/deadskullzjrs-nds-cheat-databases.488711), but one could easily create their own via [R4CCE](r.pk11.us/r4cce). The format they are produced in is typically `usrcheat.dat`, which is supported by 99% of the loader environments. This includes flashcard kernels (such as Wood R4 & YSMenu), [NitroHax3DS's fork](https://github.com/Epicpkmn11/NitroHax3DS/releases) for physical game cards & [TWiLight Menu++](https://github.com/DS-Homebrew/TWiLightMenu/releases) for digital `.nds` payloads found on the system SD card. There are two common exceptions to this rule:
 
-Homebrew/digital-based solutions can also take advantage of the cheat databases, the software currently available can use the following:
-- [NitroHax](https://www.chishm.com/NitroHax) (`cheats.xml`)
-   - NitroHax lets you use cheats with real Game Cards from a flashcard. The engine used here loads the entire cheats.xml database into the Nintendo DS's limited RAM and tries to manage things from there. This imposes a serious limit on how many cheats you can have, as NitroHax will not load a cheats.xml file past 2.4 MB
-- [NitroHax3DS](https://github.com/ahezard/NitroHax3DS/releases) ([usrcheat.dat fork](https://github.com/Epicpkmn11/NitroHax3DS/releases)) (`cheats.xml` or `usrcheat.dat`)
-   - NitroHax3DS is a version of NitroHax that runs from the system's SD card on DSi or 3DS. The original version uses cheats.xml with the same 2.4 MB limit as the original NitroHax, but there is also a fork that loads cheats from a usrcheat.dat database with no size limitation
-- [TWiLight Menu++](https://github.com/DS-Homebrew/TWiLightMenu/releases) (`usrcheat.dat`)
-   - TWiLight Menu++ reads the `usrcheat.dat` and sends off the enabled cheat values to another file, which nds-bootstrap picks up
-   - The cheat engine used in nds-bootstrap is based on the one used in NitroHax. However, due to the cheat file containing only enabled cheats for that specific title, there is only a limit to how many cheats can be enabled, not a limit on the database size
+- nds-boostrap has its own mechanism of housing cheats, but this is only a concern for pro-users launching nds-bootstrap directly. TWiLight already turns all the enabled cheats from the `usrcheat.dat` format into the format used by nds-bootstrap
+- NitroHax for flashcards reads the entirety of its cheats database, places it in memory and requires you to hotswap your card to launch the cheat menu for the proper ROM. Since dealing with decompression takes up memory not available, the most optimal use is through the `cheats.xml` format, which even there has a limit of 2.4 MB. 
 
-For the most complete cheat database, using [DeadSkullzJr's NDS Cheat Database](https://gbatemp.net/threads/deadskullzjrs-nds-cheat-databases.488711) is recomended.
-
-Cheat codes generally have types 0 through F, and here is an (unfinished) description of them:
+Cheat Code uses the Action Replay format, which generally utilizes types 0 through F. Here is an (unfinished) description of each:
 
 - The 0xE code type is a 32-bit code type that allows you to make multiple writes in many consecutive addresses all at once. Essentially, it is like the basic 32-bit RAM write code type (0x0), except this doesn't have addresses listed next the the values you want to write. Instead, the 0xE code type is programmed to automatically branch from a starting address, then determine the addresses to write to. From there, you just have to tack in the amount to write to in order for it to do the job
   - It is known that cheat codes of this type usually do not work with nds-bootstrap currently