Bring RustyNES docs up to date (FDS, disk-control, native cheats)

_typos.toml

@@ -9,3 +9,28 @@ extend-exclude = [
 ue = "ue"          # Nestopia UE
 sav = "sav"        # .sav file extension
 kernal = "kernal"  # Commodore's low-level Operating System
+gam = "gam"        # GAM4980 core name / .gam file extension
+bload = "bload"    # MSX-BASIC BLOAD command (library/bluemsx.md)
+consol = "consol"  # Atari 8-bit CONSOL_SELECT/CONSOL_START hardware register (library/atari800.md)
+pn = "pn"          # UPnP substring (ppsspp.md, netplay-faq.md, netplay-getting-started.md)
+lod = "lod"        # GLSL textureLodOffset substring (development/shader/slang-shaders.md)
+accomodate = "accomodate"  # ACCOMODATE_POSSIBLE_DYNAMIC_LOOPS, a real CRT-Royale shader macro (shader/crt_royale.md)
+betwee = "betwee"    # betwee.mp3, a real 8.3-truncated PrBoom DOS asset filename (library/prboom.md)
+messag = "messag"    # messag.mp3, ditto
+openin = "openin"    # openin.mp3, ditto
+runnin = "runnin"    # runnin.mp3, ditto
+bumpter = "bumpter"  # Vita_Bumpter_Left.png, a real Button_Pack asset filename
+outter = "outter"    # Remote_Circle_Outter.png, ditto
+tilda = "tilda"      # Keyboard_*_Tilda.png, ditto
+sentris = "sentris"  # Sentris, a real game title (image/Button_Pack/Readme.txt)
+cruzes = "cruzes"    # Cruzes, a real (stub) core entry (guides/core-list.md)
+ment = "ment"        # part of "Greg DeMent", a real person's surname (library/prosystem.md)
+nd = "nd"            # part of "Button 2ND" (library/numero.md)
+som = "som"          # som_msu1.sfc, a real filename (library/snes9x.md)
+hsi = "hsi"          # .hsi file extension (guides/softwarelist-getting-started.md)
+discernable = "discernable"  # a widely-accepted alternate spelling of "discernible" (guides/rgui.md)
+alis = "alis"        # KEY_ALIS, an example keytool placeholder (development/retroarch/compilation/android.md)
+ba = "ba"            # part of the "ba4980-c-sdk" tool-repo URL slug (library/gam4980.md)
+thq = "thq"          # THQ, a real video game publisher (library/compatibility/gba.md)
+mis = "mis"          # part of the valid "mis-matched" hyphenation (guides/softwarelist-getting-started.md)
+informations = "informations"  # only remaining match is the quick-informations.md FILENAME itself (kept as-is: many other pages link to it by this exact path); every genuine prose occurrence of this typo was fixed

docs/development/coding-standards.md

@@ -26,7 +26,7 @@ Comments use a maximum column width of 80 characters, and each new line of a mul
 ```c
 /**
   * Retrieves the sensor state associated with the provided port and ID. This
-  * function pointer may be set to NULL if retreiving sensor state is not
+  * function pointer may be set to NULL if retrieving sensor state is not
   * supported.
   * 
   * @param data  The input state struct

docs/development/cores/core-specific/mame.md

@@ -2,7 +2,7 @@
 
 ## Building libretro-mame
 
-### Build environement
+### Build environment
 
 #### Windows
 

docs/development/cores/developing-cores.md

@@ -65,7 +65,7 @@ The program flow of a frontend using the libretro API can be expressed as follow
 
 #### `retro_api_version()`
 
-This function should return RETRO_API_VERSION, defined in libretro.h. It is used by the frontend to determine if ABI/API are mismatched. The ver- sion will be bumped should there be any non- compatible changes to the API. Changes to retro_* structures, as well as changes in publically visible functions and/or their arguments will warrant a bump in API version.
+This function should return RETRO_API_VERSION, defined in libretro.h. It is used by the frontend to determine if ABI/API are mismatched. The ver- sion will be bumped should there be any non- compatible changes to the API. Changes to retro_* structures, as well as changes in publicly visible functions and/or their arguments will warrant a bump in API version.
 
 #### `retro_set_*()`
 
@@ -94,7 +94,7 @@ The frontend will typically request statically known information about the core
 
 This function will load content. If the implementation is an emulator, this would be a game ROM image, if it is a game engine, this could be packaged upassets for the game, etc. The function takes a structure that points to the path where the ROM was loaded from, as well as a memory chunk of the already loaded file.
 
-**There are two modes of loading files with libretro.** If the game engine requires to know the path of where the ROM image was loaded from, the `need_fullpath` field in `retro_system_info` must be set to true. If the path is required, the frontend will not load the file into the data/size fields, and it is up to the implementation to load the file from disk. The path might be both relative and absolute, and the implementation must check for both cases. This is useful if the ROM image is too large to load into memory at once. It is also useful if the assests consist of many smaller files, where it is necessary to know the path of a master file to infer the paths of the others.
+**There are two modes of loading files with libretro.** If the game engine requires to know the path of where the ROM image was loaded from, the `need_fullpath` field in `retro_system_info` must be set to true. If the path is required, the frontend will not load the file into the data/size fields, and it is up to the implementation to load the file from disk. The path might be both relative and absolute, and the implementation must check for both cases. This is useful if the ROM image is too large to load into memory at once. It is also useful if the assets consist of many smaller files, where it is necessary to know the path of a master file to infer the paths of the others.
 
 If `need_fullpath` is set to `false`, the frontend will load the ROM image into memory beforehand. In this mode, the path field is not guaranteed to be non-`NULL`. It should point to a valid path if the file was indeed, loaded from disk, however, it is possible that the file was loaded from `stdin`, or similar, which has no well-defined path. It is recommended that `need_fullpath` is set to `false` if possible, as it allows more features, such as soft-patching to work correctly.
 

docs/development/frontends.md

@@ -20,7 +20,7 @@ Name | Author(s) |  Description
 [Ludo](https://github.com/libretro/ludo) | kivutar | libretro frontend written in Go.
 [Lemuroid](https://github.com/Swordfish90/Lemuroid) | Swordfish90 | All in 1 emulator on Android.
 [Merton](https://github.com/snowcone-ltd/merton) | Snowcone Ltd. | Merton is a work-in-progress emulator frontend for libretro built with [libmatoya](https://github.com/snowcone-ltd/libmatoya).
-[Mininal reference fronted](https://github.com/bparker06/reference_frontend) | bparker06 | This is a barebones minimal reference frontend for the libretro API.
+[Minimal reference fronted](https://github.com/bparker06/reference_frontend) | bparker06 | This is a barebones minimal reference frontend for the libretro API.
 [minir](https://github.com/Alcaro/minir) | Alcaro | WIMP interface (Windows, Icons, Menus and Pointers), and only cares about the major desktop OSes. Drops flexibility in favor of improved out-of-the-box experience.
 [minir test fronts](https://github.com/Alcaro/minir/tree/master/subproj) | Alcaro | Three different fronts, none of which has IO drivers: retroprofile just runs the core, intended for performance tests and PGO; retrorepeat runs the core twice, expecting identical output; retrostateverify traces the entire core and verifies whether its savestates are perfect.
 [miniretro](https://github.com/davidgfnet/miniretro) | davidgfnet | This is a small (Linux only for now) CLI libretro frontend for automated testing of libretro cores. 
@@ -30,7 +30,7 @@ Name | Author(s) |  Description
 [picoarch](https://git.crowdedwood.com/picoarch/about) | neonloop | picoarch uses libpicofe and SDL to create a small frontend to libretro cores. It's designed for small (320x240 2.0-2.4") screen, low-powered devices like the Trimui Model S (PowKiddy A66).
 [Phoenix](http://phoenix.vg/) | Phoenix | Upcoming libretro frontend written with the Qt5 cross-platform application framework.
 [raylib-libretro](https://github.com/RobLoach/raylib-libretro) | RobLoach |  Libretro frontend using raylib.
-[retro_frontend](https://github.com/ehmry/genode-libretro) | Ehmry  | Frontend for the [Genode](http://genode.org) operating system framework. Following the Genode philosophy this frontend strives to be a minimal implemention that is extensible via the abstract OS services provided to it.
+[retro_frontend](https://github.com/ehmry/genode-libretro) | Ehmry  | Frontend for the [Genode](http://genode.org) operating system framework. Following the Genode philosophy this frontend strives to be a minimal implementation that is extensible via the abstract OS services provided to it.
 [RePlay OS](https://www.replayos.com/) | RTA | Upcoming libretro based frontend optimized for use with Raspberry Pi boards using both LCD and CRT screens.
 [replay](https://github.com/avojak/replay) | avojak | Native Linux multi-system emulator built in Vala and GTK for elementary OS.
 [Retrobot](https://github.com/rossimo/retrobot) | Ross Squires | A self-hosted Discord bot that allows friends to play games over chat.

docs/development/input-api.md

@@ -90,7 +90,7 @@ Coordinates in X and Y are reported as `[-0x7fff, 0x7fff]`: `-0x7fff` correspond
 ## Keyboard Input
 `RETRO_DEVICE_KEYBOARD`: The libretro API allows a core to poll the frontend for the raw current pressed state of keys. There is also a callback available which is called by the frontend in response to keyboard events. `down` is set if the key is being pressed and `false` if it is being released.
 
-Even though the frontend should try to synchronize keypresses with keycode events, cores should assume that multiple characters can be generated from a single keypress. In other words, keycode events should be treated separately from character events. Similarily if only a keycode event is generated with no corresponding character, the character should be `0`.
+Even though the frontend should try to synchronize keypresses with keycode events, cores should assume that multiple characters can be generated from a single keypress. In other words, keycode events should be treated separately from character events. Similarly if only a keycode event is generated with no corresponding character, the character should be `0`.
 
 ## Lightgun Input
 `RETRO_DEVICE_LIGHTGUN`: The libretro lightgun abstraction reports X/Y coordinates in screen space (similar to the pointer) in the range `[-0x8000, 0x7fff]` in both axes, with zero being center and `-0x8000` being out of bounds. The core an query the on/off screen state of the lightgun. It features a trigger, start/select buttons, auxiliary action buttons and a directional pad. A forced off-screen shot can be requested for auto-reloading function in some games.

docs/development/licenses.md

@@ -196,6 +196,7 @@ See below for a summary of the licenses behind RetroArch and its cores:
 | [REminiscence](../library/reminiscence.md)                                       | GPLv3                                                                                     |                |
 | RemoteJoy                                                                        | [GPLv2](https://github.com/libretro/libretro-remotejoy/blob/master/LICENSE)               |                |
 | Remote RetroPad                                                                  | [MIT](https://github.com/libretro/libretro-samples/blob/master/license)                   |                |
+| [RustyNES](../library/rustynes.md)                                               | [MIT OR Apache-2.0](https://github.com/doublegate/RustyNES/blob/main/LICENSE)         |                |
 | [RVVM](../library/rvvm.md)                                                       | [GPLv3](https://github.com/LekKit/RVVM/blob/staging/LICENSE-GPL), [MPLv2.0](https://github.com/LekKit/RVVM/blob/staging/LICENSE-MPL) |                |
 | [SameBoy](../library/sameboy.md)                                                 | [MIT](https://github.com/libretro/SameBoy/blob/master/LICENSE) | |
 | [SameDuck](../library/sameduck.md)                                               | [MIT](https://github.com/libretro/) | |

docs/development/retroarch/compilation/android.md

@@ -129,7 +129,7 @@ Next, copy the cores, assets and overlays to an assets folder you create here:
 
     mkdir -p assets/cores
     mkdir assets/overlays
-    cp ../../../../dist/android/arm64-v8a/* assets/cores/ #replace arm64-v8a here by the  archetecture of the device you will be using. Google your phone's specs.
+    cp ../../../../dist/android/arm64-v8a/* assets/cores/ #replace arm64-v8a here by the  architecture of the device you will be using. Google your phone's specs.
     cp -r ../../../../dist/info/ assets/
     cp -r ../../../../retroarch/media/overlays/* assets/overlays/
 

docs/development/retroarch/compilation/windows98-msvc-cmdline.md

@@ -2,7 +2,7 @@
 
 ## Environment configuration
 
-To compile RetroArch on the command-line targeting Windows NT4, Windows 98SE, Windows Millenium Edition or Windows 2000, we will use a combination of the MSYS2 shell and Microsoft Visual C++ 2005.
+To compile RetroArch on the command-line targeting Windows NT4, Windows 98SE, Windows Millennium Edition or Windows 2000, we will use a combination of the MSYS2 shell and Microsoft Visual C++ 2005.
 
 This guide assumes the host OS is Windows Vista or later, as MSYS2 cannot be installed on anything older.
 

docs/development/retroarch/input/overlay.md

@@ -118,7 +118,7 @@ For especially overlay buttons which map to analogs, it is useful to allow an im
 
 ## Let buttons light up when they are pressed
 
-When using individial overlays per button it will make sense to have buttons light up when they are pressed. To do this, the alpha value per-button will be multiplied by a factor.
+When using individual overlays per button it will make sense to have buttons light up when they are pressed. To do this, the alpha value per-button will be multiplied by a factor.
 
     overlay0_desc0_alpha_mod = 2.0 # Alpha is multiplied 2x when pressed.
 
@@ -179,7 +179,7 @@ will trigger both left and up at same time. Keyboard keys are an exception; an o
 To build some kind of menu system, one would need the ability for overlay_next to refer to any overlay. To do this, two extra things must be configured:
 
     overlay2_overlay = "some_overlay.png"
-    overlay2_name = "overview_overlay" # A name which can be referred to. Must be set if it is to be refered to.
+    overlay2_name = "overview_overlay" # A name which can be referred to. Must be set if it is to be referred to.
 
     overlay0_desc0 = "overlay_next,200,180,radial,40,40"
     overlay0_desc0_next_target = "overview_overlay" # When this overlay_next is pressed, it will go to index 2 directly, instead of the default 1.

docs/development/retroarch/netplay.md

@@ -58,7 +58,7 @@ Spectators send no input data.
 When new input data is received from a player, if it is before the currently
 executing frame, RetroArch will invisibly rewind and replay with the new input
 data, arriving at the original frame so that the local player's own input is
-always seemless.
+always seamless.
 
 A typical, playing client sends no data other than its own input every frame.
 During normal play, the server sends its own input data. If the server is not
@@ -74,7 +74,7 @@ to send input data until its local frame count has reached the server's.
 
 In particular, resets and savestate loads are always synchronized to the
 server's frame count, and thus only the server may reset the core or load a
-savestate. Because input preceeding a savestate load is irrelevant, upon
+savestate. Because input preceding a savestate load is irrelevant, upon
 receiving a savestate load command, all frame counts are updated to be at least
 the server's frame count, including the local frame count if applicable. This
 is the only condition under which the frame count will skip at a rate greater

docs/development/retroarch/new-menu-options.md

@@ -59,6 +59,6 @@ Now the menu has to be told how to display the option.
 
 # Finishing
 
-This guide only introduces the English menu labels. Translations are handled via Crowdin, after the pull request is accepted, new strings will appear for translators. New items wil be shown to users in English until translation is done.
+This guide only introduces the English menu labels. Translations are handled via Crowdin, after the pull request is accepted, new strings will appear for translators. New items will be shown to users in English until translation is done.
 
 There are several possibilities that can be done with the menu system, but most require additional functions. Help text may also be defined (a slightly longer description that can be displayed with Select button). Some of the menu code is dynamic depending on e.g. number of users, those items usually require extra care. Icon assignments are handled in the menu drivers (ozone, xmb, glui).

docs/development/retroarch/new-translations.md

@@ -190,7 +190,7 @@ else if (string_is_equal(language,"xx"))
 else if (string_is_equal(language, "xx"))
    return "yyy";
 ```
-3. For Windows. (OS compatiable)
+3. For Windows. (OS compatible)
     1. Open `frontend/drivers/platform_win32.c`.
     2. Go to `accessibility_win_language_code(const char* language)` function. Check if the following block is present, where `Yyyyy` is the [voice name](https://support.microsoft.com/en-us/windows/appendix-a-supported-languages-and-voices-4486e345-7730-53da-fcfe-55cc64300f01#WindowsVersion=Windows_10) for the language and if not, add it before `return ""`:
 ```c

docs/development/shader/cg-shaders.md

@@ -80,7 +80,7 @@ out_pos = mul(modelViewProj , pos);
 
 The `COLOR` semantic isn’t very interesting for us, but the example code in nVidias Cg documentation includes it, so we just follow along. `TEXCOORD` is the texture coordinate we get from the emulator, and generally we just pass it to the fragment shader directly. The coordinate will then be linearly interpolated across the fragments.
 
-More complex shaders can output (almost) as many variables they want, that will be linearily interpolated for free
+More complex shaders can output (almost) as many variables they want, that will be linearly interpolated for free
 to the fragment shader. We also need a fragment shader to go along with the vertex shader, and here's a basic shader that only outputs the pixel as-is. This is pretty much the result you’d get if you didn’t run any shader (fixed-function) at all.
 
 ```c
@@ -122,7 +122,7 @@ float4 main_fragment ( uniform sampler2D s0 : TEXUNIT0, uniform input IN , float
 }
 ```
 
-Here we use `IN.texture_size` to determine the the size of the texture. Since GL maps the whole texture to the interval `[0.0, 1.0]`, `1.0 / IN.texture_size` means we get the offset for a single pixel, simple enough. Almost every shader uses this. We can calculate these offsets in vertex shader to improve performance since the coordinates are linearily interpolated anyways, but that is for another time.
+Here we use `IN.texture_size` to determine the the size of the texture. Since GL maps the whole texture to the interval `[0.0, 1.0]`, `1.0 / IN.texture_size` means we get the offset for a single pixel, simple enough. Almost every shader uses this. We can calculate these offsets in vertex shader to improve performance since the coordinates are linearly interpolated anyways, but that is for another time.
 
 ## Putting it together
 

docs/development/shader/glsl-shaders.md

@@ -35,4 +35,4 @@ Like Cg shaders, there is a GLSL preset format. Instead of `.cgp` extension, `.g
 
 ## Converting from Cg shaders
 
-GLSL shaders are mostly considered a compatibility format. It is possible to compile Cg shaders into GLSL shaders automatically using our [cg2glsl script](https://github.com/libretro/RetroArch/blob/master/tools/cg2glsl.py). It can convert single shaders as well as batch conversion. Shader converstion relies on nVidia's `cgc` tool found in the `nvidia-cg-toolkit` package.
+GLSL shaders are mostly considered a compatibility format. It is possible to compile Cg shaders into GLSL shaders automatically using our [cg2glsl script](https://github.com/libretro/RetroArch/blob/master/tools/cg2glsl.py). It can convert single shaders as well as batch conversion. Shader conversion relies on nVidia's `cgc` tool found in the `nvidia-cg-toolkit` package.