Announcement

Collapse
No announcement yet.

(Artemis) My disfunctional memory dumper

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    From another PM I wrote to Derek8588:
    I developed an IOP module that uses low level I/O functions (open, write, close) to write to mc0. Those functions are imported from other modules and SifLoadModule() really is the only RPC involved here (every game should have it... ). All the module does is to create a text file on mc0 after it was loaded - no need to talk to EE.

    You also have to make sure that the right modules are loaded before accessing mc0. This shouldn't be a problem when you load your module _after_ the game has loaded its native ones.

    And actually, you don't need the mc* functions. As I told you, you can call open/read/write/etc. on the IOP side. On the EE, use the fio* functions.

    Comment


    • #47
      Originally posted by Lazy Bastard View Post
      The ability to make the PS2 send packets to the PC during gameplay means we could at least attach that process to a button combination (or sequence, even), and potentially force memory dumps to PC (though we'd have no way of testing codes, and we'd have to use a PC-side compare application to narrow results). That is, if we can perform a dump of memory.
      This touches a problem we need to solve in one way or another. We definitely need a reliable interface between EE and IOP, but may not be able to use SIF. This is mainly due to EE memory constraints as the RPC code needs to be resident (or we find a way to hook the respective game functions). Some kind of shared memory might be another solution (the EE can access the IOP's memory, but it doesn't work the other way around). I've got some ideas, we'll see how this ends up...

      (For the careful reader: When I was able to send data from PS2 to PC in game, I only initialized the network modules and loaded another IRX that constantly pings. There was no network code on the EE side and therefore no EE-IOP communication.)

      Hacking would be so easy if the PS2 only had one processor...

      Originally posted by cYs Driver View Post
      any attempts at ingame graphics print out?
      No. I don't know enough about graphics programming on the PS2 and I think this method very error-prone.

      Comment


      • #48
        Yeah, though I think even during the first version, we should be able to figure out a way to force scr_printf during gameplay (or FONTM, as it would likely save memory), at least for little things, like "Dump 1 complete".
        I may be lazy, but I can...zzzZZZzzzZZZzzzZZZ...

        Comment


        • #49
          Don't expect me to do anything related to the screen-USB-dump-thingy. While it might be a possible way to hack games, it's very limited and not comparable to a remote debugger. I won't waste my time on that.

          Comment


          • #50
            I was already well-aware of your inclination toward the remote debugger

            We can each do our part, and in the end, if we have any RAM-hacking system for the PS2, we're happy hackers. Still, after a proper remote debugger is finished, I'd like to work toward more on-screen features. That will be some time in the future, and you don't have to help if you don't want to. However, I/we still might ask you for advice here and there, heh.
            I may be lazy, but I can...zzzZZZzzzZZZzzzZZZ...

            Comment

            Working...
            X