Update index.md

site/content/entry/yuzu-progress-report-dec-2020/index.md

@@ -77,7 +77,7 @@ yuzu's kernel received important changes this month, focused on refactoring the
 
 First, there is an improvement to yuzu [ensuring safe memory access across threads](https://github.com/yuzu-emu/yuzu/pull/5206). A `Race Condition` happens when multiple threads are running simultaneously, and one thread modifies data while another thread accesses it. Race conditions can cause faulty or unexpected behaviour: a thread can retrieve partial data or even overwrite changes made by another. yuzu emulates the Nintendo Switch's internal memory using a type of abstract data structure called a `Page Table`, which works as a virtual layer between the physical and the emulated memory. It maps these addresses in a "contiguous table" that lets the programmer access memory easily without checking where actual memory stores everything. Most memory management operations were written before multicore CPU and asynchronous GPU were implemented. There was only a single thread back then, so there were no guards for thread-safe memory access. bunnei introduced a lock in this PR to alleviate a race condition where the data in the memory pages was being accessed while the GPU was operating on them.
 
-bunnei has also been rewriting the [kernel scheduler](https://github.com/yuzu-emu/yuzu/pull/5131) to be based on `Mesosphere`, the Nintendo Switch kernel reimplementation of [Atmosphère](https://github.com/Atmosphere-NX/Atmosphere) (the custom firmware for the Nintendo Switch we recommend in our dumping guide). Modern operating systems run many processes simultaneously, however, a single CPU core can only process one of them at any given time. The scheduler is an elemental piece of the kernel, as it is in charge of swapping CPU access to the different processes and choosing in which order this happens. As Atmosphère is intended to run on the hardware, all its components are properly reverse engineered, which ensures our scheduler will behave correctly too. This PR will also facilitate porting other parts of Mesosphere in the future. This, in turn, will make yuzu's kernel match Horizon OS more closely. We all owe a big thank you to the people working on Atmosphère, as their reverse engineering efforts facilitate the work needed to implement these services in emulators.
+bunnei has also been rewriting the [kernel scheduler](https://github.com/yuzu-emu/yuzu/pull/5131) to be based on `Mesosphere`, the Nintendo Switch kernel reimplementation of [Atmosphère](https://github.com/Atmosphere-NX/Atmosphere) (the custom firmware for the Nintendo Switch we recommend in our dumping guide). Modern operating systems run many processes simultaneously, however, a single CPU core can only process one of them at any given time. The scheduler is an essential piece of the kernel, as it is in charge of swapping CPU access to the different processes and choosing in which order this happens. As Atmosphère is intended to run on the hardware, all of its components are properly reverse engineered, which ensures our scheduler will behave correctly too. This PR will also facilitate porting other parts of Mesosphere in the future. This, in turn, will make yuzu's kernel match Horizon OS more closely. We all owe a big thank you to the people working on Atmosphère, as their reverse engineering efforts facilitate the work needed to implement these services in emulators.
 
 As a follow-up to this rewrite, bunnei reworked the way service calls were implemented in yuzu, by allocating their calls in their own [individual service threads](https://github.com/yuzu-emu/yuzu/pull/5208). Many services are running in the background on the Nintendo Switch. They are in charge of initializing and managing specific tasks, such as audio, graphics, user input, networking, etc. yuzu emulates these services through HLE - High Level Emulation. This means that, instead of dumping the binary code of these routines from the Nintendo Switch and translating their instructions so that a PC can run them, the programmer reimplements the functionality of these services in C++. Thus, HLE works like a "black box": these services are called whenever there's a request from the games, and they send (or ask) for the corresponding data, even though internally they may be different to how the service was originally implemented in hardware. But, as long as the information requested or sent through the service is valid and processed appropriately, the system is being emulated correctly.