Sony GSBox, the Sony GSCube technology prototype

You can see below a selection of pictures I took while taking apart, cleaning and reassembling the system.
Most of the screws are Japanese JIS machine screws, of a type I have yet to find a perfect replacement for. In the meantime I purchased a bag of screws with exact matching dimensions and used them in all the spots where screws were completely missing.
When I manage to find the exact ones I may eventually replace them all.
All the panels and supports that were bent, I bent them back using a rubber mallet, blocks of wood and cloth, lots of time and care...

 

Next up: extracting some information from the SDK.

 

After the physical restoration, I checked the full content of the HDD, and besides the SDK I didn't find any special demos.

The SDK examples show the main characteristics of the system: there are configuration files to configure the use of the blades, which can be used either for sound generation or for video generation, interestingly it seems the GSMs are not meant to be used for both at the same time.

The so called "Merger chip" can compose the final video output using the video feeds from 1 to 4 GSMs, and either displaying one at a time, or blending them in multiple ways.
There are four video stream blending modes:
1) Scissoring: each video stream produces a window in the final output, this way each GSM needs to render only a portion of the total framebuffer
2) Alpha comparison: each video stream is at full resolution but only pixels with specific alpha values are retained from each video stream. The alpha channel is used as a sort of stencil, and priority of the different video streams can be set
3) Z sort: this is the most significant in my opinion, and shows how the merger chip is not just a simple video stream processor, as it has to receive a fully encoded Z buffer from all GSMs.
4) Alpha blend: using the Z information, the system can not only perform per-pixel opaque Z buffer selection, but it can also perform an Alpha blend of the pixel values coming from the video streams, according to their relative Z depth using the formula: (a-b)*c>7+d

The three main use cases are therefore:
- distributed framebuffer rendering (with scissoring) when all GSMs contribute to render the same frame by drawing different portions of it
- "deep" rendering when all GSMs renders some aspects of the entire scene, and then the results are merged together
- pipelined rendering when each GSM renders the entire scene, but it is displayed in round-robin fashion, so that each GSM has more time to render.

This hardware merger has very interesting side effects. If each video stream is slightly displaced, the effect of anti-aliasing can be achieved. If on the other hand each video stream represents a different frame, then the blending can produce a form of motion blur.

The GSBox can be connected to others to form different configurations:
- GSB 0.3S is a configuration using a single box, four total blades
- GSB 0.3D is a configuration using three boxes: two hosting four blades each to generate video and audio, and the third to merge the video and audio streams coming from the other two
- GSB 0.3Q is a configuration using five boxes: four hosting four blades each to generate video and audio, and the fifth to merge the video and audio streams coming from the other four

Then there is the so-called GSB 0.8: this is a different system, that has sixteen GSMs and five merger boards all in one system. This is what became externally known as the GSCube. It is in fact possible to notice in one of the public GSCube pictures how a label on its back reports the "GSB0.8" name

After a lot of work with scripts, I also managed to extract all the RPMs that were installed on top of the vanilla Red Hat Linux 6.1 OS installation, so that I can reproduce a full installation from scratch if necessary.

This concludes my journey with the GSBox until now, of course I am open to questions of any kind, please fire away

Jollyroger

 

Is there a block diagram of the hardware?
Two PCI<->PCI bridges Intel DC1051A can be seen which are probably necessary due to the significant number of PCI devices connected:
PC, Ethernet card, <-PCI bridge -> PLX PCI9054 on BPM-1, the other two PCI slots on BPM-1, <-PCI bridge -> the four GSM-1 boards with PLX PCI9054(?can't read it)
Are the two free PCI ports on the BPM-1 meant for something in particular?
The PLX PCI bridge on the BPM-1 connects the Xilinx FPGAs that make-up the merging circuit (I guess) to the PCI bus. But there is also an Altera Flex FPGA on the bottom of BPM-1. What does it do?
What is the function of the TVP3026 video interface palette?

The VGA output from the merger is the VGA port to the left of the LVDS-B port, right?
There is an unmounted connector to the left of it. Any idea what it was meant for?
What are the LVDS-A, LVDS-B and LVDS-C ports used for?
What protocol/interface is used for transferring the image data from each GS to the "Merger chip"?

How are the four blades synchronized? Surely coding for such a thing is not straight-forward. Can two blades transfer information between each-other, or does whatever is to be rendered need to be sent to all blades by the PC in advance? Can this thing (in theory) run games at all? I mean - if the game runs on one of the EEs, then it would need to update the rest of the blades with what they need to change in the rendered scene, so if one blade can't send data to the other without the PC, then wouldn't that make it a bit slow?

What do the blue LED bars on the front panel indicate ("GSM Power Indicator", or am I misreading that)?

Differential signals seem to be used between the GS and the merger chip. I guess that was necessary because the lines are quite long.
The PM-1 (Processors Module ?) board (with EE and GS) can be seen mounted on the GSM-1 board. Is there an additional stage (FPGA) between the GS and the buffers that converts the signals to differential, under it?
Actually why was the need for the PM-1 board? Lack of space on the GSM-1 board, or the ability to upgrade it or something else?

Going to the IOP side.
The bottom edge of what is probably the PIF Xilinx FPGA can be seen under the Sound interface board. Is that it?

Two through-hole mounting points can be seen between the SIF-1 board and the PM-1 board. They are for the AIF RTC and PATA HDD I guess. The AIF FPGA can be seen on the bottom of the GSM-1 board (Altera Flex).
Is there anything else (AIF / Dev9 -related) of the under the SIF-1 board?

BTW, that cover with the PC PCB on a hinge is pretty cool, though it is probably a miracle that deformation to the box didn't cause the connector and BPM-1 PCB to get damaged, or somebody opening the cover by mistake while the unit is powered on.
Why do I have the feeling I am asking a bit too many questions...

EDIT:
What are the EE and GS revisions?
I wonder how the Z-buffer data is read from the GS?
Can the PC side read the output video stream and save it locally (the PLX PCI9054 on the BPM-1 looks as if connected to the TVP3026 through buffers)?

Congratulations on the successful restoration!

 

Ok, I will try to answer over time... I don't have the GSBox here with me right now, so some answers will have to wait for next week.

 

I don't think this system could have gone to a better person.

Good job on the restore, she looks beautiful!

 

Thank you sir!

 

One other piece of Sony ephemera you may or may not be aware of is that the first digit on those Sony 9-digit part numbers indicates the development status of the board. Numbers starting with 0- are still under the control of engineering, and the ones that start with 1- are designs that have been released to production.

So from the look of it, the entire box was still in development status - but I think you probably worked that out anyway.

One thing I would be interested to know is what sort of GS they used on those boards - is it the standard 4MB version that was used in the retail PS2 or the 32MB one they used in the GSCube?

 

No, there is no block diagram in the documentation.

It isn't clear what the two remaining PCI slots are for, but nothing is connected to it. Perhaps additional PCI I/O devices?

While it is very likely that the merger circuit is implemented in the two Xilinx FPGAs, I am not so sure the merger circuit is connected to the PCI bridge at all. None of the functionality I found so far exploits that connection, at least.
I am really not sure what the Altera part does, I will try to trace the connections, but it may be an additional bridge to implement communication protocols.

Not sure either, but this being a system designed for broadcast, the RAMDAC may be used to generate the system's main VGA signal.

Yes.

Not sure, but it could be that they originally intended to have a composited multi-av port there too?

The LVDS ports are used to transport differential digital video signals (and Z Buffer contents) between a GSBox and an external merger box.

No idea, the external communication seems to use the LVDS/LDI protocol, but I would have to snoop some of the traces to see what they use between the GSMs and the merger chip on the backplane, and I don't have differential probes...

There is a dedicated hardware communication path between the blades, which is used to perform communication between them. The video clocks are likely genlocked, but I have not inspected this, and the documentation doesn't mention it.

Actually coding wise it is pretty straightforward. It is exactly like having four TOOLs, plus a separate PC, with hardware communication channels between all of them. Each blade has a full 128MB RAM and a EE/GS pair.
The communication channel between the command processor (PC) and the blades goes over PCI, while it is not clear to me (yet) how the blades communicate to each other.
There is a dedicated set of libraries and APIs to initialize the system, transfer code and data to the blades, synchronize the system on vertical retrace and control the behavior of the merger processor.

It is a fully distributed system, so in theory one can run the game on all four blades at once independently, and each of the instances would be commanded to render a different frame, or a part of the screen.
At any rate, the PC can participate to the application being run directly, or it can operate only as a command and control unit.

The bars show the GS activity of each GSM, likely which fraction of a full frame the GS runs for...

Jolly

 

Very interesting indeed, this is clearly an engineering sample, and nowhere near ready for production...

From the very few experiments I have run so far, it seems the blades use the retail 4MB GS, but I cannot confirm it yet.
The documentation mentions explicitly the 32MB variant of the GS as the "GS Plus" chip, which has a few additional registers and settings compared to the regular GS.

Jolly

 

thank's share info and photo, it so cool !!!!

 

I am not sure, I did not remove a PM-1 board from a GSM. On the backplane one can see several chips that are used to convert digital to differential signals, likely for the LVDS connectors. I didn't trace the signals from the GS to the merger FPGA yet.

I didn't design the system
I would wager to have the chance of upgrading the EE/GS combo without a redesign of the GSM blades. I assume they would have envisioned using many revisions of the EE/GS on this system, so they likely decided to mount them on a daughterboard for that reason.

Not sure, I will have to remove a blade and inspect it.

Same as before, I would have to remove the blade to inspect under it.

I could not agree more, the whole (ASUS) motherboard swings towards the BPM-1 PCI connector, luckily when it's closed the frame is quite robust. In order to open the swinging door one has to remove 10 or so screws, so it's clearly not designed to be opened that often

I don't know, but given the presence of the full PS2 SDK, it shouldn't be hard to find out...

This is a very good question indeed, I will try to investigate it, but the documentation has no explanation.

No, the communication processor has no direct access to the video stream, at least not in a way that is accessible via the API.

Thank you

 

Yes, the FDD is used to install the OS on the machine. In fact the installation procedure requires an FTP server to be setup in advance, then a special floppy disk is used to boot a minimal Linux stack, connect to the FTP server and perform the installation of Red Hat Linux. After the OS is installed, a number of RPM modules need to be installed too, which should also come from an external FTP server, in a similar fashion to a TOOL.

The device is most definitely designed to be logged into and used as a development machine, and also optionally as an application machine as well, participating to the distributed system.
The PC side is well documented (I already purchased and stored an exact duplicate of every single component of the PC side, including power supplies, just in case) and it is easily powerful enough to support X Windows, which is mentioned clearly in the documentation. So definitely usable as a workstation.

Not sure exactly when it was built, but the documentation is from early 2000.
I can do any test you want on the software/firmware to find out, although the version of the SDK installed is from mid 2000 I believe.

No

The samples are purely diagnostic. It has a full suite of tests for every single component of the system, much like the TOOL does.
The only samples are there to show the basic API functionality, nothing more, sadly...

 

@jollyroger Not all of these are questions - some are just food for thought.

Actually it may be safer to determine the presence or absence of the Dev9C and other PS2 devices for example through the use of PS2Ident or through the SDK as you say, rather than inspecting the blade manually. @sp193 would have to say more regarding what PS2Ident needs to run on such a device. Maybe the diagnostic programs can give all the information about the hardware one might want.

The normal PS2 GS is limited to 4MB addressability even by its buffer pointer bit-field in some of its registers, which seemed somewhat odd - why didn't they design their register maps to be compatible. Did the documentation contain anything more specific about the registers of both GS version? The known GS manuals have some functioning (at least on the earlier versions) bit-fields not described and hidden behind descriptions like "always write 0 to those bit-fields". They are mostly related to the digital video input, that is known to be only used on the DTL-T10000. The GSBox can also be seen to have a connector for the adapter board for this interface. However this doesn't explains its purpose. So now that it is known that it was not used for connecting the GS chips (as I initially thought), the question of what it was meant for comes again.

I bet you would have wanted to, though.

In some PS2 early programs, the SBUS (EE<->IOP bus) or the EE is refereed to as "GM". For example in TESTSPU from the PS2 BOOT ROM - the IOP->EE interrupt is called "INUM_GM:1". I was wondering if this might be because the IOP and EE, GS were separately designed and the EE+GS was called "Graphics Module" (GM) (the name is a guess). But this is just a speculation. But now seeing the EE+GS on a separate board I it reminds me of this.

Actually the GS can output Z-buffer data on its video output if the read circuit is pointed to read the Z-buffer rather than the display buffer, but then this won't leave enough time to output the display buffer, so perhaps a different method is used.

Yes, it very much looks like just that. Good observation!

Looking again, it seems to connect to the LA probe connectors between the PCI ports, and if they don't connect to anything else, maybe it creates monitoring data, more easily visualizable on a LA, on them. Two -ROM (maybe?) chips can be seen on the top side of the BPM-1 board just next to where the Altera FPGA is on the bottom. If they are ROMs maybe they form some state-machine with the FPGAs. Could it be that FPGA contains a CPU soft-core?
From what you say it sounds like the manual of the GSBox is rather limited, which is characteristic of much of the PS2 documentation. Maybe the most open PS2 documentation is the Performance Analyzer manual, which actually describes most of the signals on the buses, but even it, at some point goes for obscurity by calling some signals
vaguely "internal" or "external".

If there is a way to capture the output video back to PC HDD it might be only for debugging the hardware, which may be why if such a functionality exists it may be hidden. However looking more closely, it seems like the 6 buffers between the PCI bridge and the TVP3026 on the board, look like they connect to the PCI interface of the PLX chip, which may mean that there is no connection between the TVP3026 and the PLX chip. Still nobody knows exactly what what the FPGAs are doing, and thus what the BPM-1 circuitry is capable of.

 

"The Thing" :O

 

Yes, I will wait for some pointers from @sp193, I can run any kind of test.

Interestingly, the documentation refers to the "Graphics Synthesizer for Playstation 2" as GS, and "Graphics Synthesizer for CreativeStation" as GSplus. I had never heard of the CreativeStation before.
The main differences between the two variants seem to be:
- the expanded memory
- two digital video output ports
- new pixel storage and video output formats (PSMZ32, PSMZ24,PSMZ16, PSMZ16S)
- all base pointer registers have their fields expanded by 3 bits
- output up to 1080p/60

You are right, the two chips are most definitely ROMs, and they sit right on top of the Altera FPGA. They likely feed something to it, so the thought of a soft-core sounds like a possibility.
The two massive ~1M gates XCV800 must also be fed from ROM or elsewhere as they are SRAM based FPGA, I wonder if they are sent configuration files from the PCI bus and programmed that way. It would mean that somewhere on the hard disk there may be the two bitstreams to program them...

Yes, the manuals are very scant. They describe the APIs and the general system overview and configuration, but nothing is explained about the system's inner workings.

Jolly

 

Very nice restoration jollyroger!
A few random questions:
How much does it weight?
How do samples are loaded, does it use dsedb/dsidb or any other commands?
If so, any clues as to what all the dipswitches on the blades do (like dsidb gives for the dsw602 on the Tool)?
Could you post a list of all the files on the hdd or are you considering sharing the hdd dump publicly?

 

Thanks!

I did not weight it, but given how heavy it feels to move around, I would wager around 30KG.
I will weigh it and let you know.

Yes, the ds* commands are all available, but they are wrapped into gs* scripts that send commands to individual GSMs or broadcast to all the connected GSBox systems connected together.

I have no idea
There are six blocks of dipswitches, I am not sure how to understand their behavior without risking damaging a blade.

I don't know what I will do with the HDD dump, but for now I will keep it private.
The file list is very long, as it includes most of the PS2 SDK, the dedicated linux drivers, etc.
All of the above is contained in a bunch of RPM archives, reported below:

etcskel-2.0-1gsbox.noarch.rpm
rootfiles-5.2-5gsbox.noarch.rpm
kernel-2.2.14-2.i386.rpm
kernel-headers-2.2.14-2.i386.rpm
kernel-doc-2.2.14-2.i386.rpm
kernel-source-2.2.14-2.i386.rpm
dev-usbpad-1.0-0.i386.rpm
powctrld-1.0-2.i386.rpm
gsb-sysctrl-1.0-2.i386.rpm
dsnet-gsb-0.1.68-3.i386.rpm
gsbsdk-tc-1.3-0.i386.rpm
gsbsdk-ps2lib-1.4.5-2.i386.rpm
gsbsdk-gsbapi-0.3.1-2.i386.rpm
gsbsdk-gsbre-0.3.1-2.i386.rpm
gsbsdk-gsbsample-0.3.1-2.i386.rpm
gsbdiag-0.3.1-5.i386.rpm

Plus a separate file (gsm1pm1-0318.bin) which probably contains some firmware that was transferred directly from a floppy disk rather than installed with the rest of the software.

Jolly

 

Of course, don't go randomly switch them around!
I imagine the docs you have don't mention them either, right?

For anyone who forgot the output of dsidb on a Tool:

Does dsidb display any info if you run it on its own?

Fair enoug, it's yours to do with as you wish, of course.
Thanks for answering!

One more question:
Do the gsb-sysctrl, gsbdiag docs or scripts refer to the dipswitches?

I suppose that floppy is just the regular RedHat 6 network/ftp install boot floppy, nothing fancy about the PC hardware used in your Box, right?