PS2 Julian's various PS2 projects (Worklog)

Some notes about libspu2/libsnd2:

ccdata.o ! compiled same source with different preprocessor flags
ccnrpn.o ! compiled same source with different preprocessor flags
s_gv.o -> s_gvex.o
s_rmp.o ! empty
s_srm.o -> s_srmd.o
spu_i.o ! merged into spu.o
spu_sb.o ! merged into spu.o
st_cb.o ! merged into st.o
st_init.o ! merged into st.o
st_mark.o ! merged into st.o
st_p.o ! merged into st.o
st_s.o ! merged into st.o
st_stat.o ! merged into st.o
st_t.o ! merged into st.o
 
Here is some information about the memory card api breakage stuff:

To check this quickly, check for the string "dmacman" in either the mcman or the mc2 library
Affected libraries and their versions:
mc2_d.irx 3100
mc2_s1.irx 3030
mc2_s1.irx 3100
mcman.irx 3030
mcman.irx 3031
mcman.irx 3100

So the deal with those new mc modules is they added new faster mc transfer functionality that inlines the sio2 stuff.

Export 67 of sio2man needs to be handled properly. However, in the new sio2man version (compared 3.1.0 with 1.6.0) the transfer init function has been merged into one, and the usage of event flags was changed to semaphores.

There does not seem to be any existing sio2man or mcman API changes (not including additions) beyond 1.6, so this should be backwards compatible.
So these set of changes should be coming to ps2sdk once I get around to doing the feature upgrade stuff.
 
Last edited:
It appears that the speed of the IDE interface on arcade hardware is limited to MDMA2.

For reference:
PIO Modes: 0 [3.3MB/s], 1 [5.2MB/s], 2 [8.3MB/s], 3 [11.1MB/s], 4 [16.7MB/s]
Multiword DMA Modes: 0 [4.2MB/s], 1 [13.3MB/s], 2 [16.7MB/s]
Ultra DMA Modes: 0 [16.7MB/s], 1 [25.0MB/s], 2 [33.3MB/s], 3 [44.4MB/s], 4 [66.7MB/s], 5 [100.0MB/s]
 
Last edited:
As far as I can find with a search (MPEG_Initialize NOT _mpeg12_slice NOT __libmpeg_H NOT ffmpeg_initialize), the only usages of libmpeg in ps2sdk are in the ps2 sdk sample itself and Simple Media System.
 
Probably for the rest of this year, I'll continue improving the ps2 toolchain and libraries, and dependent stuff will come later. It will take a while to implement fully, but I think it will be worth it since it will be easier to built on top of it rather than constantly fighting with it (e.g. remaining bugs, missing features, annoyances, non-standards, differing behavior, difficulty debugging, undocumented/unreversed/hidden code, etc.)

A lot of things to do, a lot of time, but not a lot of energy. Just going to do it bit by bit.
 
A few tidbits related to EE MMI:

GCC 3.2.3 ps2dev:

Code: 
__builtin_mmi_paddb
__builtin_mmi_paddh
__builtin_mmi_paddw
__builtin_mmi_paddsb
__builtin_mmi_paddsh
__builtin_mmi_paddsw
__builtin_mmi_paddub
__builtin_mmi_padduh
__builtin_mmi_padduw

__builtin_mmi_psubb
__builtin_mmi_psubh
__builtin_mmi_psubw
__builtin_mmi_psubsb
__builtin_mmi_psubsh
__builtin_mmi_psubsw
__builtin_mmi_psubub
__builtin_mmi_psubuh
__builtin_mmi_psubuw

GCC 9.2.0 mmi patch:

Code: 
__builtin_mmi_paddb
__builtin_mmi_psubb
__builtin_mmi_paddh
__builtin_mmi_psubh
__builtin_mmi_paddw
__builtin_mmi_psubw
__builtin_mmi_paddsb
__builtin_mmi_psubsb
__builtin_mmi_paddsh
__builtin_mmi_psubsh
__builtin_mmi_paddsw
__builtin_mmi_psubsw
__builtin_mmi_paddub
__builtin_mmi_psubub
__builtin_mmi_padduh
__builtin_mmi_psubuh
__builtin_mmi_padduw
__builtin_mmi_psubuw

__builtin_mmi_psrah
__builtin_mmi_psraw
__builtin_mmi_psrlh
__builtin_mmi_psrlw
__builtin_mmi_psllh
__builtin_mmi_psllw

GCC 3.2 GNUPro Cyngus/RedHat:

Code: 
__builtin_mips5900_pabsh
__builtin_mips5900_pabsw
__builtin_mips5900_pcpyh
__builtin_mips5900_pexch
__builtin_mips5900_pexcw
__builtin_mips5900_pexeh
__builtin_mips5900_pexew
__builtin_mips5900_pext5
__builtin_mips5900_plzcw
__builtin_mips5900_ppac5
__builtin_mips5900_prevh
__builtin_mips5900_prot3w

__builtin_mips5900_paddb
__builtin_mips5900_paddh
__builtin_mips5900_paddsb
__builtin_mips5900_paddsh
__builtin_mips5900_paddsw
__builtin_mips5900_paddub
__builtin_mips5900_padduh
__builtin_mips5900_padduw
__builtin_mips5900_paddw
__builtin_mips5900_padsbh
__builtin_mips5900_pand
__builtin_mips5900_pceqb
__builtin_mips5900_pceqh
__builtin_mips5900_pceqw
__builtin_mips5900_pcgtb
__builtin_mips5900_pcgth
__builtin_mips5900_pcgtw
__builtin_mips5900_pcpyld
__builtin_mips5900_pcpyud
__builtin_mips5900_pextlb
__builtin_mips5900_pextlh
__builtin_mips5900_pextlw
__builtin_mips5900_pextub
__builtin_mips5900_pextuh
__builtin_mips5900_pextuw
__builtin_mips5900_pinth
__builtin_mips5900_pinteh
__builtin_mips5900_pmaxh
__builtin_mips5900_pmaxw
__builtin_mips5900_pminh
__builtin_mips5900_pminw
__builtin_mips5900_pnor
__builtin_mips5900_por
__builtin_mips5900_ppacb
__builtin_mips5900_ppach
__builtin_mips5900_ppacw
__builtin_mips5900_psllvw
__builtin_mips5900_psravw
__builtin_mips5900_psrlvw
__builtin_mips5900_psubb
__builtin_mips5900_psubh
__builtin_mips5900_psubsb
__builtin_mips5900_psubsh
__builtin_mips5900_psubsw
__builtin_mips5900_psubub
__builtin_mips5900_psubuh
__builtin_mips5900_psubuw
__builtin_mips5900_psubw
__builtin_mips5900_pxor
__builtin_mips5900_qfsrv
__builtin_mips5900_pdivbw
__builtin_mips5900_pdivuw
__builtin_mips5900_pdivw
__builtin_mips5900_phmadh
__builtin_mips5900_phmsbh
__builtin_mips5900_pmaddh
__builtin_mips5900_pmadduw
__builtin_mips5900_pmaddw
__builtin_mips5900_pmsubh
__builtin_mips5900_pmsubw
__builtin_mips5900_pmulth
__builtin_mips5900_pmultuw
__builtin_mips5900_pmultw

__builtin_mips5900_psllh
__builtin_mips5900_psllw
__builtin_mips5900_psrah
__builtin_mips5900_psraw
__builtin_mips5900_psrlh
__builtin_mips5900_psrlw

__builtin_mips5900_mtsab
__builtin_mips5900_mtsah

__builtin_mips5900_mfsa
__builtin_mips5900_pmfhi
__builtin_mips5900_pmflo
__builtin_mips5900_pmfhl_lw
__builtin_mips5900_pmfhl_uw
__builtin_mips5900_pmfhl_slw
__builtin_mips5900_pmfhl_lh
__builtin_mips5900_pmfhl_sh

__builtin_mips5900_mtsa
__builtin_mips5900_pmthi
__builtin_mips5900_pmtlo
__builtin_mips5900_pmthl_lw
 
A little tidbit:

RHL 7.3 update has gcc-2.96-113.src.rpm

Timeline wise, this was after people from Cygnus took over GCC development (from ECGS) and after RedHat bought Cygnus.

Some tips on inline asm usage:
https://gcc.gnu.org/onlinedocs/gcc/...o-use-inline-assembly-language-in-c-code.html

Using coprocessor registers as variables (replacing usage of mtcX/mtcX in inline asm):
https://gcc.gnu.org/onlinedocs/gcci...ifics-for-mips-targets.html#mips-coprocessors

MIPS MSA built-in function reference:
https://gcc.gnu.org/onlinedocs/gcc/MIPS-SIMD-Architecture-Built-in-Functions.html
 
Looks like I hit a GCC bug:

"swc0" and "lwc0" aren't actually instructions, but GCC tries to generate them when you do something like this:
Code: 
register unsigned int cop0reg_Status __asm__ ("c0r12");
*status = cop0reg_Status;
OR
Code: 
register unsigned int cop0reg_Status __asm__ ("c0r12");
cop0reg_Status = *status;

Some more tidbits on lwc0/swc0: https://sourceware.org/pipermail/binutils/2013-July/081912.html

The offending code is in gcc/config/mips/mips.cc in function mips_output_move; grep l_c_ and s_c_
 
Last edited:
I looked at the firmware for BDP-S590 (2012 blu-ray model).
It was pretty easy to get code execution on those systems (keywords: AutoScript, MTKAT, CLI, CLI_exec, CLI_drv, telnetd). Surprised they left that vector open.
It appears to be evolved software (bdpprog/libX2) from the DESR systems, with some things in common (.rel extension for DLLs, XML-like structure (e.g. prml), xRegistry/xSettings/xPackmanJr etc.)
BDP-S350 seems to be the first player with XMB released in the US (2008), but stuff has been released in Japan before then (RDZ-D5 DVD recorder (2005) and BDZ-V9 BD recorder (2006)).
Sony did a major refresh of the UI in 2010 models.
Sony did another major refresh of the UI in 2015 models, no longer using the XMB.

---

I plan to continue working on reverse engineering IOP modules next month.
 
Last edited:
It appears that BDZ-ET2200/BDZ-ET1200/BDZ-EW1200/BDZ-EW520/BDZ-E520 (bdre_11g/2014-2015), the last set of models before they switched to a new (not XMB) UI, used a MIPS based processor (EMMA3). For models after that (e.g. BDZ-ZT2000/BDZ-ZT1000/BDZ-ZW1000/BDZ-ZW500) they switched to a ARM based processor.

This means the AutoScript/MediaTek based entrypoint won't work on those models, and a different entrypoint needs to be found.

(Mainly the purpose of this exercise is to dump the firmware and get more symbols for XOSD)

Also, some strings in the USB update file (BD28-VUD.BIN):
scfsscfs
scfs_compression_zlib

The HES-V1000 is also of interest to me (for English strings)... but good luck finding one I guess
 
Loading OSDSYS with arguments "BootError" and any string containing "dvdplayer.elf" or "DVDELF" will show the error "DVD Player software cannot be started." on the browser. The variable at 0x1F0014 is set to 1 and the aforementioned localized error string will be copied to 0x1F0018 (128 bytes max).

A couple ways to set a custom error message:
* Nop out the code that copies the localized error string, and put your own string, then execute main
* Change the pointers to the error string for each locale to your own buffer, then execute main
* Change the pointer of the error buffer in the code that renders the error to somewhere else, then execute main
* Hook WakeupThread syscall to overwrite error string
 
Last edited:
GCC built in defines for mips: https://github.com/gcc-mirror/gcc/b...c31e69a3f35dfe117/gcc/config/mips/mips.h#L440

---

I plan to release a tool that can do in-system flash ROM programming based on what DTL-T10000 can do. Personally, for me, I think it would be better to have a similar setup as System 147/148 where there are two partitions; first one mapped at 0xBFC00000... for boot which chainloads the second one. And the second partition is the one is that should be flashed. That way if something goes wrong in flashing it would still be possible to boot from USB or memory card to recover (drivers for which are included in first partition).

Another idea I'm thinking of is to hook up (Q/O)SPI flash ROM to SSBUS and bitbang (Q/O)SPI for more storage without needing to solder more address/data lines.

Another idea would be to compress the contents of ROM under 256KiB and then hook up a RP2040 to use with e.g. PicoROM. (OSDSYS, PS2LOGO, PS1DRV, dvdplayer might need to be loaded from somewhere else)
 
uyjulian said:
GCC built in defines for mips: https://github.com/gcc-mirror/gcc/b...c31e69a3f35dfe117/gcc/config/mips/mips.h#L440

---

I plan to release a tool that can do in-system flash ROM programming based on what DTL-T10000 can do. Personally, for me, I think it would be better to have a similar setup as System 147/148 where there are two partitions; first one mapped at 0xBFC00000... for boot which chainloads the second one. And the second partition is the one is that should be flashed. That way if something goes wrong in flashing it would still be possible to boot from USB or memory card to recover (drivers for which are included in first partition).

Another idea I'm thinking of is to hook up (Q/O)SPI flash ROM to SSBUS and bitbang (Q/O)SPI for more storage without needing to solder more address/data lines.

Another idea would be to compress the contents of ROM under 256KiB and then hook up a RP2040 to use with e.g. PicoROM. (OSDSYS, PS2LOGO, PS1DRV, dvdplayer might need to be loaded from somewhere else)
Click to expand...
Another option I discussed with a friend is also replacing the DVD player rom and making it an application storage flash memory. To allow loading homebrews without touching too much rom0
 
You must log in or register to reply here.

Similar threads

Back
Top