Skip to content
Snippets Groups Projects
  1. Nov 03, 2021
    • Geo Ster's avatar
      Set correct processor prid · fd3f2c31
      Geo Ster authored
      * As this very useful document describes [1]
      the BIOS first checks the prid of COP0 to decide
      whether to execute the IOP or EE boot sequence.
      Without this the BIOS doesn't execute the code we want.
      The code sequence that determines this is added below as
      suedo assembly
      
      MFC0: GPR[26] = COP0_REG[15] /* Load cop0 prid to GPR 26 */
      SLTI: GPR[1] = GPR[26] < 89 /* Check if its value is less than 0x59 and store the bool in GPR 1 */
      BNE: if GPR[0] != GPR[1] then pc += 20 /* If the comparison is true then jump +20 to IOP */
      
      [1] https://rust-console.github.io/ps2-bios-book/print.html
      [2] https://psi-rockin.github.io/ps2tek/#biosbootprocess
      fd3f2c31
    • Geo Ster's avatar
      Implement ORI/ADDI/LQ · ebf1986d
      Geo Ster authored
      In addition:
      * Correct register notation (word refers to a 32bit quantity not 16bit)
      * Simplify sign extension casing
      * Add more useful logging
      ebf1986d
    • Geo Ster's avatar
      Handle branch delay slots · 2f7596b8
      Geo Ster authored
      * MIPS has an architectural feature, where instead of flushing the
      pipeline when executing a branch instruction, it goes ahead and executes
      the instruction following the branch as well. Flushing the pipeline
      is costly and is the cause of those complex branch predictors on
      modern CPUs that try to guess when a branch will be taken.
      
      * To properly emulate this behaviour we must act how the pipeline acts. We
      will always have 2 instructions loaded the current one and the next one. This way
      we can load the instruction after the branch even though the pc changes.
      2f7596b8
    • Geo Ster's avatar
      Implement first instructions mfc0/sw/bne/sll · 0e09c3a1
      Geo Ster authored
      * The instruction decoding was based on the handy table in ps2tek [1]
      while the instructions themselves were written based on the document
      added.
      
      * The implementation makes heavy use of bitfields and unions in C++ to
      make accessing different bits/sections of registers easier and more
      intuitive. You may also notice the frequent casting (uint32_t)(int16_t)
      which might seem useless but is there to force the compiler to generate
      instructions to sign extend the offsets.
      
      [1] https://psi-rockin.github.io/ps2tek/#eeinstructiondecoding
      0e09c3a1
  2. Oct 31, 2021
    • Geo Ster's avatar
      Implement read/write operations and KUSEG regions · 8653f76f
      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)
      8653f76f
    • Geo Ster's avatar
      Add initial EE/Bus implementations · 2ad0640f
      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!
      2ad0640f
Loading