Add the undocumented GS registers to the SVD

[zachary-cauchi]

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:

• [x] Create a list of documentation referenced for these registers.
• [x] Create a list of registers discovered through the associated documentation.
  • Document their potential purposes, citing used sources.
• [x] 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.

[zachary-cauchi]

Current documentation:

1. ps2tek
2. Sony's official PS2 Linux gs.h
3. Sony's official PS2 Linux ps2gs.c
4. frno7/linux
5. ps2sdk
6. EE User's Manual
7. GS Mode Selector App dev diary (source)
8. pcsx2

[zachary-cauchi]

GS Privileged Registers [6]

• [x] PMODE - Various modes for the Programmable CRT Controller (PCRTC).
• [x] SMODE1 - Related to sync
  • Could not find info for all fields. Pending fields: EX, XPCK, PCK2, PHS, PVS, PEHS, PEVS, CLKSEL, NVCK, SLCK2, VCKSEL.
  • VCK - calculation
• [x] SMODE2 - Related to sync
• [x] SRFSH - DRAM refresh
• [x] SYNCH1 - Related to sync
• [x] SYNCH2 - Related to sync
• [x] SYNCV - Related to sync / start
• [x] DISPFB1 - Related to the display buffer for Rectangular Area 1
• [x] DISPLAY1 - Rectangular Area 1 display position etc
• [x] DISPFB2 - Related to the display buffer for Rectangular Area 2
• [x] DISPLAY2 - Rectangular Area 2 display position etc
• [x] EXTBUF - Rectangular area write buffer
• [x] EXTDATA - Rectangular area write data
• [x] EXTWRITE - Rectangular area write start
• [x] BGCOLOR - Background color
• [x] CSR - Various GS statuses
• [x] IMR - Interrupt mask
• [x] BUSDIR - Host interface switching
• [x] SIGBLID - SIGNALID / LABELID

[Ravenslofty]

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.

[zachary-cauchi]

That would be perfect. I'll try find the exact code it uses and include a link in the register entry.

[Ravenslofty]

(I added the official PS2 Linux GS driver in there, as well as the gs.h definitions)

[zachary-cauchi]

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?

[Ravenslofty]

actually, if you read through the frno7/linux driver, it's really clear, and that's quite promising.

[Ravenslofty]

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.

[zachary-cauchi]

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.

[zachary-cauchi]

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.

[zachary-cauchi]

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?

[Ravenslofty]

Another reference from past me: https://github.com/frno7/linux/issues/10

[Ravenslofty]

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.

[zachary-cauchi]

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.

[zachary-cauchi]

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.

[Ravenslofty]

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

[zachary-cauchi]

Fair point. In that case, I'll confirm that it compiles then open a PR shortly after.

[zachary-cauchi]

PR is up. When you can, would you please give it a look?

[Ravenslofty]

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.

[zachary-cauchi]

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.

[zachary-cauchi]

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?

[Ravenslofty]

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.

[zachary-cauchi]

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?

[Ravenslofty]

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.