Sony GSBox, the Sony GSCube technology prototype

That's right, no mention of them in the docs.
I have not tried running dsidb on its own yet, I will try as soon as I am back home where the machine is.

No problem!

I will check and get back to you. The docs don't refer to them, but I will look into the scripts.

The manual mentions that the GSBox software distribution on CDROM (which I do not have) contains a floppy disk image that needs to be written to a blank FDD to be used to perform the network installation of the GSBox. I don't have that image (I didn't check too thoroughly in the hard disk image though) but there doesn't seem to be anything seemingly GSBox specific in there, other than scripts to perform a network installation of Red Hat Linux and install the custom RPMs with all the necessary SDK and drivers...

 

On the BPM-1, IC81 (if I read it correctly) is probably the logic configuration for the Altera FPGA, IC10 is for the PLX PCI bridge (just above it). Then it could be assumed that each of the two ROMs stores the configuration for each of the two two Xilinx FPGAs, but I don't know if they support reading their configurations from such chips. It is very possible that the Xilinx FPGAs are reprogrammed on run-time depending on the mode of operation of the system. For example the SN Systems DVD Emulator does that.

This name is interesting! gsm1pm1-0318.bin: "gsm1" wold refer to a blade, so it is not for the BPM-1 board, but "pm1" might refer to the PM-1 board with the EE and GS! So there may be some other chip on it, which may also explain why it is separate. Have you checked what this binary file contains?

There was one case recently with a DTL-T10000 that got stuck in some odd state after testing different combinations of the DIP switches. Although the cause is still not known (may be anything from a faulty DIP switch through some odd configuration that overwrote the boot flash, to damages from a logic short), it proves that the TOOL was not designed with any safety regarding the DIP switches in mind. The problem is that there is this small Altera PLD on the TOOL that governs the flash switching, DIP switches, LEDs and other things, that nothing is known about.
Similar is the case with the Dev9C chip on the SCPH-30000 series. It has a buffer connected to the SSBUSC channel of the CDVD DSP, so by changing one Dev9C register, it can drive the data bus together with the CDVD DSP. In my test, nothing got damaged, but the possibility was there.

On the TOOL there are unmounted DIP switches for controlling the EE frequency, and other similar settings, so those should be easier to determine, as they are connected to certain (PLL in this case) chips.
Still it is unlikely that there is any other useful mode that that can be set through them, so experimenting on one of the rarest PS2 devices in existence would be unwise.

@jollyroger Did you scan the raw image of the HDD for deleted files?

It is interesting that the documentation about this prototype GSBox is "censored" to exclude any low-level information. So this was meant for use by people who shouldn't learn about PS2 hardware, especially the IOP side.

 

The two large ROMs (IC35=ROM#0 and IC37=ROM#1) could well belong to the Xilinx FPGAs, although they are quite far from them.

It turns out the manual refers to it as "Boot ROM".
I guess it is the base system that gets loaded onto the GSMs at startup time...
I have not checked its contents yet.

Not yet, no.

Very much so, it is clearly focused on understanding the system configuration and usage of the API to develop software for...

 

Awesome jobs with the restore and documentation! Glad to see this went to someone responsible.
Would you mind posting some pictures of the documentation you mention? Maybe front & back covers and index if possible?
Thanks and keep it up!

 

Thank you

I will take pictures of the manuals. I am in the process of scanning them, as only the paper version of them exists... I have no electronic copies, so I am making them myself.

 

This is amazing O_O glad to have some sort of documentation of it!

 

Amazing teardown, glad it went to the right person

 

Thank you!!

 

Thank you for the explanations. I too, believe that the machine is in good hands. Not everybody knows how to work with the hardware properly, and even fewer will know that and how to work with the PlayStation 2 software.

As for PS2Ident, I think it should work out of the box... once you help it to boot:

• Download PS2Ident.
• Download this package (ELF Loader).
• Extract PS2Ident to a USB disk (must have only 1 partition, and it must be formatted with FAT12/16/32).
• Extract the ELF Loader, usbd.irx and usbhdfsd.irx, to where you will run dsedb and dsidb. I don't know whether you will run dsidb and dsedb from a development machine or on the unit itself, but it is up to you...
  
• Given that the unit runs flash release 1.4.5, you do not need to change ibootp and ebootp.
• Start both dsedb and dsidb. There are 4 boards. But I suppose they are identical. You should be able to access each board's MRP device with the "-d" option (e.g. dsedb -d /dev/mrpX, where 0 <= X <= 3).
• Connect USB Disk to unit.
  
• From dsidb:
  • mstart usbd.irx
  • mstart usbhdfsd.irx
• From dsedb:
  • run ELFTest.elf mass:/path_to_PS2Ident.elf

With some luck, PS2Ident will boot.

Note: PS2Ident will not dump DEV1 (DVD ROM) if there is no filesystem. TOOLs are known to have DEV1 installed, but there is no filesystem. Instead, it just contains some device IDs at 0x1FBF0000 (When DEV1 is mounted at 0x1FA00000).
To dump the DEV1 manually, you can follow this (the section about "Dumping the ROM"): https://assemblergames.com/threads/playstation-2-tool-unit-rom-layout.67937

The reason why @wisi is suggesting that you can try to locate deleted files from the filesystem, is because @HI_Ricky suggested that the flash images are copied onto the HDD before they are written to DEV2 (BOOT ROM).
We've seen a fragment of a EE kernel from November 1999, on one of @Shuji's TOOL units. As of September 1999, the kernel was still seemingly incapable of booting ELFs with LoadExecPS2 (not implemented).

 

Its good to see someone give the unit what it deserved, great work!

 

@jollyroger Could you share content of small file local\sony\diag\diag.conf (if such or similar file exists) ? It should contain all information about console. Here is example file from tool:

Code:

#
#            Copyright (C) 1999 Sony Corporation.
#            All Rights Reserved.
#
# diag infomation
RPMDATE=200001312133
MAKEDATE=200001312203
# diag version
VERSION=1.8
# diag make revision
REVISION=2
# revision of PS2DSK
SDKREV=1.3.4
# revision of boot ROM
ROMREV=20000117

 

Sure, I will check.

 

Code:

#            Copyright (C) 1999 Sony Corporation.
#            All Rights Reserved.
#
### diag infomation
RPMDATE=200001312133
MAKEDATE=199909070557

### diag version
VERSION=0.3.1
### diag make revision
REVISION=5

### revision of boot ROM
ROMREV=20000318

### revision of SyncBP
SYNCBPREV=26
### revision of Merger
MERGERREV=F0
### revision of DAC
DACREV=42

 

It turns out the file "gsm1pm1-0318.bin" is not actually on the hard disk. It is mentioned in the manual, but I can't find it...

 

A preliminary look for deleted files (using testdisk) has not come up with anything interesting. The tool works properly, as it found some deleted files in the tmp folder, which were results of previous runs of the diagnostic tests, but I couldn't find anything particularly significant otherwise.
Any recommendations on other tools to use to recover deleted files on a set of ext partitions?

 

R-Studio, may be.

 

It seems like the USB connectors are not mounted on the blades, otherwise the USB controller is probably functioning.
So PS2Ident would have to be loaded from the host PC through DECI2.

Given that it contained the BOOT ROM's data, it can be recovered by dumping the BOOT ROM memory to a file, using DECI2 commands.
Or if PS2Ident dumps it, but then it would have to do that do host0:.

Something I just noticed:

https://pc.watch.impress.co.jp/docs/article/20000726/dsc_0045.jpg
https://pc.watch.impress.co.jp/docs/article/20000726/dsc_0048.jpg
From: https://pc.watch.impress.co.jp/docs/article/20000726/gscube.htm
Translated (by Google):

So I guess four of the five merger boards would merge the video streams from four blades each, while the fifth merges the data from the four merger boards. They are indicated by "MXn" (where n= 0 - 4) on the load indicators, while the blades are indicated with "GS". They are in the order: MX0, GS0, ..., GS7, MX1, MX4, MX2, GS8, ..., GS15, MX3.

https://pc.watch.impress.co.jp/docs/article/20000726/gscube.htm
It looks like at the very bottom center of the board there is a marking "GSM-4", so there must have been two more GS Module boards created before the GSCube.


Back to GSBox observations:

Some chips on the GSM-1 board have the same additional markings as those in the TOOL. Namely "MPU4" on a IC801 PIC MCU, again "MPU4" on the boot flash ROM, and "BP2" on a PIC MCU that in the TOOL is on the BP-2 board, but on the GSBox is on the GSM-1 board. The Altera MAX for the DIP switches and flash ROM management has a paper label "GSM-1". There is an unmounted through-hole connector mounting point to the left of the PLD (CN604). Also an IC mounting point can be seem below the FPGA configuration EEPROM.

There is an unmounted connector placement point to the left of the IOP, perhaps for controllers and MC pots. The IOP ASIC, IOP RAM and SPU2 chips seem to be the same as those of the DTL-T10000.

 

More news.
Here is the output of running gsbedb:

Code:

dsedb (Version 0.1.68 Tue Apr 11 14:24:50 JST 2000)
*** Resetting...

EE DECI2 Manager version 0.06 Mar 15 2000 16:36:01
  CPUID=2e14, BoardID=4126, ROMGEN=2000-0318, 128M

*** DBGP Version 3.02
(type `help' for getting help, or `help help' for getting help of help)dsedb

Here is the output of running gsbidb:

Code:

dsidb (Version 0.1.68 Tue Apr 11 14:24:52 JST 2000)
*** Resetting...
*** DBGP Version 3.00
(type `help' for getting help, or `help help' for getting help of help)

        
MPU-4/GSM-1 DSW602
  --- IOP kernel --
  D0   0^ NTSC mode          1_ PAL mode
  D3   0^ Extr Wide DMA      1_ Extr Wide DMA disable
  D4   0^ Dram 8M            1_ Dram 2M
  D5   0^ disable            1_ enable EE ssbus access
  --- EE --
  D6   0^ --                 1_ --
  D7   0^ EE normal boot     1_ EE/GS self test
        
 CPUID=15, ROMGEN=2000-0318, CACH_CONFIG=1edd8, 8MB, IOP mode, FlashROM boot
 <20000318-140508,ROMconf,gsm1pm1-0318.bin:11520>
 SW=b7:^^^^___^:b0, RESET parameter EE=00000000_00000000, IOP=00000000_00000000
        
IOP Realtime Kernel Ver.0.9.1
    Copyright 1999 (C) Sony Computer Entertainment Inc.
             Copyright 1999 (C) Sony Computer Entertainment Inc.
        
DECI2 manager start.
Reboot service module.(99/11/10)
Load File service.(99/11/05)
Multi Threaded Fileio module.(99/11/15)
iop heap service (99/11/03)
IOP DECI2 manager Version 0.9.1

And here is the output of running PS2Ident (unsuccessful):

Code:

dsedb S> run PS2Ident-T10K.elf
Loading program (address=0x00100000 size=0x000005d0) ...
Loading program (address=0x00102780 size=0x00087d50) ...
section header not found
dsedb S> 

 

Please download the new file. I realize that I should not have packed the file, since dsedb wants the section headers (which packing will get rid of).
I also took the opportunity to adjust the homebrew PS2SDK to support the host device. Originally, it would always add a leading slash to the path after the device name, but that will change the origin for the host device ('/' in Linux refers to root). It should remain compatible with ps2link, as ps2client also slices off any leading slashes.

Does the GSBox support controllers? If it does not, then you cannot actually control PS2Ident.
Please use this custom version that has no GUI instead: https://www.sendspace.com/file/z0uzgx
It has no requirement for the lang folder, but putting a valid PS2Ident.db file (from either PS2Ident or downloadable from here) will allow it to tell you the chip models.
When it is done, dsedb will indicate that the program has break'ed and the status is PROGEND:

Code:

dsedb S> run PS2Ident-T10K-nogui.elf
Loading program (address=0x00200000 size=0x000639e0) ...
Entry address = 0x00200000
GP value      = 0x0026aa70
*** Resetted
*** No Connect
        
EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01
  CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M
        
*** Resetted
        
EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01
  CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M
        
        
# TLB spad=0 kernel=1:12 default=13:36 extended=37:47
*** Unexpected reply - type=BREAKR result=PROGEND
dsedb S>

 

Ok, excellent I will try this later today and let you know how it goes.
The GSBox does not support controllers, so thanks for the no-gui version.
Where does PS2Ident.db have to be in the filesystem? Do I have to run the dse file server?