VIVA Preview 1 - Download and comment please!

[MrE]

Hi all,

I'm finally releasing a preview version of VIVA (VIVA Is A Visual shell Altnerative).

Admittidly the preview doesn't have much linked yet, we're releasing for you to get your comments in on the UI and to prove we have beat Project4 in 2 main aspects.

What the version has:
Ability to load the XMB or VIVA during boot time, pressing the left shoulder button loads the XMB, not pressing loads VIVA. No files have to be written unlike Project4.
ISO/CSO loading (fixed path) with the M33 and NP9660 driver, Project4 only had the ISOFs driver.

Our blog contains the link, but I'm still unable to post a link on the QJ forums (post count). If you search for threads started by me on here you'll find the other VIVA thread which contains a link to the blog.

Comments can be posted on here or the blog, just remember this has next to no functionality and is just to get a view of the UI in action and the ability to pick XMB or VIVA, so don't post anything about not being able to do anything.

[malliet]

Where's download, you title says: Download an comment please?

[BlackBurd]

Was this made in lua or c.

If its in lua then im really not going to download it. Only lua games are fun lua shells are pointless(in my opinion).

And there is no download link.

[malliet]

You're right. LUA Shells suck because there are way too many, but I would
respect a nice RPG with a story line

[Kojote]

Hi all,

I'm finally releasing a preview version of VIVA (VIVA Is A Visual shell Altnerative).

Admittidly the preview doesn't have much linked yet, we're releasing for you to get your comments in on the UI and to prove we have beat Project4 in 2 main aspects.

What the version has:
Ability to load the XMB or VIVA during boot time, pressing the left shoulder button loads the XMB, not pressing loads VIVA. No files have to be written unlike Project4.
ISO/CSO loading (fixed path) with the M33 and NP9660 driver, Project4 only had the ISOFs driver.

Our blog contains the link, but I'm still unable to post a link on the QJ forums (post count). If you search for threads started by me on here you'll find the other VIVA thread which contains a link to the blog.

Comments can be posted on here or the blog, just remember this has next to no functionality and is just to get a view of the UI in action and the ability to pick XMB or VIVA, so don't post anything about not being able to do anything.

Instead of letting everyone look after your old posts :Argh: , why not posting the link to your blog ( http://vivaisavshalternative.blogspot.com/ ) directly into your message?...

[salvy]

Awsome work love VIVA looking forward the official release

For the people who dont know is not in LUA is a replacement for the XMB like projec4 but it's installed along the XMB and you can choose whenever launch it or not, also is easy to unnistall it

EDIT: Heres the download link

http://www.mediafire.com/?sharekey=8...4e75f6e8ebb871

[MrE]

I said in my post I am unable to post links as I have less than 10 post. Please read before you go pointing the finger.

Second, this is coded in C++, and its a replacement/alternative like Project4 was, so it goes in the flash. This sort of thing wouldn't even be possible in lua.

The download link is on the blog, but as I said I can't link to the blog just yet, few more posts to go.

Our blog contains the link, but I'm still unable to post a link on the QJ forums (post count). If you search for threads started by me on here you'll find the other VIVA thread which contains a link to the blog.

I just would have thought this clear enough?

[MrE]

(Shamelessly uping my post count by not editing).

I have an idea I'd like to run past you guys. VIVA is going to take too much flash space on PSP-1000 models, so we either cut out some stuff and let the normal XMB use it, or we allow you to pick what VIVA does.

I'd pick the second option any day.

The idea I've had is at boot time, VIVA checks for all the modules assosiated with it, if theres a music player it enables the music playing capabilities, if theres the ability to load jpgs, pngs, it allows the image viewer to run, same thing with movies. This way you put what you want into the flash, and if you decide that you need something thats not there, you simply press start and boot into the XMB, simple huh? (Yes, the new version you press start to boot into the XMB direct, no restarting).

So what do you think?

[NoEffex]

(Shamelessly uping my post count by not editing).

I have an idea I'd like to run past you guys. VIVA is going to take too much flash space on PSP-1000 models, so we either cut out some stuff and let the normal XMB use it, or we allow you to pick what VIVA does.

I'd pick the second option any day.

The idea I've had is at boot time, VIVA checks for all the modules assosiated with it, if theres a music player it enables the music playing capabilities, if theres the ability to load jpgs, pngs, it allows the image viewer to run, same thing with movies. This way you put what you want into the flash, and if you decide that you need something thats not there, you simply press start and boot into the XMB, simple huh? (Yes, the new version you press start to boot into the XMB direct, no restarting).

So what do you think?

Couldn't you have it execute a "game", which could be VIVA? Similarly to irshell in that matter?

[slasher101]

very kool,
might download after,

~!SlasheR!~

edit--

have a config file on memorystick, load the files it says to like

imageviewer=enabled

at boot time, so the user can enable what he/she wants to.
so if the imageviewer is enabled load the core files off the memory stick.

~!SlasheR!~

[MrE]

I had thought about this, the question is - would you put those files on the memory stick if they wouldn't fit into flash?

PSP-2000 (and when fully hackable, the PSP-3000) will be unaffected by this and the memory limits, only the original PSP units are actually affected by both RAM and storage. The RAM can be overcome by freeing up the modules when not in use though, so its not a major problem.

[NoEffex]

I had thought about this, the question is - would you put those files on the memory stick if they wouldn't fit into flash?

PSP-2000 (and when fully hackable, the PSP-3000) will be unaffected by this and the memory limits, only the original PSP units are actually affected by both RAM and storage. The RAM can be overcome by freeing up the modules when not in use though, so its not a major problem.

You could do what I do and have a biggie big module that loads a bunch of other modules then unloads itself, or have a timeout on each module that checks if it's been called to at any time and if so, then unload it and set the master module to think that it's not there or something.

Anyhow, loading from memstick isn't that bad anymore since the 5.00 m33-6 update, it's way quicker.

[slasher101]

I had thought about this, the question is - would you put those files on the memory stick if they wouldn't fit into flash?

PSP-2000 (and when fully hackable, the PSP-3000) will be unaffected by this and the memory limits, only the original PSP units are actually affected by both RAM and storage. The RAM can be overcome by freeing up the modules when not in use though, so its not a major problem.

make a installer for it so its not a manual copy over.
then just detect if its a psp-100X and if so copy the core files from VIVA onto flash then the optional ones onto memory stick...


~!SlasheR!~

[MrE]

I'll be sticking with the current patcher, each module gets its own patching file and you select what you want installing. Maybe the dev who created the installer will publicly release how to create patch and package files, its certainly easier than coding your own flasher, you could even work it out yourself but don't tell anyone I said that >.>

As for loading the modules, it would be quicker and easier to just check if the file opens, if it does it exists, if it doesn't its not there so lock off those functions.

As for the PSP-1000 series, a simple function to check if the unit has the module loaded before calling the function, and loading if its not there would suffice, then simply ending the use by checking if its a PSP-1000 model and then unloading if it is, leaving the module in memory if its not.

As for the memory stick thing, being a flash based replacement I wasn't sure if relying on the memory stick, even if choicefully, would kill the idea or not.

[slasher101]

makes sense,

~!SlasheR!~

[NoEffex]

I'll be sticking with the current patcher, each module gets its own patching file and you select what you want installing. Maybe the dev who created the installer will publicly release how to create patch and package files, its certainly easier than coding your own flasher, you could even work it out yourself but don't tell anyone I said that >.>

As for loading the modules, it would be quicker and easier to just check if the file opens, if it does it exists, if it doesn't its not there so lock off those functions.

As for the PSP-1000 series, a simple function to check if the unit has the module loaded before calling the function, and loading if its not there would suffice, then simply ending the use by checking if its a PSP-1000 model and then unloading if it is, leaving the module in memory if its not.

As for the memory stick thing, being a flash based replacement I wasn't sure if relying on the memory stick, even if choicefully, would kill the idea or not.

With an installer, couldn't you bin2c the files with a script or something? That's what I do.

Also, for unloading, I thought unloading meant to unload it out of memory, similarly to loading into memory?

[MrE]

With an installer, couldn't you bin2c the files with a script or something? That's what I do.

No, the installer I'm using uses package and patch files, the theory is that any one of us could upgrade or bugfix our module, and not have to wait for an entirely new release of VIVA to get it "out there", instead just slightly change the patch file (to read the next version) and then you just run the flasher and done. No messing around re-installing everything and no waiting. Besides, I quite like the flashing method we're using.

Also, for unloading, I thought unloading meant to unload it out of memory, similarly to loading into memory?

Yes, I'm not sure where your confusion is coming into this. The modules can reside in memory on a newer system, but on older ones have to be unloaded and reloaded every time.

[NoEffex]

No, the installer I'm using uses package and patch files, the theory is that any one of us could upgrade or bugfix our module, and not have to wait for an entirely new release of VIVA to get it "out there", instead just slightly change the patch file (to read the next version) and then you just run the flasher and done. No messing around re-installing everything and no waiting. Besides, I quite like the flashing method we're using.



Yes, I'm not sure where your confusion is coming into this. The modules can reside in memory on a newer system, but on older ones have to be unloaded and reloaded every time.

I'm getting quite confused, I'll stop suggesting things until I actually understand this lol.

Anyhow, good release.

[MrE]

Maybe some awful psudo code will assist you:

int main()
{
	bool model;
	bool music;
	SceUID musicMod;

	//check if model is PSP-1000, if so modules must be unloaded
	
	model = isPSP1000Model();

	//check if music.prx exists, if so make music = true

	music = checkModuleExists("music.prx");

	//if module exists function is allowed

	if(music == true)
	{
		if(!musicMod)
		{
			musicMod = loadModule("music.prx");
		}
		playSong();
		
		//when finished using the music player unload the module if PSP-1000 model
		
		if(model == true)
		{
			unloadMod(musicMod);
			//memory now free on PSP-1000 models
		}
	}
}

/**
 *
 * Above method should in theory only
 * unload the module when required
 * which would be on 32mb RAM systems.
 *
 * Any system with 64mb or higher could
 * run VIVA and all its modules without
 * running low on memory and thus wouldn't
 * need to unload each module by turn. This
 * would save time loading and unload.
 *
 **/

As for your edited comment, you can't loadExec anything from flash at all, and having it on the memory card will just make it a shell in which case we'd have no reason for working on VIVA... no one can rival iRShell in terms usability and popularity, its just been around too long for that.

-----Edit-----
Huh I'm confused, it said you'd posted something different in the review bit, so I answered both the question I read before posting, and the above which I saw whilst posting.
-----Edit-----

[NoEffex]

Maybe some awful psudo code will assist you:

int main()
{
	bool model;
	bool music;
	SceUID musicMod;

	//check if model is PSP-1000, if so modules must be unloaded
	
	model = isPSP1000Model();

	//check if music.prx exists, if so make music = true

	music = checkModuleExists("music.prx");

	//if module exists function is allowed

	if(music == true)
	{
		if(!musicMod)
		{
			musicMod = loadModule("music.prx");
		}
		playSong();
		
		//when finished using the music player unload the module if PSP-1000 model
		
		if(model == true)
		{
			unloadMod(musicMod);
			//memory now free on PSP-1000 models
		}
	}
}

/**
 *
 * Above method should in theory only
 * unload the module when required
 * which would be on 32mb RAM systems.
 *
 * Any system with 64mb or higher could
 * run VIVA and all its modules without
 * running low on memory and thus wouldn't
 * need to unload each module by turn. This
 * would save time loading and unload.
 *
 **/

As for your edited comment, you can't loadExec anything from flash at all, and having it on the memory card will just make it a shell in which case we'd have no reason for working on VIVA... no one can rival iRShell in terms usability and popularity, its just been around too long for that.

-----Edit-----
Huh I'm confused, it said you'd posted something different in the review bit, so I answered both the question I read before posting, and the above which I saw whilst posting.
-----Edit-----

Yeah lol, that's what I was trying to [email protected]


I just said something similar the irshell in that you load a certain module, it loads viva from wherever, then it unloads itself.

[Mr_Shizzy]

This looks interesting.

I'll keep my eye out for future updates :)

[BlackBurd]

ok i just saw shell and said ****.

ill try it when i get home

[AdamRav]

(Shamelessly uping my post count by not editing).

I have an idea I'd like to run past you guys. VIVA is going to take too much flash space on PSP-1000 models, so we either cut out some stuff and let the normal XMB use it, or we allow you to pick what VIVA does.

I'd pick the second option any day.

The idea I've had is at boot time, VIVA checks for all the modules assosiated with it, if theres a music player it enables the music playing capabilities, if theres the ability to load jpgs, pngs, it allows the image viewer to run, same thing with movies. This way you put what you want into the flash, and if you decide that you need something thats not there, you simply press start and boot into the XMB, simple huh? (Yes, the new version you press start to boot into the XMB direct, no restarting).

So what do you think?

The 2nd option sounds the best

great work by the way

:Punk:

[MrE]

BlackBurd don't worry about it, I've seen some of the (no offence intended to those devs) crap that gets released here, but I have a brain in my head and it tells me 2 things - never use LUA, and don't try and argue with iRShell, it'll pwn you.

ShadowX has just made a post on the blog (which I can now post because my post count is above 10, yay!). From what I can see and remember, the player is very similar to LightMP3 in that it runs using the ME, which allows you to seriously underclock the PSP. Unfortunatly the look will probably have to change before release, I've not given out my graphics library yet, and due to the low memory its going to have to cut down on some things. Still bar the font and album art everything else should be simple enough to port (heh, quads basically).

[chrisp6825]

I think this will turn out really great. I've always thought that something like this would be sooo handy to me.

I have 2 questions though.. both are probably no, but :
Can't phat users just delete some stuff out of the flash for more space?
And, will any of this be open source at all?

[MrE]

Good questions, you could completely remove the XMB from the flash, that would involve removing what would be heaparea1.prx, paf.prx, and XMB.prx, theres probably more but those are the main ones I've seen that the XMB rely on (XMB.prx is just vshmain.prx renamed by the way). Doing this would free up over 1mb of space which is a fair amount should things go the way I hope, most applications/extentions should be no bigger than 100kb.

As for open source, I'm tempted to release my work under the GPL, other peoples code is obviously their own work and its up to them what they do with it. It will be a while though until anything significant is released open source, especially from me as I'm rather a sloppy programmer, I never comment my code and I have stuff all over the place; I'm sure we'd both benifit from me cleaning my code before releasing.

[chrisp6825]

Yea I also think it'd be cool if the installer had a few options :

If slim PSP then install all on flash, with all modules.
If Phat PSP then ask to install all modules, then if yes, ask to install on memstick, or to replace the XMB.

Then of course, if its a phat, unload modules when they're not in use, if they're installed.


I think that it'd be great if you released the source, but it's obviously up to you. It never really bothers me that much when code isn't commented. It's just more of a challenge. haha

[MrE]

Well seeing as installation is done through patch and package files you have the option to install what you want when you want it. In theory I could write a "patch" file to place the XMB and all the other stuff there, then you simply switch to unpatch mode and run the patcher - deletes those files.

A little bit of tinkering of the installer will be needed, flash2 and flash3 won't mount properly yet and theres no ms0 writing, but whenever the dev gets around to adding those it'll open another path to use.

The whole idea of VIVA is to give as many options as possible, with interchangable music players, image viewers, UMD loaders... all it takes is for someone to code a brand new one, write a patch file and upload it, once thats done you can choose whether to use one devs extention or the others. It also means you don't have to install everything, like a music player plugin if you rarely listen to music, but having the XMB to boot into still means you can play music should you want to.

Before the next preview I'll hopefully have had chance to work on vshmain.prx, and give you the option to use the left shoulder button or not. The only thing thats annoying me is that whenever you enter the XMB it always shows the SCE logo, I need to figure out what arguments need to go there to stop it happening.