We have seen developer @deank cooking up some nice brew lately, the latest creation of sLaunch has now evolved into a new plugin called sMAN, bringing the original vision of the developer to this single plugin containing webMAN & sLaunch, rather then having two separate plugins loaded at boot time (like the preview releases) deank uses a single plugin slot while making sLaunch an even faster sprx loaded dynamically. For simplicity, he concatenated into just one file called sman.sprx the various sprx parts of the app (rawseciso/netiso/slaunch/sman) as well as the html parts of the XMB "Sman Games" feature. If you like to use this alternative UI for loading games, then you should use the sMAN plugin going forward, if you like the traditional way (w/ My Games) then you can use the XMB feature or simply switch to the webMAN plugin as both version will still available for users.

sman.jpg

  • Now, let's move forward to the next step...

    Later today I'll release the "sMAN" - which is webMAN + sLaunch in one plugin. The reason - this is what webMAN was supposed to be - the way I wanted to be since day one:
    • Use only one plugin slot
    • Use about 128KB less vsh memory (about 384KB total vsh memory)
    • Support for /dev_usb000 to /dev_usb128
    • No need for boot delays for scanning usb drives
    • No need for XML generation, "refresh xml" or other complicated tasks
    • No need for the "My Games" entry in XMB (no need for custom category_game.xml)
    • Simplified setup page, eject/unmount/rescan/grouping options available within sMAN's front-end (sLaunch)
    • Support for over 1000 games
    • FTP/WEB/NTFS/NETISO support by the sMAN's back-end (webMAN)
    • Simple use in any cobra compatible CFW by adding sman.sprx to boot_plugins.txt without modifying other files
    • The front-end (menu) is not using resources when not active (opposed to slaunch.sprx)
    • Updated - it now supports switching groups/content-type (ALL/PS1/PS2/PS3/PSP/VIDEO) - press the [SQUARE] button.

    sMAN
    : http://deanbg.com/sman.sprx

    Dean

    p.s. The features in bold will be gradually introduced for easier transition for the users who decide to switch to sMAN.

    Edit: eventually deank decided to add the XMB "Webman Games" feature to sMan as many end users were asking for it.
    It brings back the old XML creation problem he originally wanted to get rid of however it works quite well.
    The only real glitch in sMan 1.11n (& in the latest wMM actually) is found with a limited number of ntfs hdd where the partition cannot be read using the libntfs_ext library port. Hopefully this bug should get fixed after investigation...

    The XMB Game list remains optional however, to be toggled in the sMan settings page.


  • Random Comments about sMAN from deank
    • The good thing about sMAN is that it doesn't require large amounts of memory no matter how many games you have. It can handle 2000, 3000, 5000 games even.
    • sMAN is working a bit faster than sLaunch (at least it looks that way).
    • If you decide to use sman.sprx - remove webftp_server.sprx and slaunch.sprx from your boot_plugins.txt. It is not possible to use them at the same time.
    • Yes, fan-control is still there, because it is "webMAN" in the background. For languages - there is nothing different to webMAN - you'll have to compile it yourself with proper gui.h.


  • Video (POC Version)
    ScreenShot (from preview version)
    --------------------------------------------------------------------
    slaunch_preview.jpg


 
Last edited by a moderator:
Related to my cover issue. When I convert the multiman jpg cover to png and place it in dev hdd0/tmp/wmtmp renamed to what the iso file on my NTFS usb drive is (ex Assassin Creed IV Black Flag.PNG) the cover will display but the game id will not. Where is the game id that is displayed in sman retrieved from?
 
@deank
I know what you mean... Lol
Yes, it is the usual nonsense, most of these YT videos are just nonsense.

For weeks now, vids are posted on YT advising users to disable syscalls on boot with wMM to reduce ban risk!???
A s a result, users keep asking why they cannot mount games properly anymore & reporting their CFW as buggy,....
Other vids advise people to rely on webMAN-MOD to disable syscalls partially on boot & use Ccapi to change idps during online gaming, after logging into PSN.....
 
What purpose do the .ntfs[PS3ISO] files in /dev_hdd0/tmp/wmtmp serve?
For the benefit of other users, I am going to try to answer this in a simple manner with terms that everyone can understand, I will avoid a very technical explanation.
Those files are "shortcuts" of sorts mapping the ntfs based iso files. Originally created by prepNTFS for webman/webMAN-MOD & multiman to provide those apps with access to the ntfs files without using a dedicated ntfs driver.

Only prepntfs used a ntfs library to access the drives, scan the contents & map the iso files. The other apps like multiman or webman did not use the ntfs library at all & simply processed the ntfs mapping to mount the iso files.

Nowadays this situation is rapidly evolving, prepntfs is getting obsolete. Webman & webMAN-MOD now both use the ntfs library so they do not require prepntfs anymore to map the ntfs iso files.
Same thing for sman.
Multiman might also be rid of the prepntfs dependency in the future if deank decides to include the ntfs library into multiman as well.
 
Last edited:
yeah the other day I was sorting games and apps into album folders and after naming you just press start to make the name, every other time, sMAN would open! so I had to select "start/end" from the keyboard display instead of just pressing start so sMAN wouldn't open

I think either the start button needs to be held longer or it needs to be another combo. just a suggestion
 
For the benefit of other users, I am going to try to answer this in a simple manner with terms that everyone can understand, I will avoid a very technical explanation.
Those files are "shortcuts" of sorts mapping the ntfs based iso files. Originally created by prepNTFS for webman/webMAN-MOD & multiman to provide those apps with access to the ntfs files without using a dedicated ntfs driver.

Only prepntfs used a ntfs library to access the drives, scan the contents & map the iso files. The other apps like multiman or webman did not use the ntfs library at all & simply processed the ntfs mapping to mount the iso files.

Nowadays this situation is rapidly evolving, prepntfs is getting obsolete. Webman & webMAN-MOD now both use the ntfs library so they do not require prepntfs anymore to map the ntfs iso files.
Same thing for sman.
Multiman might also be rid of the prepntfs dependency in the future if deank decides to include the ntfs library into multiman as well.

My next question would be are the .ntfs[PS3ISO] files responsible for fetching the game id and multiman cover? It is well documented by me here that the first iso alphabetically listed on my NTFS usb drives are not displaying the game id or cover properly. To expand on this point I have two Assassin Creed games on my NTFS drive. When I rename each in a fashion that it become the first alphabetical entry the cover miraculously stops displaying and I get just the icon from the iso and the game id is also not displayed. I believe this to be a bug in the creation of the the first .ntfs[PS3ISO] file.
 
My next question would be are the .ntfs[PS3ISO] files responsible for fetching the game id and multiman cover? It is well documented by me here that the first iso alphabetically listed on my NTFS usb drives are not displaying the game id or cover properly. To expand on this point I have two Assassin Creed games on my NTFS drive. When I rename each in a fashion that it become the first alphabetical entry the cover miraculously stops displaying and I get just the icon from the iso and the game id is also not displayed. I believe this to be a bug in the creation of the the first .ntfs[PS3ISO] file.
No. Prepntfs is the app responsible for scanning images & gameid + creating xml & files.
However afaik the .ntfs file does not contain that information, it is only information about the iso obtained using rawseciso & scsi, stuff like the device type, emu type, the parts/ sections/tracks of the iso file but not the metadata like gameid or cover file...
I don't think any bugs come from the .ntfs files but rather from the xml generation or whatever else...
Here is the source code building the ntfs map files:
Code:
//--- build .ntfs[] file
									p_args = (rawseciso_args *)plugin_args;
                     memset(p_args, 0, PLUGIN_ARGS_SIZE);
                     p_args->device = USB_MASS_STORAGE((mounts[i].interface->ioType & 0xff) - '0');	
                     p_args->emu_mode = emu_mode;
                     p_args->num_sections = parts;
                     memcpy(plugin_args + sizeof(rawseciso_args), sections, parts*sizeof(uint32_t));
                     memcpy(plugin_args + sizeof(rawseciso_args) + (parts * sizeof(uint32_t)), sections_size, parts * sizeof(uint32_t));
                     If (emu_mode == EMU_PSX)	
                      {	 
                             int max = MAX_SECTIONS - ((num_tracks * sizeof(ScsiTrackDescriptor)) / 8);
			             if (parts == max) continue;
					         if(cd_sector_size == 2352) p_args->num_tracks = num_tracks; 
else	 
p_args->num_tracks = num_tracks | (cd_sector_size<<4); 
                     scsi_tracks = (ScsiTrackDescriptor *)(plugin_args + sizeof(rawseciso_args) + (2 * parts * sizeof(uint32_t)));
 										if (!cue)
										{
											scsi_tracks[0].adr_control = 0x14;
											scsi_tracks[0].track_number = 1;
											scsi_tracks[0].track_start_addr = 0;
										}
										else	
									{
											for (u8 j = 0; j < num_tracks; j++)
											{
												scsi_tracks[j].adr_control = (tracks[j].is_audio) ? 0x10 : 0x14;
												scsi_tracks[j].track_number = j + 1;
												scsi_tracks[j].track_start_addr = tracks[j].lba;
											}
										}
									}
 									//--- write .ntfs[ file
									FILE *flistW;
									snprintf(path, sizeof(path), "/dev_hdd0/tmp/wmtmp/%s%s.ntfs[%s]", filename, SUFIX2(profile), c_path[m]);
									flistW = fopen(path, "wb");
									if(flistW!=NULL)	
								{
										fwrite(plugin_args, sizeof(plugin_args), 1, flistW);
										fclose(flistW);
										sysFsChmod(path, 0666);
									}
								}
							}
 
Last edited:
For a OS to find a file on a hdd, the system queries the partition's file allocation table for the disk address of the corresponding file path. This operation will take as much time for /dev_hdd0 or /dev_hdd0/plugins, as I said it makes no difference as far as loading the plugin with Cobra is concerned.
However I have not seen the code running during the prx file launch. It's possible that some other operation performed by the prx on boot slows the process depending on the location of the prx file but I doubt it very much.
deank might be able to tell you more...
 
No. Prepntfs is the app responsible for scanning images & gameid + creating xml & files.
However afaik the .ntfs file does not contain that information, it is only information about the iso obtained using rawseciso & scsi, stuff like the device type, emu type, the parts/ sections/tracks of the iso file but not the metadata like gameid or cover file...
I don't think any bugs come from the .ntfs files but rather from the xml generation or whatever else...
Here is the source code building the ntfs map files:
Code:
//--- build .ntfs[] file
                                    p_args = (rawseciso_args *)plugin_args;
                     memset(p_args, 0, PLUGIN_ARGS_SIZE);
                     p_args->device = USB_MASS_STORAGE((mounts[i].interface->ioType & 0xff) - '0');   
                     p_args->emu_mode = emu_mode;
                     p_args->num_sections = parts;
                     memcpy(plugin_args + sizeof(rawseciso_args), sections, parts*sizeof(uint32_t));
                     memcpy(plugin_args + sizeof(rawseciso_args) + (parts * sizeof(uint32_t)), sections_size, parts * sizeof(uint32_t));
                     If (emu_mode == EMU_PSX)   
                      {    
                             int max = MAX_SECTIONS - ((num_tracks * sizeof(ScsiTrackDescriptor)) / 8);
                         if (parts == max) continue;
                             if(cd_sector_size == 2352) p_args->num_tracks = num_tracks;
else    
p_args->num_tracks = num_tracks | (cd_sector_size<<4);
                     scsi_tracks = (ScsiTrackDescriptor *)(plugin_args + sizeof(rawseciso_args) + (2 * parts * sizeof(uint32_t)));
                                         if (!cue)
                                        {
                                            scsi_tracks[0].adr_control = 0x14;
                                            scsi_tracks[0].track_number = 1;
                                            scsi_tracks[0].track_start_addr = 0;
                                        }
                                        else   
                                    {
                                            for (u8 j = 0; j < num_tracks; j++)
                                            {
                                                scsi_tracks[j].adr_control = (tracks[j].is_audio) ? 0x10 : 0x14;
                                                scsi_tracks[j].track_number = j + 1;
                                                scsi_tracks[j].track_start_addr = tracks[j].lba;
                                            }
                                        }
                                    }
                                     //--- write .ntfs[ file
                                    FILE *flistW;
                                    snprintf(path, sizeof(path), "/dev_hdd0/tmp/wmtmp/%s%s.ntfs[%s]", filename, SUFIX2(profile), c_path[m]);
                                    flistW = fopen(path, "wb");
                                    if(flistW!=NULL)   
                                {
                                        fwrite(plugin_args, sizeof(plugin_args), 1, flistW);
                                        fclose(flistW);
                                        sysFsChmod(path, 0666);
                                    }
                                }
                            }


There are no xml with sman as far as I know so where if all iso are in one directory why would all but one be scanned and displayed. This problem is not isolated to just one NTFS usb drive as I have tested it on all of mine and the problem persists across all of them. All ISO created using multiman and transferred from internal hdd to NTFS usb drive using Gamesonic Manager. I have 0 games on internal PS3 hdd. I'm stumped to say the least. It makes no sense for it to happen on every USB drive. I have also formatted the internal hdd and re installed Habib 4.81 1.02 just to make sure it wasn't something simple like that.
 
The next sMAN version will require to be named sman.sprx and located in /dev_hdd0/sman.sprx.

The reason for it is that the sprx itself will have added resources (glued to the sprx file) with background, icons and other things. sMAN will need to know its location to be able to extract these for its normal operation. And I don't like this "webftp_server/sman" swaping.

boot_plugins.txt with the propler path:

/dev_hdd0/sman.sprx

That is simple enough. I don't understand all these youtube videos with 15 min explanations how to swap/use sMAN. If you're on rebug just delete the webftp_server.sprx from your flash and use a proper boot_plugins.txt file.

Don't even have to manually delete, just disable Rebugs integrated webman via the toolbox and carry on as normal with the boot_plugins.txt....

Even webmanmod will install to the hdd using the plugins file that way.

Don't know why people trust these trolls on youtube... Most are 8 year olds with no idea what they are doing or just deliberately trying to get people banned / bricked anyway.

A little common sense goes a long way. ;)

edit: Example of why you don't trust the internet. hahaha

m1goJCc.jpg
 
Last edited:
There are no xml with sman as far as I know so where if all iso are in one directory why would all but one be scanned and displayed. This problem is not isolated to just one NTFS usb drive as I have tested it on all of mine and the problem persists across all of them. All ISO created using multiman and transferred from internal hdd to NTFS usb drive using Gamesonic Manager. I have 0 games on internal PS3 hdd. I'm stumped to say the least. It makes no sense for it to happen on every USB drive. I have also formatted the internal hdd and re installed Habib 4.81 1.02 just to make sure it wasn't something simple like that.

Sorry but you were asking about the .ntfs files & what they contain so I explained what they are & their relationship to prepntfs so I also explained how it all worked. I used xml because it has been the core piece to store the information for ages so all users should be familiar with the concept but it could be a text file or a sql db, the problem would be exactly the same.
You said there may be a bug with ntfs map file creation leading to your other issues however the .ntfs files do not contain the data you are talking about so how could they be responsible?
Sman is another story & you did not ask about that in particular either... It does not use xml to store info but it still scans content, create cover files & extract gameid just like prepntfs did so it can make errors in the same way, whether it is xml or not does not matter.

Also take into consideration that all this is WIP.
The newly ported libntfs library is still being tested, stability & compatibility will improve but there is still some research to be done.
Also keep in mind that the use of a ntfs driver has a memory cost & devs are currently getting familiar with requirements.
Changes occur everyday in all webman related brews atm so expecting a fully working webman release at this stage is not realistic.
 
Last edited:
For the benefit of other users, I am going to try to answer this in a simple manner with terms that everyone can understand, I will avoid a very technical explanation.
Those files are "shortcuts" of sorts mapping the ntfs based iso files. Originally created by prepNTFS for webman/webMAN-MOD & multiman to provide those apps with access to the ntfs files without using a dedicated ntfs driver.

Only prepntfs used a ntfs library to access the drives, scan the contents & map the iso files. The other apps like multiman or webman did not use the ntfs library at all & simply processed the ntfs mapping to mount the iso files.

Nowadays this situation is rapidly evolving, prepntfs is getting obsolete. Webman & webMAN-MOD now both use the ntfs library so they do not require prepntfs anymore to map the ntfs iso files.
Same thing for sman.
Multiman might also be rid of the prepntfs dependency in the future if deank decides to include the ntfs library into multiman as well.

@deank
Very good if you deploy in multiman too
 
Since you guys are talking about NTFS. There is no way to support GUID (GPT) partitions? It sucks when people want me to setup their external for the PS3, and they bring me these new 3, 4, or 5TB HDDs. The 4k sector size is set mechanically now, so can not emulate it and make MBR larger than 2TB. Even if you try and make more than one partition, you lose all the space larger than like 2.2TB. I am lucky I got my 5TB before the change.

Anyway, awesome job with sMAN! I am testing it out now for the first time. I love it!
 
Since you guys are talking about NTFS. There is no way to support GUID (GPT) partitions? It sucks when people want me to setup their external for the PS3, and they bring me these new 3, 4, or 5TB HDDs. The 4k sector size is set mechanically now, so can not emulate it and make MBR larger than 2TB. Even if you try and make more than one partition, you lose all the space larger than like 2.2TB. I am lucky I got my 5TB before the change.

Anyway, awesome job with sMAN! I am testing it out now for the first time. I love it!

Hmm, I don't think GPT can be supported Because there's no EFI on PS3, but I think EXT3/4 can be done.

By the way, did you try split partition? like FAT32/NTFS.

I think it can be done if you do like 2TB for FAT32 and 2TB for NTFS and another 1TB for FAT32..

A friend of mine used to do FAT32 for all 4TB and worked fine for him as well long ago.
 
A good solution for largue hdds could be to implement UFS support for external USB drives
https://en.wikipedia.org/wiki/Unix_File_System

PROS
-Is nativelly supported by PS3 firmware (is what the GameOS internal hdd partition uses) so there is no need to use custom libraries or custom drivers
-100% stable and efficient at day one, because is official sony code
-Allows for huge filesystems and file sizes

CONS
-We would need an specific program to manage the contents under windows OS

---------------
As said, PS3 supports UFS nativelly, the problem is the firmware has some kind of lock somewhere (or functions missing) to not allow drives with UFS partitions to be connected externally by USB
 
Back
Top