• Hey, Guest!

    XenForo 2.2 is coming soon, it's bringing many new features such as a PWA app for OG etc. It also comes with the drawback of more costs to update themes/some addons. It'll also remove access to some older browsers which'll suck but these shouldn't be used as their security sucks.

    With the costs already looming we decided to improve OG's look with a new fancy theme that gives OG a more gamer feel. This has cost us only slightly more than it would have cost to renew the current theme and runs alot nicer.

    You can beta test it here: Linky. (Please note only dark is live, light will come once issues are ironed out.)

    If the current theme breaks on update we will end of life it, but we'll make something looking similar based on the default free theme so don't fret!

PS2 Is using ProDG 3.0 with any of the leaked official Sony SDKs feasible?

Husbjörn

Registered
Registered
Joined
Jul 14, 2019
Messages
6
Reaction score
0
As the title suggests I'm looking for opinions on whether it is reasonable to use ProDG 3.0 on Windows for development with a T10K, given what is available in terms of tool applications, patches, etc.

For some background, I have a working setup using Metrowerks CodeWarrior already, so yes, I could just use that. But to be honest I find myself not liking it very much despite giving it a couple of months to "get used to it". Thus I've turned my eye to the other alternative, ProDG by SN Systems. The latter feels more "official" due to their developers' entanglement with SCEI, and from what I've gleaned it feels more like a proper Windows IDE suite than CodeWarrior. As I'm a Visual Studio user since VS2005 (or VS2008 for more serious development), the included VS integration that comes with ProDG is a big plus for me as well (even though it is for VS98 only; it seems that the commandline tools are documented well enough that you could probably integrate it with a later IDE version yourself if you felt up to the task however - I cannot say the same for CodeWarrior, at least from what documentation I've managed to find for it). The ProDG target manager also seems superior, alas I haven't been able to use the debugger so I can't say for that one.


Onto the problems then:
There is a leaked version of ProDG 3.0.1, but it seems to only be partially patched for license checks and as such will not work as-is. Now there is a keygen for an older version (2.76 or something I believe?); this will not wotk with the 3.0 target manager or debugger, however it does (seemingly) let the compiler run. No other components (linker, assembler etc.) seem to check the license at all. For the target manager, it seems to be possible to just run in permanent evaluation mode without any restrictions(?), and there is a patch for the debugger that allows it to bypass the initial license + validity period check. However, even this patched debugger fails whenever you try to actually attach it to a running session on the target Tool. I'm guessing this happens as it extracts some part of initialization data from a (valid) license that is just bypasssed and not properly set by the patch. I've tried looking into reverse engineering the debugger for the license check for a couple of days myself - I've managed to find where it checks the MAC address but that's it for now, and I'm not sure whether butting my head against this wall anymore is really worth the bother.
Furthermore, it seems like certain instructions / compilation does not yield the correct output when built with the ProDG compiler, and so I'm starting to wonder if perhaps that too is missing some initialization data from the (old) license, even though it doesn't complain about it being invalid out loud? To clarify, it does successfully compile code but unless it's a very simple "Hello World"-style program, it will fail to run on the console, usually when trying to do anything with the GS, and the same code compiles and runs fine with CodeWarrior so it isn't that the source itself is faulty (although I guess they do use different SDK versions so one cannot be 100% certain).

So, my questions then are:
1) Is it worth trying to get this to work? Has anyone else managed to (by looking at old AssemblerGames threads it doesn't really seem like it)? Or should I just write it off and fall back to sticking with CodeWarrior? (I'd be lying if I didn't say I'd really like to do some actual PS2 development for once).

2) Is it perhaps possible to procure a valid license somehow? If nothing else it would be a big help to have a good case in trying to reverse its checking algorithm. I doubt SN Systems would be willing to hand them out but perhaps someone wouldn't mind sharing a working one (along with whatever MAC address it is tied to then of course). But then again I wouldn't be surprised if any actually sold licenses have long since timed out anyway (although if so, can you get around it by simply patching the time retrieval API calls in the executables? Or simpler yet, just pull your system clock back a decade or two?).

3) Do anybody know whether my suspicion about the compiler possibly not working fully due to the incorrect license is likely or not?


Thanks for reading; I'm grateful for any pointers or other ideas/discussion.


------
It should perhaps be noted that the ProDG compiler seems hardcoded to use version
2.9-ee-991111 of the EE SDK libraries. I don't have this particular version and so have rerouted it to version 2.95.3 which was the closest I could find. There were also some minor oddities needed to get the compiler/linker to work such as #defining long as int, or it wouldn't be recognized, and the EXCLUDE_FILE() operation not being recognized in app.cmd, which I thus simply removed from there to get it to build. Just in case this may play into the results I'm getting, though I doubt it should (I'd rather expect it to fail to build at all than runtime errors from the latter).
 

uyjulian

AG Refugee
Refugee
Registered
Joined
May 30, 2019
Messages
69
Reaction score
30
What do you need from ProDG? If you just need the compilers, GCC 3.2.3 is available if you are using homebrew libraries. You can also use dsnet from the Kermit distribution, which works great with Windows.
 

Husbjörn

Registered
Registered
Joined
Jul 14, 2019
Messages
6
Reaction score
0
I guess I'm one of those loonies who enjoy using the authentic things (to a certain degree I'll admit; I know if that was 100% true I'd just go the RedHat route).
Besides that it cannot be denied that the official tools must be considered fully functional, whereas homebrew solutions usually have several things lacking. I won't state that being the case here for a fact as I don't really know though, but just generally speaking.
I wouldn't mind having a look at whatever you'd recommend if it can be considered feature complete enough however. My impression of homebrew PS2 solutions have been that it's Linux-only and targets retail consoles via FireWire and/or USB upload solutions. As stated I'd prefer to develop using a Windows box and I also have a fully functional DTL-T10000 for the purpose. Is that something that these homebrew solutions can leverage when it comes to debugging / monitoring etc. in the same way that the official tools can? If so, would you mind providing a link to where I could read up further on it?
 

Husbjörn

Registered
Registered
Joined
Jul 14, 2019
Messages
6
Reaction score
0
I see hm, well WSL doesn't directly scream "native Windows" but I'll try to read through that next weekend assuming I won't get tied up in Christmas preparations. Thanks ?

For the record, I'm still very much interested in the initial topic (ProDG) if anybody coming by would happen to have anything to share regarding that.
 

lv1

Registered
Registered
Joined
Jun 25, 2019
Messages
2
Reaction score
2
AG User Name
illobrandt
AG Join Date
Apr 8, 2013
Maybe inspect the .ppf that ships with the keygen or apply the .ppf and compare the resulting patched ps2dbg.exe with the original one. This might give some insight in what the crack changes which in turn might give some pointers on what additional spots to look out for.

That being said, from what I remember from a discussion with @HI_RICKY over at ASSEMBLERgames he has access to a more recent version of ProDG and Tuner that shipped with his T15K (possibly with a valid license). Maybe that helps (provided I remember correctly and he's willing to share his copy/license of course).
 

the7thchild

AG Refugee
Refugee
Registered
Joined
Jun 13, 2019
Messages
20
Reaction score
26
AG User Name
the7thchild
AG Join Date
2011-2-7
Some years ago there was an SDK installer iso of 3.0.1 leaked. It is functional with the patchers just that the debugger is a bit buggy. It does run however with VSI most of the time. All samples complied well and it also works well with the RenderWare SDK found in the BloodRoar 4 retail disc. To make things work:

1. Windows XP is preferred
2. Install visual studio
3. Install the ps2 SDK installer disc
4. Generate license file with correct MAC for your LAN card
5. Patch the debugger
6. Check if samples complie
7. If you got link error regarding gcc, patch crt0.s and rule out the #ifdefine gcc part
8. If the complied code won’t run. Patch the parts regarding module leading and reset iop parts.
9. Do it in a VM is a good idea.
 

Husbjörn

Registered
Registered
Joined
Jul 14, 2019
Messages
6
Reaction score
0
Thanks @the7thchild .
As I've been trying to use this with Windows 7 and on top of my already existing SDK installations I decided to give your step by step instructions a try on a clean Windows XP SP3 VM install. Unfortunately the results seem to be the same (thanks for the "gcc" pointer though - undefining __GNUC__ seems to make everything(?) build cleanly without having to outcomment a lot of things here and there in various headers. I'm not sure what defines that to begin with though, but still, nice to know!).

Anyhow, building and executing elfs seem to work, but as soon as I try to use the (patched) debugger it fails with an "Unrecoverable error - TTY Stack Error in TTYUpdate Ln 120. Unable to resume!" message box.
It should be noted that the way the PPF patch I have is named seems to suggest it should be applied to the installer executable, but that just corrupts it. So I've been applying it to the debugger executable alone. Just in case this isn't how it's supposed to be used (however it does bypass the "invalid license" prompt you get from an unpatched debugger so I assume this is indeed correct).
Unless this is what you define as "a bit buggy" with regards to the debugger? :p
 

Husbjörn

Registered
Registered
Joined
Jul 14, 2019
Messages
6
Reaction score
0
Oh, I see, that is an older version than the one that comes bundled with the 3.0.1 installer (1.50.8 vs. 1.76.14). Is it the one from the 2.x leak that fails to reset the IOP properly?
In any case I didn't think to try mixing components like that but it does seem to start up and remain stable which is a lot more than could be said for the newer version. I will try to run it for real against my Tool tomorrow and see if/how that behaves but I'm hopeful, thanks for your assistance @the7thchild !

Edit: It indeed does work, with some minor issues here and there (popup messages about some errors that ultimately don't seem to affect anything and no automatic source opening by the debugger, manual seems to work fine though). :)
 
Last edited:
Top