Received a DTL-T10000 today and seem to be getting the same TOOL screen on both the AV MULTI OUT and VGA displays regardless of the TOOL/WS/EMU/DVD switches. I was under the impression that one display would display a Unix screen and the other would display the TOOL INFO screen, but not both. Running a self diagnostic test on it now - will update this when it's complete.
Have you taken the metal plate off at the bottom on the back and used the PC side VGA port? 2 screws on it. Easy to find.
Yeah technically you aren't supposed to get a Linux screen as you're supposed to connect in via the network, which is why they put a metal plate over the VGA port that does display a Linux screen. All the official development tools work in a client/server arrangement, which is good because the PC in the TOOL is terrible.
Technically correct yes, but unfortunately this is how most people tend to use their kits. I just didn't want him to assume there was a problem with his TOOL by not seeing the Linux side of the TOOL that he was expecting to see. (which judging by his post, he did assume there was an issue) For the people that can't/won't install the PS2 SDK using their kits in the way I suggested is the only way they'll be able to get any use out of it, (even if just to boot master/normal discs) which is a damn shame as they are fun as hell to develop on with the proper environment set up.
Ah right okay that makes sense then, I must have just seen it somewhere and assumed it to be its purpose. I have a beta PS2 disc - what's the best method of booting this with the official tools/without my PS/2 keyboard (on its way; my USB->PS/2 adapter didn't work)?
Here's the log file from the self diagnostics:- https://mega.nz/#!VlMRhYBY!-57kBHfCXUkShDLBNYGQYX7Ii4vUNiJO1aaY_0dJjeQ I noticed a few errors in there - but during the tests I noticed some of the usual stuff like teapots etc on-screen, so I don't know what exactly is the issue. I have tried resetting with dsedb -d x.x.x.x 2 0 from within a VM using Vagrant with a disk inserted both beta & blue retail and nothing happens. Could it be that the TOOL is outdated a bit? EDIT: After updating the flash ROM to 3.00, using reset 2 0 seems to boot an application from disk - however both retail & beta disks seem to crash with this:- Code: *** Unexpected reply - type=BREAKR result=EXCEPTION *** Target program stopped. Check the location by dr command. Also, what should the dip switches be typically set to?
Logging into the Linux part will cause the login to be recorded, so that wouldn't be ideal if the user would like to maintain the original condition of the TOOL in that sense. You can't. It originally wasn't meant to be booting discs directly. SCEI eventually added a boot option to boot discs within the late flash ROM, but that has to be specified as part of the EBOOTP reset parameter. Not all diagnostics will pass on every TOOL. Some of them weren't updated to work with the late flash ROMs. It's not a concept of being "outdated" or not, but your ROM is meant to match the SDK that you are using. In your case, you wanted the new feature that allowed developers to test their master discs directly, but the result is that you are using a newer flash ROM. Depends on what the fault is. The late ROM also had some runtime checks implemented within its EE kernel, so you probably triggered one of them and there should have been some other message before this break exception message. You can disable the new runtime checks by specifying 0x000F0002 for EBOOTP. As mentioned before, the ROM had to fit the SDK that you are developing on. If your game was made with an older SDK, its IOP modules may not be replaced correctly. For the late ROM versions, SCEI added an option for a test mode, which will cause the modules that are used in a DEX to be loaded. Specify 0x100 for IBOOTP. What DIP switches?
I tried to run ./dsedb -d x.x.x.x reset 0x000F0002 0x100 with both the beta and retail discs and I still get the same thing. The log is like this:- Code: vagrant@vagrant-ubuntu-precise-32:/vagrant/bin$ ./dsedb -d x.x.x.x -r dsedb (Version 1.26.1 Wed Jun 30 16:00:32 JST 2004) *** Resetting... EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M *** DBGP Version 3.20 (type `help' for getting help, or `help help' for getting help of help) dsedb R> reset 0x000F0002 0x100 EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart. # Initialize GS ...NTSC mode # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize User Memory ... # Initialize Scratch Pad ... # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart Done. *** Resetted EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M # Restart Without Memory Clear. # Initialize GS ...NTSC mode # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize Scratch Pad ... # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart Without Memory Clear Done. *** Resetted *** Resetted EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M Using Reversed DMA list to store Z Buffer *** Unexpected reply - type=BREAKR result=EXCEPTION *** Target program stopped. Check the location by dr command. dsedb S> quit Could it be that it's attempting to run in NTSC as opposed to PAL? The ones at the back. At the front, I have TOOL & DVD set.
What is the output of dr? Is the game known to actually work? Is this a burned disc or a pressed PS2 disc? Games have full control of the hardware, so it likely isn't a problem. Usually, you shouldn't have to adjust those. Most of the settings are undocumented. Only 1 of them is documented, which adjusts the default video mode (NTSC/PAL). As games have full control of the hardware, it isn't very important.
This is a burned beta disc of Crusty Demons. It works within an emulator, retail PS2 (w/ FMCB) & PS3s which support BC. Here's the output of dr:- Code: vagrant@vagrant-ubuntu-precise-32:/vagrant/bin$ ./dsedb -d x.x.x.x -r dsedb (Version 1.26.1 Wed Jun 30 16:00:32 JST 2004) *** Resetting... EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M *** DBGP Version 3.20 (type `help' for getting help, or `help help' for getting help of help) dsedb S> reset 0x000F0002 0x100 EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart. # Initialize GS ...PAL mode # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize User Memory ... # Initialize Scratch Pad ... # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart Done. *** Resetted EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M # Restart Without Memory Clear. # Initialize GS ...PAL mode # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize Scratch Pad ... # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart Without Memory Clear Done. *** Resetted *** Resetted EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M Using Reversed DMA list to store Z Buffer *** Unexpected reply - type=BREAKR result=EXCEPTION *** Target program stopped. Check the location by dr command. dsedb S> dr at=00890000 v0-1=00b4dd34,fffffffc a0-3=00000000,07ffe8a0,07ffe7a0,00000000 t0-7=0085bb31,07ffe8b5,00000000,a0026580, 20888a80,a0000000,00000004,0000001f s0-7=0085bb28,00b4dbc0,00b4dd38,00860000, 01efff90,00000000,00b4db00,008ac750 t8=80025980 t9=00035540 k0=80016ed8 k1=00000000 gp=00882770 sp=07ffe860 fp=00000000 ra=006a440c lo=0181e460 hi=00000000 sa=00000000 PC=006aa6ac badvaddr=0000000c badpaddr=26d94480 $cause = 0x40008008 [ BD2 CE0 EXC2=Reset IP7 EXC="TLB miss,load/fetch" ] $status = 0x70030c13 [ Cu210 EDI EIE IM3 IM2 KSU=User EXL IE ] 0x006aa6a4: 0xffbf0000 sd $ra,0($sp) 0x006aa6a8: 0x7fb00030 sq $s0,0x30($sp) ->0x006aa6ac: 0x8c90000c lw $s0,0xc($a0) 0x006aa6b0: 0x12000014 beq $s0,$zero,0x006aa704 0x006aa6b4| 0x00a0882d move $s1,$a1 0x006aa6b8: 0x3c120089 lui $s2,0x0089 # 0x008910c4 0x006aa6bc: 0x8e4210c4 lw $v0,0x10c4($s2) dsedb S> quit I flipped switch 5 so that it now runs in PAL mode, I tried it in NTSC aswell, but the same thing happens. What's weird, though, is that since flipping that switch and running ./dsedb -r on the T10K after doing the above, removing and inserting a retail PS2 disc - the retail PS2 disc booted! I guess now it's just a case of whether or not this beta disc uses IRX's which aren't available or are newer/older than needed? EDIT: Ok so, the retail disc was FFVII: DIrge of Cerberus and although it did infact boot - it crashed just after the intro FMV, just at the main menu, with the following output:- Code: vagrant@vagrant-ubuntu-precise-32:/vagrant/bin$ ./dsedb -d x.x.x.x -r dsedb (Version 1.26.1 Wed Jun 30 16:00:32 JST 2004) *** Resetting... EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M *** DBGP Version 3.20 (type `help' for getting help, or `help help' for getting help of help) # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart. # Initialize GS ...PAL mode # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize User Memory ... # Initialize Scratch Pad ... # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart Done. *** Resetted EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M # Restart Without Memory Clear. # Initialize GS ...PAL mode # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize Scratch Pad ... # TLB spad=0 kernel=1:12 default=13:36 extended=37:47 # Restart Without Memory Clear Done. *** Resetted *** Resetted EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01 CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M *** Unexpected reply - type=BREAKR result=EXCEPTION *** Target program stopped. Check the location by dr command. dsedb S> dr at=70000000 v0-1=00d326b0,00532660 a0-3=00532660,00000000,1485fffb,00000001 t0-7=004e8ad0,00000000,00fd46d4,00f98000, 00d4fba0,004f0000,00d4fba0,3f800000 s0-7=00d32650,00000001,24630004,00d326b0, 00d32650,00fd4650,004ee4a0,00000000 t8=70002020 t9=00000045 k0=80016ed8 k1=00000000 gp=0000000e sp=01fff8c0 fp=00000000 ra=002eb68c lo=00000000 hi=00000000 sa=00000000 PC=002eb820 badvaddr=1485ffff badpaddr=26d94480 $cause = 0x40008010 [ BD2 CE0 EXC2=Reset IP7 EXC="Address Error (load/fetch)" ] $status = 0x70030c13 [ Cu210 EDI EIE IM3 IM2 KSU=User EXL IE ] 0x002eb818: 0x10c00007 beq $a2,$zero,0x002eb838 0x002eb81c| 0x00459821 addu $s3,$v0,$a1 ->0x002eb820: 0x84c20004 lh $v0,4($a2) 0x002eb824: 0x44820000 mtc1 $v0,$fpr0 0x002eb828: 0x00000000 nop 0x002eb82c: 0x46800020 cvt.s.w $fpr0,$fpr0 0x002eb830: 0x10000002 b 0x002eb83c dsedb S> quit Could it be overheating or faulty components?
I think it is possible that the optical drive of your TOOL might be having some problems. You can see in the debug messages that they are both derefencing NULL or invalid pointers, so something has caused that to happen. If this happens to all DVD-based things, maybe you could try a CD-ROM game instead?
I see, well unfortunately, the Crusty Demons disc is a CD-ROM game. I'll try with some other things, in the meanwhile, I read in another thread that it's possible to launch homebrew without the EELOADCNF replacement and that you need to launch rom0:UDNL before attempting to launch homebrew. How are you launching UDNL? I've tried launching OPL with ./dsedb pload OPL.ELF but I get "section header not found" with v0.9.3.
How about a pressed CD-ROM game? Rightfully, homebrew software shouldn't even be using EELOADCNF because that is a ROM-specific file. :/ It's an old practice that carried on for years, without people knowing why. For the DTL-T10000, I added a new option into OPL v0.9.3's source code to make it compatible with the DTL-T10000. You just need to change that option in the Makefile to 1 before rebuilding OPL, and you will get a copy that is compatible. But in all seriousness though, it's far cheaper on the long run to play games with a common CEX console - you won't feel the pain when it actually breaks. Like the PSX, the TOOLs also have their OS stored on HDDs. Although they can be replaced (unlike the PSX), you will have to take the trouble to do it. The optical block of the TOOL is also a KHS-400A or something, so it is also hard to replace. You need to boot the uncompressed executable, not the packed one. The DSEDB tool is not compatible with the packed file. For the late flash ROM image with the test mode option, the DEX modules are only loaded if rom0:UDNL is executed. So you should just change the IOP reboot parameter for any homebrew software to reboot with "rom0:UDNL". Regardless of whether an IOPRP image is used or not. This was designed this way because the late ROM assumes that your software is developed with the late SDK and you will reboot the IOP. If you're using an early flash ROM image (i.e. v2.0), then you don't need to do anything at all because the incompatible FILEIO RPC server was introduced at v2.3.4. The test mode option was added around v2.3.4, I guess. If you're using a really early flash ROM image (i.e. v1.00), then you might have a problem with the EE kernel patches. SCEI released some patches that came bundled with later games for the early EE kernel that came with the SCPH-10000 and SCPH-15000. However, those patches are not compatible with the counterpart that is present in the first version of the TOOL's ROM (v1.00). There is nothing much you can do here, other than simply not using the old ROM.
I'll give a pressed CD-ROM game a try soon. I'm not looking to use the T10K for just playing games - I just wanted to check that the laser was working correctly etc. I'll be using this for development. How do you reboot with that file? Do you use dsedb? Doing ./dsedb run rom0:UDNL gives me a file not found error.
That's great! It needs to be done by the program itself. Homebrew software will reboot the IOP in general. UDNL will break if an IOPRP image cannot be found, which is rom0:EELOADCNF in the case of software like uLaunchELF. So you will have to edit the software. If you can't recompile the software, then hex-editing it (change the " rom0:EELOADCNF" part to 0s) would probably do. Some software also depend on ROM-specific modules like those X-modules, LIBSD and FONTM, so you need to get the software to use their own modules instead. There are the free ones from the homebrew PS2SDK. Or you could use copies of the modules from a CEX unit's ROM. Although that would make the code unfit for distribution (due to copyright issues). There is no direct substitute for the FONTM font module, unfortunately.
