Cool.I've been busy for a while, but time should be freeing up soon…
What I'd like to do:
Finish dsnet reverse engineering (…unless SilverBull decides to show up again)
Remote control of power/reset buttons
Replace the remaining 50mm fans with 40mm fans + adapter (more info on this soon)
Raspberry Pi CM4 to PICMG 1.2 half size adapter
Hello everyone! Recently I got my T10K model PS2 Devkit. I tried to turn it on, and seems the PC side works fine, however, the PS2 side, ~10secs after I turned it on, the screen starts showing 8 grey-ish color vertical bars (they evenly occupied the whole screen).
This kit currently does not have any hard drives in. I am not sure if the vertical bar staff is normal or its a bad sign of the GPU/Vram.
Wondering if anyone has seen this before?
I found an YouTube video looks exactly the same (Look at 8:42)
Ok i can tell you if the tool dosent have any hdds, then you are not going to get anything on the ps2 side. This may be the cause of your grey bars, flash a drive with a tool ps2 image of hdd1 and it should fix your problem. I recommend running a cf card vs a normal hdd since it will last longer.
Here you go guys, roms dumped for my other 2 T10k
both dumps taken while set to TOOL mode on the front switch panel (from powered off)
I come bearing gifts:
- T10k-1 https://mega.nz/folder/6PxFTALD#-86975rqUsviL9DKGDp1Iw
- T10k-2 https://mega.nz/folder/qP4RhaCB#QJp2v6tRzpHoLUnkclQMkA
note 10k-1 was tampered with before i dumped it (new user account "dev" added but thats it). the second kit was untouched.
also strangely enough, the second kits drive1 dump compressed is larger than the compressed dump from the first kit, was expecting it to be similar in size. i havn't run recovery on either yet, ill try run r-studio over them soon and upload the scn files to mega
Hi, ive fixed the links on the original posts, link is also available here: https://mega.nz/folder/yOpWWC7B#qO5mMyCnT04DC9nbhcgSzwAny chances that these can be reuploaded somewhere please?
The links are dead.
ouch, so does that mean that the tool is a 30lb paper weight or is it fixable?
How "dead" is it?
If there is no EE serial output, check the serial cable going from the PS2 board to the PC board.
If there is no IOP serial output, check the connection between the backplane and the PS2 board, and also the flash ROM.
UnderstandableIt wasn't fixable at all. I've on sold it now.
I messed around with it for years, pulled a part and put back together multiple times and no go. I was told to try doing a similar fix to PS3 YLOD, but I didn't want to heat up the board cause I didn't want to f**k it.
This system is very quiet now, no more whine
For the fan adapter, this is what I used: https://www.thingiverse.com/thing:735038
For the PC board fan, I used the following: Amazon product
For the EE/GS fans, I used the following: Amazon product
It may be challenging to insert the PC card once the EE/GS fans are placed, but it is still possible.
Thank you for the info, ill add this to my guide and update the resource. Ill post the link to the updated guide here.An excerpt from my old thread "PS2 Tool: Questions" on Assembler Games, with some updated information. Also thanks to wisi for some of this info.
I have a few questions about the PS2 Tool.
* 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?
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.
* Is there any way to disable writing to the Flash ROM?
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.
* 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?
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?).
(After some time): I took out the following:
CDVD drive (and associated ribbon cable)
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)
* Is it possible to use the other three PCI slots from the PC side or the PS2 side?
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.)
* Is there a way to switch to YCbCr mode?
EE argument bit 4 0x00000010 Component video output
* 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.
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.
* 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.
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.
* Are there any upgrades or replacements for the SBC?
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).
* Misc information about my system
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)
(At the end, I just left it in, since it's easier to switch it and the cable isn't that long)