PS2 Julian's various PS2 projects (Worklog)

I finished up making progress with making iomanX more portable.
I also went ahead and finished up the libsecr/secrman/secrsif integration into ps2sdk.

Another thing I could finish up real quickly is the romdrv integration and the partition/filesystem check module integration.
 
Okay, I've done a quick search.

There appears to be two source available sequenced music players available: amigamod and AHX.

The deal with these two players, however, is that it mixes the sequenced data on the IOP into PCM, then uses the SPU2 to play them back.

What I'm really looking for is a sequenced data player that has samples stored in ADPCM, then uses the SPU2 to play them back.

So, I guess I'll add reversing modhsyn.irx and modmidi.irx to the backlog.

This should at least allow me to have the entire sequenced audio playback stack from PSF2 to .bd/.hd/.sq to SPU2 be a "white box", making things easier to understand instead of me just throwing random stuff at the wall until it works.
 
A little tidbit:

The font used for the "PlayStation 2" logo used in PS2LOGO and embedded in discs, and also the incorrect disc / red screen of death menu in OSDSYS appears to be the "Zrnic" font.

The font used for the menus in OSDSYS (At least for Latin based character sets) appears to be Helvetica, but stretched and outlined. I'm not sure what font is used for the other supported locales.
 
It seems like it would be easier to implement SSL using wolfSSL instead of mbedTLS. I just sent a patch to wolfSSL to handle 32 bit pointers / ABI on mips64.

Also, wolfSSL supports TLS 1.3. I'm not sure what version of TLS that mbedTLS uses.

---

I'm planning to introduce a patch to shim/emulate openat/fchdir/etc. to newlib for those platforms that don't support it. The goal is to have libarchive "just work" without any additional changes.
 
I sent a patch to ps2sdk to improve old SIO2MAN / PADMAN compatibility, mainly used for old homebrew.

For SIO2MAN, I made it reflect the behavior of the original module, while for PADMAN, I only adjusted the EE RPC interface and the interface to SIO2MAN (other internals were not adjusted, like MCMAN old variant).

My eventual goal is to make old homebrew work, mostly unmodified with OSS IOP modules, when loaded from wLE from e.g. arcade or TOOL consoles, which has newer IOP modules in its ROM with incompatible RPC interfaces.
 
Some small snippet relating to interfacing Raspberry Pi Pico with dev9...

Looks like there are 16 address lines and 16 data lines on expansion bay connector.
I believe the voltage of those address lines and data lines coming out of the SSBUS controller into the expansion bay connector is 3.3 volts so no level shifters needed.

Now... Raspberry Pi Pico has 26 GPIO. If I wanted "more" GPIO I would probably need to grab 2 Raspberry Pi Picos, connect the first one to address lines, the second one to data lines, then to each other just SPI lines.

Lame, inefficient hardware usage, but it might work
 
These would be some assorted user stories/use cases for reversing each module and then compiling them/implementing features for the PPC IOP:

SYSMEM: How would I allocate memory in the 4MB total space of the IOP?
LOADCORE: How would I load PPC relocatable executables?
EXCEPMAN: How would I handle exceptions when PPC reads at an invalid address?
INTRMANP/INTRMANI: How would I handle saving/restoring PPC registers and calling native PPC interrupt handlers?
TIMEMANP/TIMEMANI: How would I handle timers that were based on the clock speed of the MIPS to be translated to the PPC clock speed?
DMACMAN: How would I do DMA transfers inside the 4MB total space of the IOP?
SYSCLIB: How would I accelerate commonly used C functions using native PPC code?
THREADMAN: How would I handle thread management in coexistence with the PPC, especially when mixing PPC native and MIPS native code?
REBOOT: How do I properly reload DECKARD to its initial state?
 
I believe these are the remaining pieces in order to make old homebrew more compatible with systems with newer/different boot ROM versions, like the arcade systems and TOOL systems:

* Implementation of old version of FILEIO RPC server
* fileXio and ps2link more dynamic retrieval for grabbing the file handles and device tables from ioman
* Multi version handling for SBV patches regarding the device blacklist/whitelist for elf/irx loading
 
The ps2dev OCI container is now on GitHub Container Registry, in addition to DockerHub.

This allows access to more countries and can avoid the potential rate limiting that DockerHub may activate.

---

For implementing the PS2 clock animations in glTF, I think it should be possible to just use linear and spherical linear interpolation.
 
I went ahead and labeled most of the IOP base modules from 1.3.4. Haven't finished typing them, however.

What I've found:

* UDNL doesn't call the export at index 2 of each module, unlike RebootStart in MODLOAD
* When reset packet comes from EE, it gets received in REBOOT module. REBOOT module then calls RebootStart in MODLOAD.
* RebootStart in MODLOAD finds IOPBOOT in the ROM, and jumps directly there.
* UDNL doesn't call RebootStart. It loads SYSMEM and LOADCORE, links them, then jumps to LOADCORE entry point.
* FILEIO also contains IOP heap remote functions.
* For the "prnt" function in SYSCLIB, there seems to be some special functionality for character=511 and 512, which STDIO uses...
* MODLOAD and LOADFILE seems to have some interface with SECRMAN. Those can possibly be more fully documented...
* IOMAN deletes and then makes a dummy "tty" device, then has files at index 0, 1, and 2 open that device...

Since implementing the base modules will take some time, it will have to wait until December...
 
I went ahead and implemented direct folder access for PSF2 in my PSF test program.

In this case, it is possible to play unpacked PSF2 contained in a folder, instead of needing to repack into PSF2 before playback. This will decrease the time needed in the debug cycle.

I also checked which version of MAME source code the Audio Overload PSF source is based off of. It seems to be similar to version 0.97 or below. I'll see if I can attempt to port a newer version of the MAME sources.
 
I ordered myself one of those Gamestar SATA network adapters.

I wonder if it is possible to reflash the CPLD on those to do something different...

---

These are the other things I'd like to do next, regarding hardware enablement:

PPC-IOP (requires IOP software stack RE)
Arcade extended PCB attached to DEV9 (requires RE of related modules)
DEV5 SPEED interface on DESR (requires RE of related modules)
IR remote connected to Mechacon (requires RE of related modules)
IR remote connected to DVRP (requires RE of related modules)
UART/modem on network adapter (requires RE of related modules)
PDA communication over SIO2 (requires RE of related modules)
MRP driver for DECI2 (requires RE of related modules)
Tuners/video input on DESR (???)
PSP video encoder on DESR (requires RE of related modules)

More hardware documented means more device support. Personally, I'm doing this so that it is easier to add support for these devices in Linux.
 
Last edited:
My change to allow wolfSSL to be compiled targeting the PS2 has been merged!

However, they did this in a roundabout way.

wolfSSL requires a CLA (Contributor License Agreement, not the kind HWNJ likes to refer to) to assign copyright to them. However, my change is a 1 line change (checking the ABI for 64 bit in addition to the architecture), which wasn't long enough to allow me to sign one.

In that case, they just treated it as a bug report and rewrote the change.

As an aside, when contributing to ps2sdk etc., you don't need to sign any CLA; you own your code even after you contribute it.
 
Taking a look at libarchive again, the major work that is needed to be done to make it compilable with ps2sdk is to fix the usages of open() on a directory and the usage of fchdir(). Not sure if I want to implement a shim of the *at functions in ps2sdk, or just fix libarchive code to store paths instead of file handles (just like it already does in its win32 implementation).

---

pspsdk and ps2sdk both have libcglue, with similar functionality. I think it would be nice to try to attempt to merge the two...
Also, pspsdk has file descriptor mapping (e.g. for both network stack and file stack, it is possible to map those independent file descriptor namespaces to one namespaces). I wonder if that could be ported to ps2sdk...
 
After my missing libcglue function PR, here is what might be left to be implemented for libarchive...

dup
fchdir
getgid
getgrgid
getgrnam
tcgetattr
tcsetattr
umask
waitpid

And here is the CMake invocation
Code: 
cmake .. -DCMAKE_TOOLCHAIN_FILE=$PS2SDK/ps2dev.cmake -DCMAKE_INSTALL_PREFIX=$PS2SDK/ports -DBUILD_SHARED_LIBS=OFF -DENABLE_WERROR=OFF -DENABLE_TEST=OFF
 
I've been making some progress on compiling PS2 Linux 3.8 on my Ubuntu 22.04 LTS system.

Once I get it into a state where you can compile it very easily, I'll write up some instructions and then post them somewhere.

I'm not too sure if kernelloader I ported to the new toolchain will work just fine. In any case you can use old kernelloader with newly built kernel.
 
You must log in or register to reply here.

Similar threads

Back
Top