Closed zachary-cauchi closed 4 months ago
GS Privileged Registers [6]
I think the unofficial driver at least provides the formulae for the pixel clock based on the SMODE1
fields, and the various porches needed for correct signal timing; that can be used as a basis for an implementation for our own SetGsCrt
equivalent.
That would be perfect. I'll try find the exact code it uses and include a link in the register entry.
(I added the official PS2 Linux GS driver in there, as well as the gs.h
definitions)
I found this section in ps2sdk that seems to break down some default configurations for SMODE1. Right above it are the presets the values correspond to. Do you think these might be of some help?
actually, if you read through the frno7/linux driver, it's really clear, and that's quite promising.
I found this section in ps2sdk that seems to break down some default configurations for SMODE1. Right above it are the presets the values correspond to. Do you think these might be of some help?
While I think they are, the frno7 driver seems to derive the values from first principles (but uses the Sony defaults to tiebreak), and I think that would be a more general approach than trying to hardcode some tables.
While I think they are, the frno7 driver seems to derive the values from first principles (but uses the Sony defaults to tiebreak), and I think that would be a more general approach than trying to hardcode some tables.
True, makes for a more robust implementation like that. I'm going to begin working on the SVD definitions, at least going through them bit-by-bit (pun intended) and taking notes either there or in this list.
Made some small progress: Added definitions for the PMODE
and SMODE1
registers. Definitions are currently defined in their own peripheral since I saw mentioned in the EE User's Manual that they may be accessed directly without manual GIF configuration. Although, it apparently uses the GIF all the same to fetch the values, so I suppose they may need to be moved to the GIF peripheral.
Another thing: I saw reference to a ps2gs_en.txt file in the official PS2 linux distro but I can't find it online. If you happen to stumble upon it, would you please let me know?
Another reference from past me: https://github.com/frno7/linux/issues/10
Another thing: I saw reference to a ps2gs_en.txt file in the official PS2 linux distro but I can't find it online. If you happen to stumble upon it, would you please let me know?
Nope, no luck finding it.
Another reference from past me: frno7/linux#10
Thanks!
Nope, no luck finding it.
No problem. So far, I've been finding all the crucial information, so I guess we're not missing out. Will continue tomorrow by starting with SMODE2
.
All the undocumented registers listed in the EE_Users_Manual are now in the SVD. I tried piecing together as much as I could from the various sources listed above. I'll continue refining the SVD, entering in the last missing bits of data, tightening the access fields and use cases, and making sure it compiles using svd2rust
.
Even though it's unrefined, that seems like a good checkpoint to merge progress; it's not like we presently have any users to break /j
Fair point. In that case, I'll confirm that it compiles then open a PR shortly after.
PR is up. When you can, would you please give it a look?
https://www.psx-place.com/threads/request-im-collecting-info-about-ps2-consoles-revisions.23276/page-3 (search for "identifying EE chips")
Not GS-related, but this has some fairly interesting information about an undocumented part of the memory map.
https://www.psx-place.com/threads/request-im-collecting-info-about-ps2-consoles-revisions.23276/page-3 (search for "identifying EE chips")
Not GS-related, but this has some fairly interesting information about an undocumented part of the memory map.
Ooh, that's interesting. Thanks for the link, shall go through it after work! The more the merrier.
Now that this is merged into master, I presume this issue can be closed. What's the plan now? Should we set up a script to generate the a lib.rs
file from the SVD file?
I try to stay within the rust-embedded conventions; what we have here is a peripheral access crate (PAC). playstation2
is an available crate name, so we might as well use it for the generated lib.rs; let's leave the "prussia" crates for the SDK built on top.
I do think we should migrate the documentation references into a new issue though.
I try to stay within the rust-embedded conventions; what we have here is a peripheral access crate (PAC).
playstation2
is an available crate name, so we might as well use it for the generated lib.rs; let's leave the "prussia" crates for the SDK built on top.
I see, so this PAC would house everything needed to abstract away how Rust deals with memory on the target platform (the PS2 in our case) such as our SVD? In that case, shall I create the playstation2
crate, copy over the SVD file, and continue from there?
I do think we should migrate the documentation references into a new issue though.
True, this issue served its purpose. How about including the documentation as a bibliography of sorts in the prussia wiki?
I try to stay within the rust-embedded conventions; what we have here is a peripheral access crate (PAC).
playstation2
is an available crate name, so we might as well use it for the generated lib.rs; let's leave the "prussia" crates for the SDK built on top.I see, so this PAC would contain house everything needed to abstract away Rust is implemented on its target platform (the PS2 in our case) such as our SVD? In that case, shall I create the
playstation2
crate, copy over the SVD file, and continue from there?
PACs seem to be safe but very low level; SVD lets us create a safe wrapper over the various registers, but doesn't have any abstractions. I think trying to use the PAC directly would be... miserable, to say the least.
I do think we should migrate the documentation references into a new issue though.
True, this issue served its purpose. How about including the documentation as a bibliography of sorts in the prussia wiki?
Sure.
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: