(Artemis) Thoughts or Ideas

[Derek8588]

Maybe the SBV patch doesn't work with the IOP program loader (Module_Manager + Module_File_loader) that comes with newer games. I'll do some further research when I'm finished with my other work.

Btw, here is a Win32 port of irxtool:
http://gshi.org/vb/showthread.php?t=3232

Thanks. irxtool works beautifully

[misfire]

You're welcome. I only had to add the elf.h header file to the sources, then I changed a few code lines and it worked like a charme.

[Gtlcpimp]

If anyone has information on how to force the ps2 to read and write files reguardless of what module versions are loaded, then please share. I mean, I can do a fucked up ghetto way of dumping memory, but would only be however much space I have on KSEG0 and KSEG1 combined that I can store data in. I've already accomplished doing it the messed up way by copying around 32kb of RAM over to KSEG0 and about 32kb of RAM over to KSEG1, then ejecting my disc tray right when the game tries to reset the IOP or reboot the ELF so then it launches the Browser. Since I have FREEMCBOOT installed, it loads ULaunchELF v4.12, allowing me to load up PS2 Link to send over an ELF I slapped together in like 5 minutes to dump KSEG0 and KSEG1.

I would much rather prefer to just do a straight dump to the Memory Cards or the USB Drive though, because it's a lot more simple and allows me to dump more than aproxmiately 64kb...

[Derek8588]

If anyone has information on how to force the ps2 to read and write files reguardless of what module versions are loaded, then please share. I mean, I can do a fucked up ghetto way of dumping memory, but would only be however much space I have on KSEG0 and KSEG1 combined that I can store data in. I've already accomplished doing it the messed up way by copying around 32kb of RAM over to KSEG0 and about 32kb of RAM over to KSEG1, then ejecting my disc tray right when the game tries to reset the IOP or reboot the ELF so then it launches the Browser. Since I have FREEMCBOOT installed, it loads ULaunchELF v4.12, allowing me to load up PS2 Link to send over an ELF I slapped together in like 5 minutes to dump KSEG0 and KSEG1.

I would much rather prefer to just do a straight dump to the Memory Cards or the USB Drive though, because it's a lot more simple and allows me to dump more than aproxmiately 64kb...

If all else fails, you could invest in building a SIO cable. It does require some soldering, patience, and of course a steady hand. The only downsize is that dumping over the serial cable takes approximately two hours. I just start mine before I go to bed, wake up, and its done. No time at all eh? lol. Nah but I hope we can get mc0 access at least or mass: access if we are lucky. But if not, you could resort to the above...

[misfire]

[...] I mean, I can do a fucked up ghetto way of dumping memory, but would only be however much space I have on KSEG0 and KSEG1 combined that I can store data in. [...]

kseg0 (0x80000000 - 0x81FFFFFFFF) and kseg1 (0xA0000000 - 0xA1FFFFFFFF) both refer to the same physical memory space. How can you combine them to get more space?

[Polo35]

Hey.


I'm new here, and i'm really interested by you EE core solution.
I mean a way to handle a pad press ingame.

I think i can adapt it for my 'combo button trick' in HD project.

I didn't think to cheat system possibility before ffgriever ( from psx-scene ) help me to handle 'iop reboot request' from EE side.
HD Project solution for that was only IOP side before ( 'fakeboot' module ), and use some IOP memory for nothing.
Now i'm using 'sioshell' way to get syscalls fonction and hook some of them to catch reboot request and make it with my own fonction which call 'rom0:UDNL' directly and pass 'IOPRPxxx' image as parameter.


All of this shown me how hooking EE kernel fonctions and how making code resident in EE.
That's why i think i can write my own 'In Game Reset' from your cheat system.


I've got some basis in PS2 dev, so don't hesitate is you want some help on 'Artemis'.

If anyone has information on how to force the ps2 to read and write files reguardless of what module versions are loaded, then please share.

Dlanor ( from psx-scene ) re-wrote a ioman header file some time ago to make mcsioemu module compatible with ps2sdk. ( It was originaly wrote with $ony sdk. )

mcsioemu use 'open/close/read/write/lseek/mount/devctl' from fileio module loaded at game startup.

I think there is no problem to use this header in both EE or IOP side. ( I mean ELF and IRX )

This header is part of HD Project so no problem to re-use it if you specify it's 'wrote by Dlanor from psx-scene for HD Project'.


I attach this header here.


Best regards

Polo

[misfire]

With the "new" IOMAN header, I don't see any declaration that can help us here. The imported functions have the same number and prototype, and even the library version is the same (IOMAN 1.1). All it does is to add some function declarations from iomanX.h that seem to be present in some IOMAN modules too.

[Polo35]

Oh, sorry.


I didn't take a look to the source, and thought it was a 'iop size' attemp to open/write a file.

Anyway new_ioman header only allow access to extended fonctions set from ioman game module.


I go out.


Best regards

Polo

[misfire]

More on version dependencies between modules:
http://forums.ps2dev.org/viewtopic.php?p=71704#71704

[Derek8588]

ps2img

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

[Gtlcpimp]

If all else fails, you could invest in building a SIO cable. It does require some soldering, patience, and of course a steady hand. The only downsize is that dumping over the serial cable takes approximately two hours. I just start mine before I go to bed, wake up, and its done. No time at all eh? lol. Nah but I hope we can get mc0 access at least or mass: access if we are lucky. But if not, you could resort to the above...

If I wanted to resort to soldering anything to my PS2, I would much rather get a programmable Chip soldered directly to the PS2's RAM (if you catch my drift)

kseg0 (0x80000000 - 0x81FFFFFFFF) and kseg1 (0xA0000000 - 0xA1FFFFFFFF) both refer to the same physical memory space. How can you combine them to get more space?

0x80078250 - 0x80080000 = Aproximately 32kb (I haven't tried going past 0x80080000 because it smells fishy with the whole RAM's lowest point is 0x00080000)
0xA0078250 - 0xA0080000 = Aproximately 32kb

The reason why I choose 0x80078250 and 0xA0078250 as the lowest point is because I have noticed that nothing is stored from that point on to the rest of the kernel of KSEG0 or KSEG1

I don't see how those refer to the same physical memory space when 0x8 is not 0xA, but I have already accomplished what I have tried...
I have stored data in KSEG0 and different data in KSEG1, reset IOP and what not, then dumped the whole KSEG0 and KSEG1 to compare. Guess what I found, KSEG0 still had what I wrote to it, and KSEG1 still had what I wrote to that.

Btw, is there a way to prevent the PS2 from writing to certain memory addresses, or at least preventing it from flushing changes during IOP reset? I have noticed that if I write to the memory addresses that house ROM1, all of my changes are cleared as soon as the IOP is reset...

[Derek8588]

You can use memory from 0x80000000 and up as long as nothing is written to it. The kernel resides here, but you can utilize the space it doesnt use. the homebrew SIOSHELL app puts itself at 0x80050000 if I remember correctly. And it runs at ALL times. Even when sitting at the ps2 browser. I have created a kernel loader that puts an elf at 0x80025000. I can then jump to my elf from within a game. Using this memory space gave me much more room while being hidden from user memory

[Gtlcpimp]

You can use memory from 0x80000000 and up as long as nothing is written to it. The kernel resides here, but you can utilize the space it doesnt use. the homebrew SIOSHELL app puts itself at 0x80050000 if I remember correctly. And it runs at ALL times. Even when sitting at the ps2 browser. I have created a kernel loader that puts an elf at 0x80025000. I can then jump to my elf from within a game. Using this memory space gave me much more room while being hidden from user memory

Um, yeah, I believe I have already established that...

[misfire]

[...] 0x80078250 - 0x80080000 = Aproximately 32kb (I haven't tried going past 0x80080000 because it smells fishy with the whole RAM's lowest point is 0x00080000)
0xA0078250 - 0xA0080000 = Aproximately 32kb

The reason why I choose 0x80078250 and 0xA0078250 as the lowest point is because I have noticed that nothing is stored from that point on to the rest of the kernel of KSEG0 or KSEG1

I don't see how those refer to the same physical memory space when 0x8 is not 0xA, but I have already accomplished what I have tried...
I have stored data in KSEG0 and different data in KSEG1, reset IOP and what not, then dumped the whole KSEG0 and KSEG1 to compare. Guess what I found, KSEG0 still had what I wrote to it, and KSEG1 still had what I wrote to that. [...]

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.

[misfire]

Also, here are some more mappings I wrote down:

0xBE000000 - 0xBE03FFFF ROM1
0xBE040000 - 0xBE1FFFFF EROM
0xBE400000 - 0xBE43FFFF ROM2

Those are at least valid on my machine.