As with the price post I've been sitting on these docs for about 7 years. The information here is related to the alpha/beta devlopment target boxes released prior to the PSTOOL. I have compiled it from various official, albeit copyright of SCEI sources. They are reproduced in whole or part without authorisation under my nation's educational / fair use copyright policy. EDIT: I just found a pic of an EB-2000/S in another doc woot! I suspect the EB-1000 will look pretty much the same but white. Sorta interesting it has 4 controller ports, huh? The unit also sems to be 128 bit... I also removed the installation FAQ as it was too big and too specific. These kits came after the DTL-H10100 GS Evaluation board. --------------------------------------------------------------------------------------- PS2 Tool Frequently Asked Questions (FAQ) Q: What is the EB2000? The EB2000 and EB1000 was the old prototype PS2 development system which interfaced to the Linux host directly via an interface card and cable, rather than over the network. All EB2000s and EB1000s have long since have been exchanged for T10000s. --------------------------------------------------------------------------------------- Development Machine Specifications As of July 26, 1999, the basic specifications for the different development machines are below. There are no functional differences between EE 2.3 and 2.4. EB-1000 EE 1.0 System CLK 200MHz GS 1.0 RDRAM 128MB SPU2 none Case colour: white EB-2000 EE 1.0 System CLK 200MHz GS 3.0 RDRAM 128MB SPU2 none Case colour: green EB-2000S EE 2.3/2.4 System CLK 200MHz GS 3.0 RDRAM 128MB SPU2 present Case colour: green --------------------------------------------------------------------------------------- [FAQ] Controller Connection Locations This is an announcement informing licensees that the controller connection locations have changed from what was described in "Development Software for EE Release 0.3.0". If the four controllers on the EB-1000/2000/2000S are referenced from the left as A B C D the connection locations would be as follows. * pre-0.3.0 environments controller 1: D controller 2: B * 0.3.0 and later controller 1: D controller 2: C For details on the drivers, please refer to sce/doc/ee/kernel/eekernel.txt. --------------------------------------------------------------------------------------- [FAQ] librspu2 Operation on the EB-1000 and EB-2000 8th July 1999 The librspu2 sound library is a new addition to the "Development Software for EE Release 0.3.0". Since the EB-1000/2000 development machine is not equipped with an SPU2, the sound library (librspu2) will not operate properly. Thus, the sample programs in /usr/local/ee/sample/spu2/ will not work. We apologize for the confusion experienced by the licensees due to our inadequate documentation. The EB-2000S, which will be shipping soon, will come with the SPU2. Please contact the Business Division for specific shipment schedules. --------------------------------------------------------------------------------------- Differences between EB2000 From: "Anthony Lloyd" <tony@argonaut.com> Newsgroups: sce.dev.devkit Date: Tue, 12 Oct 1999 17:04:30 +0100 Has anybody noticed differences between different EB2000's. We've got a piece of code that works on one, but refuses to work on another. It seems to crash in a function called dpmul (used ee-addr2line and got something like gcc/build/dp-bit.c) ...also... anybody had it randomly hanging in openpad? -- Tony Lloyd - Argonaut Software Ltd - 0973 561927 --------------------------------------------------------------------------------------- Differences between EB2000 From: Dean Ashton <Dean_Ashton@scee.sony.co.uk> Newsgroups: sce.dev.devkit Date: Wed, 13 Oct 1999 07:39:23 +0100 Hi Tony, Not had sceOpen() hang for the pad:/pads: device, but we spent oh-so-much-time looking at a 'works on one kit, not on the other' problem. It turned out (for us at least) that something was causing a floating point divide to fail, causing some spline calculations to go awry. I mentioned it a bit in sce.dev.prog.ee. Colin told us "it sounds like a hardware bug.. don't worry about it"... so now we're just hoping the DTL-T10000's will be either completely working, or at the least consistently f**ked. :/ Dean ~ --------------------------------------------------------------------------------------- Differences between EB2000 From: "Breugelmans" <mark_breugelmans@scee.net> Newsgroups: sce.dev.devkit Date: Wed, 13 Oct 1999 09:56:28 +0100 Hi, Yes we have a a bug on the CPU on one of our kits. That's what you get with prototype hardware I suppose. Mark --------------------------------------------------------------------------------------- Next Generation PlayStation: Technical Considerations DEVELOPMENT TOOLS/HARDWARE Hardware EB-2000S The current development kit, EB-2000S. includes the EE Target Box, two Dual Shocks with DB-9 connectors, a PCI I/F card, I/F connecting cable, power and AV cables. External connections include four DB-9 controller ports, a Sony Multi A/V port, and a DB-9 connector for external devices. The target box connects to the PC via the PCI I/F card. The provided development software is known compatible with RedHat Linux Release 5.0 -.2, kernel versions 2.0.30 -.36, and includes: • GNU development tools • Documentation • Linux Driver for the PCI card • TCP/IP based communication tools • Sample code • Cygnus VU Simulator Source. Setup is simple and consists of: 1. Connecting the power, AV, and controller cables to the EE Target Box. 2. Installing the PCI card into a PC with Linux OS. 3. Attaching the Target Box interface card via the interface cable. 4. Powering on the Target Box, power-on the PC. 5. Mounting the software CD-ROM and coping its contents to the desired directory on the PC. 6. Running a shell script to install the appropriate driver. 7. Loading the TCP/IP communication daemon. DTLH-10000 The final development hardware, the DTLH-10000, will be housed in a PC Tower and function as a standalone workstation or a remote host. Components include: • CD/DVD Drive • Interface connections • Controller • Memory Card • USB • PCMCIA • IEEE 1394 • 100 Base/T with modular connector • Multi-A/V #2 output • Composite video- in (not to be present on final NG PlayStation) • Full PC/AT system • Linux w/inetd and communication stub • HDD • VGA • PS/2 mouse and keyboard connections No artist or sound specific hardware will be provided. Tools Communication utilities supplied with the EB-2000S interface with the PCI card via a Linux kernel Module named “mrp” and an associated character based Linux device file. Mrp is installed simply by running a supplied shell script that calls insmod.. Once the driver has been installed, the communication daemon, dsnetm, must be loaded. Dsnetm sets up a TCP/IP stock on the host machine and detects calls from supported DS utilities. Being TCP/IP based the DS tools lend the EB-2000s to remote and multi user access. The DS tools are: • Dsnetm - communication daemon • Dsedb - gdb-like debugger • Dsxxx - various utilites Other Software provided includes: • GNU Tools • gcc - Compiler. • gdb - GUI and command-line debugger. • SKY Simulator • Simulates the EE and aids in debugging VU code. --------------------------------------------------------------------------------------- Changes to the EE for the EB-2000S EE Rev.2.3/2.4 has been installed starting with the EB-2000S development unit. EE Rev.2.3/2.4 provides fixes for known bugs in EE Rev.1.0 (/usr/local/sce/1st_read/bugs.txt). The following changes to EE Rev.1.0 are in Rev.2.3/2.4. 1. SPR (Scratch PAD RAM) DMA transfers The following restriction has been eliminated. * In DMA transfers where the SPR is the transfer source, the final address of the transfer must be set to a multiple of 8qword 2. MFIFO DMA transfers The following problem was fixed. * Incorrect Ds_MADR, Dd_TADR values when calculating the MFIFO ringbuffer size. 3. VPU constant register The values in the VPU constant register (VF00) have been changed to the following. * VF00 = (0.0, 0.0, 0.0, 1.0) 4. IPU The following limitation has been eliminated. * When an IDEC or a BDEC command is executed in the IPU, decoding may be interrupted under certain data conditions. 5. VPU instructions The following VPU Lower instructions and the corresponding macro instructions can now be used. RSQRT ERLENG ERSQRT The following three items in bugs.txt have not been fixed in Rev.2.3/2.4. 1. Debugging features (hardware breakpoints, etc.) The following problems and inconsistencies still exist. * The data value breakpoint and the performance counter for hardware breakpoints do not always stop at the precise Program Counter position. * The data value breakpoint/ address breakpoint for hardware breakpoints do not work correctly. 2. MFIFO Drain Channel settings If the MFIFO ring buffer address is changed while MFIFO Drain Channel DMA is active, operations may become unstable. Please do not change the ring buffer address during Drain Channel transfers. 3. EFU instruction latency When moving to 300 MHz in the future, the EFU instruction throughput/ latency will increase by 2 cycles. Microprograms that do not synchronize with VPU1 WAITP may have difficulty transitioning to 300 MHz. --------------------------------------------------------------------------------------- GS chip version From: "George Bain" <ps2_support@scee.net> Newsgroups: sce.dev.prog.gs Date: Fri, 7 Jul 2000 17:52:01 +0100 The warnings were for developers using the EB2000. The revision of the GS chip on the EB-1000 is 1.0, and the revision on the EB-2000 is 3.0. However, both of these dev kits are very old and not used by developers anymore. The current GS version is 8.0. The difference between Revision 1.0 and 1.0+ is the mapped address when viewed from the EE side. This is because of the difference in specification around the CRT. BAIN@SCEE "Steve Agoston" <sagoston@ea.com> wrote in message > Thanks! That's exactly what I wanted to hear > > So are the warning in the docs just plain wrong? > > > --------------------------------------------------------------------------------------- EB-2000s From: "George Bain" <ps2_support@scee.net> Newsgroups: sce.dev Date: Sat, 11 Nov 2000 14:33:20 -0000 Hi there, Yes, it was the old PS2 dev kit before the T10K. They were all shipped back to Japan and probably crushed into a thousand pieces... BAIN@SCEE "mark" <mark@moderngroove.com> wrote in message > Does anyone have any info on this tool? Please email me at > mark@mgentertainment.com > > thanks, > Mark > > ~
Interesting that most console dev tools are for Linux since the late nineties yet very few "big-content" software companies have ever released games for Linux (or other Unix-like operating systems), I think they just exploit as a versatile dev platform and that's all (the usual closed mindset of console game publishers).
What you will find even funnier is the devs were crying out for ways to get out of using Linux with PS2 development but Sony hit them with it again for PS3 hehe. Maybe it is a cost issue, or that paying to use a Microsoft OS licence would also be paying to support their competitor, the Xbox.
I've always believed the latter Wouldn't ProDG render complaining about Linux moot (then again, you had to pay separately for ProDG right...)
oh, i have the runtime library .... EB-S8820 and DTL-S12000.....xD btw, SONY working on UNIX is long time ago on boardcast video edit system there easy way for them buil it,
there is setup guide about EB2000 setup1.txt ---------------------------------------------------------------------- EE Board Hardware Setup Guide ---------------------------------------------------------------------- Set up the hardware according to the following procedure. ---------------------------------------------------------------------- Explanation of Terms ---------------------------------------------------------------------- PCI interface cable: Cable for connecting the PC to the Rack Soft power switch: Self-lit square pushbutton located at lower right front of the unit (the front is the side where the board is visible). Reset switch: Red pushbutton located below "soft power switch" Main power switch: Black tact switch on rear panel Controller pin: D-sub 9-pin connector; same specifications as DTL-H2500; when facing the front, ports 3, 2, 1, and 0 are arranged sequentially from left to right; normally port 0 is used ---------------------------------------------------------------------- Setup ---------------------------------------------------------------------- 1. Connect cables 1) PC and Rack connection After confirming that both the PC power and Rack power are off, connect the PC to the Rack using the PCI interface cable. 2) Rack and AC power cable connection After confirming that the "main power switch" on the rear panel is off (0), connect the AC power cable to the power supply connector on the rear panel and connect the plug end to a wall socket. 3) Controller and video cable connections Connect the controller to port 0. Note: Connect the second controller to port2. 2. Turn power on 1) Turn the PC power on and start up Linux. 2) Turn the Rack power on (hard power supply) Turn on (1) the "main power switch" on the rear panel of the Rack. The circuit boards are not yet receiving power in this state. 3) Turn the Rack power on (soft power supply) Pressing the "soft power switch" on the front panel for two seconds will cause a beeping sound to be emitted and turns the power on. At this time, the "soft power switch" will change color to yellow. Power has now been supplied to the circuit boards. Confirm whether or not power is on by checking the "soft power switch" light. The pushbutton will be illuminated if power is on. 3. Turn power off 1) Turn the Rack power off(soft power supply) Pressing the "soft power switch" on the front panel for two seconds will cause a beeping sound to be emitted and turns the power off. The "soft power switch" light will turn off at this time. In this state, the controller can be removed because circuit board power has been turned off. Note: Always turn the power off before removing the controller. Otherwise, damage to the board may occur. 2) Turn the Rack power off (hard power supply) After confirming that the soft power supply is off, turn off (0) the "main power switch" on the rear panel. At this time, the power will be completely turned off. setup2.txt ---------------------------------------------------------------------- EE Board Software Setup Guide ---------------------------------------------------------------------- This guide explains the procedures for driver loading, flash updating and sample program compilation/execution. Except for "Driver loading", the following operations can be performed from a user account. ---------------------------------------------------------------------- Path setting ---------------------------------------------------------------------- All commands should either be in /usr/local/sce/bin or symbolic links should be created for them. Set the path to /usr/local/sce/bin. ---------------------------------------------------------------------- Driver loading ---------------------------------------------------------------------- Perform this step from root. Since the Linux kernel module is used for drivers, the module must be installed in the kernel. If it has been removed, rebuild the kernel before loading drivers. # mrp start To automatically load drivers when the machine is restarted, add the following lines to /etc/rc.d/rc.local. if [ -x /usr/local/sce/bin/mrp ]; then ( cd /usr/local/sce/bin && ./mrp start ) fi ---------------------------------------------------------------------- Starting dsnetm ---------------------------------------------------------------------- dsnetm is a daemon that is used to provide data communications between the target and various types of commands (clients) on the host. socket is used for exchanges between dsnetm and each of the commands. This allows each of the commands to be used from other hosts. Basically, dsnetm operates in the background. If it starts up normally, the following messages will be output: $ dsnetm dsnetm (Version 0.1.41 Wed Aug 11 15:45:06 JST 1999) Connecting to /dev/mrp0 ... Entering server mode $ In a manner similar to that described for drivers, by adding the following lines to /etc/rc.d/rc.local, the program can be automatically executed when the machine is restarted. if [ -x /usr/local/sce/bin/dsnetm ]; then ( cd /usr/local/sce/bin && dsnetm ) fi ---------------------------------------------------------------------- Flash Update ---------------------------------------------------------------------- Download flash-0825.bin and copy it to a suitable directory on the development machine. When the flash-0825.bin is copied to /tmp: $ dsflash /tmp/flash-0825.bin If the following is displayed on the screen, the update was completed successfully. : romflash Revision: 1.2 quick mode (pos=c, sig=a4) on native kernel Read 'flash-0825.bin' ... 524174 bytes Clear flash memory Writing flash memory (source address 0x00041100-0x000c108d) Verify flash memory Wrote flash memory Complete ! ---------------------------------------------------------------------- EE Sample Program Compilation/Execution ---------------------------------------------------------------------- By executing $ make under sce/ee/sample, all sample programs can be compiled. To compile individual programs, please execute the make command under each sample directory. By executing $make run the sample can be executed. The dsedb command can also be used to execute the program. Although the dsedb command is essentially a debugger, it is also used just to execute programs. For example, when the execute form file is sample.elf, input the following: $ dsedb -r run sample.elf To execute the program by starting the debugger, input the following: $ dsedb dsedb (Version 0.1.41 Wed Aug 11 15:45:18 JST 1999) *** Resetting... (type `help' for getting help) dsedb > run sample.elf The program is executable even when the dsnetm is operating in other hosts. In this case, specify the name of the host in which the dsnetm is being executed as follows: $ dsedb -d hostname -r run sample.elf For detailed operation methods of the various commands, e.g. debugger, refer to the documents under doc/tool. Refer to "Makefile" in the sample directory for program compilation methods, etc. Use app.cmd for the link command file and crt0.s for the start-up file. ====================================================================== Preparation for IOP Program Loading ---------------------------------------------------------------------- When setup is complete, execute the following command: $ dsreset 0 2 This disables activation of the program which starts operating in the event of default and receives controller file requests from the EE. This setting will remain effective from this point on even when the system is reset. Therefore, when executing the EE program in the system, execute the following command or re-activate the dsnetm: $ dsreset 0 0 ---------------------------------------------------------------------- IOP Sample Program Compilation/Execution ---------------------------------------------------------------------- Execute the following under sce/iop/lib: $ make This will set the compiler path, etc. Then, execute the make command under the directory where the program exists. Executing the following command makes sample execution possible. $ make run Note: The sample under sce/iop/sample/kernel/thread cannot be executed by the make run command. Refer to readme.txt under the thread sample directory for execution procedures. The program can be executed from the command line. In this case, use the dsistart command. With the hello sample, input the following: $ dsistart hello Also, the dsidb command can be used to run the program. The dsidb command is similar to the dsedb and is an application designed for program execution and debugging. To run the program by starting the debugger, input the following: $ dsidb dsidb (Version 0.1.41 Wed Aug 11 15:45:23 JST 1999) *** Resetting... *** DBGP Version 3.00 : : dsidb > mstart hello The program is executable even when the dsnetm is operating in other hosts. In such cases, specify the name of the host in which the dsnetm is being executed as follows: $ dsistart -d hostname programname $ dsidb -d hostname Refer to "Makefile" in the sample directory for program compilation methods, etc.
Notes.txt ---------------------------------------------------------------------- Notes on hardware revisions ---------------------------------------------------------------------- The versions of each chip are listed below. See the bugs.txt file for information about known bugs. 1. EE The version of the EE chip mounted on the EB-1000 and EB-2000 is 1.0. From the EB-2000S onwards, the version is 2.3/2.4. 2. GS The GS may have slightly different specifications depending on the chip version. The version of the GS chip mounted on the EB-1000 is 1.0, and the version mounted on the EB-2000 onwards is 3.0. A difference that has been confirmed between version 1.0 and subsequent versions is that addresses viewed from the EE side differ because CRT-related specifications differ. Functions that will be supported beginning with revision 3.0 are as follows: - Texture function HILIGHT2 - Destination alpha test mode - The maximum uv values available when using REPEAT with CLAMP_1 and CLAMP_2 registers have been expanded from 1024 to 2048. bugs.txt ---------------------------------------------------------------------- Information about known bugs ---------------------------------------------------------------------- The EE (Rev. 1.0 and 2.3/2.4), has a number of bugs, and contains functions which are subject to change in future releases. Be careful when using the functions described below. ---------------------------------------------------------------------- Restrictions and malfunctions in the EE (Rev. 2.3/2.4) ---------------------------------------------------------------------- 1. Debugging Functions (Hardware Breakpoint etc.) The following problems exist: - The hardware breakpoint's data value break point and performance counter do not stop precisely at the exact Program Counter location.. - The hardware breakpoint's data value breakpoint / address breakpoint do not function properly. 2. MFIFO Drain Channel setup If the MFIFO Ring Buffer address is changed while an MFIFO Drain Channel DMA is in progress, unpredictable operation may result. Avoid changing the Ring Buffer address during a Drain Channel transfer. 3. EFU Instruction Latency The following specifications will be changed in the final specification version. Module to be changed : EFU Contents to be changed: EFU instruction latency As shown in the table below, the throughput and latency of the EFU instruction will increase by 2 cycles. It is possible that the microprograms that do not synchronize with the WAITP in the VPU1 might become inoperable with the shift to 300MHz. We apologize for the inconvenience, but appreciate your understanding on this issue. EFU new throughput/latency -------------------------- =========================================================== 200Mhz 300Mhz instruction throughput latency throughput latency ----------------------------------------------------------- EATAN 51 52 53 54 EATANxy 51 52 53 54 EATANxz 51 52 53 54 EEXP 41 42 43 44 ELENG 15 16 17 18 ERCPR 9 10 11 12 ERLENG 21 22 23 24 ERSADD 15 16 17 18 ERSQRT 15 16 17 18 ESADD 8 9 10 11 ESIN 26 27 28 29 ESQRT 9 10 11 12 ESUM 9 10 11 12 ----------------------------------------------------------- 4. Conditional Branch Problem The branch condition might be misunderstood if all the following conditions are satisfied. - In a loop of 5 steps or less - The branch condition depends on 8-byte alignment - All instructions and data access is executed on the cache If bus access is made in a loop, or an instruction with a large latency exists, this problem will not occur. < Action > Do not use a loop of 5 steps or less in assembler descriptions. 5. SQ Instructions in VPU With the combination of any upper instruction and an SQ (lower) instruction, when the floating destination register number (fd) of the upper instruction and the integer source register number (it) of the SQ instruction are the same, an unnecessary stall occurs because it is assumed that there is register dependency. This does not occur in SQI, LQI, SQD, LQD instructions. This limitation will be corrected in the final specification version. 6. DMA-tag mismatch error in VIF A DMA mismatch error interrupt might occur if VIFn_ERR.ER0 is set to 0 (DMA-tag mismatch error mask disable), even if a correct packet is sent to the VIF. < Action > Set VIFn_ERR.ER0 to 1. ---------------------------------------------------------------------- * Restrictions and Malfunctions of EE (Rev 1.0) ONLY -- These have been already fixed/changed in EE(Rev 2.3/2.4). -- ---------------------------------------------------------------------- 1. SPR (Scratch PAD RAM) DMA transfers There is a problem with DMA transfers when the SPR is the transfer source. For a DMA transfer in which the SPR is the transfer source, the transfer must be specified so that the last transfer address is a multiple of 8-qwords. This problem is expected to be fixed in the final specification version of the chip. 2. MFIFO DMA transfers The following problem occurs. When calculating the remaining size of the MFIFO Ring Buffer, an incorrect value (0) will be returned for a Ds_MADR or Dd_TADR read (Ds: source channel, Dd: destination channel). An address for using the Ds_MADR or Dd_TADR should be obtained as shown below. This problem is expected to be fixed by the final specification version of the chip. 3. VPU constant register In the final specification version, the VPU constant register (VF00) will be changed to the following value. VF00 = (0.0, 0.0, 0.0, 1.0) 4. IPU If the following condition is satisfied when an IDEC or BDEC command is executed by the IPU, decoding may stop before it completes. This problem is expected to be fixed by the final specification version of the chip. The condition is satisfied when the 62nd coefficient (initial coefficient=1) becomes the last non-zero coefficient in the list of pre-reverse scan coefficients while decoding each block, after the VLC has been decoded. ---------------------------------------------------------------------- * Restrictions and Malfunctions of EE(Rev 2.3/2.4) ONLY ---------------------------------------------------------------------- 1. Simultaneous Transfer of DMA ch1 and ch9 Transfer might stall when the toSPR and toVPU1 source chain modes are executed simultaneously, and when TTE of toSPR is 0 and TTE of toVPU1 is 1. < Action > Do not activate the DMA under the above conditions. This limitation will be corrected in the final specification version. ====================================================================== GS (Rev. 1.0/3/0) has the following restrictions. Take special care when using. The GS chip revisions on the development tools are as follows: GS 1.0: EB-1000, EB-2000 GS 3.0: EB-2000S ---------------------------------------------------------------------- * Restrictions and Malfunctions of GS(Rev 1.0) ONLY ---------------------------------------------------------------------- - When a negative value is set for offset K when calculating LOD, subsequent drawing may be corrupted. - When the value of texture buffer width TBW is set to 0x20, improper operation will occur. - When CLUT replacement occurs during drawing using Trilinear (LINEAR_MIPMAP_LINEAR), the contents of CLUT memory may be destroyed. - When the PSM value of DISPFB1(2) is PSMCT16, PSMCT16S, or PS-GPU24, and the DBX satisfies the following condition, it will not be displayed correctly. 32+64*n <= DBX < 63+64*n ---------------------------------------------------------------------- * Restrictions and Bugs in GS(Rev 3.0) ONLY ---------------------------------------------------------------------- - In a 150MHz clock cycle immediately after access to any registers of FRAME_1, FRAME_2, ZBUF_1, and ZBUF_2, when the vertex register for drawing is accessed, the previously accessed content of the FRAME_1, FRAME_2, ZBUF_1, and ZBUF_2 might not be set correctly. - In the local-host transfer, the transfer might fail when the pixel store mode of transfer data is any of PSMCT24, PSMCT16, PSMCT16S, PSMZ24, PSMZ16, and PSMZ16S, and when the GS is in the wait mode during transfer. < Action > By setting the transfer data size to a 8-qword, 256-bytes multiple, all data transfers are+ executed by DMA. This makes it possible to prevent the GS wait in the most cases.
