forums.ps2dev.org

I have an unmodded PS2 and I recently acquired the ARMAX. I have been wanting to get into some ps2 development and the media player of ARMAX has the ability to load and run elf binaries from a usb pendrive. As I don't have a network interface for the ps2 this is a nice way to test out the elf binaries. I have tried a few of the demos and emulators available, some work and some don't. I am guessing this is because I am running it from an untested setup. Anyway, I downloaded the toolchain and sdk and built the hello world sample but it doesn't work in my setup. I was wondering if anyone else has tried it this way. I am looking for some help as to what extra initialisation is needed in the code?

Thanks.

I'm not sure what initialization code AR MAX does and does not do.

I have the AR MAX and Max Drive. If you want, I can provide in .MAX save file format or downloadable from the Codejunkie save file site (which AR MAX can directly download to the PS2 from) a copy of the Mr Brown exploit. I have been looking into doing this for a while and including PS2MENU (default) and PS2LINK. The biggest issue I have is deciding which are the best PS1 games to select to trigger the exploit. The implimentation allows up to approx 190 triggers to be defined (of which Mr Brown only provides around 19 be default). I would like to get a good mix of popularly owned and still widely available games in the list.

many old homebrew elfs try to write to the console and that might be a reason for them not working, others might want to load data from host:.

the hello world example by default from cvs only prints to the console and therefor might be perceived as not working, change the code to only have the scr_printf and it should print to screen.

I guess the FF series would be a good start.

To clarify, when blackdroid says they are writing to the console, he is referring to them doing printf to the tty text console, and all tty is rerouted over the link software to your PC.
So in other words, if you are using link software to run the code the printfs show up on your PC, but if you aren't then they go off into nothingness.

fluke: At one point there was a much larger list of games, but I guess it never did make it to his website. I suppose if he doesn't mind I'll add it to my list of things to hunt down and post somewhere when I get a chance.
BTW, if you use the Greatest Hits list, adding a few games you can think of off the top of your head, and a couple old circa '96-'99 sports games (they can be picked up dirt cheap at used game shops) just about everyone will have a game on the list or can get one for a couple bucks.

You can add a lot more than 197 entries if you change the PAYLOAD_OFFSET constant in titleman.c. The EXPLOIT_TOTAL constant is the size of each exploit trigger, so you multiply EXPLOIT_TOTAL by the number of entries you want to get the new PAYLOAD_OFFSET. You will also want to make sure the new PAYLOAD_OFFSET is divisible by 8.

You will also need to change the init_exploit_data() function (starts at line 143 in titleman.c) to jump to the new PAYLOAD_OFFSET address. If your new PAYLOAD_OFFSET is 0x22020, then you would use: The main issue when modifying PAYLOAD_OFFSET is that you do NOT use an address that contains two consecutive zeros. If you do, then PS1DRV's strcpy() routine will terminate on the address, and the exploit will fail.

Oh yeah, you will need to modify the file linkfile to use your new PAYLOAD_OFFSET also. Change the ".text" line.

Ok. Cool!

Here is what I got so far. I'm pulling game IDs from these two sources:

http://www.dklemu.com.ar/Emus/Psx/bleem ... bility.txt
http://members.iinet.net.au/~coleman/psxlist.html

The Bleem group seem to lean very heavily towards US games so I'm ending up with 605 games for US and 209 games for EU.

Anyways, thinking out-loud for a moment--I need to allow for 608 entries with a EXPLOIT_TOTAL size of 334. 608 * 334 = 203072 or 0x31940 and the patch goes something like this:

linkfile line 4: .text linkfile 0x831940: { *(.text) }
titleman.c line 47: #define PAYLOAD_OFFSET 0x31940
titleman.c line 151-154:
exploit_data[EXPLOIT_OFFSET] = 0x40;
exploit_data[EXPLOIT_OFFSET + 1] = 0x19;
exploit_data[EXPLOIT_OFFSET + 2] = 0x83;
exploit_data[EXPLOIT_OFFSET + 3] = 0x20;

I'm going to make ps2menu v2.6 the default so that people that don't have the broadband adapter can take advantage of this (such as to run off of umcdr's) but will also supply ps2link v1.22 (which can be run from ps2menu). Users will need about 1.5 Megs free on the memory card (from ps2menu, users can delete the ps2link files if they don't want them).

It would really polish things off, it would be nice if ps2menu supported mass: access. But I have been able to get mass_usb to work. I have been running into problems with the mass_usb code using different IOP thread structures than exists in ps2sdk v2.2.

Thanks

start working on a usbd.irx cause that is missing :)

What about npm-usbd?

You have to get Napalm's permission to use or distribute it.

So, is there any chance that if we start up a fund that Napalm would be willing to sell the source code to the usbd.irx?

I took a look at what would be involved in porting libusb (from SourceForge) and it was ugly. I'm also running into problems finding what chipset is acting as the USB controller. Also, it looks like the stub files are based from information off of JamPak demo disks but it doesn't say which ones.

Anyways, back to distributing the exploit. I have the patched version of titleman which allows for 608 entires resulting in a 200K title.db file. I have ps2menu v2.6 as the default boot.elf and I have ps2link v1.24 with extraconf loading ps2netfs. This all takes about 1MB of the memory card and I believe should provide a good starting point for anyone looking to either use umcdr or ps2link to load homebrew code.

I have the exploit in the following formats:
BADATA-SYSTEM.cbs (US CodeBreaker v8)
BADATA-SYSTEM.max (US Max Drive)
BADATA-SYSTEM.npo (US nPort)
BADATA-SYSTEM.p2m (US Shark-port 4/Xploder 4)
BADATA-SYSTEM.xps (US Shark-port 2/X-port 2)
BEDATA-SYSTEM.max (EU Max Drive)
BEDATA-SYSTEM.npo (EU nPort)
BEDATA-SYSTEM.p2m (EU Shark-port 4/Xploder 4)
BEDATA-SYSTEM.xps (EU Shark-port 2/X-port 2)

I'm currently working on the documentation/credits readme file.

Is there anything else I should add? Does there exist a Europe or Japan version of CodeBreaker? Is there a Japan version of Max Drive?

Thanks

fluke wrote:So, is there any chance that if we start up a fund that Napalm would be willing to sell the source code to the usbd.irx?

...............

Is there anything else I should add? Does there exist a Europe or Japan version of CodeBreaker? Is there a Japan version of Max Drive?

Thanks

From what I have been told, only Nick holds copyrights to the napalm usb driver.

japan has the Xploder, they do not have a max drive. Their last version of the AR equivalent was the pro action replay v2.

The USB chipset is LSI logic integrated onto the IOP.

I have documentation from LSI from their website thats likely to represent
the same register values for the USB functions as exists on the IOP.
However, the base address would need to be known since the offsets I do
not think are the same. Give me a 1/2 or so to dig things up and a way
to send the info to you.

Gorim

fluke wrote: I took a look at what would be involved in porting libusb (from SourceForge) and it was ugly. I'm also running into problems finding what chipset is acting as the USB controller. Also, it looks like the stub files are based from information off of JamPak demo disks but it doesn't say which ones.

Erm... isn't libusb a usermode library for providing platform independent access to kernel level usb drivers? In other words... It's it for talking to the usb driver, and not a usb driver itself?

That being said...

Have you taken the time to notice there is a WIP (Work In Progress meaning it hasn't Progressed enough to be Working ;) usbd in cvs?

Drakonite wrote: Erm... isn't libusb a usermode library for providing platform independent access to kernel level usb drivers? In other words... It's it for talking to the usb driver, and not a usb driver itself?

Depends where you draw the line between the driver and the protocol stack. Based on the information in the usbd header file, the line is drawn at a very high level.

Please allow me to side track the conversation for a moment to explain. ps2eth and the tcp/ip stack on the PS2 appear to be seprate drivers so on the OSI model of network the ethernet driver might have it's line drawn around layer 3 such the the driver handle mostly just raw read/write to the hardware. Then the high level protocol stuff, such as the stuff that takes place at OSI layer 4-6 is in a clearly seprate driver.

usbd.h indicates that UsbOpenEndpoint(), UsbIsochronousTransfer(), UsbBulkTransfer & UsbInterruptTransfer are part of the usbd driver. These functions are *high* level protocols similar to what you expect from a TCP/IP stack. Hence, usbd goes beyond just raw level read/write to the hardware and is an actual implimentation of the USB protocol itself as well. Hence the desire to be able to steal from libusb. It is bad enough having to write the low level driver. But the whole protocol stack as well? Have you read the USB 1.1 spec? Parts of it read like some fan of Alice in Wonderland & Looking Through the Looking Glass decided to take the books and make a computer protocol out of them.

Btw, back to being slightly off topic, but does anyone remember the ISA vs. Microchannel wars? IBM wanted to charge for royality fees for Microchannel so then a screwy work around named EISA was created which was poorly thought out but royality free. Well, I think we have been stuck with a repeat of history. Apple demanded royality fees on Firewire so now the poorly thought out but royality free USB 2.0 has come to "save" the day. What a pain it is to relive history because others refuse to learn from it.

Drakonite wrote: Have you taken the time to notice there is a WIP (Work In Progress meaning it hasn't Progressed enough to be Working ;) usbd in cvs?

Nope. Haven't taken the time. I have taken the time to notice that there is a couple YEARS worth of work that has accumlated in the CVS. I think it is great that there is so much work that has already been done but as a new comer, going through the CVS feels a little like learning all about a spoken language by starting at the first letter in an unabridged dictionary and working word by word till the end. I'm taking the CVS one piece at a time and haven't gotten to any usbd other than the header/stub. If you want to give me the address/phone number in the CVS of WIP usbd then I'll check her out and see if we can make it a date. Otherwise, I'm still playing with the idea of porting rdate/ntp to PS2 and looking for how to permentally write the time to the hardware. So far I have only found the OSD Set functions which seem to only set the system time for the current session til reboot.

Getting back to the topic... :)
I didn't realise printf didn't go to the ps2 screen (maybe that function should be named something more appropriate?). I tried scr_printf but that didn't link. I found it in the header files with the comment that it will be removed from the library. Has it been removed from the binary already?
I then thought I would try gslib. I built them ok but they don't appear to be working either. And i can't seem to download gskit correctly.
So far I have had no luck. I have had a look at the demos that did work but I haven't been able to build them myself. Not all of them have source.
Is there anyone willing to help me get this working?

radad wrote:I tried scr_printf but that didn't link. I found it in the header files with the comment that it will be removed from the library. Has it been removed from the binary already?

Are you using ps2sdk? If so, #include <debug.h>

BTW, have you ever done gui programming in windows? If you do a printf where does it go, on top the gui window or console debug output in the background? ... Exactly.

I am using ps2sdk. The problem I was having was a link problem. What library should scr_printf be in?

I have done gui window progamming. printf goes to the console window on the screen. The printf in the ps2sdk gets sent to the connected pc. Is that via a usb link or via a network link?

radad wrote:I have done gui window progamming. printf goes to the console window on the screen. The printf in the ps2sdk gets sent to the connected pc. Is that via a usb link or via a network link?

Yeah, printf goes to the debug console window. It just happens that the debug console has to be on the PC, which after you get used to it does make a lot of sense.

It'll go over whatever your link software uses, as thats what sets up the handler for printf. So if using naplink it goes through usb, and ps2link it goes through net.

As I stated before I am not using any link software. Does the elf created with ps2sdk leave out any initialization that is normally taken care of when run through the link software? I am looking for something that is different in the way I am using it.