Project Artemis

[Viper187]

PS2CC Rev 13 is up. Jimmi PMed me about a change to the buffer and number of codes that can be activated, so I took care of that. I also cleaned some things up and eliminated a few callbacks that I always felt were redundant. I didn't think of a decent way to do it until the other night.

Edit: Make that 15. I fixed a minor issue with 'I Forgot' searches, then was reminded that the Page Up/Down keys should serve a purpose on the results tab. I also threw together a quick readme to better keep track of changes for now. Let me know if any other keyboard shortcuts would be useful right now. At some point, I need to figure out why my text box handler makes the damn tab key not work. I happen to like tabbing from one value box to the next.

[Berion]

This is very early version. I'll try make preview in flash but this must be waiting for a while.

On some LCD monitors, background could be to brightly. I'll recomend check it on CRT. Resolution is actually for native PAL, but of course i'll prepare NTSC too.


THX for positive opinion.

[Lazy Bastard]

Great; that'll allow easier integration

[misfire]

Wow, nice! I'm planning to release my cheat program next week. So...

[Lazy Bastard]

Berion has begun work on the boot GUI. Here's a screenshot of this work in progress (it looks quite nice):

[jimmikaelkael]

I'll wait some advanced game hackers to test to new patch mem features, but I've tested this one given by bungholio:

Burnout Dominator PAL
Drive Through Cars
0026d7d8 03e00008
0026d7dc 00000000

and it works fine with the last ps2cc/CLv2. I can really drive trough traffic...

[Parasyte]

For what it's worth, I think Jimmi, misfire and whoever else is working on the PS2-PC comms should be keeping Parasyte's SRDP proposal in mind. I didn't really get it til Para explained a little in IRC today, but it would definitely be a good thing. It could set the standard for future projects of this sort.

In case anyone else is confused about what "SRDP" (Scalable Remote Debugger Protocol) is, I like to explain it with an analogy of the World Wide Web. And it goes a little something like this:

SRDP is synonymous to HTTP. Granted, most people who I point this connection to, really don't understand what HTTP is; they just know that websites they visit usually start with http://. This is because HTTP is quite transparent, and that's why it works so well.

The "real" HTTP (Hypertext Transfer Protocol) defines a set of methods, like GET, POST, and PUT. It also defines a set of response codes, like 200 "OK", 403 "Forbidden", and 404 "Not Found". Most of you may recognize these. These are all agreed upon standards by the implementers of HTTP; web servers like Apache, IIS, and LightTPD; and by web browsers like Firefox, Opera, Safari, Chrome, Lynx, and IE. For such a number of applications to interoperate with one another (and this isn't even scratching the surface of all HTTP servers/clients) is an impressive feat. But it really does make HTTP transparent. All clients speak the same language as all servers.

This is what SRDP needs to do for debuggers. It needs to define a set of commands, like "READ MEMORY", "WRITE MEMORY", and "SET BREAKPOINT". It also needs to define a set of response structures, like how the data returned by "READ MEMORY" is structured when it comes back in different data sizes, for example. If SRDP can become the "HTTP of debuggers", we will certainly have something useful on our hands. All debugger UIs speaking the same language as all the debug targets (game consoles, emulators, etc.)

I'm willing to discuss this at length with misfire and Jimmi (and anyone else interested) in the immediate future. I'm also willing to help define the spec, and possibly the implementation (meaning write some code). My only limitation is that I cannot do it alone, because there is no way that I can think of everything myself. Please join me in #srdp on irc.freenode.net so we can get the ball rolling!

I know talk is cheap, but what that really means is, talk is not as expensive as going back and rewriting a bunch of code if you decide later to adopt whatever else is agreed to become "SRDP".

[misfire]

@Viper187: SRDP is worth considering but as long as there're no actual specifications it's very hard to take it into account. However, if the program is cleanly divided into different layers (protocol layer etc.), it should be easy to add SRDP at a later point in time.

@kh2k4: I advised Jimmi to use UDP because a) it's faster and b) it's better suited for "ad-hoc debugging" (no connect/disconnect crap). UDP is absolutely sufficient for debugging in a LAN.

[kh2k4]

Any chance you could add a address monitor to PS2CC? so you can see the value changing without having to do a full dump each time.


NOTE: Most of network enabled games will not connect with the Win32 app, the reason why I want to switch to UDP.
I didn't get that jimmikaelkael what's wrong with what is currently being used? how will switching to udp solve it?

[Viper187]

Have you tried HCTP that's when the game got the overhaul in the engine which has been copied and pasted in every version since, changed modules
I bet JBI works too just like SYM.
PS2CC results checker works fine :-)

I hated HCTP. That's when I quit playing Smackdown.

Edit: I updated again with a little fix. It wasn't sending the reset command to the PS2 before updating the list, and we can have up to 126 codes, according to Jimmi.

For what it's worth, I think Jimmi, misfire and whoever else is working on the PS2-PC comms should be keeping Parasyte's SRDP proposal in mind. I didn't really get it til Para explained a little in IRC today, but it would definitely be a good thing. It could set the standard for future projects of this sort.

[kh2k4]

Have you tried HCTP that's when the game got the overhaul in the engine which has been copied and pasted in every version since, changed modules
I bet JBI works too just like SYM.
PS2CC results checker works fine :-)

[Viper187]

Ok, we should be able to test results now. Check out Rev 11 of PS2CC. Big thanks to Jimmi for pointing out a couple mistakes I made there.

It's working for me on Smackdown SYM [SLUS-20483] with the standard core launcher ELF so far.

[kh2k4]

Had a further look at Xploder HDTV today
20409EC0 00000XXX
21FDFBA0 00000XXX
it uses the following two addresses to set the Y position.
Here's the presets, I'm sure with codes you could make your own resolution setting but I don't know how you'd make a mastercode for it, I got the above searching pcsx2 memory dumps.

PAL (50hz) (672, 72)
NTSC (60hz) (672, 56)

HDTV (480p/60hz) (283, 34)
HDTV (576p/50hz) (283, 34)
HDTV (720p/60hz) (309, 146)
HDTV (1080i/60hz) (563,330)

VGA (640x480 60hz) (283, 34)
VGA (640x480 72hz) (331, 30)
VGA (640x480 75hz) (366, 18)
VGA (640x480 85hz) (270, 27)
VGA (800x600 56hz) (543, 82)
VGA (1024x768 60hz) (283, 34)
VGA (1280x1024 60hz) (354, 49)

[Viper187]

Honestly, I decided to use what worked, rather than screwing around trying to do something I couldn't get to work before. It would've been nice to eliminate all/most globals from the project, but the goddamn pointers always give me trouble any time I try to change my methods. I don't know if it's just impossible to malloc with a pointer to a local or what. It works on the global RamInfo with the LoadFile function but I always break the whole thing when I try to keep local. I could try using malloc before calling LoadFile, but that means needing another function to find out how much to malloc. Doing it all in LoadFile always seemed like cleanest way to code it. The pointers would probably cause me issues in GetSearchValues() too.

I still haven't gotten this to work on either of my preferred OSes. I wanted to stay with Ubuntu, but I couldn't get a connection through wine. I tried XP 64-bit, and got a connection but it wouldn't dump anything. It worked on Vista and XP Home so far. It's just weird. My dialup connecting at 26k is pissing me off enough without this networking shit. Comcast's site claimed to have cable here, but when I called the bastards said they don't have lines out this way. It'll probably be a couple months before I have the spare cash to buy a dish, but that's looking like my only option.

Edit: I uploaded Rev 8. My first compiled copy using Ubuntu. Unfortunately, I had to boot windows to upload the damn thing since I haven't figured out SVN on Ubuntu yet. In any case, the consecutive/matching results filtering function for the extended search options was MIA before. I added that and scratched the memory editor from the tab list for now. I still haven't found out why Ubuntu is shitting on the PS2 connection. Maybe it's blocking the port needed? XP x64 only gave me problems because I didn't have Symantec set right.

Edit 2: Rev9 uploaded. I added some code so we can test results, but it refuses to work. I can't figure out what's wrong with my implementation in lib_ntpb.c. If anyone figures out the problem, let me know. I still can't test this shit without a hassle, so I have less and less patience for things not working.

[misfire]

The search functions themselves are separate (lib_search.c). The problem is most, if not all, the vars needed to conduct a search are retrieved by the API. If the 2 structs are initialized properly, the search functions can be called from anywhere though. I'm not sure how to make it anymore independent of the API.

I understand. So technically it's not a library because it depends on global structures that must have been set up before and it calls the external function UpdateProgressBar().

You can make it really independent by passing the structures (via pointers) to the search functions and implementing a callback for the progress bar stuff. For the latter, take a look at https://svn.bountysource.com/artemis...mp2mass/main.c