ravenslofty / prussia Goto Github PK

As was highlighted in this comment on #18, there are two big advantages to supporting virtual memory that warrant implementing support for the TLB. To support this, we should add support for the TLB-related registers and instructions.

Definition of Done:

• Add support for the TLB-related registers in the EE Core Users Manual.

• figure out what to do about CPU exceptions; debugging quality-of-life is going to be really important to avoid misery.
• inside what would presumably be prussia_gs, reimplement SetGsCrt for setting screen resolution. (note to self: or do I just have one huge prussia crate?)
• revisit prussia_dma to improve its safety; while it's apparently possible to directly poke the GS registers to draw things, it's more efficient to transfer things through DMA, since once a DMA transfer is started the EE can do other things. This probably means we need to come up with a DMAtag builder.
• inside either prussia_gif or prussia_gs, provide a GIFtag builder, and then we can provide a GS builder that wraps that. (yes, it's abstractions all the way down)
• write some form of GS allocator to setup a framebuffer for each field inside GS memory
• build a triangle inside the current field, DMA it to the GIF, wait for vsync interrupt, update DISPFB1/DISPFB2 (whichever we choose) to point to that field.
• triangle?

With the steady progress on the given SVD file, and a newly-created Peripheral Access Crate as discussed in #13, having a place to track progress/completed tasks would be useful for all contributors and owners and allow for better coordination of tasks and what order to prioritise them. It doesn't need to be detailed or formal, even a single issue would help.

Definition of Done

• Create a roadmap/task list to track important features, tasks, or similar objectives.
• Move in the existing feature goals from README.md into this new destination.
• Establish a milestone and plan out the must-haves leading up to that milestone.

With #19 merged in, we now have access to the CoP0 exception-related registers, meaning we can create basic exception-handling.

Definition of Done:

• Create a basic panic handler, if possible using Rust's panic_handler function.
• Dump the values of the exception registers (such as CoP0.Cause) to EEOut.

Some open questions:

• Wrap all syscalls? (Even the undocumented ones)
• Wrap useful syscalls? (Nobody cares about _ExceptionEpilogue, right?)
• Implement it all in Rust? (as much as I'd like to, this might bloat executables a bit).

This would allow buffers that are not 'static to be safely used.

I read some comments in the code and you seem to want to be able to run it on the stable toolchain. Maybe change that?

To begin work on exception-handling, there would first need to be support for the EE exception registers. These are listed in Chapter 3.2 of the EE Core User's Manual.

Definition of Done:

• Add all exception-related CoP0 registers to the CoP0 routines in prussia_rt/src/routines.S.
  • BadVAddr
  • Count
  • Compare
  • Status
  • Cause
  • EPC
  • BadPAddr
  • Perf
  • ErrorEPC

Following the discussions in issue #9, there is incentive to remove dependency on the BIOS outright to free up much-needed resources (approximately 1MB of RAM). The only reason so far to hold onto the BIOS is the setGsCrt syscall, which configures the video mode used by the PS2. This syscall sets a number of registers to enable the correct video output, but these registers are undocumented.

If these registers were documented, and defined in the ps2.xml SVD file, then we can reverse engineer the syscall to identify what values are set in which registers and cut out the syscall completely. Currently, the only known sources of documentation for these are found in Sony's official PS2 Linux distribution, this unofficial linux driver, and ps2tek.

Definition of Done:

• Create a list of documentation referenced for these registers.
• Create a list of registers discovered through the associated documentation.
  • Document their potential purposes, citing used sources.
• Include definitions for these registers in the SVD file.
  • This step does not expect total coverage since no formal documentation exists, but majority coverage is desired.
  • Give as detailed an explanation within the SVD files as possible to serve as additional documentation.

For ABI reasons, linking to PS2SDK from Rust isn't a feasible approach.

So, five years ago, I hatched a plan: if the data in the official manuals could be encoded in System View Definition then a tool like svd2rust could be used to generate a set of register bindings and remove the misery of manually abstracting over all the things in the PS2. It seemed like a good idea at the time.

Unfortunately, I majorly underestimated the effort it would take to encode data into SVD; the manuals are PDF format, and are too irregular to attempt to parse directly - you would be writing almost as many exceptions as you would be writing parsing rules.

The only way I've found that reliably works is to write the SVD by hand, referencing the manuals. Understandably, pretty much everybody who comes across this project and asks how they can help gets cold feet after I explain this to them.

I don't really know how to resolve this problem, and that's why this project hasn't seen activity in five years.

I don't know if anybody will come across this issue and offer assistance in doing mind-numbing work, but perhaps this can offer an explanation for why things are stuck.

What version/flavor of binutils is required use prussia? And how did you install/compile it?

The ps2toolchain project uses binutils 2.14 with this patch: https://github.com/ps2dev/ps2toolchain/blob/master/patches/binutils-2.14-PS2.patch