diff options
| author | 2025-09-10 03:45:36 +0300 | |
|---|---|---|
| committer | 2025-09-09 20:45:36 -0400 | |
| commit | 109c3705ffe306f99a070b4bb65bf86c2124eed5 (patch) | |
| tree | 1e3ddcb51727c33b8245384fd261f3078963111a | |
| parent | 94205daf2190b07f25f5890113f41e176286d1b6 (diff) | |
docs: fix assorted typos (#14152)
| -rw-r--r-- | docs/man/mame.6 | 6 | ||||
| -rw-r--r-- | docs/source/commandline/commandline-all.rst | 4 | ||||
| -rw-r--r-- | docs/source/conf.py | 2 | ||||
| -rw-r--r-- | docs/source/initialsetup/compilingmame.rst | 4 | ||||
| -rw-r--r-- | docs/source/techspecs/cpu_device.rst | 2 | ||||
| -rw-r--r-- | docs/source/techspecs/device_sound_interface.rst | 2 | ||||
| -rw-r--r-- | docs/source/techspecs/floppy.rst | 4 | ||||
| -rw-r--r-- | docs/source/techspecs/layout_files.rst | 2 | ||||
| -rw-r--r-- | docs/source/techspecs/m6502.rst | 2 | ||||
| -rw-r--r-- | docs/source/techspecs/memory.rst | 4 | ||||
| -rw-r--r-- | docs/source/techspecs/nscsi.rst | 2 | ||||
| -rw-r--r-- | docs/source/techspecs/osd_audio.rst | 6 | ||||
| -rw-r--r-- | docs/source/techspecs/poly_manager.rst | 4 |
13 files changed, 22 insertions, 22 deletions
diff --git a/docs/man/mame.6 b/docs/man/mame.6 index 38b31f12de2..225ad8317ca 100644 --- a/docs/man/mame.6 +++ b/docs/man/mame.6 @@ -745,7 +745,7 @@ Default is OFF (\-nosyncrefresh). .\" SDL specific .\" +++++++++++++++++++++++++++++++++++++++++++++++++++++++ .B NOTE: -All the options in this group are available only with softare video +All the options in this group are available only with software video rendering subsystem, i.e \fB\-video soft\fR. .TP .B \-prescale\fR [\fIvalue\fR] @@ -959,7 +959,7 @@ pick a sane duration. .\" ******************************************************* .TP .B \-[no]coin_lockout, \-[no]coinlock -Enables simulation of the "coin lockout" feature that is implmeneted +Enables simulation of the "coin lockout" feature that is implemented on a number of game PCBs. It was up to the operator whether or not the coin lockout outputs were actually connected to the coin mechanisms. If this feature is enabled, then attempts to enter a coin @@ -1168,7 +1168,7 @@ information. The default is OFF (\-noverbose). .TP .B \-[no]update_in_pause Enables updating the screen bitmap while the game is paused. This is -useful for debuggin in some scenarios (and gets in the way in others). +useful for debugging in some scenarios (and gets in the way in others). Default is OFF (\-noupdate_in_pause). .TP .B \-[no]debug, \-[no]d diff --git a/docs/source/commandline/commandline-all.rst b/docs/source/commandline/commandline-all.rst index 13913bd31fc..586faaca201 100644 --- a/docs/source/commandline/commandline-all.rst +++ b/docs/source/commandline/commandline-all.rst @@ -1354,7 +1354,7 @@ Core Search Path Options Specifies the default path from which to load loose software image files. - The default is ``sofware`` (that is, a directory ``software`` in the current + The default is ``software`` (that is, a directory ``software`` in the current working directory). Example: @@ -1811,7 +1811,7 @@ Core State/Playback Options All save states will be stored inside sta\c64\robby\ .. Tip:: Note that even on Microsoft Windows, you should use ``/`` as your - path seperator for **-statename** + path separator for **-statename** .. _mame-commandline-noburnin: diff --git a/docs/source/conf.py b/docs/source/conf.py index fad41753088..e957196eae1 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -264,7 +264,7 @@ texinfo_documents = [ #texinfo_show_urls = 'footnote' # Add download links at bottom left when the MAMEDEV environment -# varaible is set. See versions.html in the _template folder. +# variable is set. See versions.html in the _template folder. try: html_context except NameError: diff --git a/docs/source/initialsetup/compilingmame.rst b/docs/source/initialsetup/compilingmame.rst index a4559842b39..1e467fff552 100644 --- a/docs/source/initialsetup/compilingmame.rst +++ b/docs/source/initialsetup/compilingmame.rst @@ -577,7 +577,7 @@ Including subsets of supported systems SUBTARGET Set emulator subtarget to build. Some pre-defined subtargets are provided, using Lua scripts in *scripts/target/mame* and system driver filter files in - *src/mame*. User-defined substargets can be created using the **SOURCES** + *src/mame*. User-defined subtargets can be created using the **SOURCES** or **SOURCEFILTER** option. SOURCES Specify system driver source files and/or folders to include. Usually used @@ -762,7 +762,7 @@ the ``_FORTIFY_SOURCE`` macro is set in the RPM build environment, and not by distributing a modified version of GCC.) If you get compilation errors in ``bits/string_fortified.h`` you should first -ensure that the ``_FORTIY_SOURCE`` macro is defined via the environment (e.g. +ensure that the ``_FORTIFY_SOURCE`` macro is defined via the environment (e.g. a **CFLAGS** or **CXXFLAGS** environment variable). You can check to see whether the ``_FORTIFY_SOURCE`` macro is a built-in macro with your version of GCC with a command like this: diff --git a/docs/source/techspecs/cpu_device.rst b/docs/source/techspecs/cpu_device.rst index c21a20a4fe7..6b566a53ac3 100644 --- a/docs/source/techspecs/cpu_device.rst +++ b/docs/source/techspecs/cpu_device.rst @@ -225,5 +225,5 @@ will retry the access. At this point, interruptibility and DRC are entirely incompatible. We do not have a method to quit the generated code before or after an -access. It's theorically possible but definitely non-trivial. +access. It's theoretically possible but definitely non-trivial. diff --git a/docs/source/techspecs/device_sound_interface.rst b/docs/source/techspecs/device_sound_interface.rst index 6e229d7ffa0..80331b633f6 100644 --- a/docs/source/techspecs/device_sound_interface.rst +++ b/docs/source/techspecs/device_sound_interface.rst @@ -230,7 +230,7 @@ stored output value. ``start`` tells where to start (default index 0), ``count`` how many (default up to the end of the buffer). -``copy`` does the same as fill but gets its value from the indentical +``copy`` does the same as fill but gets its value from the identical position in an input channel. Note that clamping should not be used unless it actually happens in diff --git a/docs/source/techspecs/floppy.rst b/docs/source/techspecs/floppy.rst index 39060d4eddf..f910d08fb29 100644 --- a/docs/source/techspecs/floppy.rst +++ b/docs/source/techspecs/floppy.rst @@ -66,7 +66,7 @@ The data is structured at two levels: how individual bits (or nibbles, or bytes) All floppy controllers, even the wonkiest like the Apple II one, start by dividing the track in equally-sized cells. They're angular sections in the middle of which a magnetic orientation inversion may be present. From a hardware point of view the cells are seen as durations, which combined with the floppy rotation give the section. For instance the standard MFM cell size for a 3" double-density floppy is 2us, which combined with the also standard 300 rpm rotational speed gives an angular size of 1/100000th of a turn. Another way of saying it is that there are 100K cells in a 3" DD track. -In every cell there may or may not be a magnetic orientation transition, e.g. a pulse coming from (reading) or going to (writing) the floppy drive. A cell with a pulse is traditionally noted '1', and one without '0'. Two constraints apply to the cell contents though. First, pulses must not be too close together or they'll blur each-other and/or be filtered out. The limit is slightly better than 1/50000th of a turn for single and double density floppies, half that for HD floppys, and half that again for ED floppies with perpendicular recording. Second, they must not be too away from each other or either the AGC is going to get wonky and introduce phantom pulses or the controller is going to lose sync and get a wrong timing on the cells on reading. Conservative rule of thumb is not to have more than three consecutive '0' cells. +In every cell there may or may not be a magnetic orientation transition, e.g. a pulse coming from (reading) or going to (writing) the floppy drive. A cell with a pulse is traditionally noted '1', and one without '0'. Two constraints apply to the cell contents though. First, pulses must not be too close together or they'll blur each-other and/or be filtered out. The limit is slightly better than 1/50000th of a turn for single and double density floppies, half that for HD floppies, and half that again for ED floppies with perpendicular recording. Second, they must not be too away from each other or either the AGC is going to get wonky and introduce phantom pulses or the controller is going to lose sync and get a wrong timing on the cells on reading. Conservative rule of thumb is not to have more than three consecutive '0' cells. Of course protections play with that to make formats not reproducible by the system controller, either breaking the three-zeroes rule or playing with the cells durations/sizes. @@ -108,7 +108,7 @@ Other encodings exist, like M2FM, but they're very rare and system-specific. 2.3.1.6. Reading back encoded data `````````````````````````````````` -Writing encoded data is easy: you only need a clock at the appropriate frequency and send or not a pulse on the clock edges. Reading back the data is where the fun is. Cells are a logical construct and not a physical measurable entity. Rotational speeds very around the defined one (±2% is not rare), and local perturbations (air turbulence, surface distance…) make the instantaneous speed very variable in general. So to extract the cell values stream, the controller must dynamically synchronize with the pulse train that the floppy head picks up. The principle is simple: a cell-sized duration window is built within which the presence of at least one pulse indicates the cell is a '1', and the absence of any a '0'. After reaching the end of the window, the starting time is moved appropriately to try to keep the observed pulse at the exact middle of the window. This allows the phase to be corrected on every '1' cell, making the synchronization work if the rotational speed is not too off. Subsequent generations of controllers used Phase-Locked Loops (PLLs) which vary both phase and window duration to adapt better to inaccuarate rotational speeds, usually with a tolerance of ±15%. +Writing encoded data is easy: you only need a clock at the appropriate frequency and send or not a pulse on the clock edges. Reading back the data is where the fun is. Cells are a logical construct and not a physical measurable entity. Rotational speeds very around the defined one (±2% is not rare), and local perturbations (air turbulence, surface distance…) make the instantaneous speed very variable in general. So to extract the cell values stream, the controller must dynamically synchronize with the pulse train that the floppy head picks up. The principle is simple: a cell-sized duration window is built within which the presence of at least one pulse indicates the cell is a '1', and the absence of any a '0'. After reaching the end of the window, the starting time is moved appropriately to try to keep the observed pulse at the exact middle of the window. This allows the phase to be corrected on every '1' cell, making the synchronization work if the rotational speed is not too off. Subsequent generations of controllers used Phase-Locked Loops (PLLs) which vary both phase and window duration to adapt better to inaccurate rotational speeds, usually with a tolerance of ±15%. Once the cell data stream is extracted, decoding depends on the encoding. In the FM and MFM case the only question is to recognize data bits from clock bits, while in GCR the start position of the first group should be found. That second level of synchronization is handled at a higher level using patterns not found in a normal stream. diff --git a/docs/source/techspecs/layout_files.rst b/docs/source/techspecs/layout_files.rst index fb4894971c7..7fb304b292c 100644 --- a/docs/source/techspecs/layout_files.rst +++ b/docs/source/techspecs/layout_files.rst @@ -1496,5 +1496,5 @@ internal layouts included in MAME. Effectively using groups as a procedural programming language to build up an image of a trainer board. `beena.lay <https://git.redump.net/mame/tree/src/mame/layout/beena.lay?h=mame0261>`_ - Using event-based scripting to dynamically position elements and draw elemnt + Using event-based scripting to dynamically position elements and draw element content programmatically. diff --git a/docs/source/techspecs/m6502.rst b/docs/source/techspecs/m6502.rst index f5d55fc9af4..6e2a4523b41 100644 --- a/docs/source/techspecs/m6502.rst +++ b/docs/source/techspecs/m6502.rst @@ -374,6 +374,6 @@ Current TO-DO: - Integrate the I/O subsystems in the 4510 -- Possibly integrate the sound subsytem in the rp2a03 +- Possibly integrate the sound subsystem in the rp2a03 - Add decent hookups for the Apple 3 madness diff --git a/docs/source/techspecs/memory.rst b/docs/source/techspecs/memory.rst index 9f0a31758c7..aa877d0101d 100644 --- a/docs/source/techspecs/memory.rst +++ b/docs/source/techspecs/memory.rst @@ -282,7 +282,7 @@ view can be re-enabled at any time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some specific CPUs have been upgraded to be interruptible which allows -to add bus contention and wait states capabitilites. Being +to add bus contention and wait states capabilities. Being interruptible means, in practice, that an instruction can be interrupted at any time and the execute_run method of the core exited. Other devices can then run, then eventually controls returns to the @@ -950,7 +950,7 @@ data passed around. A write tap happens before the access, and can change the value to be written. A read tap happens after the access, and can change the value returned. -Taps must be of the same width and alignement than the bus. Multiple +Taps must be of the same width and alignment as the bus. Multiple taps can act over the same addresses. The ``memory_passthrough_handler`` object collates a number of taps diff --git a/docs/source/techspecs/nscsi.rst b/docs/source/techspecs/nscsi.rst index da3773a30ff..022c269fa5c 100644 --- a/docs/source/techspecs/nscsi.rst +++ b/docs/source/techspecs/nscsi.rst @@ -128,7 +128,7 @@ In **scsi_command()**, the device can either handle the command or pass it up wi To handle the command, a number of methods are available: -- **get_lun(lua-set-in-command)** will give you the LUN to work on (the in-command one can be overriden by a message-level one). +- **get_lun(lua-set-in-command)** will give you the LUN to work on (the in-command one can be overridden by a message-level one). - **bad_lun()** replies to the host that the specific LUN is unsupported. diff --git a/docs/source/techspecs/osd_audio.rst b/docs/source/techspecs/osd_audio.rst index 659336b4fcf..290e992c781 100644 --- a/docs/source/techspecs/osd_audio.rst +++ b/docs/source/techspecs/osd_audio.rst @@ -10,10 +10,10 @@ host system audio. A part of it is the OSD support, where a host-specific module ensures the interface between Mame and the host. This is the documentation for that module. -Note: this is currenty output-only, but input should follow. +Note: this is currently output-only, but input should follow. -Capabitilies +Capabilities ------------ The OSD interface is designed to allow three levels of support, @@ -175,7 +175,7 @@ every frame would be a bad idea. virtual uint32_t get_generation() override; That method returns the current generation number. It's called at a -minimum once per update, which usually means per frame. It whould be +minimum once per update, which usually means per frame. It should be reasonably lightweight when nothing special happens. .. code-block: C++ diff --git a/docs/source/techspecs/poly_manager.rst b/docs/source/techspecs/poly_manager.rst index d30a57c39c3..8dd4f7ee0fb 100644 --- a/docs/source/techspecs/poly_manager.rst +++ b/docs/source/techspecs/poly_manager.rst @@ -556,7 +556,7 @@ typically have many more object-wide parameters defined here:: bitmap_rgb32 *dest; // pointer to the rendering bitmap bitmap_ind16 *depth; // pointer to the depth bitmap rgb_t color; // overall color (for clearing and flat shaded case) - uint16_t depthval; // fixed depth v alue (for clearing) + uint16_t depthval; // fixed depth value (for clearing) }; Now it’s time to define our renderer class, which we derive from **poly_manager**. As @@ -1018,7 +1018,7 @@ returned in **chunk**: * **chunk** is a reference to a variable that will be set to the actual number of contiguous items available starting at **index**. If **chunk** is less than **count**, - then the caller should process the **chunk** items returned, then call ``countiguous()`` + then the caller should process the **chunk** items returned, then call ``contiguous()`` again at (**index** + **chunk**) to access the rest. **Return value:** a pointer to the first item in the contiguous chunk. No range checking |
