I have acquired an old tool T10000, when dsnet is run, the command hangs for several mins and then "no connectr" shows. I have tried disassembling the unit and make sure every connection is tight but the problem persist. What could the problem be....?
I am not sure what you have done. Could you please elaborate? Usually, dsnetm is automatically run at boot, so you cannot run it again. Did you confirm that it failed to work at boot? Connectr stands for Connect Response. Connect would be issued to both the EE and IOP DECI2 managers, which will send Connectr back to the Host node. So to troubleshoot which CPU may have a hardware problem, you can run dsnetm in interactive mode (dsnetm -i), so that the logs can be checked on with the "show log" command. Upon a fresh boot, does the TOOL successfully show the TOOL boot screen? I mean the one that says "TOOL" and displays the network configuration.
Thanks SP193. You are always helpful to this community. I think the communication board (bottom one) is dead and I managed to source for another one. I have a new problem which may need your help. As I do not want to open my T15000 too frequency to connect my PS2 side HDD to WinHiip, I really want to get HDL dump server running on my TOOL. I know you are the expert on this matter. Could you please give me some suggestions? Thanks!
Before you get rid of the "faulty" board, maybe you would want to check that it looks like the one you replaced it with. It is unlikely, but it would be a shame if somebody tosses away some pre-release hardware. As for HDLDump, you should try booting it from dsedb when the WS mode ROM.
Thanks for your help. HDL server runs on WS mode only.... (May I ask why?) Now the HDD is started and the ip is reported back to tty. I can ping the ip alright but now the hdl_dumb.exe said connection refused... What is the problem? Thanks!
The TOOL/WS mode switch selects between the TOOL's two operating modes, although only one is implemented. The switch also selects between two flash ROMs. The WS mode ROM was never updated, so it always contains the oldest-possible kernel modules, which are believed to be from SDK v1.3.4. Homebrew software are generally made to work with the kernel modules from the CEX's ROM, which also contain the oldest-possible kernel modules. On the other hand, the TOOL's flash ROM was meant to be always flashed to contain kernel modules from the SDK that the developer is using. At some point, Sony changed their semantics for some RPC services, but the old RPC clients that the homebrew SDK uses lack version checking (and it cannot be implemented with the old IOP modules anyway). So if you use new IOP kernel modules with homebrew software, then it might work... or it may give you an exception within some kernel module. There's also this issue with earlier homebrew software using board-specific modules. Assuming that the board-specific files do exist, they may even be of incompatible versions. So to keep things simple, just use WS mode. It is not a total solution for all cases, however. With the introduction of the libosd kernel patch, the old kernel from WS mode is actually corrupted whenever homebrew software with that patch is run. This is because the TOOL's kernel from that time did not share the same regions of unused space, as the SCPH-10000. Are you using the correct client version? There's HDLDump v0.9.x, which requires a matching client. Likewise, v0.8.6 must work with a v0.8.6-compatible client.
Thanks for your explanation! I have managed to connect hdl dump by 0.8.6 ( I was using 0.8.3). So the WS mode is useful after all huh?! My next target is to run retail ps2 browser on the tool. Let's work on it
Congratulations! This will likely require more work than just using WS mode. The browser requires the board-specific modules and resources, which do not exist on the TOOL's ROM. So unless you manage to get the browser to load all modules and files from host (and provide the necessary files from there), it will require actual modifications to the browser. I remember seeing that there was some code that caused the host device to be accessed, but you need to figure out how to use it. Some things, like reading of model name, may not work because the default CDVDMAN module from the T10000 v1.00 ROM is missing some system functions like sceCdRM(). Who knows why it was made that way, but that is how it was. Thankfully, I doubt there will be any problems, even if this function does not work.
Thanks for your expert comments SP. Or alternatively... to keep works to a minimal level, can we patch the kernel in ram so that the future calls to rom0 can be redirected to host0? My vision is to create an "system software mode" environment which will facilitate the use of homebrew, ps2 browser etc... my experience is not enough for this vision tough...
Why not just run the software on a CEX, like they were meant to? When software is transitioned from development to testing, the code had to be altered to access whatever device it was meant to support, and to reboot the IOP with the supplied IOPRP image. During development, the official software used the host: device. If you really want to see a browser run on this, why not choose the HDD Browser? I think it'll be easier to work with it, since it was made to run on all CEX consoles, regardless of model (hence doesn't use board-specific modules/files).
Note to someone with similar experience in the future: The dsnet commands hanging problem was caused by a broken flex cable connecting the motherboard and DVD drive. The board is always waiting for handshake from the drive and so never response probably. A replacement fixed the problem: 0.5mm pitch 54pins 27.5mm wide 275 - 300 mm long (both connectors on same side) flex cable
