- Nov 14, 2021
-
-
Geo Ster authored
* Since we have encountered our first FPU register, add the 32 floating point registers to the CPU. * In addition solve a small bug in the JAL instruction related to the return link address. See previous commit for details
-
Geo Ster authored
* Having the header files in a seperate dir is only useful when developing libraries that are meant to be used by other programs. In our case though it makes the file structure more tedious so gather everything in one place.
-
Geo Ster authored
* std::cout is not fit for our usecase, which is format heavy output. This results in a lot of code bloat from switching between std::dec and std::hex. Switching to fmt yields significantly cleaner code.
-
- Nov 13, 2021
-
-
Geo Ster authored
* This is only supported on GCC/Clang making compilation fail on MSVC. In addition we don't really need this since accessing the entire 128bit register is very rare and can be emulated by setting each of 64bit parts seperately.
-
Geo Ster authored
* Nothing special really, just adding more instructions and fixes minor bugs to progress further
-
- Nov 04, 2021
-
-
Geo Ster authored
* Currently the BIOS tries to write something to scratchpad and it fails because its address is not our currently supported range. So add a new buffer for the 16KB scratchpad used by the CPU and add a function to use it if the address is in the correct range. * Also shorten some function names and change some array to C-style because we like to work with pointers and STL doesn't like that.
-
Geo Ster authored
* COP0 instructions sadly have way too many encoding to use a single template one them, so rewrite the decoder to manually extract the required bits for each instruction. This fixes a bug where the MTC0 instruction was mistaken for MFC0. * Implement more instructions so we can execute more of the BIOS. In addition fix an oopsie in the ORI instruction which fixes some bugged memory writes. As of now the BIOS tries to write address 0x70003fe0 which maps to the scratchpad memory (assuming no further logic errors are present). Need to investigate why this is and how to emulate it before continuing...
-
- Nov 03, 2021
-
-
Geo Ster authored
In addition: * Correct register notation (word refers to a 32bit quantity not 16bit) * Simplify sign extension casing * Add more useful logging
-
- Oct 31, 2021
-
-
Geo Ster authored
* Now that the BIOS is loaded we can start executing it! The starting address the EE uses is 0xbfc00000 which maps to KUSEG1. Since all KUSEG regions except KUSEG2 are mirrors of each other we only need to translate the address to the KUSEG appropriate. * The functional differences between KUSEG0/1 are minimal and very niche so I won't bother emulating them now. Address wise we can notice that the only difference between addresses is the most significant half byte. By using that byte as an index in a mask table we can define an appropriate mask for each KUSEG address. Idea taken from a very handy PSX document I discovered last year [1] [1] https://svkt.org/~simias/guide.pdf (43)
-
Geo Ster authored
* The ps2tek documentation states the memory map clearly [1]. It seems to have a similar architecture with the PSX, where the main memory map (KUSEG0) is mirrored in multiple regions (KUSEG1/KUSEG2) with different access patterns for each region. For now we don't have to emulate all of them, just the main memory map. * Allocate the entire 512MB memory into an array and make a convenient struct to abstract memory range operations. [1] https://psi-rockin.github.io/ps2tek/#memorymap
-
Geo Ster authored
* This commit adds a most basic CPU class that acts as a template which we will slowly build. * The architecture is pretty simple; the ComponentManager will create all the seperate components (EE, VP, IOP, GS etc) as unique_ptr's since it owns them and only it has access to them. All the other components must pass through the manager to read/write data to memory. To achieve this they are given a pointer to the ComponentManger in their constructor. * For now the CPU directly accesses the bios which shouldn't happen but will be fixed eventually when I implement generic read/writes. The goal is to start implementing the CPU as fast as possible in order to get to the GPU/VPU's and display something!
-