diff --git a/maze_solver_design_report.md b/maze_solver_design_report.md
index cffcbc9..c4cd151 100644
--- a/maze_solver_design_report.md
+++ b/maze_solver_design_report.md
@@ -115,7 +115,7 @@ Since we transformed the absolute wall configuration to a relative one, there is
 
 In the datapath, this is as easy as selecting the right bit, then the up bit, then the left bit, etc. of the relative wall config to see if there's a wall there (this happens in the `wall_check` module of the datapath). We invert the wall input so if there is no wall and the move is valid, the `val_move` flag goes high. This flag is an input to the FSM.
 
-> *Example: Our relative wall config is 1100, which means we can't go right or up. We can go left (11), so we'll choose that move.*
+> *Example: Our relative wall config is `1100`, which means we can't go right or up. We can go left (`11`), so we'll choose that move.*
 
 The relative move is saved to the `rel_move_reg` register. Now we can tranform our relative move to an absolute move. This is done simply by adding our relative move to our absolute direction, and happens in the `rel_to_abs_alu` module.
 
@@ -125,7 +125,7 @@ The relative move is saved to the `rel_move_reg` register. Now we can tranform o
 
 We now have our absolute move, which is saved to the `abs_move_buf` register and is an input to the `back_test` module. The second input to the `back_test` module is the value at the top of the stack, representing the last valid move pushed to the stack. The `back_test` module checks to see if these moves are opposite; in other words, if the current move and the top move of the stack are inverse (up & down, or left & right), we know we are backtracking. If so, the back_test module sets the `back_flag` to `1`.
 
-> *Example: If the last absolute valid move was left (`11`), and our current absolute move is down (`10`), then we are **not** backtracking because these are not inverses. The back_flag is **not** set to `1`.*
+> *Example: If the last absolute valid move was left (`11`), and our current absolute move is down (`10`), then we are **not** backtracking because these are not inverses. The `back_flag` is **not** set to `1`.*
 
 ### Storing the Correct paths
 
@@ -147,21 +147,21 @@ The current move is translated into an ALU operation and input like this:
 
 The `x_y` bus is added to or subtracted from the current address to form the next address, stored in the `next_addr_reg` register and split into its x and y chip outputs with the `addr_split` module. This address is requested from memory.
 
-> *Example: Let's say our previous address was [x,y] = [13,5] (11010101), and our current move is left (11). We subtract 1 from the x coordinate: 11010101 - 00010000 = 11000101, which is [12, 5]. The outputs x = 12 and y = 5 are requested from external memory.*
+> *Example: Let's say our previous address was [x,y] = [13,5] (`11010101`), and our current move is left (`11`). We subtract 1 from the x coordinate: `11010101` - `00010000` = `11000101`, which is [12, 5]. The outputs x = 12 and y = 5 are requested from external memory.*
 
 The final part of the main FSM loop involves updating the internal registers. The current move is written to the abs_dir_reg, since it is not the absolute direction we are travelling through the maze. The current address is updated to the next address. The FSM then returns to S1 where it waits for the next input.
 
-> *Example: The current move, left (11), is written to the abs_dir_reg register. The address stored in the next_addr_reg register, 11000101, is stored in the cur_addr_reg register.*
+> *Example: The current move, left (`11`), is written to the `abs_dir_reg` register. The address stored in the `next_addr_reg` register, `11000101`, is stored in the `cur_addr_reg` register.*
 
 ### Outputting the Solution
 
-When the chip has reached the end of the maze, it's time to send the solution. This is all implemented in the FSM and stack. Details on the stack implementation can be found [here](###the-stack).
+When the chip has reached the end of the maze, it's time to send the solution. This is all implemented in the FSM and stack. Details on the stack implementation can be found [here](#stack).
 
-The stack has an internal pointer, separate from the stack pointer, which starts at stack address 0 and can be incremented by the FSM with the stack_sol_inc signal. The FSM increments this pointer and checks to see if it has reached the end of the path with the stack_ptrs_eq flag, set by the stack when the output pointer has reached the top of the stack, marked by the stack pointer. 
+The stack has an internal pointer, separate from the stack pointer, which starts at stack address `0` and can be incremented by the FSM with the `stack_sol_inc` signal. The FSM increments this pointer and checks to see if it has reached the end of the path with the `stack_ptrs_eq` flag, set by the stack when the output pointer has reached the top of the stack, marked by the stack pointer. 
 
 On each increment of the solution pointer, the FSM...
-1. enables the sol_reg register, writing to the solution [1:0] output pins, and 
-1. sets out_val to 1, marking the output valid.
+1. enables the sol_reg register, writing to the `solution [1:0]` output pins, and 
+1. sets `out_val` to 1, marking the output valid.
 
 This marks the end of the datapath.
 
@@ -470,7 +470,7 @@ endmodule
 
 The module has two separate internal wires for x and y called `add_x` and `add_y`, which it combines into the single `x_y` output with an `assign` statement. We chose this design so the module can be expanded according to the `MAX_SIZE` parameter.
 
-See the previous section for details on the move conversion logic.
+See the previous section for details on the [move conversion logic](#updating-the-next-address--internal-registers).
 
 ### Splitter