(Artemis) Thoughts or Ideas

[Gtlcpimp]

Does anyone have any ideas on how to open a file during game-play without the PS2 locking up / freezing? From the ways I have tried, the PS2 refuses to access the file and locks up / freezes on every attempt.

What I have been doing is loading my ELF into address 0x01E00000, making a function that will be hooked to from within the game, locating the address of that function for making the hook, and then integrating my Cheat Device features into it so I can apply that hook in the form of a "Jokered Code". I have tested the function to make sure it is working by setting it to do other features such as modify the game memory to apply a different code or two, just to make sure it works, and it works flawlessly. The only problem is, every time I try to open a file using the "fopen" or "fioOpen" functions, my PS2 locks up and never accesses the file. I don't know if it matters or not, but I have even tried saving every single "Register" (what I consider just simple variables) in the game from the launching of my ELF, then loading those up in the function that accesses the file during game play to see if it would work. Even that idea failed to work.

Does anyone have any thoughts, ideas, or suggestions on how I could open a file during game-play?

[cYs Driver]

The reason fioOpen will lock up is because all those functions are contained in the ps2sdk which isn't getting loaded into where your cheat device is (i haven't looked at yours so that is a guess). So to get around that you must load the entire elf including all needed ps2sdk functions into memory where its not going to get overwritten, or find some low level functions that allow opening of files. The later method i have never looked into and the first method i always had trouble with

[Gtlcpimp]

There is no issue with data being over written. 0x01E00000 is not touched by any game I have seen, and is free to be used. I have my ELF loading to that address, and every bit of data contained by the ELF is not removed or overwritten at all. The PS2 will simply lock up no matter what: fopen(); fioOpen(); ExecPS2(); LoadExecPS2(); etc.

[Pyriel]

Well, it'd be easier to venture a guess if there were some source code to look at. That way we could at least tell if there's something simple missing from your code. As it is, we can only speculate blindly.

The file I/O features will obviously require that the right modules are loaded to the IOP, among other things. As to the syscalls failing, I could only guess. I'm not terribly familiar with the rules for their use, and especially how calling them in an unintended fashion would affect them. It's also possible that the game unregisters them. Although that seems unlikely.

For what it's worth, the approach I've been toying with in my head is to let the IOP handle most of the tasks at a very low-level. Writing a small module that either carries or finds what it needs, and then pulls blocks of memory from the EE according to prearranged conditions, writing them to a file. If I read the documentation correctly, at least one of the channels between them is bi-directional, and there is functionality for the IOP to request data transfer from the EE. In the end, the only code that might need to run on the EE to facilitate this (in its simplest form) is a small routine that keeps the IOP module running.

Of course, I'm working with a highly theoretical knowledge at this point, as I never mucked with the IOP much, and I haven't done any PS2 development in several years. At any rate, you guys can make of that what you will, and feel free to use the idea. It could be completely wrong, and I may not have time soon to test it. I meant to try it this weekend, and wound up tossing my nephew around instead.

[Lazy Bastard]

Pyriel: Heh. I also spent most of the weekend with the family, but I did play around with fonts and padlib a bit, in the interest of building the GUI. It's great that you're helping us muck around the PS2 for the right answers; thanks for joining in.

gtlcpimp: Yes, please do share some of your source. The goal here is to allow the scene to benefit from the best PS2 hacking system possible, not to trade bits of sparse knowledge, so we can each make our own marginally useful application.

[Derek8588]

I have been busy with life lately, but in regards to this topic, I have had a lot of trouble opening files as well from in game. I load all my code at 0x80025000 and jump to it from within a game (in kernel mode of course). I have tried fioOpen, mcopen, and neither works. I have yet to try and create an IOP module to test simple mc0 read and writes. When I get the time I will. In the meantime, I have been using my EE SIO port to debug and dump my games.

[Gtlcpimp]

I have done a quick slap together (since I deleted my previous source) so then you all can have something to look at. I have included my functions that utilize drawing strings on the screen. The syntax for them (if you would like to use them with your own projects, your welcome ):

DrawString("Text or String Here", X, Y, R, G, B, PACKET, Width, BgR, BgG, BgB);

X - X Coordinate
Y - Y Coordinate
R - Red Color Value
G - Green Color Value
B - Blue Color Value
PACKET - Graph Packet Used
Width - How wide it will go before it wraps below
BgR - Back Ground Red Color Value
BgG - Back Ground Green Color Value
BgB - Back Ground Blue color Value

The source code: http://www.cheaterslounge.net/downlo...GameFileEx.rar

It utilizes my simple cheat engine in order to apply memory modifications during gameplay. I use SOCOM: Combined Assault to do quick testing with In-Gameplay projects, so I included the "codes" to assist you if you have that game.

[misfire]

[...] For what it's worth, the approach I've been toying with in my head is to let the IOP handle most of the tasks at a very low-level. Writing a small module that either carries or finds what it needs, and then pulls blocks of memory from the EE according to prearranged conditions, writing them to a file. [...]

This is similar to what I've described here:
http://gshi.org/vb/showthread.php?p=29681#post29681

[Pyriel]

Well, nobody ever said all ideas had to be completely original. Now I know my thinking wasn't totally out of bounds, in any case.

[misfire]

In fact, letting the IOP handle most of the work is a very good idea! We should be able to call the actual game's SifLoadModule() function to execute our IOP module(s) at will. Then we have to find a appropriate way to transport memory chunks from EE to IOP. I guess the first thing I'm gonna try is shared memory, though I have to take care of race conditions.

Btw, Mega Man's Kernelloader uses IOP RAM above 0x001FF000 as shared memory:
http://kernelloader.cvs.sourceforge....der/sharedmem/