Newbieness, offer for help, and doubts :)

Printable View

12-26-2006, 12:02 PM
Jcl

Newbieness, offer for help, and doubts :)

Ok, I've had my PS2 (big one) for not over two weeks. It came (second hand) with a Matrix Infinity modchip and the network adapter, for which I've put in a Seagate 200Gb HD I had spare around.

I installed on both the HD and the memory card (a Max 64Mb one), uLaunchElf (4.08) and HDLoader (several different patched versions). uLaunchElf seems to work perfectly fine with my 512mb Trascend USB Pendrive (haven't still been able to test it with my 2Gb Sony one).

I can boot in DEV1 or DEV2 modes with Matrix Infinity (after upgrading it to latest firmware version... 1.93 IIRC), and currently, I have it booting in DEV1 mode to uLaunchElf (from mc0).

Now for my questions:

1 - Is there any way to get uLaunchElf read the configuration from the HD? I can boot it from the MC without a problem, and it'll read the configuration from the same directory where the ELF is... no way to do it from HD. When I boot it up from HDD, it seems to load up the HDD modules before starting the program, so it -should- be able to read the HD (and thus the CNF file).

2 - Is there an easy way to store the file sorting/display method for the navigator? I have to set it everytime (since I want the game names to appear by default on the MC... I use uLE to copy the savegames I don't need on the HD... that way, the MC seems to be much faster [the Max one is VERY slow]).

3 - Can one use ARMax from HD (using uLaunchElf) to load games from HD? (or HDLoader, for the matter).

4 - Is there a way to make "corrupted data" (which seems to come from the BOOT directory and everything you put in there) not be shown on PS2's browser? I don't want to accidentally delete it, and I want to distinguish that "corrupted data" (which is a directory I want) from other possibly real corrupted data (since there are games which won't save correctly to the non-official 64mb MC).

5 - I have the PS2 on the living room and there's only an HTPC nearby. The HTPC is connected to my wireless network and I can't wire all the house (or my gf will kill me :) ). Is there any way I could use the HTPC (using Internet Connection Sharing or other means of routing using the HTPC) to connect the PS2 wirelessly? In case it's not possible by using a crossover cable... is there any kind of cheap device that will bridge ethernet to wireless I could buy?

I would like to do some coding for the PS2 (I work as a programmer myself), and I can just use my laptop from the living room (the wireless router is at the other side of the house) to do so. Would wireless be fast enough?

And 6 - Is there any way to reboot the PS2 using the pad? When I'm testing stuff, having to sit down near the PS2 (and VERY near the TV) to reboot when needed is a pain in the ass... I'd rather be testing it from the comfort of my sofa :-)

Sorry, I know some questions are not specific to uLaunchElf... but most of them are, so I hope this is the right forum to ask.

As for the offer for help... if you have a setup like mine and need some help doing anything I have already done... feel free to ask me and I'll be glad to explain anything.

I'm experienced with computers, operating systems, networking etc. (just not with consoles)... I just don't have too much time to do "live" tests and probably most of you have done what I need (if it's possible) already, and would be great if you could ensure it was possible to do without too much trial and error testing.

Thank you in advance :)
12-26-2006, 12:40 PM
Bootlegninja

2 Attachment(s)

Quote:

Originally Posted by Jcl

1 - Is there any way to get uLaunchElf read the configuration from the HD? I can boot it from the MC without a problem, and it'll read the configuration from the same directory where the ELF is... no way to do it from HD. When I boot it up from HDD, it seems to load up the HDD modules before starting the program, so it -should- be able to read the HD (and thus the CNF file).

From what I've read, the order uLE searches for the config files are
A. The same directory uLE is loaded from.
B. mc0:/SYS-CONF/

Quote:

Originally Posted by Jcl

2 - Is there an easy way to store the file sorting/display method for the navigator? I have to set it everytime (since I want the game names to appear by default on the MC... I use uLE to copy the savegames I don't need on the HD... that way, the MC seems to be much faster [the Max one is VERY slow]).

As for it "remembering" the display settings in the file browser, I don't have any info on this but mainly as I don't use this feature often. EP or dlanor would be the ones to give you a definate answer on that. And as for the 64MB mc, it has been mentioned in the main thread here by a few people that they are slow.

Quote:

Originally Posted by Jcl

3 - Can one use ARMax from HD (using uLaunchElf) to load games from HD? (or HDLoader, for the matter).

yes. there is a tutorial floating around but to save some time I have a copy of it in a txt file attatched

Quote:

Originally Posted by Jcl

4 - Is there a way to make "corrupted data" (which seems to come from the BOOT directory and everything you put in there) not be shown on PS2's browser? I don't want to accidentally delete it, and I want to distinguish that "corrupted data" (which is a directory I want) from other possibly real corrupted data (since there are games which won't save correctly to the non-official 64mb MC).

Attatched is a zip file containing 2 files that will display an icon for your BOOT directory on your mc. Just use ule's file browser to copy these file in that directory.

Quote:

Originally Posted by Jcl

5 - I have the PS2 on the living room and there's only an HTPC nearby. The HTPC is connected to my wireless network and I can't wire all the house (or my gf will kill me :) ). Is there any way I could use the HTPC (using Internet Connection Sharing or other means of routing using the HTPC) to connect the PS2 wirelessly? In case it's not possible by using a crossover cable... is there any kind of cheap device that will bridge ethernet to wireless I could buy?

I'm not sure on that. You may want to check the Online gaming section in the forums on that topic.

Quote:

Originally Posted by Jcl

I would like to do some coding for the PS2 (I work as a programmer myself), and I can just use my laptop from the living room (the wireless router is at the other side of the house) to do so. Would wireless be fast enough?

You may want to check http://ps2dev.org to get started there.

Quote:

Originally Posted by Jcl

And 6 - Is there any way to reboot the PS2 using the pad? When I'm testing stuff, having to sit down near the PS2 (and VERY near the TV) to reboot when needed is a pain in the ass... I'd rather be testing it from the comfort of my sofa :-)

I believe (and someone please correct me if I'm wrong) that if you have a V9 or newer that you can reset using the dvd remote. If you have an older ps2, in the case modding section a member called helltick had a wireless doorbell mod that would do what your asking, but people also reported that it didn't work well with systems with modchips. And also his tutorial page where its located is down. I had previously saved it for offline use and reuploaded it here. http://www.megaupload.com/?d=OBY7JQ36
12-26-2006, 02:33 PM
Jcl

Now that's what I call good support... thank you very much!
12-26-2006, 05:57 PM
dlanor

----- snip ----- re: your hardware setup

Quote:

Originally Posted by Jcl

USB Pendrive (haven't still been able to test it with my 2Gb Sony one).

Please report results with that 2GB unit, using FAT32. Many people have reported failures with 2GB units, and I'm beginning to suspect there may be some driver limitation. I'd like to get those doubts cleared up either way.

Quote:

I can boot in DEV1 or DEV2 modes with Matrix Infinity (after upgrading it to latest firmware version... 1.93 IIRC), and currently, I have it booting in DEV1 mode to uLaunchElf (from mc0).

That is the recommended mode for your setup.

Quote:

1 - Is there any way to get uLaunchElf read the configuration from the HD? I can boot it from the MC without a problem, and it'll read the configuration from the same directory where the ELF is... no way to do it from HD. When I boot it up from HDD, it seems to load up the HDD modules before starting the program, so it -should- be able to read the HD (and thus the CNF file).

The problem is that homebrew and commercial code use different methods of launching stuff from the HDD. Current versions of all homebrew programs are only compatible with the homebrew method of passing the launch path. We intend to fix that in some future version of uLE, but until we do you'll have to use the default CNF location ("mc0:/SYS-CONF/") when booting by Dev2.

Quote:

2 - Is there an easy way to store the file sorting/display method for the navigator?

No. Not at present. We could do that of course, but I consider it unsuitable. I hope you are aware that game titles are not necessarily unique, whereas the real folder names are. Relying only on game titles to identify saves is a sure way to head for disaster. It's just a matter of time...

For example, two saves with identical titles may still represent entirely different game states. If you erase one of them based only on the titles you may lose most of the time spent on that game.

On the other hand, two saves with very different titles may very well have exactly the same folder name (and file names inside that folder), even though they are in fact saves from different parts of the game, but using the same 'slot'. Attempting to place both of those saves on the same MC, misled by those titles, will result in only one of those saves surviving.

Such complications are part of the reason why I implemented the CNF variables "PSU_HugeNames" and "PSU_DateNames", to ensure that all relevant info can be saved for PSU backups. Unfortunately we don't have room to display all that stuff in the regular browser. As a compromize I've made it default to showing true folder names, as that is what determines uniqueness on the MC.

Quote:

I have to set it everytime (since I want the game names to appear by default on the MC... I use uLE to copy the savegames I don't need on the HD... that way, the MC seems to be much faster [the Max one is VERY slow]).

True. For some reason those Max MCs get slower for each additional save stored. I have two 32MB units myself, but there's no point attempting to use their full size, as the speed drops below acceptable levels.

Quote:

3 - Can one use ARMax from HD (using uLaunchElf) to load games from HD? (or HDLoader, for the matter).

Those are really two questions. You can use ARMax for HDL games only by modifying the CDVD image of each game to be cheated, so as to contain both ARMax and the game. Such a combined image can then be installed to HDLoader and used to play the game with cheats. But this method will not work with games dependent on a specific disc structure, such as most Square-Enix games.

CodeBreaker is more flexible when it comes to HDD cheating, though it does rely on launching HDLoader (or uLE) from a CDVD disc. This is what I do when I want to experiment with game cheats.

As for launching HDLoader from HD, that's no problem. Just store it as any other ELF in a normal HDD partition, and use uLE to launch it from there.

Quote:

4 - Is there a way to make "corrupted data" (which seems to come from the BOOT directory and everything you put in there) not be shown on PS2's browser? I don't want to accidentally delete it, and I want to distinguish that "corrupted data" (which is a directory I want) from other possibly real corrupted data (since there are games which won't save correctly to the non-official 64mb MC).

The Sony browser will say that any folder is corrupt if it doesn't contain a valid "icon.sys" file plus some icon file indicated by the "icon.sys", as that is how that browser finds out what to display. You can use various MC tools to make your own files to satisfy that requirement.

You can also copy such files from another save folder, if you're desperate, but you will no longer be able to see any difference between those two folders then, in that browser. Even in uLE they would look identical in title mode, since it is the "icon.sys" file that contains the game title of each save folder.

Quote:

5 - I have the PS2 on the living room and there's only an HTPC nearby. The HTPC is connected to my wireless network and I can't wire all the house (or my gf will kill me :) ). Is there any way I could use the HTPC (using Internet Connection Sharing or other means of routing using the HTPC) to connect the PS2 wirelessly? In case it's not possible by using a crossover cable...

You will need a physical connection to one unit (PC/hub/router) at least, and this must give you connection to one PC where you can make some config changes. If this is not the PC containing the stuff you want to access, then you'll need to define 'network drives' on it, which connect to network shares of the other computer, holding the stuff you need. I do similar things myself, except that I use a wired network throughout. But my PS2 only contacts one of my PCs, even when accessing data from another PC, just like yours would as outlined above. As for ICS, I think very little homebrew stuff will work through such a connection, though I never tried it myself.

Quote:

is there any kind of cheap device that will bridge ethernet to wireless I could buy?

I don't know of any.

Quote:

I would like to do some coding for the PS2 (I work as a programmer myself), and I can just use my laptop from the living room (the wireless router is at the other side of the house) to do so. Would wireless be fast enough?

Sure. The PS2 is no speed freak when it comes to networking.

But your real problem may be the hookup for interactive tests. You will need to run PS2Link on a PC to which the PS2 is 'directly' connected (even via hub/router). Just having a connection to one PC will not allow interaction with PS2Link running on another PC. Network drives can't save you there, nor can ICS.

But if you do your testing without PS2Link (thus no feedback on the PC), then you can transfer compiled ELFs like any other files, for local testing on the PS2.

Quote:

And 6 - Is there any way to reboot the PS2 using the pad?

No. But I believe some models support reset/poweroff from the official Sony remote control unit, though I've never had one myself.

Quote:

Sorry, I know some questions are not specific to uLaunchElf... but most of them are, so I hope this is the right forum to ask.

I'll accept it, as long as the main content is uLE related.
(And I do consider all that networking stuff as being so.)

Anyway, if you want to get serious about PS2 programming, then you'll also need to register at ps2dev.org, as that is the development center of most of the tools and programming libs we use.

Best regards: dlanor
12-27-2006, 04:41 AM
Jcl

Thank you very much. I'll snip the parts that you got perfectly clear, and just quote what I still have doubts with.

Quote:

Originally Posted by dlanor

Please report results with that 2GB unit, using FAT32. Many people have reported failures with 2GB units, and I'm beginning to suspect there may be some driver limitation. I'd like to get those doubts cleared up either way.

I will... as soon as I get it back (I lend it to someone).

Quote:

The problem is that homebrew and commercial code use different methods of launching stuff from the HDD. Current versions of all homebrew programs are only compatible with the homebrew method of passing the launch path. We intend to fix that in some future version of uLE, but until we do you'll have to use the default CNF location ("mc0:/SYS-CONF/") when booting by Dev2.

Sorry if this is a newbie question or if I'm terribly wrong... I just want to understand this (for if I get to do any coding)... but, as far as (my) programming logic comes, if you can boot uLe from the HDD, and before anything gets loaded (it does so when loading from HDD) it loads its own HDD modules (and thus can access the HDD without further driver loading), what would be the problem on... hmn... "delaying" the CNF reading so that it's read -after- the HDD has been initialized (so it can load the file from wherever... argv[0] should be routed as hdd0:/__boot/boot.elf , wouldn't it? so it should be a matter of reading the CNF file from default locations, and if it's not there, just read it from the stripped path of argv[0], so you could just store the CNF file along with the ELF and it'd work no matter what).

Maybe there's just a different programming logic on the PS2, and maybe just argv[0] is something that doesn't just exist on it... but all of this seems logical to me.

Quote:

No. Not at present. We could do that of course, but I consider it unsuitable. I hope you are aware that game titles are not necessarily unique, whereas the real folder names are. Relying only on game titles to identify saves is a sure way to head for disaster. It's just a matter of time...

Yes, I understand this, but I tend to know what's on my MC (since I am the only PS2 user here), and if in doubt, I could always revert manually to folder name display before doing anything.

This is not something that is bugging me all that much, and I'm not really requesting it for future versions (I am sure you have plenty of other things to do)... just wondered if it was possible already to do so, but if it's not, pressing 3 buttons on the PAD when I'm going to manage the savegames is not all that much of a hassle :)

Quote:

True. For some reason those Max MCs get slower for each additional save stored. I have two 32MB units myself, but there's no point attempting to use their full size, as the speed drops below acceptable levels.

For what I've been told by several people (although I can't say this is true), Max memories are just 8mb cards with some kind of hardware compression embedded in (up to different levels for 16, 32 and 64 models). It just gets slower to find stuff on the card since there's no direct file allocation table access and it has to sequentially find (from start to the desired location) everytime you try to load anything.

This may be all bullshit, but I've been told by a few different people already and it makes sense.

Quote:

Those are really two questions. You can use ARMax for HDL games only by modifying the CDVD image of each game to be cheated, so as to contain both ARMax and the game. Such a combined image can then be installed to HDLoader and used to play the game with cheats. But this method will not work with games dependent on a specific disc structure, such as most Square-Enix games.

Yes, that's what I understood from the tutorial bootlegninja's kindly attached on the first reply... I was actually wondering if there was a method to load up ARMax so that ARMax would load HDLoader (and boot the game afterwards).

I know this might sound extremely tricky (specially since I don't know how ARMax for PS2 works... but I would assume it's just some kind of trainer that gets TSR'ed and keeps hooking on memory locations... if HDLoader doesn't clear it up, it'd not be that weird to think one could load ARMax, make it load HDLoader, and then use HDLoader to boot up the game, with ARMax still in memory).

Quote:

As for launching HDLoader from HD, that's no problem. Just store it as any other ELF in a normal HDD partition, and use uLE to launch it from there.

Yes, you misunderstood me... I wanted ARMax to load HDLoader, not boot HDLoader (that's exactly what I do, boot uLe then HDLoader).

I tend to use the optical lens on the PS2 as little as possible :)

About all the networking stuff... I was hoping the TCP/IP stack would allow the use of a gateway and just make a different subnet for the PS2/HTPC and the wireless network... so just using the gateway would allow "direct" connection to any computer on the wireless network. But if the PS2 is acting like the server, then problems may begin here.

I guess when I can sit down and start coding for it (currently I have tons of work and really can't spend all that time), I'll just get a VGA Box and bring the PS2 to my computer room,connect it to a monitor, and plug it into the router or directly to my laptop, wired

Quote:

No. But I believe some models support reset/poweroff from the official Sony remote control unit, though I've never had one myself.

I've read it works for those models with embedded IR receiver (that's V9 and on), which is not my case... I don't really know which model I have (haven't still counted the screws on the case :) ) but I'm quite positive it does not have a built in IR display. Doesn't matter a lot.. if I'm gonna bring it to the computer room to code in it, I'll have it handy from my chair :)

Quote:

Anyway, if you want to get serious about PS2 programming, then you'll also need to register at ps2dev.org, as that is the development center of most of the tools and programming libs we use

That was in fact the very first site I visited when I got the PS2 home... I haven't registered there because I can't spend time coding for the PS2 right now, but intend to do it as soon as possible.

I'm experienced with 3D and graphics programming and want to do some homebrew demos (as in demoscene ones) for the PS2... (I used to be an active PC demoscene member). Once I get the rid of programming on it, if you (by then) need some help with uLe development, I'll be glad to help (but I guess by then, everyone will be doing stuff on the PS3... talk about coming late to the console world, hehe).

Anyway, thanks for the useful replies (to both of you), at least now I know what can be done or not, and don't have to keep testing "what-seems-logical" stuff which just can't work on the thing :)
12-27-2006, 04:41 PM
taonaut

Quote:

Originally Posted by Jcl

... is there any kind of cheap device that will bridge ethernet to wireless I could buy?

Maybe this is what you are looking for then?
12-28-2006, 03:58 AM
Jcl

Quote:

Originally Posted by taonaut

Maybe this is what you are looking for then?

Actually yes, but the cheapest of those being $60 is not what I'd call "cheap". I was hoping to find some kind of cheap wifi thing where you'd plug an ethernet and it'd only pass packets through.

Seems it's more complicated than that (otherwise I don't get the price tag).

Anyway, thanks :-)
12-28-2006, 01:35 PM
rathunter

The more complicated bit is authentication, you can't just pass through the air. Security aside, it wouldn't work if anyone else was in range.
12-28-2006, 07:33 PM
dlanor

----- snip ----- re: CNF loading for Dev1 boot method

Quote:

Originally Posted by Jcl

what would be the problem on... hmn... "delaying" the CNF reading so that it's read -after- the HDD has been initialized (so it can load the file from wherever... argv[0] should be routed as hdd0:/__boot/boot.elf , wouldn't it?

There are several problems hidden here.

One of them is this:
On the PS2 it's not possible to replace a running HDD driver by a new one without first performing a system-wide 'IOP reset', which kills all running IRX modules, and basically restarts the IOP processor. Such a reset has various side effects (kills all resident threads, thus killing any debug sessions etc), which is why it's supposed to be optional in uLE. So this 'IOP reset' should only be performed if a setting in "LAUNCHELF.CNF" specifies it. So the CNF must be loaded before any change is made to the IO system. It is this that allows uLE to be used with debuggers such as PS2Link.

Note that as used without/before IOP reset uLE simply assumes that all IO drivers in use by the IOP processor are compatible with the libs used by uLE for the EE processor. That's not necessarily the case with a commercial product (such as a mod-chip) as they may use drivers that differ from the homebrew ones of PS2SDK. In any case, there is no generic way for uLE to test this, so we have no choice but to assume compatibility...

Quote:

so it should be a matter of reading the CNF file from default locations, and if it's not there, just read it from the stripped path of argv[0], so you could just store the CNF file along with the ELF and it'd work no matter what).

Not really, because some device drivers have interdependent code in the IRX drivers for the IOP processor and the high level libs for the EE processor. When one EE program launches another, the IOP code modules of the first program remain in RAM, even if the new EE program is not compatible to them and needs other ones.

A path passed in argv[0] will only work if it points to a device driver compatible to the launched program, which is one reason for incompatibility between code using Sony's SDK and code using homebrew PS2SDK.

Another complication is that the PS2 HDD implementation is split into two separate but interdependent devices, the HDD device and the PFS device.

So you can access "hdd0:" to read partition data of the physical drive, but you must mount such a partition on "pfs0:" (or "pfs1:" etc) before you can access the filesystem contents. This raises some doubt as to how to pass the launch argument.

A path for hdd0: as used in IO calls simply consists of the device name and a partition name, without additional path info, so passing that is useless.

A path for pfs0: (or pfs1: etc) is what you need to use in accessing any data files (like CNF), so passing that in argv[0] would make some sense. But unfortunately that doesn't inform the new program about the partition used, as that was held in EE memory of the previous program...

Both of those devices use the 'fileXio' system calls, rather than the 'fio' used by most PS2 devices (eg: MC, USB mass).

Unfortunately some people long ago decided to use a very odd method of dealing with this, by using a pseudo device named "host:" (same name as a networking driver) in a special IRX driver called 'fakehost'. What this does is to indirectly access the HDD and PFS drivers, so that a launched program can use 'fio' calls with the path passed in argv[0] to read files files on HDD, as the fakehost driver translates this to "fileXio" calls using a "pfs0:" path as specified by the launcher program.

This means that a launched program can treat such a launch case almost identically to how it treats a debugging case where it's launched via PS2Link, using the real "host:" device driver. Thus it simplified the coding for some developers, which seemed like a good thing to them. But it was not really a good standard for the future, as it hides the true launch path from the launched program, in a non-recoverable way (AFAIK anyway).

Many programs also refer to HDD paths simply by using a fused combination of the HDD path of the partition and the PFS path in that partition, such as in a combined path like "hdd0:+ELFS/SMS/SMS.elf", though in fact there is no device driver available that can 'swallow' a complete path like that for direct use in any file access calls, neither of 'fileXio' nor 'fio' type. But this is the kind of path set up in argv[0] by the mod-chip Dev2 methods that I know about.

Such a path needs to be split in two, used separately as mentioned above, which is not even attempted by the normal startup code in most homebrew applications. However, even if we do split the path correctly and perform all necessary unmount and mounting operations properly, this is only guaranteed to work if we start with a proper 'IOP reset', to ensure that we get IRX modules that are compatible to the EE libs of the launched program, and that's exactly what we can't do with uLE, since we need to read the CNF *before* deciding whether or not to perform an IOP reset at all... It's 'Catch 22' !

One potential solution to this quandary is to make IOP reset mandatory when booting from HDD, and optional when booting from other devices. However, even that might not solve all problems, as the 'IOP reset' is a very odd and tricky procedure. Changing the order of IO operations surrounding it (which this fix would require) can cause unexpected failure of IRX modules not directly related to any of those changes. This is probably due to a side effect of how some of the Sony code is patched by the 'subversion' code (Needed to allow homebrew module loading to work properly). And that is what ruined some of the attempts I've aleady made to adapt uLE to the Dev2 bootup path usage. (So that stuff is not present in released versions.)

Hopefully I can find a working solution for this eventually, but until then we'll just have to use the default CNF location on MC for such cases.

Quote:

Maybe there's just a different programming logic on the PS2, and maybe just argv[0] is something that doesn't just exist on it... but all of this seems logical to me.

PS2 programming is indeed very different from programming for a normal computer, since there is no real operating system, and Sony have some odd ideas about how to implement stuff. It is those odd ideas, as well as some odd ideas of the homebrew community, that complicate matters.

----- snip ----- re: Saving browser mode flags in CNF

Quote:

just wondered if it was possible already to do so, but if it's not, pressing 3 buttons on the PAD when I'm going to manage the savegames is not all that much of a hassle :)

I probably will add it in even though I'll never use it myself, as I know that many others want it like you do. I do use title mode sometimes, but I'll never save it for default use, but since some prefer it I guess I should allow it.

----- snip ----- re: Story about Datel faking Max MC size by compression to 8MB
I'm sure you're just passing on what you heard, but I have to say that this idea is pure BS, as is easily proven by storing files containing data that is already highly compressed (such as normal JPG pictures). Compressing those by an additional factor of four, so as to store 32 MB of such files in a physical RAM of 8 MB, that is quite simply impossible. (Note that I only mentioned the cards I actually have, though I know other sizes exist.)

Besides, why would they skimp on physical storage space that way, with modern chip prices being what they are. It just makes no sense, even if we disregard the impossible compression requirements.

No. Most likely it's their method of dealing with the MagicGate encryption that's responsible for the slow access. They're not paying Sony for that license (nor do I think Sony would accept their money, as there are some conflicts).

It is quite likely, however, that Datel did use an 8MB Sony MC as basis for their 'MagicGate' workaround, and such chips may even be incorporated in their Max MC design, but some other flash memory must still be used to hold the stored data, to enable the larger storage capacity.

----- snip ----- re: ARMax usage with HDLoader
Tons of people have tried to make that work ever since HDLoader appeared, and using all available cheat devices. In the case of ARMax, the only successful usage I've heard of is with ARMax integrated with the game ISO.

To me that is a completely useless method, as it won't work with my favourite games, so I make my 'cheat' experiments with CodeBreaker instead, which has no problems cooperating with HDLoader, as long as it gets to launch some CD in lieu of the 'cheated' game. I simply let it launch a boot CD for uLE, and use it to launch HDLoader from HDD, which then starts the game with cheats active. No problem. My laser is only active for the short interval needed to boot that uLE CD, which is completely negligible compared to the laser-time saved by running the game off HDD.

On the other hand, the ARMax method is the only method I know of that could work for people whose laser is already completely dead...

Quote:

About all the networking stuff... I was hoping the TCP/IP stack would allow the use of a gateway and just make a different subnet for the PS2/HTPC and the wireless network... so just using the gateway would allow "direct" connection to any computer on the wireless network.

You can have a router between the PC using ps2client and the PS2, that is what I do myself using a D-Link DI-604 currently, which recently replaced my old NetGear RT-314, which I used the same way earlier.

But trying to use a PC with ICS (one alternative you mentioned) is not the same thing at all. ICS is a method to connect several computers to the Internet, not to connect stuff locally. You might be able to use other software to make a PC work more like a router, but I see little point in it.

Quote:

But if the PS2 is acting like the server, then problems may begin here.

For the Host protocol as well as the FTP code in uLE the PS2 *is* the server, obviously. You can't run a client program on the PC and expect that to 'be a server'. I'm not sure what you meant here, but possibly we have some terminology mixup. I know that the term 'server' is sometimes used about an entire computer, but I used the term only as it relates to TCP/IP protocol usage.

----- snip ----- re: remote control for PS2 on/off

Quote:

I've read it works for those models with embedded IR receiver (that's V9 and on), which is not my case...

OK, but it might work with a plug-in remote receiver too, though I've no idea if it really does. But since uLE can switch off the PS2 just by running some code, whatever driver that plug-in receiver has should be able to do the same.

Quote:

I don't really know which model I have (haven't still counted the screws on the case :) ) but I'm quite positive it does not have a built in IR display.

I did have such a model before my present v7, but I can't remember that it looked much different from the v7. It definitely didn't have any extra 'display', nor is it supposed to. The IR unit is just a receiver, not a display.

Quote:

I'm experienced with 3D and graphics programming and want to do some homebrew demos (as in demoscene ones) for the PS2... (I used to be an active PC demoscene member). Once I get the rid of programming on it, if you (by then) need some help with uLe development, I'll be glad to help

You'll be welcome to do so.

Many others have contributed to uLE besides EP and myself, since Mirakichi released the LaunchELF sources, and though EP and I are the only ones to stick with the project throughout, all efforts by others are both welcome and appreciated.

Quote:

(but I guess by then, everyone will be doing stuff on the PS3...

Oh yeah ? Maybe, but I doubt it. The PS3 console has barely been released as yet, and that initial release was simply laughable in its magnitude and geographical extent, compared to the potential user base. (no release at all yet where I live)

It's obvious that Sony's plans for mass production have failed, and the only reason they've released the console at all even now is simply that they couldn't afford to lag too far behind the XBox 360 release nor the Wii release. They're selling stuff at cost now, because they can't afford to lose the public's attention. But inability to deliver mass produced consoles on a worldwide scale means that they've already lost that race. Now Sony's only chance to win is if the PS3 really proves greatly superior to the other consoles, in terms not only of potential capacity, but in terms of new advanced features that game designers really use, to make games that can attract customers from the other consoles.

Anyway, even when the PS3 does become generally available, there are other obstacles to be overcome before homebrew coding for it is a viable alternative. Someone is going to have to develop useful libs and SDK tools for it, and even if some can be had 'for free' by using linux, they still have to be tailored for use with the PS3 processors, and that is no small task. No previous code in the linux world can help much with that, as the new PS3 stuff has no close relatives among normal computers or old consoles... Those tools will take quite some time to develop, so I think you have plenty of time to learn PS2 coding before that stuff is anywhere near complete.

Quote:

talk about coming late to the console world, hehe).

I did that too. I completely skipped the NES and SNES generations (except for emulators on PCs now), as I was too busy working with various normal computer work in those days. I got into PS1 stuff towards the end of that era. My first Sony console was a slim PSone rather than the thicker PSX (which I also have now). This got me hooked on the Square RPGs, and since these favour Sony consoles I've stayed with those for the PS2 as well.

As for the PS3, I'll have to wait and see, but the price prognosis is not favourable. (Swedish retailers won't deal with less than 100% or more markup, so it's quite normal for customer prices here to be twice as high as in the USA.)

But my first console of all was some really old unit which simply showed a moving blob of light on a black TV screen and let you twist some knobs to move rectangular paddle blobs of light up or down to make the moving blob bounce back and forth. There were several such 'consoles' around, and they called the games 'ping-pong' or 'hockey' etc depending mainly on how many 'paddle' blobs there were, and if there were any other 'bounce' walls. But there was nothing even remotely resembling real program code there. They didn't have any real CPUs, so the games were preprogrammed into the main controller chip.

Best regards: dlanor
12-29-2006, 06:39 AM
Jcl

About the Hard Disk accessing on bootup
Thanks, that was a great explanation. Yes, it seems that the PS2 has its very own caveats, and since I haven't attempted any coding on it yet, I hope you can understand my whole confusion around all this stuff.

About the Memory Card
You are right about the compression thing... shows I have no clue how data is accessed on memory cards on the PS2 (hadn't even heard of MagicGate encryption before till you mentioned it) and yes, I was just passing word of mouth (that's why I warned it could be utter bullshit).

About having the PC as a router
ICS does that actually, I've used it to route through internal LANs some times, as long as the output network is the one which XP uses for internet access, it'll route correctly, it's just that I don't want to have more "devices" in my living room. The PS2 and the HTPC already get on my girlfriend's nerves (that's why cabling is impossible also... she would not allow it. If she didn't pay half of the house, I'd just do it ;-) ).

But yes, I think I'll just bring the PS2 to the computer room and buy an VGA box (can you recommend one?) to connect it to a monitor with a switch I have here (and have spare switch connections to it)... this will be the simplest option, and since I don't really play with the PS2 all that much (I'm not that much of a gamer person) it'll be ok to have it here :)

About using the PS2 as the server
... yes, I meant exactly using it as the TCP/IP server, thus needing to route the incoming packets to it (something which is automatically done by the router if it's the client the one connecting). Managing a server on a PC is easy, discovering what needs to be routed is pretty easy with PC tools... doing it on the PS2 might be a much harder task if you are to route all services (then again, it may only use some TCP port and it'd all be as easy as opening a NAT translation, but I just don't know it). Was kinda thinking loud on this. I have a kind of weird network at home (with three different subnets, two of them ethernet connected, and a wireless one). Not that those three subnets are necessary for a conventional network environment at home... but I need it to test stuff on my work projects (which are sold to larger scale corporations, and I need to emulate those environments at home).

About the IR remote
Well, I don't know if it works or not, but definitely, it doesn't with the Sony official DVD remote unless your PS2 has an integrated IR receiver (eject and reset buttons in the remote will not work). This is by design on their remote (it's said on almost every store that sells it online), don't know if due to a hardware limitation.

My guess (and just a guess) is: you can turn the PS2 off by software, but you can't turn it back on unless the IR receiver is having power, and neither the PAD ports or the USB ones in the console are receiving power (and so can't work out any function on the remote) till the console is turned on. The integrated IR receiver is indeed receiving power while the console is in stand-by mode, thus allowing to turn it off and on at will.

About coming late to consoles
I had a Megadrive when I was something like... 10/11 years old (I'm 27 now), and I remember playing with the ping-pong one my uncle had when I was a kid. Since I didn't have any money and my dad was not that much fond of games, I actually only played Sonic on the console (which came bundled-in), and then forgot about the console for ages till I gave it to a friend fro his son.

Never ever had a console again till 2/3 weeks ago when I bought this second hand PS2... Actually, this was not intended.. I wanted to sell an radio-cd for my car... and as noone seemed to be interested, I saw this guy selling his PS2 and wanting to buy a radio-cd like mine, and did a change with him. Never really thought of buying a PS2... but now that I have it, I find it as something great to spend free time on it (by exploring and developing for it, not playing games.. althought that's funny for some time :) ). The bad part is, I'm in the middle of a big project ending at work, and really can't spend too much time on it... but it'll be a great thing to spend time on once everything gets calmed down at work ( :banghead: ).

Anyway, thanks again, you are being of unvaluable help with all this stuff, and your explanations are just great! (and of course, thanks for continuing the work on uLe, which is amazing).

Sorry again if any of my questions seems too much of a newbie... I'm not a programming newbie, but I'm completely new to the PS2-scene (or any console's for the matter).