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.
I've tried it with Dev2 booting now and it doesn't work. It just crashes with garbage on screen.
This garbage takes the form of 10 evenly spaced and perfectly stable vertical bars, starting with a white one at the left edge, followed by alternate black and white ones, ending with a black one at the right edge of the screen.
None of those bars are purely white or black though, as they are also mixed with random dot garbage forming rectangular patterns, with each such rectangle having a width equal to that of the bars (and aligned to them), and a height of appx 1/16 of the screen height. But the brightness of this random dot garbage is very low, probably never exceeding 15% of the white bar level.
In all of this there is nothing that resembles normal character graphics, even garbled, so it is very doubtful if any text had been displayed at the point of crashing.
It all looks rather peculiar, but trying to draw any program related conclusions from these symptoms is probably hopeless...
What I think we see here is random initialization data of the dynamic RAM cells. Many DRAMs I've seen through the years have been designed with alternating cell sequences tending to pull low and high respectively, and I think it is this that causes the black/white bars.
The above was for a clean start from an enduring standby mode.
If I make a 'warm' reset after running other programs then the above will also be mixed with graphic remnants from the preceding programs. Thus I have seen at one and the same time graphic remnants from the uLE skin and the ToxicOS skin, mixed with the black-and-white bars. Since at least one of those skin remnants is two resets 'old' by that time, I think we can assume that the crash occurred before myPS2 initialized screen.
I almost forgot to add that the program works fine when launched from uLE in a normal manner, using the same ELF in the same place and with the same config files.
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..
I'm not sure what you mean here. Since "__boot" is a partition, not a folder, it is never legal to access it as "pfs0:/__boot/". Such a usage would refer to a folder named "__boot", which is certainly not what I'm using.
Of course, it is permitted to have folder names identical to the partition names too, but I advise strongly against doing that, as it only gets confusing, and serves no functional purpose.
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/.
The generic method used by uLaunchELF is to split any full HDD path into two parts.
For the example given here, the full path to split is: "hdd0:/+ELFS/myPS2/v1.2/MYPS2_2006.02.27_ntba2.ELF" (a real example from my own HDD)
The first part split off contains the drive and partition names, like "hdd0:+ELFS", and is used for mounting the partition on a PFS mountpoint, like "pfs0:".
The second part contains all the stuff that followed after the first part, which here is "/myPS2/v1.2/MYPS2_2006.02.27_ntba2.ELF", so that is what must be appended to the PFS path, resulting in "pfs0:/myPS2/v1.2/MYPS2_2006.02.27_ntba2.ELF".
One slight complication is that there may or may not be a '/' separator between the drive spec and the partition name. uLE normally uses one, but DMS4 Dev2 does not. But for program launching uLE uses fakehost anyway, so myPS2 will never see the paths used internally by uLE.
Also, for Dev2 booting you never have to consider the case of "boot.elf" being inside any folders, since that's not implemented. It's always in the root directory of the "__boot" partition, for current implementations anyway.
I'll have to take a closer look at it after dinner.. my kids are buggin me to make supper for them.
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
I tried your method of using the myps2 partition; once again it started up with the same behavior as before bsod upon activating a skin (using ntba2 v1.2); however, both your beta versions allow me to switch skins from the hdd ...the blank character you refer to has happened before when I was loading from my usb flash drive it must have been a sector corruption since after deleting the skins folder and re-transferring back it would read and activate skins fine (this was not specific to a single skin)...
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.
I got the same thing as dlanor booting direct from dev2 (screen garbage); half the matrix logo the other half thick garbled lines. unrelated to this on both beta versions of v1.2 it will not allow me to launch elf files (freezes). this is a non-issue since I use uLaunchELF for this function, though the one problem with this is that when I want to exit myps2 I can't launch uLaunchELF
Last edited by flamingo24; 07-01-2006 at 08:42 PM.
I got the same thing as dlanor booting direct from dev2 (screen garbage); half the matrix logo the other half thick garbled lines.
It's interesting to note that results for a DMS4pro and a Matrix Infinity (which I assume you have, from your comment) both give identical results.
If you haven't already done so, could you please try the earlier beta again (it doesn't crash here, but only fails to load CNF), and report the exact strings displayed for "Load Path:" and "SetElfPath:" with Matrix Infinity. We need to know if both modchips use the same argv[0] string for Dev2 launches.
unrelated to this on both beta versions of v1.2 it will not allow me to launch elf files (freezes). this is a non-issue since I use uLaunchELF for this function, though the one problem with this is that when I want to exit myps2 I can't launch uLaunchELF
I don't get that problem here. I have no problem starting uLaunchELF from any version of myPS2, including Mike's two betas.
Since the skin implementation of myPS2 can affect both functionality and appearance, this could in fact be a skin issue. Have you tried with just the original default skin installed ? That's what I use, and it might make a difference for your setup too.
I don't get that problem here. I have no problem starting uLaunchELF from any version of myPS2, including Mike's two betas.
Since the skin implementation of myPS2 can affect both functionality and appearance, this could in fact be a skin issue. Have you tried with just the original default skin installed ? That's what I use, and it might make a difference for your setup too.
Actually, I have tried it with the default skin, and 3 different versions of myPS2. In any case I can only run some of the elfs that I have. ps2link, execftps, 3stars all seem to run. However hdl 8b, uLaunchElf 3.61, and myPS21.2 don't run. So I do see it as a bug, it's just looking at the SVN logs I see there has been some changes to the elf loading part. Which might not be completed yet.
as for dev2 booting, I spent most of tonight looking over SVN logs for elf loader but I did manage to think about it and came up with some interesting
questions..
first off hdd0:__boot/myPS2/myPS2.ELF for example.
hdd0 has to be mapped to a pfs entry in which it becomes
pfs[x]:/myPS2/myPS2.ELF but only if it's mounted. So how do we know if the mod chip has already mounted it or not. what happens if the mod chip mounted that as pfs0. From what I've read everything coming from a hard drive must be handled through the pfs file system. However what's to say the mod chip didn't simply open the elf, read it to memory and unmount the filesystem, then execute the file. I couldn't find any function to figure out what partitions are mounted. So I'll have to keep on looking.
But I have to say thank you for the support, my crash course in ps2 development is turning out to be very enjoyable lol.
If you haven't already done so, could you please try the earlier beta again (it doesn't crash here, but only fails to load CNF), and report the exact strings displayed for "Load Path:" and "SetElfPath:" with Matrix Infinity. We need to know if both modchips use the same argv[0] string for Dev2 launches.
I tried the earlier beta and it said there was no config.dat present, I did'nt remember the exact string so I relaunched from dev2
the dms team were the first to release a modchip with dev support (dms3) all other modchips I think model after them for there dev implementation.
Since the skin implementation of myPS2 can affect both functionality and appearance, this could in fact be a skin issue. Have you tried with just the original default skin installed ? That's what I use, and it might make a difference for your setup too.
this was my bad; at first I tried this and modified the config.dat placed another fresh myps2 installation (ntba2 v1.2-as is) in a different area on my hdd, replaced the myps2.elf with the beta myps2 elf and relaunched...I had the same issue launching ule (v3.79) it was at this point I realized I have only attempted to test this with the ule.elf. I then went to the original installation relaunched under the macos skin and applied the partition where I store all my elf files used with ule, went over to myprograms and launched super mario war and it worked I jumped the gun alittle, still the only elf I really want to launch from myps2 freezes
edit: I do not think this is at all a ule problem; myps2 has flakey elf launching capabilities; also I don't think this has anything to do with the beta's. now that I think about it I recall back when I used myps2 to launch elf files it did take issue with some elfs and others it did not, it's probably something simular to what sms had issues with launching certain elf files on exit...
Last edited by flamingo24; 07-02-2006 at 12:25 PM.
ok, sorry I couldn't work on this for the last 6 days. I had to fight my kids to get my ps2 back.. seems they love the custom modded uLaunchElf and HDL that I created for them.
Anyway I'm releasing a new beta for dev2 booting. I can't test it but all it does is turn hdd0:/x to pfs0:/ when booting off hard drive.
When booted you should see.
Code:
Load Path:hdd0:__boot/boot.elf
SetElfPath:pfs0:/
That means myPS2 will search for it's configure file where ever you booted myPS2 from. So if you boot from hdd0:__boot/myPS2.ELF you should also have the hdd0:/__boot/CONFIG.DAT which becomes pfs0:/CONFIG.DAT.
I've also removed all references to loading ps2link. So this will work with a original myPS2 1.2 setup. So if you tried my other beta's and added the language and skins files you will need to revert them for this to load. I wanted to remain as original as possible incase this does work for people.
Hopefully this actually works, because I can't test it. I didn't even know mod chips could boot code directly when I bought my mod chips, so now I'm thinking of going out and getting a couple DMS4 chip instead of the cheap chips I did buy (duo2 GT) which don't support dev2 booting. it's just that it will be several weeks before I can even consider that, I'm in the middle of negotiating a new job for myself.
Also thank you everyone for the great support. I hope this works so I can at least help out the ps2 development scene. Not to mention, I'd love to keep helping out with coding where ever I'm needed
I'm glad to see your still working on a solution I tried booting from dev2 with the latest beta the results are simular to the 2nd beta, newest version shows the bottom half the matrix logo the top half alternates (solid pattern) between thick black and thick white lines.
I'm glad to see your still working on a solution I tried booting from dev2 with the latest beta the results are simular to the 2nd beta, newest version shows the bottom half the matrix logo the top half alternates (solid pattern) between thick black and thick white lines.
Thanks, I'm trying.. it's just I don't have much time between this interview process and the kids wanting to play with the only ps2 that has a hard drive.
It sounds like for some reason the gs isn't getting setup properly (just my guess that the gs is already initialized and myPS2 isn't resetting it, simply because it seems like the matrix logo is a texture left over in video memory that should have been erased). Thanks also to the great description given by dlanor.
I'll have to take a closer look at it when I get back. Although I don't really know much about the gs yet. Hopefully it's not something I need a mod chip to be able to get working. I just don't have the time to look into it this weekend as i'm in the middle of planing a trip for an interview on Monday.