PSXlauncher WITHOUT FreeMCboot? (Swaps, SPCH-90001, Ule)

[dlanor]

Okay, I've tested a bit more.

You don't have to reboot Ule. Just remove your mod after you put in the psx disc and put it back in. Then launch ps2disc.

Yes, with mod removed the combination of normal PS2 behaviour and the "Disc control" feature of uLE should ensure a new media scan whenever a disc is replaced without sensor blocking.

The tip about relaunching uLE was part of my attempt to make it work with your original 'always blocking' sensor mod. But I think uLE might need to borrow some of the code from DVDlauncher to do that right, as that program obviously could enforce a new media scan at any time, regardless of sensor mod state.

NO REGION RESTRICTIONS!!!

Well yes, but to the rest of us that is very old news.

The regional boot restriction is part of the mechacon's media scan work, so once you bypass that to make a backup work you have also bypassed the region limitation. And that is also why all the PS2 backup game loaders have no problem with it, since they don't use physical discs and therefore don't involve the mechacon (at least not the real one).

EDIT: Ps2 cannot be booted via swap in Ule. Thoguh PS1 can on these models (except for the additional swap that was discussed earlier on early ps2 models)

I never expected uLE to be a universal swap tool, nor is it intended to be.
It is just a nice side effect that it can be used this way for PS1 games with most models.

Btw:
About HDTV modes as well as the NTSC/PAL switching, you really should look into the program GSM (Graphics Synthesizer Modeselector) and how it can be used before launching your games, in order to force them to run in a good video mode.

It doesn't allow every game to run in any existing video mode, as there are some compatibility issues. But it allows nearly all games to be forced into either PAL or NTSC, and most games can also be forced to run in at least one HDTV mode, and usually with more to choose from. (VGA modes are also possible, with a suitable VGA adaptor for the component outputs.)

It even has a special trick to enforce PAL or NTSC mode for PS1 mode, though this is done by first switching to a related HDTV mode, which the PS1 driver then changes into either PAL or NTSC when it activates. That leaves the picture looking very odd in the interval between choosing mode in GSM, until you launch the PS1 game from uLE (as relaunched by GSM). But that is no real problem if you have configured uLE properly so you can handle the launch even when 'half blind' like this.

You will find the GSM project in the main "PS2 Homebrew/Dev & Emu" forum, in a thread beneath the list of the many project subforums. Since the GSM stuff is a single thread it doesn't merit a separate subforum, though it is a separate project, originally created by doctorxyz but now mostly maintained by me. (He got some hardware problems preventing his active PS2Dev participation for a while.)

Best regards: dlanor

[personuser]

Yes, with mod removed the combination of normal PS2 behaviour and the "Disc control" feature of uLE should ensure a new media scan whenever a disc is replaced without sensor blocking.

Ahh, yes, also, I've tried swapping the disc to my interactive CD vol 3 before launching ulaunch from the swap, and it loads, but it still finds the PS2 dvd, so yeah.

Btw:
About HDTV modes as well as the NTSC/PAL switching, you really should look into the program GSM (Graphics Synthesizer Modeselector) and how it can be used before launching your games, in order to force them to run in a good video mode.

hmm, interesting...

It doesn't allow every game to run in any existing video mode, as there are some compatibility issues. But it allows nearly all games to be forced into either PAL or NTSC, and most games can also be forced to run in at least one HDTV mode, and usually with more to choose from. (VGA modes are also possible, with a suitable VGA adaptor for the component outputs.)

It even has a special trick to enforce PAL or NTSC mode for PS1 mode, though this is done by first switching to a related HDTV mode, which the PS1 driver then changes into either PAL or NTSC when it activates. That leaves the picture looking very odd in the interval between choosing mode in GSM, until you launch the PS1 game from uLE (as relaunched by GSM). But that is no real problem if you have configured uLE properly so you can handle the launch even when 'half blind' like this.

I've handled SOME launches COMPLETELY blind...mainly for a pal-only game I bought by accident a month back (i think it was a PAL viewtiful joe) NO idea how a video game, let alone a PAL video game, got into a farmer's market in my hick town, but it was cheap (about $2.57) so I got it, and after learning I needed my swap to launch it, the screen went black but there was still sound. I fiddled around with the directions and X button until the picture came on and the text was in german. I ripped it into an ISO with IMGburn and tested it on PCSX2, and there was 2 menus, language and 50/60HZ. I backed it up and wrote the buttons I needed to press to get it 60hz and english on the backup, and I've been fine from there.

Enough of my boring story. Anyway, I have square configured to MISC/PS2DISC already. What do you mean by "related HDTV mode? Do you mean throwing in the components? (which CAN display Ule) OR actually changing something on my TV? It's a sylvania 32" with a built-in DVD player.

Otherwise, I boot "GSM" as an ELF, set the console to turn PAL into NTSC somehow, then it boots itself back into Ule, which looks odd, then I perform my swap, use misc/ps2disc and it loads the psx backup in 480p?

You will find the GSM project in the main "PS2 Homebrew/Dev & Emu" forum, in a thread beneath the list of the many project subforums. Since the GSM stuff is a single thread it doesn't merit a separate subforum, though it is a separate project, originally created by doctorxyz but now mostly maintained by me. (He got some hardware problems preventing his active PS2Dev participation for a while.)

Best regards: dlanor

I've seen the topic floating around the uncategorized section of the PS2 forum. Is there any visual tutorials on exactly how you HD-ify PS1 backups there? I've looked for a while but couldn't spot one.

[dlanor]

What do you mean by "related HDTV mode? Do you mean throwing in the components?

I mean that we can't just tell GSM to enforce NTSC or PAL, because GSM itself will 'die' when the PS1 driver activates, and having enforced NTSC or PAL before that had NO long-term effect. The PS1 driver still switched to what it 'wanted' to use, either based on the disc or based on the console region.

But after some experiments we discovered that if GSM first enforces an HDTV mode before being killed by the PS1 driver, then this affects what non-HDTV mode the PS1 driver will choose to use.

HDTV 480p in GSM => NTSC 480i in PS1 driver (with 640x448 OR 320x224 used by games)
HDTV 576p in GSM => PAL 576i in PS1 driver (with 640x512 OR 320x256 used by games)

Another problem is that it is useless to choose the normal 480p or 576p settings, as those have screen positioning and sizing settings as appropriate for those HDTV modes, which would cause the visible game screen to be outside of the visible screen area when PS1 driver has switched the physical mode to PAL or NTSC (but without properly adjusting offsets)

Because of this GSM contains special preset choices for PS1 modes, which activate a suitable HDTV mode, but with screen positioning and sizing settings suitable for PAL/NTSC, so that the PS1 screen will be properly visible after the PS1 driver has activated.

But until that activation is complete, the screen will look very odd even on an HDTV set, and on an SDTV set it will probably just show black until that completion.

When you use the PS2Disc command of uLE, and it attempts to launch the game, the first thing you will see in PAL/NTSC is the PS2Logo at twice the normal scale (init still not quite complete), but then as the game itself starts it should come up with proper centering and scale (except in some cases when scale remains wrong, for unknown reasons...)

Otherwise, I boot "GSM" as an ELF, set the console to turn PAL into NTSC somehow, then it boots itself back into Ule, which looks odd, then I perform my swap, use misc/ps2disc and it loads the psx backup in 480p?

No. We can't do that with PS2 in PS1 mode, since that kills GSM.
We can only use GSM to cause a PAL/NTSC choice, indirectly via HDTV modes in GSM as described above.

The only way to really use HDTV modes inside a PS1 game is to run it through the PS2PSXe emulator, as this works like other PS2 homebrews so that it can coexist with the resident routines of GSM without killing them (unlike the Sony PS1 driver).

And as yet we do not have a full release of PS2PSXe, as the current version available for download is just a preview, far from the full version we are all waiting for. (for example, that preview has no sound implementation at all...)


Edit:
Hmmm... This is really funny.
Apparently some of the changes that we made to GSM recently had more far-reaching effects than I had at first realized, with regard to our influence over the PS1 driver.

In my latest experiment I was able to make changes to the video mode in ways that never worked before, without going through the HDTV modes, like we always had to do before.

Some users have reported similar results too though I wasn't (and isn't) quite sure what to make of it. This definitely merits more experimentation as it now appears that we can achieve good results with PS1 games even without using those 'intermediate' HDTV modes to do it.

Best regards: dlanor

[personuser]

I mean that we can't just tell GSM to enforce NTSC or PAL, because GSM itself will 'die' when the PS1 driver activates, and having enforced NTSC or PAL before that had NO long-term effect. The PS1 driver still switched to what it 'wanted' to use, either based on the disc or based on the console region.

But after some experiments we discovered that if GSM first enforces an HDTV mode before being killed by the PS1 driver, then this affects what non-HDTV mode the PS1 driver will choose to use.

HDTV 480p in GSM => NTSC 480i in PS1 driver (with 640x448 OR 320x224 used by games)
HDTV 576p in GSM => PAL 576i in PS1 driver (with 640x512 OR 320x256 used by games)

Another problem is that it is useless to choose the normal 480p or 576p settings, as those have screen positioning and sizing settings as appropriate for those HDTV modes, which would cause the visible game screen to be outside of the visible screen area when PS1 driver has switched the physical mode to PAL or NTSC (but without properly adjusting offsets)

Because of this GSM contains special preset choices for PS1 modes, which activate a suitable HDTV mode, but with screen positioning and sizing settings suitable for PAL/NTSC, so that the PS1 screen will be properly visible after the PS1 driver has activated.

But until that activation is complete, the screen will look very odd even on an HDTV set, and on an SDTV set it will probably just show black until that completion.

When you use the PS2Disc command of uLE, and it attempts to launch the game, the first thing you will see in PAL/NTSC is the PS2Logo at twice the normal scale (init still not quite complete), but then as the game itself starts it should come up with proper centering and scale (except in some cases when scale remains wrong, for unknown reasons...)

No. We can't do that with PS2 in PS1 mode, since that kills GSM.
We can only use GSM to cause a PAL/NTSC choice, indirectly via HDTV modes in GSM as described above.

The only way to really use HDTV modes inside a PS1 game is to run it through the PS2PSXe emulator, as this works like other PS2 homebrews so that it can coexist with the resident routines of GSM without killing them (unlike the Sony PS1 driver).

And as yet we do not have a full release of PS2PSXe, as the current version available for download is just a preview, far from the full version we are all waiting for. (for example, that preview has no sound implementation at all...)


Edit:
Hmmm... This is really funny.
Apparently some of the changes that we made to GSM recently had more far-reaching effects than I had at first realized, with regard to our influence over the PS1 driver.

In my latest experiment I was able to make changes to the video mode in ways that never worked before, without going through the HDTV modes, like we always had to do before.

Some users have reported similar results too though I wasn't (and isn't) quite sure what to make of it. This definitely merits more experimentation as it now appears that we can achieve good results with PS1 games even without using those 'intermediate' HDTV modes to do it.

Best regards: dlanor

You've lost me a bit.

So, you boot a gsm elf, activate the ps1 settings and set it to 480p/480i (for a NTSC DTV) (isn't ps1 480i already?), go back to the odd-looking Ule, swap, and misc/ps2disc and THEN the ps2 logo looks fat like windows in safe mode, THEN the ps1 driver starts in better quality?

But a new edit makes it possible to skip most of that crap and just run it?

I'm not a really dumb guy, but some layman's terms would be nice here if I'm not getting it. Thanks.

PU

[dlanor]

You've lost me a bit.

So, you boot a gsm elf, activate the ps1 settings and set it to 480p/480i (for a NTSC DTV) (isn't ps1 480i already?),

NTSC PS1 and PS2 modes are theoretically 480i, just like PAL PS1 and PS2 modes are theoretically 576i. But in practice these consoles can only use 448 and 512 lines respectively for NTSC and PAL. And in non-interlaced NTSC and PAL they only use half of that, so 224 and 256 lines.

However, trying to switch between PAL and NTSC directly did not work properly with the older GSM versions, as the PS1 driver then reset the mode in a way we could not fix, except by using the workaround of those HDTV modes to fool it.

go back to the odd-looking Ule, swap, and misc/ps2disc and THEN the ps2 logo looks fat like windows in safe mode, THEN the ps1 driver starts in better quality?

No. Not in much better quality as HDTV modes are not possible there, that was all just a trick to gain control over the PAL/NTSC choice, and the main reason for doing this is usually to make an NTSC game display correctly on a PAL console, where the PS1 driver will want to launch it in PAL mode (giving big black borders) if not tricked by GSM.

But a new edit makes it possible to skip most of that crap and just run it?

Not quite. But the new GSM version allows us to choose a proper NTSC or PAL setting for enforcing, so we can avoid having to use the HDTV trick, which would leave us half-blind during part of the game boot. And a proper mode with normal visibility makes the process much simpler.

Just launch GSM, press a preset button to set the mode you want, then press the exit combo to relaunch uLE where you then use PS2Disc to launch the game, with normal visibility all the way.

I will need to make a new GSM release before those new methods can be available as built-in preset modes. But even now they can be set manually, and saved in the user defined mode slots.

I'm not a really dumb guy, but some layman's terms would be nice here if I'm not getting it.

Sorry, the whole thing really was needlessly complicated by me bringing up a mess of old and new methods all mixed together. I suggest you just download the program and play around with it. It's not all that hard to get the hang of it that way.

The GSM releases are available in the first post of of the thread reached through this link (GS Mode Selector: Development & Feedback).

Best regards: dlanor

[personuser]

NTSC PS1 and PS2 modes are theoretically 480i, just like PAL PS1 and PS2 modes are theoretically 576i. But in practice these consoles can only use 448 and 512 lines respectively for NTSC and PAL. And in non-interlaced NTSC and PAL they only use half of that, so 224 and 256 lines.

However, trying to switch between PAL and NTSC directly did not work properly with the older GSM versions, as the PS1 driver then reset the mode in a way we could not fix, except by using the workaround of those HDTV modes to fool it.

No. Not in much better quality as HDTV modes are not possible there, that was all just a trick to gain control over the PAL/NTSC choice, and the main reason for doing this is usually to make an NTSC game display correctly on a PAL console, where the PS1 driver will want to launch it in PAL mode (giving big black borders) if not tricked by GSM.

Not quite. But the new GSM version allows us to choose a proper NTSC or PAL setting for enforcing, so we can avoid having to use the HDTV trick, which would leave us half-blind during part of the game boot. And a proper mode with normal visibility makes the process much simpler.

Just launch GSM, press a preset button to set the mode you want, then press the exit combo to relaunch uLE where you then use PS2Disc to launch the game, with normal visibility all the way.

I will need to make a new GSM release before those new methods can be available as built-in preset modes. But even now they can be set manually, and saved in the user defined mode slots.

Sorry, the whole thing really was needlessly complicated by me bringing up a mess of old and new methods all mixed together. I suggest you just download the program and play around with it. It's not all that hard to get the hang of it that way.

The GSM releases are available in the first post of of the thread reached through this link (GS Mode Selector: Development & Feedback).

Best regards: dlanor

Okay, so I set up GSM, but I can't find a way to tell it to boot an .elf (of Ule, on the MC as BOOT.elf (or on the USB stick as SMBOOT0.elf). I even got the .cnf from the BOOT folder in the MC it saved it to, but it looks like this:

GSM_CNF_version = v0.23s2
Option_1 = Default
Option_2 = 0
exit_option = -1
User_Index = 0
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 1
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 2
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 3
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 4
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 5
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 6
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 7
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 8
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 9
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 10
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 11
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 12
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 13
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 14
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0
User_Index = 15
interlace = 0
mode = 0
field = 0
display = 0
syncv = 0
smode2 = 0

So, if I can, where in there can I add .elfs in directories?

Thanks.

[dlanor]

Okay, so I set up GSM, but I can't find a way to tell it to boot an .elf (of Ule, on the MC as BOOT.elf (or on the USB stick as SMBOOT0.elf). I even got the .cnf from the BOOT folder in the MC it saved it to, but it looks like this:

GSM_CNF_version = v0.23s2
Option_1 = Default
Option_2 = 0
exit_option = -1

That "exit_option" value means that the user (yep, that's you) has never used the command to toggle beween the various exit options, so it remains in the initial unset position, as indicated by the -1 value.

Start up GSM again, and keep it in a normal mode so you see all the text. And then look at the bottom-most text lines on screen.

The bottom one shows the button combo command [L2]+[R2] you use to save CNF file.

But the three lines above that deal with the 'Exit Options:'. The way we illustrate it may seem a little cryptic, but is intended to show the following two commands:

[Start]+[DPad_Up] => Step up through the list of 'Exit option' alternatives (wrapping at end)
[Start]+[DPad_Down] => Use the currently set exit option (launch either an elf or FMCB)

The elfs to load can not be freely chosen and their path is not in the CNF file.
The only thing related to it is the 'exit_option' index value, which interpreted as follows:

	{	{ 0, "PS2 BROWSER",	"PS2 BROWSER"},
		{ 1, "DEV1       ",	"BOOT/BOOT.ELF\0"},
		{ 2, "HDLoader   ",	"BOOT/HDLOADER.ELF\0"},
		{ 3, "PS2LINK    ",	"BWLINUX/PS2LINK.ELF\0"}
	}

Unlike the others, the first of those entries does not represent a normal elf launch from MC, but instead represents the boot sequence used to relaunch either the Sony Browser (if not using FMCB) or the FMCB menu/Browser.

The elf paths of the other choices are hardcoded inside the GSM elf, so they are not subject to configuration.

So what you need to do in order to change GSM so as to exit to uLE (assuming that is your "mc0:/BOOT/BOOT.ELF" file) is to proceed as follows:

1: Start GSM and push some button to reach its main screen.
2: Press the combo [Start]+[DPad_Up] once to change "Exit to NONE" into "Exit to PS2 Browser"
3: Press the combo [Start]+[DPad_Up] again to change that string into "Exit to DEV1"
4: Press the combo [L2]+[R2] to save the changed setting to CNF

And from now on you can exit from GSM by launching uLE when you press the combo [Start]+[DPad_Down]

Best regards:dlanor

[personuser]

That "exit_option" value means that the user (yep, that's you) has never used the command to toggle beween the various exit options, so it remains in the initial unset position, as indicated by the -1 value.

Start up GSM again, and keep it in a normal mode so you see all the text. And then look at the bottom-most text lines on screen.

The bottom one shows the button combo command [L2]+[R2] you use to save CNF file.

But the three lines above that deal with the 'Exit Options:'. The way we illustrate it may seem a little cryptic, but is intended to show the following two commands:

[Start]+[DPad_Up] => Step up through the list of 'Exit option' alternatives (wrapping at end)
[Start]+[DPad_Down] => Use the currently set exit option (launch either an elf or FMCB)

The elfs to load can not be freely chosen and their path is not in the CNF file.
The only thing related to it is the 'exit_option' index value, which interpreted as follows:

	{	{ 0, "PS2 BROWSER",	"PS2 BROWSER"},
		{ 1, "DEV1       ",	"BOOT/BOOT.ELF\0"},
		{ 2, "HDLoader   ",	"BOOT/HDLOADER.ELF\0"},
		{ 3, "PS2LINK    ",	"BWLINUX/PS2LINK.ELF\0"}
	}

Unlike the others, the first of those entries does not represent a normal elf launch from MC, but instead represents the boot sequence used to relaunch either the Sony Browser (if not using FMCB) or the FMCB menu/Browser.

The elf paths of the other choices are hardcoded inside the GSM elf, so they are not subject to configuration.

So what you need to do in order to change GSM so as to exit to uLE (assuming that is your "mc0:/BOOT/BOOT.ELF" file) is to proceed as follows:

1: Start GSM and push some button to reach its main screen.
2: Press the combo [Start]+[DPad_Up] once to change "Exit to NONE" into "Exit to PS2 Browser"
3: Press the combo [Start]+[DPad_Up] again to change that string into "Exit to DEV1"
4: Press the combo [L2]+[R2] to save the changed setting to CNF

And from now on you can exit from GSM by launching uLE when you press the combo [Start]+[DPad_Down]

Best regards:dlanor

Kay, that's what DEV1 is. Thanks Dlanor.

Are you guys ever thinking of adding in a command that boots an ELF from the USB in there? (like mass:\BOOT\BOOT.ELF) and how hard would it be to implement? It would save a lot of space on those 8-mib memcards

EDIT: Tried to launch FCEU with it, and it only covered a third of the screen vertically. This is in 480p and 720p
Same happens to sms, pvcs, infoGB...but not SNES...odd...

Any way to fix the other emus?

EDIT: when running a game snes is only a third of the screen. why is this caused?

Also, the TV shows 480i...remember when I was talking about people having trouble with swaps and 480p? I'm pretty sure this was the trouble they had.

[dlanor]

Are you guys ever thinking of adding in a command that boots an ELF from the USB in there? (like mass:\BOOT\BOOT.ELF) and how hard would it be to implement?

I guess we could do that, embedding the same drivers used for uLE.

It would save a lot of space on those 8-mib memcards

Would it really ?

Personally I want my main tools to work independently of any USB drive that may get mislaid, so booting uLE from MC is absolutely mandatory for me, and having GSM there is also something I won't compromize with. And since the only elf I ever exit to from GSM is uLE, which is also on the MC, such a change would not save a single byte on MC for me.

In fact it would increase the space used on MC, as the GSM program itself would then have to have those drivers embedded (as it must be possible to use it even without FMCB and its normal USB drivers in SYS-CONF). So GSM would increase by the packed size of the USB device drivers USBD.IRX and USBHDFSD.IRX, plus some new code needed to load those device drivers and also modifications to the elf loader so as to also cope with another launch device. Each of these additions may not be very large, but it all adds up...
(In unpacked form USBD.IRX + USBHDFSD.IRX are appx 74KB together.)

----- snip ----- re: Weird results with many homebrew emus
It is very possible for some emus to have code that interacts badly with the GS control of GSM, just like some games may have (though differently of course, using Sony libs).

I think I need to make time soon for some extensive testing of current GSM with a view to making new improvements. But there are also many other things that I need to make time for, such as uLE improvements of several kinds, perhaps most importantly the SMB implementation. And there are other things demanding more time too, not related to those projects (such as my new PS3 which I've barely had time to touch in the last two days).

And my abilities to 'make' time are quite limited, and mostly restricted to cutting down on the time 'wasted' on sleeping, which never-the-less is necessary to keep my other abilities up.

So I'm not promising any dates when new improvements will be ready.
It will happen, but it will have to wait until I get around to it...

Best regards: dlanor

[RandQalan]

Take your time everyone needs sleep + less likely to make mistakes.