Solution to "Loading GUI String Table...FAILED"

Quote:

---

Originally Posted by E P

Dlanor, I should now be able to help you to some capacity.:) All my tools are still on this XP machine so I'll have to shift Slax over to a different PC so I can continue to use this one for development.

---

Good, but I assume you'll have both those PCs active in your LAN then. This may help untangle some of the problems you had earlier, not being able to see Windows shares via Samba on myPS2.

Quote:

---

Anyway I never did compile myPS2 but maybe now I should try to see if it's a packer issue as Thumps seems to believe.

---

I think you misunderstood that reference. I think he was just talking about the normal storage space problem when using large unpacked binaries on a small 8MB memory card.

Best regards: dlanor

Quote:

---

Originally Posted by dlanor

I'm not so sure. At this point the IOP state is unknown, set up somehow by the modchip, with details unknown to us, and therefore not to be relied on (as chip manufacturers may differ).

---

ok, I didn't consider the IOP state at all. Although from what I have causually gathered, most applications stick libraries for io into it. hense the IOP name I'd guess lol. However if this version of myPS2 works for you, we can begin some furture tests.

Quote:

---

I made some experiments with uLE, trying to load CNF from HDD at this stage, but ran into some odd problems. This often happens when trying to load drivers before a necessary IOP reset (specified in the loaded uLE CNF), as the PS2SDK drivers are mostly allergic to being loaded twice by the same EE application... :(

---

It makes sense there would be issues if you loaded the same module twice. If the loading code doesn't check that the module isn't already loaded you could end up with two identical functions at different addresses.

Quote:

---

I disagree. It should still be possible to recognize all possible boot methods, as long as they all use argv[0] for the launch path. For the case of a DMS4pro chip (which I have), the Dev2 boot method is testable as:
"booted_Dev2 = !strcmp(argv[0], "hdd0:__boot/boot.elf");"

NB: I may have missed a slash separator there, as I can't check the debug info right now.

---

I think the point I was attempting to make was missed here. The source for myPS2 didn't test for hdd0: in argv. Therefore it didn't know it was booting off hard drive.

When myPS2 called the SetBootMode function to figure out how it was being booted it only checked for host, mc, usb and cd. If your modchip calls it as hdd0:__boot/boot.elf, myPS2 wouldn't know it's booting from hard drive.

I've added a test for this to the current code. Hopefully it might help in the dev2 booting. At the very least we can gather some more information, because I've added the argv[0] to the information myPS2 displays at start up. if we can gather this information from when it doesn't work we might be able to figure out why it's not working.

Just look for the following messages right when myPS2 boots.

Load Path:
SetElfPath:

Those two variables set the stage for how myPS2 attempts to boot.

Quote:

---

But that's really an unrelated issue. I don't see how this affects recognition of boot methods.

---

Actually it was meant as more of a warning :) although it's available as a configure option and off by default. I've included the modified language fils and default theme file for the network settings to turn it back on if you want.

Quote:

---

Originally Posted by dlanor

Good, but I assume you'll have both those PCs active in your LAN then. This may help untangle some of the problems you had earlier, not being able to see Windows shares via Samba on myPS2.

---

Yeah that's what I plan to also do especially since I managed to get both machines running slax to test smb. I had a one-way connection going so the shares do work properly with samba. XP and Slax networking should be far easier than dealing with Slax and 98. Network changes to Windows 98 SE can become very tedious with all the rebooting usually involved.

Anyway I used Slax to burn a Slax CD to run it on another machine and it worked. Now with my XP machine I have access to all the ps2dev tools and a more comfortable environment to work from.

Quote:

---

Originally Posted by dlanor

I think you misunderstood that reference. I think he was just talking about the normal storage space problem when using large unpacked binaries on a small 8MB memory card.

---

Oh, yeah that was it.

Quote:

---

Originally Posted by flamingo24

there is another issue switching skins while running myps2 from the hdd, when I try and switch a skin running from my ps2 hard drive it drops to a bsod; :chinscrat if you can get myps2 to boot directly from dev2 this issue will need to be remedied.

---

ok, if I get any positive feedback about the myPS2 I posted, I'll take a closer look at the skin switching. Cause we have to keep those skins. BTW those skins in your sig are amazing. Thank You. I have found that trying to switch skins while playing an mp3 is a no no. Although I haven't had any problem switching skins from hard drive as all my myPS2 stuff is stored on the hard drive.

Quote:

---

I took a course in cisco systems and the actual use of samba is really not difficult weather it's through linux or windows (I have managed to use the myps2 samba without the imhost simply by changing the samba.xml from computer name to ip address after making some adjustments to my router settings) my in house systems are networked with windows since I play alot pc games ;)

---

Yeah that's exactly what I did two. I just use ip addresses in my samba.xml file even though I do have a wins server on my network. I just found that myPS2 had issues with my dns and figured why bother trying to poke around I know the ip addresses off by heart.

Mike

Quote:

---

Originally Posted by E P

Well it wasn't as hard as I had earlier thought. In my networking computer science class, our team members were too afraid to deal with linux let alone Samba. I have done things with linux to some degree but only command based things like Oracle. Never really got to play around with it until now. I really wanted to get into linux the right way with Fedora but Slax does quite nicely. It's great to be able to take an OS with you with Slax on a stick.

---

it's amazing how flexible Linux is sometimes. When I first used Linux the only none open source appliacation available was a early version of Netscape. There wasn't any samba support so I had to use ftp or appleshare to transfer files. Now my Linux system offers full samba support including domain logins.

Quote:

---

Dlanor and I use the precompiled binaries of ps2packer from here. Although now that I have thought about it maybe our older ps2dev environment may be a factor. I don't know but I guess the only way to find out is to compile it myself. I didn't really care before since SMB didn't work but now that I got it working with Slax everything has changed.:)

---

Darn, I wish I read that earlier, I ended up having a heck of a fight to get ps2-packer to compile. There was some issues with my native cygwin trying to compile it. Seems my version of cygwin didn't really like being compiled with ee code. Although thankfully in the end I won the fight and managed to get the whole ps2-packer installed and running. I know my ps2dev environment is taken directly off SVN. It's been updated a few times but still requires the patches included with myPS2.

Mike

Quote:

---

Originally Posted by Thumps

ok, I didn't consider the IOP state at all. Although from what I have causually gathered, most applications stick libraries for io into it. hense the IOP name I'd guess lol.

---

That is the main purpose of it, but IOP memory is managed independently from EE memory, and there is no real standard for what the IOP contains when an application starts. Normally it does contain some basic drivers, including the one through which the application ELF was loaded, but not even that is certain, as the launcher may have made an IOP reset before passing control to the ELF code.

Quote:

---

However if this version of myPS2 works for you, we can begin some furture tests.

---

It does work, including Samba access. But here's something really weird: After making that test I decided to make another, whose results left me flabbergasted.

:crazy:
The test version I recompiled back in March also works now.
With full Samba support!
:crazy:

I've tested that ELF, and variants of it, dozens of times before, without any Samba success at all. But now, all of a sudden, it works perfectly. I just don't get it...


----- snip ----- re: Problem with reinitialization of drivers after IOP reset

Quote:

---

It makes sense there would be issues if you loaded the same module twice. If the loading code doesn't check that the module isn't already loaded you could end up with two identical functions at different addresses.

---

That's not the problem. An IOP reset cleans out the old IOP functions, so at that point you have to reload some IOP modules to be able to do anything. This includes the drivers to all IO devices you want to use.

The problem is that the PS2SDK libs for the EE processor will malfunction for the new incarnation of the IOP modules, since those EE libs only allow initializing a module once, and they have no idea that IOP reset can ever be performed. So most attempts to repeat initilization leads to no response at all (device won't work at all), or to suicidal insanity (device malfunctions badly, possibly crashing the application).

We've had to solve this problem for some devices, as we must be able to read CNF files before deciding whether or not to perform IOP reset in uLaunchELF. Those changes are included in our source releases. But for some other devices our changes don't work, such as the gamepad. If we use any of the pad access functions before performing an IOP reset, then the new pad initialization thereafter will malfunction. (And we still don't know exactly why...)

Quote:

---

I've added a test for this to the current code. Hopefully it might help in the dev2 booting. At the very least we can gather some more information, because I've added the argv[0] to the information myPS2 displays at start up. if we can gather this information from when it doesn't work we might be able to figure out why it's not working.

Just look for the following messages right when myPS2 boots.

Load Path:
SetElfPath:

Those two variables set the stage for how myPS2 attempts to boot.

---

Unfortunately that's not much help with some DMS4 launch methods.

I just tried launching your ELF from the ToxicOS browser (works fine to launch uLE), but it just resulted in a garbled screen (with no sign of normal myPS2 output). This happens for any myPS2 ELF, so it's not just yours...

Trying it with the Dev2 launcher works better, but the result is still wrong.
"Load Path: hdd0:__boot/boot.elf"
"SetElfPath: hdd0:__boot/"
"Failed loading CONFIG.DAT"
"CONFIG.DAT must be"... and so on

Naturally, CONFIG.DAT was present beside the ELF, together with the usual myPS2 folder tree, so that was never the real problem. The problem is that you apparently attempt to use "hdd0:__boot/" as a valid path for accessing files, which it isn't. It can only be used for mounting. All file access must be made through PFS.

Best regards: dlanor

@Thumps

I finally got a chance to test your myps2 beta; now it seems I can switch skins running from the hdd with this version (although it was not a priority in this release) :) the only trouble I ran into was after boot and making one skin change the second attempt will freeze at the activate skin dialog. this is an improvement from before since I am able to at least switch skins running from the hdd :D however, I did notice if I save the myps2 settings after switching to another skin it does not freeze! :dance:

samba works, still it doesnt seem to want to boot directly from dev2; since this version allows me to switch skins (hdd) I'm sticking with your beta...thanks...:cheers:

Quote:

---

Originally Posted by dlanor

Unfortunately that's not much help with some DMS4 launch methods.

I just tried launching your ELF from the ToxicOS browser (works fine to launch uLE), but it just resulted in a garbled screen (with no sign of normal myPS2 output). This happens for any myPS2 ELF, so it's not just yours...

Trying it with the Dev2 launcher works better, but the result is still wrong.
"Load Path: hdd0:__boot/boot.elf"
"SetElfPath: hdd0:__boot/"
"Failed loading CONFIG.DAT"
"CONFIG.DAT must be"... and so on

Naturally, CONFIG.DAT was present beside the ELF, together with the usual myPS2 folder tree, so that was never the real problem. The problem is that you apparently attempt to use "hdd0:__boot/" as a valid path for accessing files, which it isn't. It can only be used for mounting. All file access must be made through PFS.

---

I think you hit it right on the nail there.. it seems to be a chicken or egg problem. myPS2 needs to load it's config file to start up, let me see if I can't work up something newer to test.

ok here is a newer version that should check for being booted as hdd0: and set the elf path to pfs0:/ I'm not sure how well that'll work cause I can't test it. but it's worth a try.

Mike

Quote:

---

Originally Posted by flamingo24

@Thumps

I finally got a chance to test your myps2 beta; now it seems I can switch skins running from the hdd with this version (although it was not a priority in this release) :) the only trouble I ran into was after boot and making one skin change the second attempt will freeze at the activate skin dialog. this is an improvement from before since I am able to at least switch skins running from the hdd :D however, I did notice if I save the myps2 settings after switching to another skin it does not freeze! :dance:

samba works, still it doesnt seem to want to boot directly from dev2; since this version allows me to switch skins (hdd) I'm sticking with your beta...thanks...:cheers:

---

You're welcome, I'm glad it at least works better for you. I've been working with a few of the skins myself. It appears some act strange when loading. Although I haven't had any crashes while loading them from hard drive. I have found that some don't like to be loaded the BeOS one specifically can not be loaded from the default skin. All it does is add a blank character to the themes list and returns to the current skin. Although I don't think it's a hard drive problem per say. I have all my myPS2 files in the myPS2 partition and simply boot into that using the options

Code:

---

hdd_boot_part                = hdd0:+MYPS2
hdd_boot_path                = /

---

that way with the exception of the BeOS skin, I can switch skins all I want and haven't had a single crash.

hope that helps
Mike

Quote:

---

Originally Posted by dlanor

Unfortunately that's not much help with some DMS4 launch methods.

I just tried launching your ELF from the ToxicOS browser (works fine to launch uLE), but it just resulted in a garbled screen (with no sign of normal myPS2 output). This happens for any myPS2 ELF, so it's not just yours...

Trying it with the Dev2 launcher works better, but the result is still wrong.
"Load Path: hdd0:__boot/boot.elf"
"SetElfPath: hdd0:__boot/"
"Failed loading CONFIG.DAT"
"CONFIG.DAT must be"... and so on

Naturally, CONFIG.DAT was present beside the ELF, together with the usual myPS2 folder tree, so that was never the real problem. The problem is that you apparently attempt to use "hdd0:__boot/" as a valid path for accessing files, which it isn't. It can only be used for mounting. All file access must be made through PFS.

---

Quote:

---

Originally Posted by Thumps

I think you hit it right on the nail there.. it seems to be a chicken or egg problem. myPS2 needs to load it's config file to start up, let me see if I can't work up something newer to test.

ok here is a newer version that should check for being booted as hdd0: and set the elf path to pfs0:/ I'm not sure how well that'll work cause I can't test it. but it's worth a try.

---

ok I just thought of something really dumb.. if hdd0:__boot/ gets mounted as pfs0:/ then trying to access pfs0:/__boot/ is going to fail.. normally that's not a problem I could just replace the path with pfs0:/ but there is a problem if someone tries to stick myps2 inside a folder in a partition say hdd0:__boot/myps2/ Then I'll need to switch it to pfs0:/myps2/. I'll have to take a closer look at it after dinner.. my kids are buggin me to make supper for them.

Mike