I bought these a wile ago , I thought they where suppose to be used with a PS2 Debug console. I got one of those recently ,i put one card in the debugger and it freezes at startup and gives a black screen . If i startup first and use the browser to see whats on the card ,then i can see that there are some kind of drivers on there . It says : System drivers and Sus drivers I would like to know where they are used for , and what i can do with them
Nice find! I think it works only with one model of TEST unit, take a look at http://snsys.com/playstation2/proviewplus.asp So, what is your TEST model number? Does the PS2 browser display any free space for the card or is it read-only? A picture or two of the internals of the card would be interesting if you have a screwdriver lying around... Can you access the files on the card using uLaunchelf?
The model number is DTL-H30002 The browser displays that there is 5,541 Kb of free space. I have a used and 2 new ones , the used one has a stored system configuration in it. I don't have such a small screwdriver lying around so i cant open it up (for now) I have to look in to uLaunchelf , dont know how that works
You need an DTLH-30102 to be able to use it. :nod: And absolutely do not write anything to it or change/move files from it or you will end losing the device. :shrug:
According to the manual, it works with the following models only: DTL-H10100 DTL-H30100 series DTL-H50000 series Some random Q&A: Can "SUC Driver" be copied to another START-UP CARD? Since a copy protection attribute is set to "SUC Driver", it cannot be copied on the browser. However, if a program for copying files is created, it can be copied, and the START-UP CARD of the destination can also be operated. When copied, "SYSTEM DRIVER" cannot be operated. I accidentally deleted "SUC Driver". Can it be repaired? "SUC Driver" can be setup again. However, the START-UP CARD no longer function as a START-UP CARD. Therefore, setup must be conducted by using DTL-T10000 or by using another START-UP CARD and the debugging station.
He can't dump it anywhere besides on the intended devices it's meant to run with. Magic Gate keys for that card are different than that of retail PS2s and DEV units without the "1" on the middle of the model number have Magic Gate capabilities disabled on hardware.
What? A DTL-H10100?! :-0 Never heard of such a thing, probably the rarest of the debuggingstation 2's ray:
I tried dumping one on my DTL-H30101 but couldn't make it bootable. On a side note, internally they have exactly the same hardware as a standard SCPH-10020 memory card. I ended up finding mine a mere 4 days after getting my debug. Edit: the contents are 4 drivers and the executable, the 4 drivers correspond to the 4 main regions: NTSC-J NTSC-U/C NTSC-C and PAL. If someone wants me to check let me know. Finding one of these a few weeks ago is one of the main reasons I joined
Basically they will be the usual OSD update (KELF or KRYPTO ELF) files osdxxx.elf / osdmain.elf / osdsys.elf and icon files for the save on OSD memory card manager. The catch22 here is that the KELF file requires to be "bound" to a memory card ID to be decrypted properly from the MC. So a KELF taken from a card can only be decrypted if you have the obfuscation keys that are specific for that card. Each card memory controller has an unique key pair (KC and KBIT) which combined with the file specific keys form the unique key that matches the header on the file. Only the original key can unlock the said KELF file and the MC signed key which is used in combination with the MC ID is needed to recover the original key which in turn is used to decrypt the file. So I said you don't touch the files (in case the card works) because it's possible to lose the files ultimately making then the card useless. :shrug: It's the egg and chicken dilemma. :nod: Edit: And I forgot to mention, the only thing that card has different from a retail card is the FIRMWARE on the memory controller chip (the small square chip close to the middle of it's board).
To clarify, mine does boot, the copy doesn't. I'm pretty sure it's the MagicGate/MCID protection or a related issue, I really didn't give much thought about how to do that when trying the first time. An interesting thing is that the SCPH-10000 actually recognizes the original as bootable card and then proceeds to spaz out trying to run it. All other retails seem to just ignore it.
Strictly speaking, every PS2 has at least limited MagicGate support, because the console must authenticate to the memory card (the SecrAuthCard export). The card actively refuses to talk to anyone not properly authenticated, so if this feature was missing, the console would be unable to use any (well, official ;-)) card at all. That part aside, there are basically three variants of MagicGate support I'm aware of, depending on the machine type: TOOLs. The secrman_for_tool module does not include any exports beyond SecrAuthCard, especially nothing to decrypt KELF files. You can try to rebuild those functions, but the MechaCon will simply refuse to do anything, as necessary commands are simply not implemented... NB: I'm sure there are modified TOOLs that have fully-functional MechaCons, but they were probably only used internally. And if any of them had gotten into the wild, this feature is probably too obscure for anyone to notice. TESTs. For all I know, secrman_for_dex does include the decryption functions, but the MechaCon does not (similar to the TOOLs). This only applies to the H1000x and H3000x series, though. The Hxx1xx and H5000x and later should behave like retails. Retails. Secrman_for_cex includes all necessary functions, and the MechaCon also implements the commands. However, it will refuse to decrypt anything from the wrong region. There is another odd bit of information: certain file keys are blacklisted in later MechaCon firmwares. So even if you have a seemingly correct file from the correct region, a console may refuse to decrypt it because the MechaCon has that file blacklisted. This is what happened to the original DVD Player released for the SCPH-10000. This file had the feature that it respected the user's choice of output format to the letter (which means easily-circumvented Macrovision by using component output). It got "fixed" in a later version, but there was no way for Sony to invalidate existing copies of the player. So what they did instead was to blacklist the file's key, so any newer console refuses to start the old DVD player.
I now own a DTL-H30102 , the startup cards work on it ,however i still do not know where they are used for It seems that i have 2 different kind of cards three of those give the following screen : http://i.imgur.com/oFdWA.jpg And one gives : http://i.imgur.com/4am3A.jpg
I believe you have two different versions of the start-up software. The second picture defiantly is the old SN systems logo and is probably version 2.0 of the software. They are mainly used with software known as Proview and Proview Plus. It's basically for debugging software on retail like hardware (I guess the Tool isn't retail enough for finding certain types of bugs.) You can read about them from this address :http://www.snsys.com/playstation2/proviewplus.asp. Anyway without the PC applications the card itself won't really do anything. I do have to ask the experts though as to why it is using the Ethernet port on the card? I thought these cards used the ilink (i.e. Firewire or 1394) port and left Ethernet alone to simulate a retail environment.
I also have the original Proview software as well , but i have no license so i can not finish the installation
Yeah I remember that part about SN-Systems software. I do know there is a hack to get the Target Manager, and ProDG for the Tool to work (at least one released publicly). They might work with with a debugging station, emphasis on the might. Proview was never leaked publicly so I haven't seen the software myself. If memory serves correctly the license is tied to the MAC address on the PC network card. The idea here is to prevent a studio from purchasing one license and installing on all of their PCs. Of course that leaves open the possibility of using valid license files on a PC outside the studio (most network adapter allow you to set your own MAC address.).
I know that this is an old thread, but do you or anyone else here still have these older versions of the TDB startup card? I think that I have a dump of v1.01 that has SDK release v2.8.1 on it, but I'll like to collect dumps of older versions for research purposes. My project is basically a clone of the TDB startup card, but for retail sets. If it's actually possible to use the default kernel of the console without resetting the peripherals or replacing the whole kernel, I'll like so see how thanks being done. As of right now, I've managed to get the default EE kernel working with the IOP-side and to get all the debuggers working, but the screen gets blanked because the peripherals all get reset during the kernel reboot into debug mode. This is unlike what all the startup cards out there do. Over the course of time, Sony had changed the specifications of various libraries. If an old-enough tool can be found, that would be great for this project because I will get to learn how they initialized and interacted with the old libraries that are found in the PS2 boot ROM. Homebrew software generally use the default modules in the boot ROM, hence why information from an older startup card would help.
