fix markdown for document converter

2 files changed, 24 insertions, 22 deletions

diff --git a/docs/architecture.md b/docs/architecture.md
index 4ebc674..9c1e5f5 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -14,10 +14,10 @@ Important notes:
 
 The playable character has 4 actions that it can perform:
 
--	horizontal movement
+- horizontal movement
 - aiming
--	jump 
--	ability / use
+- jump 
+- ability / use
 
 To perform these action there will be 6 buttons for the user to use.
 
@@ -51,11 +51,12 @@ The game engine will be designed to support 2D games. The engine will use a stat
 FSM is a useful tool for managing game states and transitions. A game can have many different states, such as a title screen, a level selection screen, a loading screen, and various gameplay states. Each state represents a particular configuration of the game, with different sets of variables, objects, and logic
 
 The state machine will be designed with the following states:
-1.	Initialization: The initialization state will be responsible for initializing all game-related variables and subsystems, including the FPGA-based picture processing unit.
-2.	Title Screen: The title screen state will display the game's title screen and wait for user input to start the game or access the options menu.
-3.	Options: The options state will allow the user to configure game settings, such as sound and graphics options.
-4.	Game Play: The game play state will be responsible for running the game logic and updating the game state.
-5.	Game Over: The game over state will display the game over screen and wait for user input to restart the game or return to the title screen.
+
+1. Initialization: The initialization state will be responsible for initializing all game-related variables and subsystems, including the FPGA-based picture processing unit.
+2. Title Screen: The title screen state will display the game's title screen and wait for user input to start the game or access the options menu.
+3. Options: The options state will allow the user to configure game settings, such as sound and graphics options.
+4. Game Play: The game play state will be responsible for running the game logic and updating the game state.
+5. Game Over: The game over state will display the game over screen and wait for user input to restart the game or return to the title screen.
 
 # PPU
 
@@ -275,6 +276,7 @@ The Audio Processing Unit (APU) is programmed on the FPGA, here it will produce
 These signals will be generated using PWM, this allows a digital signal to act as an analog signal. Using this method it is theoretically possible to create all of the aforementioned signals.
 
 ![Audio signal with PWM](../assets/audioPWM.svg)
+
 This figure shows an example signal (in blue), created by the FPGA. and the corresponding analog signal (in red).
 
 
diff --git a/docs/research.md b/docs/research.md
index ecabfe6..a7a6dcb 100644
--- a/docs/research.md
+++ b/docs/research.md
@@ -234,21 +234,21 @@ There are a lot of ways of creating tiles and sprites for pixel art. Underneath
 
 The playable character has 4 actions that it can perform:
 
--	horizontal movement
+- horizontal movement
 - aiming
--	jump 
--	ability / use
+- jump 
+- ability / use
 
 To control these actions there has to be at least 4 inputs. 
 These can either be a button or joystick. 
 The actions can be done as follows:
 
-| Action | Button |	Joystick |
-| ------ | ------ | -------- |
-| Movement | 	x | x |
-| Aiming | 	x | x |
-| Jump |	x	 |  |
-| Ability | 	x	|  |
+| Action   | Button | Joystick |
+| -------- | ------ | -------- |
+| Movement | x      | x        |
+| Aiming   | x      | x        |
+| Jump     | x      |          |
+| Ability  | x      |          |
 
 ## Handling
 
@@ -271,12 +271,12 @@ This will decrease the delay between the user-input and onscreen gameplay.
 
 The hardware of the game consist out of a microcontroller(stm32) and a FPGA(basys3). The hardware components needs to communicate with each other. For this a protocol is needed.
 See table 1 for a comparison of possible protocols:
-| Protocol |	UART |	I2C	| SPI |
+| Protocol | UART | I2C | SPI |
 | -------- | ----- | ---- | --- |
-|Number of lines |	1/2 |	2 |	4 |
-|Duplex	| Half-duplex	| Half-duplex	| Full-duplex |
-|Data transfer speed |	Upto 5mbps | Upto 3.4Mbps – 5Mbps	| Default at 50Mbps. Upto 100Mbps |
-|Speed	| Slowest |	Faster than UART | Fastest |
+|Number of lines | 1/2 | 2 | 4 |
+|Duplex | Half-duplex | Half-duplex | Full-duplex |
+|Data transfer speed | Upto 5mbps | Upto 3.4Mbps – 5Mbps | Default at 50Mbps. Upto 100Mbps |
+|Speed | Slowest | Faster than UART | Fastest |
 
 There are only two devices that has to be connected. Complexity and master/slave amount are not relevant for this purpose. 
 If there are multiple entities the delay will increase and decreases the playability of the game.