typos/correction

docs/index.html

@@ -207,7 +207,7 @@ <h4>SA-1</h4>
 <p>Features that run on the SA-1 will be marked with this badge: <sup class="badge sa1-badge">SA1</sup>.</p>
 
 <h4>Implementation</h4>
-<p>There are specific routines that get run at the beginning and end of every frame to manage the OAM buffer. These routine aren't coded very efficiently. They've been heavily to allow more CPU time for all the extra features. The SNES CPU then sends an interrupt request which tells the SA-1 to process controller input for shortcuts. If a shortcut is found, a vector pointing to its routine in ROM will be saved in memory. The next frame, the SNES will check for this vector, and respond accordingly.</p>
+<p>There are specific routines that get run at the beginning and end of every frame to manage the OAM buffer. These routine aren't coded very efficiently. They've been heavily optimized to allow more CPU time for all the extra features. The SNES CPU then sends an interrupt request which tells the SA-1 to process controller input for shortcuts. If a shortcut is found, a vector pointing to its routine in ROM will be saved in memory. The next frame, the SNES will check for this vector, and respond accordingly.</p>
 <p>For the game HUD, almost every reference to its WRAM buffer has been changed to a location in BWRAM where the SA-1 can see it. Once the HUD's buffer has been modified by the game, it copies a handful of variables that are only visible to the SNES CPU into memory that is visible to both the SNES and the SA-1. This is where most of the time saved with OAM optimization is accounted for. After these variables are copied, the SNES sends another interrupt request to the SA-1 to indicate that the coprocessor can do its own changes to the tilemap before it gets drawn to the screen. Some features (such as the hearts) are still written to their original WRAM buffer. This way, they can contribute their normal CPU load without ruining the HUD.</p>
 <p>On any frame where the HUD doesn't update, a separate check makes sure that these variables are still copied over, as this copying is critical to balancing the practice hack back in line with vanilla. The rest of the code hacked in is very minimal, and those few extra cycles are very unlikely to create additional lag frames.</p>
 <p>Certain features require more variables to be copied over than others. These will necessarily require a slightly higher fraction of the CPU's time, but they will only take this time when the HUD is redrawn. Such features will be marked with this badge: <sup class="badge lag-badge">EX</sup>.</p>
@@ -234,7 +234,7 @@ <h2>Caveats</h2>
 <h3>Overlay corruption and the SA-1</h3>
 <p>The memory layout of the SA-1 puts important hardware registers and on-board memory in an area potentially affected by overlay corruption. To prevent corruption to the SA-1, the star tile holes routine will be intercepted if it is about to write too far. This will have some effect on the timing of longer corruptions.</p>
 <p>When cut short, the practice hack will continue reading without writing to see how far the writes would have gone. If they reach too far (<code>$4200</code>), then a blue screen of death will be displayed to explain the intentional lock.</p>
-<p>In addition to the writing, this type of corruption may also read too far. This does not have the potential to corrupt the SA-1, but it does throw the behavior out of sync from vanilla. Normally, corruption that reaches this far should terminate at the address <code>$4307</code>; however, the values read from SA-1 registers and memory prevent that precise target from being hit. To guarantee that corruption resolves, a large block of memory from <code>$3680</code> to <code>$37FF</code> has been filled with the necessary terminator value. This solution necessarily means that far-reaching corruption will end much sooner than it normally would, making timings unreliable.</p>
+<p>In addition to the writing, this type of corruption may also read too far. This does not have the potential to corrupt the SA-1, but it does throw the behavior out of sync from vanilla. Normally, corruption that reaches this far is dependent on open bus behavior; however, the SA-1 places registers and memory in this region, effecting a less deterministic sea of values. To coax corruptions into resolving, a large block of memory from <code>$3680</code> to <code>$37FF</code> has been filled with the required terminator value. This solution necessarily means that far-reaching corruption will end much sooner than it normally would, making timings unreliable.</p>
 
 </section>
 

docs/updates.html

@@ -34,13 +34,12 @@ <h3><a href="https://github.com/spannerisms/lttphack/releases/tag/14.3.5">v14.3.
 	</li>
 	<li>Other:
 		<ul>
-			<li>Redid the lag compensation calculations and changed the code a bit. Lag should be closer than every before. There should also be no more risk of crashing old consoles from the HDMA bug.</li>
+			<li>Redid the lag compensation calculations and changed the code a bit. Lag should be closer than ever before. There should also be no more risk of crashing old consoles from the HDMA bug.</li>
 			<li>Fixed extra phantom second from moving walls (I think). (Better timer code)</li>
 			<li>Timers now update upon opening a key door or performing a hop.</li>
 			<li>Fixed stagnant room flags on preset load.</li>
 			<li>Fixed initialization bug that affected pokeys RNG.</li>
 			<li>Made the blue screen of death not broken.</li>
-			<li>Added a "Vanilla items" option to the randomizer version.</li>
 		</ul>
 	</li>
 </ul>