PS2 Julian's various PS2 projects (Worklog)

I ported the fps2bios modules to use the new toolchain with ps2sdk definitions. It's in the fps2bios branch of my ps2iop repository.

What's probably missing now:
fileio: backwards compatibility can probably be added to filexio.
igreeting
ioman: backwards compatibility can probably be added to iomanX.
loadfile
modload
reboot
romdrv
sifinit
stdio
threadman

For now, I'll focus on cdvdman/cdvdfsv and the various DVRP interface modules.

I'd like to make it so that CDVDMAN will return the correct data no matter if the disc is identified as a DVD Video or a PS2 DVD disc. I'd like to make this a "drop-in" module, so you can e.g. play DVD Video discs in the DVD player while still using MechaPwn, or emulate the DVD player in PCSX2.
 
As an alternative to interfacing with the IOMAN task on the DVRP, I made some changes to ps2sdk and wLE to access the "bhdd" device.

At the moment, this will not work standalone (without DVRP) for the following reasons:
1. The HDD is encrypted
2. The code relies on the non-48-bit LBA size returned by the emulated HDD by the DVRP

Also, write support is blocked. I think it should be done by using dvr_hdd / dvr_pfs anyways.

--

Fun fact: the compressed size of the boot sound (SNDSE00BD) is larger than the uncompressed size!
 
Last edited:
I decided to take a brief look at Namco System 246 modules. A few tidbits:

1. The arcade hardware appears to communicate via DEV9 (just like the DVRP and the network adapter)
2. The arcade hardware appears to have a FPGA? (DESR has one too…)
3. The arcade hardware appears to have mapped flash ROM (just like the DVD ROM or the Chinese font ROM)?

What files got symbols? I put a listing here… https://gist.github.com/uyjulian/f4c25ddaea40aa545fd3b2e274c82ee3
 
  • Like
Reactions: TnA
A description of the problem when using objdump -g…

Anonymous structures first defined in typedefs are described in the first function prototype encountered and not in the first time the typedef is encountered.

For such an example (from XZ Utils)…
Code: 
static void parse_real (register (struct %anon1 { /* size 40 */
  char **arg_names; /* bitsize 64, bitpos 0 */
  unsigned int arg_count; /* bitsize 32, bitpos 64 */
  char *files_name; /* bitsize 64, bitpos 128 */
  struct _IO_FILE /* id 2 */ *files_file; /* bitsize 64, bitpos 192 */
  char files_delim; /* bitsize 8, bitpos 256 */
}) *args /* 0xd */, register int argc /* 0x6 */, register char **argv /* 0x3 */);
and afterwards the typedef is described at…
Code: 
typedef struct %anon1 args_info;

But really, it should look like
Code: 
static void parse_real (register args_info *args /* 0xd */, register int argc /* 0x6 */, register char **argv /* 0x3 */);
and
Code: 
typedef struct %anon1 { /* size 40 */
  char **arg_names; /* bitsize 64, bitpos 0 */
  unsigned int arg_count; /* bitsize 32, bitpos 64 */
  char *files_name; /* bitsize 64, bitpos 128 */
  struct _IO_FILE /* id 2 */ *files_file; /* bitsize 64, bitpos 192 */
  char files_delim; /* bitsize 8, bitpos 256 */
} args_info;

3 years ago, I was thinking of post-processing the output of objdump -g. It was never finished.
I took a look at processing the STABS data directly in Python, but then I figured that it would be better to modify "prdbg.c" from binutils to output JSON instead of ^, and reorder the information in Python using the processed JSON data.
Even the Ghidra WIP STABS parser is a hackjob, so that is one of the reasons why I decided to modify objdump instead which already has a STABS parser and is probably the program that GCC will target for debugger usage.
 
I wrote some utilities to extract the .stab and .stabstr section out of ELF, and to also convert .mdebug section to the .stab/.stabstr format.

Current work is in stab_debuginfo_utils repository on my account; still working on JSON output patches to objdump…
 
I added a JSON output patch to objdump in stab_debuginfo_utils repository.

Next up…
* Moving around anonymous structures to their associated typedef instead of inside the function prototype
* Output to an industry-leading disassembler's scripting format
 
Mostly finished the script output. At this point, I think this is good enough to get started.

At the moment, the following are missing:
* C++ types
* Global variable types
* Local variables
 
I fixed .mdebug section to .stab / .stabstr section conversion.
The string offsets weren't getting calculated correctly for multiple compilation units.

A known limitation is that it only supports 32-bit source files.

Also, I fixed the script output so that global variables types are now added. For now, you need to run the script twice due to interdependency issues.

---

Little note…
ACCDVD is CDVDMAN compatible with arcade interface (ATAPI)
ACCDVDE is CDVDFSV compatible with arcade interface (ATAPI)

It would be interesting to use ATAPI B/C/DVD disk drives with the network adapter…
 
For trimming down CDVDMAN/CDVDFSV, I removed the following:
* ISO filesystem parsing (the CDFS module does a better job with long filename support anyways)
* Most S-commands are removed (use sceCdApplySCmd instead)
* Stream commands
* Sector commands
* Key / encryption functions
However, the following is added compared to the ROM 1.3.4 version:
* Dual layer support

Basically, I'm aiming for a minimum library to handle CDVD related functions.
 
I've been wondering about…
* How to enable CDVD interrupt power button handling by software
It seems like this gets done when loading dev9, but I'm not too sure which register write etc. controls this behavior…

* How to control the disk access LED
It turns out the disk access LED is connected to the expansion bay connector without any chips in between… so you need to use the SPEED chip to control the disk access LED.

* How to control the fan speed on older SCPH-3xxxx models
It looks like the PWR_CTRL / POW_CTRL line is connected to both the expansion bay connector and the SYSCON.
I wonder if it would be possible to toggle 0xBF80146C in such a way that there the dev9 device remains powered on while the fan speed remains low…
 
I sent pull requests to ps2sdk and wLaunchELF that allows filesystem access to the dev9 external flash rom.
I also sent some 48-bit LBA related fixes which should match up more with the original atad. 48 bit commands are only used if necessary (and they won't work for write access).

I'm working on getting the filesystem interface working so that write access is possible.
For some reason, the filesystem interface times out. It seems like 0xB0004230 & 0x2 is stuck…
 
Last edited:
I checked the drivers between 1.31 and 2.11, and there doesn't seem to be major changes in pvrdrv.

I tried a no-op devctl:
Code: 
fileXioDevctl("dvr_misc:", 0x5664, NULL, 0, NULL, 0)

but it times out because of the 0xB0004230 & 0x2 stuck issue.

I wonder if sceCdXLEDCtl has anything to do with it… but I'll need to finish the CDVDMAN/CDVDFSV reimplementation first.
 
I sent relevant pull requests to ps2sdk and wLaunchELF for dvr_hdd0: access. This should allow accessing of the >137GiB portion of the disk, since the DVRP errors on the 48-bit commands.

This is probably the last thing I'm going to work on for this break. Until next break, I guess…
 
I'm thinking of writing a new host: filesystem driver that uses UDP. After writing the iomanX->FUSE interface and dvrfile driver, I think I have a better idea of what to do.

That will probably get started after I'm less busy with moving… I'm also going to see if some people at uni are interested in this sort of stuff…
 
The PS2 is the perfect place to learn easy and complex stuff from all varieties of coding-fields and IT.
Graphics, encryption, embedded platform (hence skills regarding optimization, etc.), the SDK&Toolchain and so on are ALL interesting fields.

It's actually a very good learning object and subject for students! Most Universities rather go for teaching the embedded stuff on a RasPi, ARMadillo (or how the name was), ATMega, ESP8 or ESP32, and I forgot one VERY known board used in the maker-scene, etc., graphics via a HAL and usually on PC instead of directly, no manual setup for basically everything, but via APIs, HALs/ALs, abstractions, OS drivers, more abstractions... :P lol
 
Random idea...
It would be interesting to have a network adapter that could do...
1. emulate 40GB HDD
2. emulate CDVD drive (for SCPH-3000x only since the pins are connected there)
3. emulate DVRP filesystem interface (no more fragmentation or filesystem issue, just drag and drop)
4. gigabit ethernet (like PS3) (but in practice max speeds won't be reached)
5. SATA
6. wake on LAN
7. IOP processor override/redirect to emulated IOP processor

... but for now, I'll probably look into the software for now, when I have time in around 3 months. Hardware isn't very useful without software to go with it (see: the remaining issues with MX4SIO and Open PS2 Loader)
 
It looks like Raspberry Pi has an undocumented high speed bus SMI, and looks like the PiStorm project is successfully using it to interface with Amiga hardware with better CPU usage and speed.
I wonder how hard it would be to interface with the Expansion Bay connector on the PS2 with a Raspberry Pi... I'll probably investigate this later...

--

I've been thinking for a while based on the speeds/performance off udpbd... There probably isn't enough bandwidth for raw 1080i@60, but I wonder if it would be possible to use e.g. mpeg2 or mpeg4 compression... Another reason to finish up the libmpeg2 and SMS fixups for the new toolchain...
 
You must log in or register to reply here.

Similar threads

Back
Top