I have a few questions about the PS2 Tool. 1. What is MRP? mrp.o appears to be a Linux kernel module. How does it communicate with the PS2 side? Does it communicate through the serial cable or through the PCI slot? 2. Is there any way to disable writing to the Flash ROM? 3. How much of the TOOL's internals can you take out/disconnect before basic functionality (running programs on the EE and IOP) will stop working? 4. Is it possible to use the other three PCI slots from the PC side or the PS2 side?
3: should provide basic functionality along as the backplane pci card hdd and power supply are connected. I’m not sure about the sub board that the drive ribbon connects to though. There’s a good chance that any useful functions require that too
MRP = Linux kernel Module for the Request Processor (this is a guess) It is the PC-side driver for the PIF (PC(SBC)/Processor InterFace), which is the big Xilinx FPGA on the backplane (together with the 4 FIFO chips on the bottom side of the backplane). There are (similar) registers on PC (PCI) and PS2 side, through which communication is done. There two channels - one single byte "serial" port and another that can transfer packets (using DMA as well). DECI2 packets are sent over it. In the same registers range there are also registers for controlling the power/reset of the PS2 and PC sides, LED control, power button reading, etc. the BID (Board ID) register is there as well. The register range starts at 0xBF803800. A list of the register ranges under the EXTR (EXTRA) SSBUSC device channel and registers descriptions is attached. It was compiled with the help of SP193. The PIF/MRP (FPGA) connects through buffers to the PS2 IOP SSBUS and through a PLX PCI9050 PCI<->other buses bridge to the SBC PCI bus. I do not know of such a way (unless you manually disconnect its write-enable line and set it to inactive state), but depending on the DIP switch on the back, only half of the Flash-ROM will be written on update (AFAIK). But disconnecting the /WE line will also prevent reading the Flash ID and other data, so this won't work correctly. In theory the CDVD PCB and the AIF (+Dev9) PCB can be removed and it might even be possible to disconnect the Backplane from the MPU4 board, leaving you with a bare MPU board, that if you power somehow should run as a bare PS2 (with more RAM), but it will probably require emulating some of the signals that connect it with the backplane and will a different ROM image that does not try to initialize the missing components. But if you need it to run as a TOOL, then there is hardly anything that can be disconnected, leaving it still fully-functional (maybe the AIF board only and additional PCI boads?). The PIF is a peripheral PCI slave device on the PCI bus, so AFAIK it cannot become a PCI master and communicate with other PCI devices. It should be possible to use any of the PCI slots for mostly anything PCI slots can be used for, although there may be a requirement in which slot the SBC must be and also some of the PIF drivers (powercontrol) require the PIF to be connected to PCI slot 0 (if I remember correctly). (Otherwise up to four MRP devices are supported, but in this case the PIF is integrated on the backplane, and it needs to be on a PCI card for this.)
about #3: I took out the following: CDVD drive (and associated ribbon cable) AIF HDD SIO2 ports (controller and memory card) Eject board (and associated cable) LED board (and associated cables; showing the status of TOOL/WS and CDVD/EMULATOR modes, as well as one LED for 3 HDDs) Since it was sold with broken plastic casing, I put it to the side, intending to fix it later. I trashed most of the foam and copper tape. I used a compressed gas duster to clean out most of the dust. I replaced the HDD connected to the PC SBC with a CF card. I might take out the TOOL/WS/CDVD/EMU switch board, since its primary function (ROM swap) can be replicated by DIP switch #1 (1-indexed, away from the PSU) I have more questions: 1. Is there a way to switch to YCbCr mode? 2. Is there a way to make the SBC go past the initialization screen faster? I already disabled the built-in floppy controller, disabled boot seeking, disabled the extended memory checking, set the boot order to C only, and disabled the primary slave HDD. 3. Has anyone benchmarked the speed of the SBC PCI<->IOP yet? I'm curious if this is faster than the speed of an HDD connected to the Network Adapter. 4. Are there any upgrades or replacements for the SBC?
If some DIP switches of it are in default "connected" state, you would also have to replicate those connections. I don't know, but I guess it should be the same as on a regular PS2, so you may need to write a small program to do that, if one does not yet exist. I can't think of anything more than what you already did. You could try updating the BIOS, and look for a "fast-boot' option. As for the Linux startup - you could probably edit the bootloader configuration, and the Linux startup scripts. It *should* be very fast compared to PS2 Ethernet connection speed, but I think it is at least two to five times slower than the PS2 internal HDD. The maximum transfer rate on the IOP is ~120MB/s, and when transferring data between a peripheral device (SPEED chip - HDD) and the EE it is half that ~50MB/s. The SPEED chip SSBUSC channel is configured to the fastest SSBUSC settings (and so is the CDVD device if I remember correctly). But the EXTRA SSBUS channel uses lower speeds - at least twice lower, but I don't know for sure (because of the multiple buffers between the SSBUS and the PIF FPGA). Also the PCI interface limits the maximum speed somewhat. So it is probably the second or third fastest peripheral device after the internal HDD. I have read about this on the forums (but I don't remember the thread). On the PS2 TOOL, the SBC was meant only as a communication processor and no work was done directly on it. (almost quoting SP193) Also given that Ethernet is used to connect it to the development PC(s), it probably didn't need to be particularly fast. On the PA DTL-T15000 (AFAIK) there is a dedicated MCU connecting the main sampling FPGA to the PIF FPGA and/or PCI bridge, which probably enables faster transfers of sampled data to the network (but I don't know exactly how this system works).
The RGB/Component colour space setting is either set via the DIP switch at the back or via dsnet. I forgot. But you can refer to the user manual for that. I think the bootup times are quite normal for Linux on a Pentium/Pentium Celeron of that time. Once we start up the machine, there is no need to reboot that part, so the overhead is not really a problem. BTW, these sets are very rare and difficult to repair. So while it is good to explore, please be careful with what you do...
A bit off-topic: The GS video input is an interesting feature available on the early GS revisions and the TOOL - the S-Video input on the back. I once did a test of it on a SCPH-30003 (only the alpha input, as the color inputs are grounded), by both displaying the captured video and recording it to the internal HDD, as raw frames and then playing it back. The code used in the video had some bugs (due to other tests done using the same code) which resulted in much lower transfer rate than the maximum 53MB/s, because I made the video a few months after coding it and at the time of recording didn't feel like going through all the code to fix its issues.
Ah, found this information in the dsnet overview manual: bit 4 0x00000010 Component video output 0 RGB 1 Y/CrCb
Did you manage to get this to work? My TOOL had developed this fault in recent years, whereby lots of wavy lines appear on the screen. I usually use composite with the TOOL because I connect my CEX PS2s to component. So to check whether it's a problem that also affects component, I plugged the component cable into the TOOL, but I cannot get a signal. Not even if I enabled this option.
I haven't tried it yet. Have you tried a component-to-VGA adapter on the VGA port, then connecting the component to your TV?
Anyway, for reasons... it started working after I went away to play on my PS3 for a while. As in, I left it to install games onto the HDD unit, went away, and found that it started displaying video. Maybe it's a hardware problem. I'll probably make a thread to ask for help about all the problems someday. The waves are less prominent over component. Thanks though!
