Remove emojis in admonition boxes, replace them with a textual description/intro to the explained concept (#5)

Author: avivace

src/cheatsheet.md

@@ -75,7 +75,7 @@ ldh [rLCDC], a
 
 **To turn the LCD off:**
 
-:::warning: ⚠️
+:::warning
 
 Do not turn the LCD off outside of the Vertical Blank Phase. See "[Wait for the vertical blank phase](#wait-for-the-vertical-blank-phase)".
 

src/part1/assembly.md

@@ -47,13 +47,13 @@ Instruction | Mnemonic | Effect
 ------------|----------|----------------------
 Load        | `ld`     | Copies values around
 
-:::tip:ℹ️
+:::tip
 
 Due to CPU limitations, not all operand combinations are valid for `ld` and many other instructions; we will talk about this when writing our own code later.
 
 :::
 
-:::tip:🤔
+:::tip
 
 RGBDS has an [instruction reference](https://rgbds.gbdev.io/docs/gbz80.7) worth bookmarking, and you can also consult it locally with `man 7 gbz80` if RGBDS is installed on your machine (except Windows...).
 The descriptions there are more succinct, since they're intended as reminders, not as tutorials.

src/part1/header.md

@@ -123,7 +123,7 @@ But why is `EntryPoint` there?
 Well, as you may have figured out from the warnings RGBFIX printed, it *overwrites* the header area in the ROM.
 However, RGBLINK is **not** aware of the header (because RGBLINK is not only used to generate ROMs!), so you must explicitly reserve space for the header area.
 
-:::danger:🥴
+:::danger Common mistake
 
 Forgetting to reserve this space, and having a piece of code or data ending up there then overwritten, is a common beginner mistake that can be quite puzzling.
 Fortunately, RGBFIX since version 0.5.1 warns when it detects this mistake, as shown above.

src/part1/jumps.md

@@ -32,7 +32,7 @@ We will focus on the first two, `jp` and `jr`, for now.
 `jp`, such as the one on line {{#line_no_of "^\s*jp" ../assets/hello-world.asm}}, simply sets PC to its argument, jumping execution there.
 In other words, after executing `jp EntryPoint` (line {{#line_no_of "^\s*jp EntryPoint" ../assets/hello-world.asm}}), the next instruction executed is the one below `EntryPoint` (line <!-- should be {{#line_no_of "^\s*EntryPoint:" ../assets/hello-world.asm}} + 1 --> 11).
 
-:::tip:🤔
+:::tip
 
 You may be wondering what is the point of that specific `jp`.
 Don't worry, we will see later why it's required.
@@ -75,7 +75,7 @@ Here's the interesting part: since we've just copied one byte, that means we hav
 (We have seen `dec` two lessons ago; as a refresher, it simply decreases the value stored in `bc` by one.)
 Since `bc` contains the amount of bytes that still need to be copied, it's trivial to see that we should simply repeat the operation if `bc` != 0.
 
-:::danger:😓
+:::danger
 
 `dec` usually updates flags, but unfortunately `dec bc` doesn't, so we must check if `bc` reached 0 manually.
 

src/part1/memory.md

@@ -1,8 +1,8 @@
 # Memory
 
-:::tip:🎉
+:::tip Congrats!
 
-Congrats, you have just finished the hardest lessons of the tutorial!
+You have just finished the hardest lessons of the tutorial!
 Since you have the basics, from now on, we'll be looking at more and more concrete code.
 
 :::

src/part1/palettes.md

@@ -5,7 +5,7 @@ In the previous lesson, I briefly mentioned that colors are applied to tiles via
 The black & white Game Boy has three palettes, one for the background called [`BGP`](https://gbdev.io/pandocs/Palettes.html#ff47---bgp-bg-palette-data-rw---non-cgb-mode-only) ("BackGround Palette"), and two for the objects called [`OBP0`](https://gbdev.io/pandocs/Palettes.html#ff48---obp0-object-palette-0-data-rw---non-cgb-mode-only) and [`OBP1`](https://gbdev.io/pandocs/Palettes.html#ff48---obp1-object-palette-1-data-rw---non-cgb-mode-only) ("OBject Palette 0/1").
 If you are wondering what "objects" are, you will have to wait until Part Ⅱ to find out; for now, let's focus on the background.
 
-:::tip:🌈
+:::tip Colors
 
 The Game Boy Color introduced, obviously, colors, and this was mainly done by reworking the way palettes are handled.
 We will not talk about Game Boy Color features in Part Ⅰ for the sake of simplicity, but we will do so in later parts.

src/part1/registers.md

@@ -21,7 +21,7 @@ For now, let's focus on this small box near the top-right, the *register viewer*
 
 ![Picture of the register viewer's location](../assets/img/reg_viewer.png)
 
-:::warning:⚠️
+:::warning
 
 The register viewer shows both *CPU registers* and some *hardware registers*.
 This lesson will only deal with CPU registers, so that's why we will be ignoring some of these entries here.
@@ -37,7 +37,7 @@ Registers are pretty much the CPU's workspace.
 They are small, tiny chunks of memory embedded directly in the CPU (only 10 bytes for the Game Boy's CPU, and even modern CPUs have less than a kilobyte if you don't count <a href="https://en.wikipedia.org/wiki/SIMD"><abbr title="Single Instruction, Multiple Data">SIMD</abbr></a> registers).
 Operations are not performed directly on data stored in memory, which would be equivalent to breaking eggs directly inside our fridge, but they are performed on registers.
 
-:::tip:ℹ️
+:::tip
 
 There are exceptions to this rule, like many other "rules" I will give in this tutorial; I will paper over them to keep the mental complexity reasonable, but don't treat my word as gospel either.
 

src/part1/tilemap.md

@@ -1,6 +1,6 @@
 # Tilemap
 
-:::tip:🧐
+:::tip Nomenclature
 
 Some spell them "tile map", some "tilemap".
 I will be using the latter by preference, but I also stay consistent with it in the code (`Tilemap` and not `TileMap`), as well as later when we will talk about attribute maps ("attrmap" and `Attrmap` instead of `AttrMap`).

src/part1/tiles.md

@@ -1,6 +1,6 @@
 # Tiles
 
-:::tip:💭
+:::tip Nomenclature
 
 "Tiles" were called differently in documentation of yore.
 They were usually called "patterns" or "characters", the latter giving birth to the "CHR" abbreviation which is sometimes used to refer to tiles.
@@ -32,7 +32,7 @@ You can combine the various VRAM viewers by going to "View", then "Combine Video
 We will come to the other viewers in due time.
 This one shows the tiles present in the Game Boy's video memory (or "<abbr title="Video RAM">VRAM</abbr>").
 
-:::tip:🤔
+:::tip
 
 I encourage you to experiment with the VRAM viewer, hover over things, tick and untick checkboxes, see by yourself what's what. Any questions you might have will be answered in due time, don't worry! And if what you're seeing later on doesn't match my screenshots, ensure that the checkboxes match mine.
 

src/part1/tracing.md

@@ -23,7 +23,7 @@ Let's run RGBLINK to generate a sym file for our ROM:
 $ rgblink -n hello-world.sym hello-world.o
 ```
 
-:::warning:‼️
+:::warning
 
 The file names matter!
 When looking for a ROM's sym file, emulators take the ROM's file name, strip the extension (here, `.gb`), replace it with `.sym`, and look for a file **in the same directory** with that name.
@@ -35,7 +35,7 @@ When looking for a ROM's sym file, emulators take the ROM's file name, strip the
 When pausing execution, the debugger will automatically focus on the instruction the CPU is about to execute, as indicated by the line highlighted in blue.
 ![Screenshot of the debugger showing that the highlighted line corresponds to PC](../assets/img/pc.png)
 
-:::tip:ℹ️
+:::tip
 
 The instruction highlighted in blue is always what the CPU is _about to execute_, not what it _just executed_. Keep this in mind.