New PS2 Tool owner, have some questions...

Hello there,

i bought actually a TOOL too



But it takes a little time to arrive here. But i have many questions to the tool. I found the BASICS Thread... But there are more Questions.. Hope you can help here?!

My Questions

The Tool has 2 HDDs.. how big they are? 20 GB? 30 GB?

I can put a TV AND a PC Monitor to the tool, or?

Do i need any special thing to Plug in a Monitor? Or can i use every Standart VGA Monitor for the tool?

Can i put my Retail Games on the Tools HDD and Play them? If YES how is this working?

kk I think thats it. More question come when the TOOL arrives i think

Regards
Bjoern

 

Sorry, couldn't resist :110:.

You only need the SDK if you want to write programs against official Sony libraries or use the official compiler. If you simply want to control the TOOL itself (e.g., reset, start and debug programs), you can use the software that is already installed on the machine (/usr/local/sce/bin). These files are identical to those in the corresponding SDK, so you could even transfer them to another Linux machine...

Probably I was the one you heard that from ;-). The TOOLs typically have two 60GB HDDs installed, but only the first ~6GB are partitioned; the remaining space is not used at all.

Even if there was a way to use a standard BIOS, you most likely wouldn't want to do so. The TOOL uses a heavily customized/extended version of the PS2 hardware, and you would lose almost all extended functionality by using a retail BIOS. That is, if it would start at all...

There is a way to update the TOOL's PS2 BIOS, though, but I strongly recommend not to try this with any retail image, as you could easily brick the machine. :noooo:

Anyway, by changing a Linux init script instead, you can configure the TOOL to start a game after reboot. The Network Information screen is displayed automatically whenever the ethernet interface is activated, but you can change that to any action you want.
For example, to start a game disk instead, locate the following lines in /etc/sysconfig/network-scripts/ifup-post:

Then change it to something like this:

I don't think there's any game data stored on the system HDDs. TOOLs were merely used to run and debug programs, whereas all data files were stored either on the development PC or optical discs/emulator HDD.

60GB, of which 6GB are partitioned. The remaining space is unused.

Yes. A standard PC Monitor for the Linux side, and a normal TV for the PS2. Please note that there are two VGA ports on the back of the TOOL: the one near the PS2 Multi A/V outputs the same signals as the Multi A/V, so regular monitors won't show anything when connected here. To get the output of the Linux side, remove the metal plates above and below the ethernet port on the left-most PCI slot bracket, then connect your monitor to the second (hidden) VGA port found on the card.

Standard VGA for the Linux side, standard Multi A/V for the PS2.

No, you can't. If you have a T14k/CDVD Emulator card installed, you may be able to run some games from the emulation HDD; however, I'd expect almost all games to be incompatible with it. To run your games, insert the disk into the optical drive, then perform something like "dsreset 2 180" on the TOOL's Linux side.
There is no way to execute games from HDD; even if you attach an external HDD (via PCMCIA card) to the TOOL, a standard HDLoader won't be able to access it.

 

SilverBull, why do you expect most games to be incompatible with the t14k?

 

Unless I missed something in the software for the T14k, it doesn't allow placing files at specific sector locations; instead, when adding files to an image, it fills the emulated disk just like a regular CD/DVD writing application would. This does not present a problem as long as the game uses the regular ISO file system to locate its files; however, to be honest, none of the games I've seen so far (which are not too many, maybe 20 or so) rely entirely on ISO. They all do some more-or-less nasty stuff to place their files on the disk.

Some use hard-coded sector addresses, others place their own file system into standard files visible in the ISO file system (which may have certain ordering requirements on the disk).
For example, Final Fantasy X (the german "not-for-resale" release I got with my first PS2) uses hidden files. Aame-related data is not indexed in the ISO file system at all; only the main ELF and IOP replacement image are. Makes something like ~7MB for the visible part of the directory tree, whereas the DVD contains roughly 4GB.
Another example is Xenosaga 1 to 3 (american version), which use their own file system as well. Only the file index is stored in a regular file, the data area follows directly afterwards. There are file entries for this data area in the ISO system, but they are never used by the game; it simply gets the start sector of the index file, then uses raw sector I/O to read everything else.

 

Interesting tip- not too sure if I'll end up using it, but interesting nonetheless..

In regards to the game data- I've seen mention of a few tools that seemed to have incomplete copies of (insert game here), for example, there's currently a system up on ebay that purports to have a copy of an ICO pre-release build left on it, but no t14k-
I'd expect there was a temp file area from where to execute game exe's, but I could be wrong- does the sdk REALLY ship all the files as needed via ethernet?

If this is the case, I can see where the T14k would be invaluable in terms of pure execution speed...

Anyway- I plan to probably first and foremost use this to look into a few retail games I need more info from whilst they are running...

That, and I'm not overly comfortable using the target box as any sort of development platform, but would prefer to retain its functionality as just that... To each their own, right?

I also agree, that well.. there's no huge reason that the T14k SHOULDN'T be able to run _anything_ that the system can natively, even moreso if there's no concept of a master disc involved, that one simply ships the system the disc to be emulated 's contents...

I agree that the need for a dashboard is unnecessary, I was just curious given the functionality of a number of HDD-boot games, that only install from optical, not boot the exe... debugging a functional mockup of the loader would have been nuts without either a dashboard or a emulator for a TEST...

any idea, on that topic, how one would in theory launch a hdd-installed game off the external ps2 hd without access to it from within linux?

In regards to the FW updates- can someone get in touch with me about what's updates are floating around? I would be grateful...

Final question- My take on the second drive is that this would be used to restore your functional devkit environment from if all hell breaks lose, but how would one actually go about using this in reality- are actual tool operation manuals that scarce? I don't see any real need/use for the data to be seen to the PC board... But from my readings, it seems that no one has a clear idea as to why there's 2 copies of the boot drive.

 

Those are just some sort of copy protection mechanism, during the development I doubt every version of those titles used the raw sector I/O method to load files.

And you can use the t14k software to export .ccz and .h files with the exact position of each file, to use them either in cd/dvd generator to burn a proper disc or in your code...so I don't see why you couldn't specify the exact position of the files on the hdd (maybe in a later version of the software).
An exemple from my emu hdd:

defor, often you can find a beta/preview game disc in the optical drive of your unit, left by whoever sold it.

 

things to ponder...
thanks!

 

About your questions and thoughts:
there is another Tool that uses an internal hdd as if it was an expansion bay type PS2 model, it is compatible with HDD enabled games and software like the broadband navigator.
Note that the DTL-T10000H can use the external hdd with hdd enabled game and software, but the loader/interface software is more likely different from what is found on the retail PS2.
You can also use some tools on a Test PS2 to debug the running code, check snsystem's website.

According to all the materials I could find, if your Tool has a problem, you just call Sony for them to repair it, no licensed dev is allowed to open the unit and fiddle with its internals.
Even if the 2nd hdd (identical to the 1st one) was used as a backup copy, why plugging it and having it being accessible from the PS2 side of the Tool...

The last firmware I know of is the rel300, to know the version on your Tool, just run dsidb, you should have something like this displayed:

 

ASSEMbler is selling this unit, but I doubt the ICO beta is on the unit itself. I'd expect him to include it on DVD.

When running an ELF/IRX via the debugger, it is directly written into PS2 memory, then the target side debugger is instructed to jump to the program's entry point.
All communication with the PS2 hardware is performed via the DECI2 protocol. On the ethernet side, DECI2 packets are encapsulated in a regular TCP/IP stream; on the PS2 side, packets are sent directly, without the TCP/IP header. There is some additional (out-of-band) signalling on the PS2 - like specifying which target protocol (debugger, TTY, file server, ...) or which processor (EE or IOP) the packet is intended for - but nothing in the whole protocol indicates that the Linux side caches any data.

If I'm not mistaken, a regular PS2's optical drive provides at most 4x DVD read speed (burst), which is ~5.5MB/s, or ~55% of the TOOLs network connection. Doesn't sound too unreasonable to me.

Indeed :033:.

Well, the T14k should be able to emulate the hardware side of an optical disk, but that's not all that is required for a retail game. As unclejun wrote, there is no (known ;-)) method to upload a sector-by-sector image of a CD/DVD; instead, you simply put files on virtual images, and the emulator automatically creates the corresponding file system.
It is just like when creating CDs/DVDs in your favorite recording application; you have no control over the order of the files on the disk, let alone of the exact logical sector numbers they are stored at. However, some retail games might be expecting their files at well-known locations; these games might simply read the corresponding sector without going through the file system at all, and will almost certainly crash when there's something unexpected.

Unfortunately I don't have much experience with the PS2 HDD, as it has never been officially released around here :crying:. However, I'm quite sure the technical requirements checklist (TRC) mentions that all executable code on both the MC and HDD had to be encrypted, and I also think large parts of the MagicGate system (used to install ELFs to both the HDD and MC, as well as to read encrypted files) are not supported by the TOOL, at least not by these units we are talking about here (available outside of SCEx). To my knowledge, even official developers could not encrypt their ELFs for retail systems; to create these so-called "KELFs", they had to send their unencrypted files to a Sony web service, which would then send back the encrypted files for the intended target region. So I'd expect some shortcuts to be used during development, and the full encryption only to be used on TESTs (there are certain models that do support full MagicGate, like the DTL-H3020x).

I'd expect by running the target (unencrypted) ELF directly, via the debugger.

During normal development, the flash rom contents are expected to match the library version the game has been compiled against. For this purpose, each SDK contains a TOOL BIOS (t10000-rel???.bin for normal SDKs, or dnas???.bin for DNAS versions), which must be active to get the full functionality of the IOP debugger (the EE debugger seems not to be affected by this).
However, you can use a different flash version than the one used to compile a game by starting the system in TEST mode (set the 0x100 bit in iop_bootp, like "dsreset <some-number> 0x100"). If you want to get the "intended" version number for a particular game, have a look which IOP replacement image (ioprp???.img, dnas???.img) is present on the disk.

I have an official user's manual for the TOOL, and it doesn't mention anything on this topic, let alone anything else related to the unit's internals. When reading that manual, one clearly gets the idea that Sony didn't want anybody to look into the unit more closely; which leads to some rather comical advices in the manual. Top examples I remember:

• (description of the "WS" position of the TOOL/WS switch on the front): "This switch is for extended use".
• (from the FAQ section, in case you have forgotton the admin password for the TOOL website): contact support. It is not written there, but I suspect they want you to send the unit in then :banghead:. Just for your information: the fix is easy, it takes something like 2 minutes, but requires some fiddling with the Linux installation.

Are you sure this is for copy protection? I always thought it to be a necessity to get around CDVDMAN's restrictions when parsing an ISO file system.

This may not be the right place to ask, but anyway: what do you think, should I release my homebrewn debugger anytime soon? The one that allows DSEDB/DSIDB to be used on retail machines... :rambo:

 

Ok, perhaps I'm missing something, but if the entire game runs from PS2 memory space.. how are file assets handled? wouldn't that mean either devs (without a emulator) would have to provide media of cd/dvd or simply have to work extremely piecemeal in order to get a game near completion? I'd think both would be a total nightmare?!

I'm not against either method, it just in the end feels that the concept of the tool as a serious build tool (excuse the pun) would be wasted if everything had to be loaded to ram, and no files of any considerable size could exist at execution ... kind of the mentality used in yaroze dev, etc.. your game code is sent remotely, but any assets come from the disc because there just isn't space to load it all into ram...

 

Well there is a lot of place to hide a disc in the Tool!
The t14k is designed to emulate the seek times read speed as closely as possible as the cd/dvd drive, so it won't load your games faster.

Maybe you're right about the cdvdman, I haven't really looked into it...
Anyway, most of the games you mentioned are obscure J-RPG games, I don't know anyone who enjoys them

No question wether you should or not release it, of course you do!
But you'll have to issue the patented code problem first, I'm sure the people at ps2dev.org would be very please with your program then and the ones working on project Artemis would be extremely jealous!

It loads the files from either the cdrom/emulation hdd or from the pseudo filesystem host0: on the computer you use for development.

 

OHHHH

that's more or less where I was headed with the initial question!
that works!

EDIT- or do you mean only for the emulator card?

 

Oh, and is there any truth to the concept that the TOOL can be used to develop psx titles or is this bunk?

 

The TOOL's IOP kernel provides a special "host:" device to access the development PC's file system. The game can then use regular file I/O routines (very similar to those found in a C runtime library) to read and write all required files.
In later development stages, data files can be read from optical disk by simply replacing the path used for file I/O (that is, if CDVDMAN's restrictions on the ISO file system do not disrupt this; otherwise, one could always use some other layer to access a custom file system). The game doesn't need to be started from disk in this case, it can still reside on the development PC and be send via the debugger. Instead of normal file I/O, the game can also request to read data from optical disk directly.

In this case, "optical disk" can mean both the emulator as well as the real optical drive. There is no difference from a software point of view, the emulator hardware simply "takes over" the corresponding hardware registers when active.

Perhaps my statement of the Linux side not "caching" anything was a bit misleading. In fact, the Linux side is mainly used as a communication facility, to forward DECI2 packets between the (development-PC-side) ethernet port and the PS2 side. It doesn't interfere in any way, it mainly provides some services used by the development PC to control the PS2.

I wish I hadn't, CDVDMAN is mind-boggling. I found three different versions in my retail BIOSes, each with a different set of export functions implemented. Depending on the version of the driver, there are even differences in how low-level commands are sent to the hardware. The interface to CDVDFSV (the RPC server, needed to call CDVDMAN functions from the EE by means of libcdvd) is also interesting, as it uses both regular exported functions, device I/O control requests (mainly for streaming), "special commands" (via a single exported function, whose first parameter specifies the intended operation) and even undocumented control flags for regular (documented) exported functions :evil:.

Well, you do now :110:. FFX was the reason I bought my first PS2 :033:.

Thanks. Whenever I hear "patent" and stuff, it reminds me that I probably studied the wrong topic... :banghead:At least this program does not require any copyrighted Sony code to work; or none of it that cannot be sourced out to memory card.

Do you know whether the communication mechanism between the two DECI2 managers on PS2 side is patented in any way?

 

Hmm, what initial question?
If you don't have the emulator card, you can load your files at will using host0: as the source instead of cdrom0:

Where did you get such an idea?
The Tool can't run PS1 titles...according to Sony...

Patented, copyrighted, do you see a difference?

Not to mention the usual stuff in the manuals:

They are using the DECI protocol since the beginning of the Playstation so they wouldn't leave it unpatented for everyone to copy and use without being a licensee, would they?

 

ok about the host0- good for me...

about PS1 - that's what I thought too, I'd jsut seen people mentioning that it "replaced" the old pile of cards devkit for PSX, but i agree there.. I don't see anything to support this claim at all.

 

The Tool ps1 compatibility came often on the official newsgroups, sony answers never changed, although there are some hints in the Tool firmware that it could do such a thing:

See what I mean?

 

I tried some things with this, but never got very far.

The TOOL BIOS does contain the PS1 kernel (rom0:SBIN), as well as the code in the bootstrap file (rom0:RESET) to start it when the hardware is executing in PS1 mode. In addition, the DSNET startup script has a parameter for DECI1 mode, which is the communication protocol used for PS1 development. When specifying this parameter, the script starts the mrp driver (used to connect the Linux system to the PS2 hardware) from the psnet directory, instead of the regular dsnet. I think I found the correct psnet mrp driver, but DSNET was unable to connect to it, so I used the regular (DECI2) variant for the following tests.

Unfortunately, the TOOL BIOS does not contain a PS1DRV, so I tried to use the file from my retail console instead. An unmodified file does not work at all, it almost immediately crashes deep down in the IOP kernel; that's because the file I/O code it has been compiled for is incompatible with the TOOL BIOS. The same happens when trying to run homebrew code that relies on file I/O (like ULE) on the TOOL. This somewhat depends on the flash rom version; I tested with both release 2.8 and 3.0, and got the same error both times.
There is an obscure hack to get around this, though: just run the relevant parts of the retail BIOS on the TOOL :evil:; the same mechanism is used by games to update the IOP kernel on startup. To do so, I had to create an IOP replacement image from the retail BIOS. As the IOP then ran the correct BIOS, PS1DRV got a little bit further.

I think I got PS1DRV to the point where it reboots the IOP in PS1 mode. However, the system was completely dead afterwards. :banghead:
The EE debugger (used to single-step through PS1DRV) hung, but that wasn't unexpected. The IOP is used to forward debugger commands to the EE, and single-stepping over IOP reboots doesn't even work in PS2 mode (if you try it, you'll most likely get a crash deep down in the EE kernel debugger stub).
However, in this "half-PS1"-mode, the entire debugger connection was dead; even the IOP debugger did not respond anymore, which indicates the IOP at least entered some operation mode other than the regular one (or quite simply crashed in the DECI2 manager).

Result: PS2-side unresponsive, and a black screen instead of a PS1 logo :crying:. At least it worked again after a dsreset.

 

oh dayum, that's a BIG wall of text to wake up for :lol:

it was either you silverbull or then unclejun whom i heard about the HDDs' and whatnot. i can't really remember, i got way more PM's regarding the tool than i care to count for

just few things popping in my mind after reading all this stuff

Xenosaga games do not hold any special files or weird sector-based mumbo-jumbo.

there's files inside the disk with extensions .00 .01 .02 and so on..
the reason the game ever only seeks for file .00 is because all the files are the same thing, it was just split to ~1Gb files for a reason only the devs know.
you can use the DOS' copy /B file.00 + file.01 + file.02 newfile.00
and just rebuild the game only using the merged file, it will work.
changing the file's position on the disk also has no impact on functionality.

the container file hosts it's own LBA table just like most files from every game. (aside those square games that always use proprietary filesystems -_-) it's not too hard to open and tools to do that have existed for quite a while now. I don't really know anything about TOOLs and programming but extracting and editing games is something i consider myself somewhat familiar with

then, the magic of HDD boot applications, I remember seeing it in the HDDrestr.pdf on SDK 3.0 somewhere that sony actually forbid hdd installable games from directly being ran from the HDD. Even tho an actual bootcode for it was done and even a sample provided. I've been currently examining a retail game installed on a HDD with navi to see if i can get around the archaid "copy protection" which in reality doesn't seem to exist, it seems to be only a boot parameter on the masterpartition of the gamedata which was used by BBnavi (and DESR) to regognize and return metadata of the game and boot it on request. (naturally forcing the load of MAIN_APP from cdrom0:\)

encryption of data wasn't mentioned iirc, and there was a: quote: "password protecting the partition is optional, but recommented"

good thing SCEI provided a sample source to rebuild ps2pfs partitions and metadata More on that after i get navi turned into a HDLoader

Then something that has been bothering me a while now.
one of the main reasons I initially wanted a tool years ago was ram dumps.

is that even doable ? a full 32Mb ram dump, be it all at once or in pieces.
I don't really have as much use for that as I would have had earleir, but it has bothered me for ages now.

i suppose it's not totally out of reality since Vram dump can also be done

once again i'll just return with a wall of questions
..maybe someday in the distant future there's someone i can teach about using one of these machines

edit: also SilverBull, please tell me that vramdump is a fake? HOW in ***** did you do that ?

 

As I said, I studied the wrong topic to discuss this :banghead:. I always tried to stay as far away as possible from this ****(censored by author).

It is some sort of file system as well, consisting of directories and files. The .00 file is the index block, which encodes the directory structure, file names and addresses. The other files are what I called the "data area" of the file system. XS's read code uses regular file I/O (sceCdSearchFile) to get the logical sector number (in DVD sectors) of the .00 file; read operations for individual files are then performed relative to the end of the index block, using absolute sector adresses, irrespective of the ISO file system. It doesn't matter whether the .01, .02, ... files are present in the ISO directory listing or not, or even whether they reference the correct sectors on the disk. All that matters is that the start of the .00 file is correct, and its data area is located directly after the index block. I don't remember quite now, but I think the game does not even check the length of the index block (as reported in the ISO file system), so it would even run if the directory entry indicated the file to be of length zero.

Nevertheless, I agree in that this structure is extremely extraction-friendly, in that you can simply concatenate the files to produce an image of the underlying file system. That wasn't necessary at all; they could have simply omitted the ISO file entries at all, and hardcoded the LSNs of the .00 files.

By the way: is there any publicly-available extractor for this XS file system that can reconstruct the directory structure? I know of an extractor, but it simply creates consecutively numbered output files without paying attention to directories.

Its even simpler than doing VRAM dumps, as you don't need to touch any other hardware components at all. VRAM dump is performed through the GS/GIF combo, so it can interfere with the running game if it is accessing these components at the same time. That's why I wrote some time ago that VRAM dumping is quite buggy, even when using VRAMsnap: in order to copy the memory, the bus direction to the GS has to reversed, but there is no way to capture the old state in order to restore it later (the corresponding GS registers are write-only). A debugger would have to track any access to these registers during the lifetime of the application, and Sony hasn't implemented anything like that.
DSEDB and VRAMsnap perform different operations to circumvent this problem, but they can both screw up a running game when done at the wrong time:

• DSEDB simply invokes some kind of sceGsSetDefStoreImage/sceGsExecStoreImage (via a DECI2 ESDBG/RDIMG message). The call switches the bus direction, transfers some data, then switches the bus back (to the "regular" transfer direction host->local). This call might fail (time out) in case some other GS operation was being performed by the game at the time DSEDB broke in.
• VRAMsnap performs the equivalent of an sceGsResetPath before doing RDIMG; via direct memory writes to the respective control registers, using ESDBG/WRMEM :evil:. The reset path command switches all involved components (VU1, VIF1, GIF) to their default state, which effectively cancels all pending commands a game might have had outstanding. On the upside, the following RDIMG will almost always succeeded (since there is nothing else that could block PATH3); on the downside, this can severly confuse (e.g., hang) a game, depending on when the command is issued and which state the game expects its hardware to be in. For example, the regular loop when using the homebrewn gsKit will hang in gsKit_finish when trying this OH:.

On the other hand, a RAM dump can be performed at arbitrary times, as reading memory does not have any noticeable side effects at all. The main problem is not to perform the RAM dump itself, but to get the memory contents out of the PS2, into a PC for analysis.
The TOOL has a dedicated communication channel for this: the "host" interface of the DECI2 system, which uses some parts of the IOP address space that are not populated on retail machines; this is the PS2 side of the hardware component the TOOL Linux uses the mrp driver for. Retail machines don't have it, so one must take other measures to get that data out. Some ideas:

• I remember seeing some (game-specific) patches a long time ago, which replaced the built-in safe function. When "saving" in such a patched game, it would simply write some part of RAM to the memory card.
• Project Artemis aims to use the PS2-side ethernet port, but I don't know how far they are. The main problem I see with this approach is arbitration: they need to synchronize access to the port with the game, in case it wants to use it, too. In addition, the network port is quite a complicated beast; you need a suitable dev9 driver and network stack in addition the ethernet driver as well. And I expect that IOP memory might get short as well.
• My own debugger uses i.Link and the EE's SIO port, if available. Both are quite "raw" channels and don't need much driver overhead; in addition, they can both be programmed from the EE side alone, so there's no need for any fancy IOP hacks (these are present nevertheless, but serve another purpose :lol. There are also very few games using these ports, so the chance of getting collisions is by far lower (I do not actively prevent them, or "virtualize"/multiplex the hardware).

I'll let my TOOL speak for me:



How did I get that? Well, I once wrote I had my own DECI2 implementation, and I've written some more applications using this stack during the last week. I now have replacements for almost all applications from the official Sony SDK, and this screen simply was a test for my software stack. The only official Sony code (besides the basic TOOL installation) was their gstitle.elf, everything else is my own software. To reproduce this screen with Sony software, do something like this (either on the TOOL, or on a development PC with the SDK installed; this should work, but is untested):

• Create a file named "text" containing your message
• Start dsedb in the same directory, "reset 0 0", "run /usr/local/sony/bin/gstitle.elf" (you might need to adjust the path)

If it works, it'll display your message on the TOOL background. If it cannot find the file, you'll get a plain image without a message, and the debugger should display error messages that the file wasn't there. One will come from dsedb itself, the other from gstitle.elf.

You can also use DSEFILESV to provide the text file to the console. It uses a higher priority than DSEDB, so if it is running at the same time, the console will read the file using the DSEFILESV instead of through the debugger.