(Artemis) Thoughts or Ideas

[misfire]

I just committed version 1.1 of lsmod with limited IOP library support. For now, it only prints out a list of the loaded libs and some attributes. The next version will output all function imports and exports, too.

As a side note, I modified the imports.lst file in a way that you can now specify the exact version of the library you want to import functions from.

[misfire]

I wonder why socom 2 and other games have their IRX's in a folder that includes IOPRXXX.IMG or DNASXXX.IMG. Im wondering if this image file contains newer irxs than the ones currently in the same directory, or if it just points to those in the directory. If we used ps2img to extract these IMG files, maybe would could create new import and export lists for whatever module we use (lsmod.irx) I also noted that the sbv patches are being applied because they return 0.. which = success. Within the above posted thread, Lukasz says "So if the SIO2 module gets updated from version 1.0 to 1.1, due to changes in the joypad module, then both the joypad and memory card module must now change their SIO2 module imports to version 1.1, to be compatible." So maby minor revision changes do matter? hmm

sbv_patch_disable_prefix_check() returns 0 if it succeeded in patching the 16th function exported by the modload library. Although it's likely, this doesn't necessarily mean that the patch still works with newer libraries.

I can't tell you much about the ROM image files (*.img). All I know is that they contain replacement modules that are loaded by passing the file name to SifIopReset().

IIRC, the image file on a game disc doesn't contain the single IRX modules in the same directory, but don't quote me on that. When a game starts the image file is first passed to SifIopReset(), then after the IOP reset the single modules are loaded one after the other using SifLoadModule().

I don't know why the modules are loaded in two different ways. If someone knows, please tell us.

[Gtlcpimp]

I just committed version 1.1 of lsmod with limited IOP library support. For now, it only prints out a list of the loaded libs and some attributes. The next version will output all function imports and exports, too.

As a side note, I modified the imports.lst file in a way that you can now specify the exact version of the library you want to import functions from.

While I have that lsmod.irx stuff on my mind, I have a small question to ask you. Seeing as lsmod returns the names of the modules, their address information and what not, does it actually return the exact location of the module on RAM? I have tried dumping the whole RAM where lsmod shows to be the module(s) text start, entry, etc., and It all comes back blank. Am I misunderstanding what the lsmod is returning or am I doing something wrong with it? I want to be able to locate each module's location on RAM and patch specific data within the modules.

[misfire]

Yes, the addresses belong to the actual location in IOP RAM. Keep in mind that you have to add 0xBC000000 to the address if you dump from EE, as this is where the IOP RAM is mapped.

[misfire]

[...] Within the above posted thread, Lukasz says "So if the SIO2 module gets updated from version 1.0 to 1.1, due to changes in the joypad module, then both the joypad and memory card module must now change their SIO2 module imports to version 1.1, to be compatible." So maby minor revision changes do matter? hmm

FYI, fps2bios only checks the major version. Look for match_version_major() inside link_client().

[Lazy Bastard]

As far as the expertise of Lukasz, he's already agreed to provide whatever support for Artemis he can from a knowledge standpoint...so you can always just ask him

[Gtlcpimp]

You're making some wrong assumptions here.

1. The kernel resides at 0 - 0x7FFFF. You have to be in kernel mode to access this memory via kseg0 or kseg1. From user land, you can access 0x80000 - 0x01FFFFFF without any problems. So far, so good.

2. The reason why both kseg0 and kseg1 refer to the same physical memory is a technique called memory mapping. There are a couple different ways of addressing the same memory. This document describes the memory layout as followed:

0x00100000-0x01ffffff RAM Mirror Address. (cached)
0x20100000-0x21ffffff RAM Mirror Adress. (not cached)
0x30100000-0x31ffffff RAM Mirror Adress. (not cached & accelerated)

0x70000000-0x70003fff Scratch Pad RAM Adress.

0x1FC00000 - 0x1FFFFFFF ROM BIOS Mirror Adress. (not cached)
0x9FC00000 - 0x9FFFFFFF ROM BIOS Mirror Adress. (cached)
0xBFC00000 - 0xBFFFFFFF ROM BIOS Mirror Adress. (not cached)

0x80000000-0x9fffffff KSEG0.
0xA0000000-0xbfffffff KSEG1.

kseg1 is mapped into the same physical address region as kseg0, except that it is uncached.

Think about it. The PS2 only has 32MB of physical RAM, how could 0x80000000 and 0xA0000000 refer to different physical memory locations?

Also, check out this, especially the last post by TyRaNiD.

Yeah, apparently I was fooling myself or were unknowingly high on a drug... lol. When I wrote to KSEG1, then read that address back along with the same address in KSEG0, I noticed that KSEG1 was w/e data I wrote but KSEG0 was still blank. But when I wrote into KSEG0, and did the same reading process, KSEG1 came up to be the same data as KSEG0 the very instant I wrote to KSEG0. So your right, I fooled myself. Either way, I moved the point where I store memory I dump, and I now can get up to 332kb worth of a memory dump. The only issue is, I still have not been able to get the PS2 to read and write files during gameplay of modern games (only the old games with old modules work ). I still have to dump the 332kb of data to Kernel, then find a point on the game where the PS2 resets IOP or does a transaction that if the disc is not in, it reboots the PS2. Then from there I keep my memory card in that has MCBOOT installed on so I can boot up ULaunchELF v4.12 to load a Kernel Dumper ELF file I wrote to dump my kernel for me to extract the 332kb of memory I dumped from the game.

I was wondering though, are there header files that support the newer modules? If so, couldn't I just compile an ELF with the new modules and headers for the new modules so then the in-game file management would work with modern games?

[misfire]

I was wondering though, are there header files that support the newer modules? If so, couldn't I just compile an ELF with the new modules and headers for the new modules so then the in-game file management would work with modern games?

Absolutely. All you have to know is:
- library name
- library version
- function prototype
- function number

Take a look at how the PS2SDK handles imports. Library name and version can also be defined in the imports.lst file.

[misfire]

Just another idea that might solve our problem with the module dependencies:

Instead of adapting our code (import lists etc.) to the actual game we want to hack, we could try to run game modules and rom0 modules (the ones supported by the PS2SDK) simultaneously. To avoid linking errors, we could simply rename the library names, e.g. ioman to ioman1. Of course, all the (rom0) modules that originally relied on ioman must be patched to use ioman1 instead, but this shouldn't be that difficult. The method is definitely worth a try.

UPDATE:

Here's how patching of rom0 modules could be done:
- copy the module from rom0 to mc0
- patch the module's import tables (i.e. change library names)
- apply sbv_patch_disable_prefix_check()
- load module from mc0 while game is running