Printable View
Well, I noticed that the latest build of Hostcore by HBPoison seems to be running Nethost 1.7. However, in IrShell 3.7+ Nethost is apparently 2.1.
Long story short, does anyone have the source code for the new nethost? (I mean, the PSP side, apparently IrShell's providing the source code for the PC and not PSP)
See Here for the first post about this on IrShell.org
:eek:
Heh... good luck on getting a straight answer. ^^;
Hey, do you know if it'd be possible to work NetHost support into a slim program like PSPFiler? I don't want to re-arrange the file structure of my stuff on my PC just so I can access it using Hostcore, but I'd like to be able to do simple copy/paste file operations.
PSPFiler's focus as a File Explorer gives it tons of advantages over IRShell's feature (Like a progress indicator. ^^; ), and that Nethost support is pretty much the only reason I keep IRshell installed on my PSP. Bit of a waste of space.
Well, with the source in hand, it may not be too hard, but since I don't even have that I have no idea if it can be done or where to start.:eek:Quote:
Originally Posted by Tesseract
Really, Hostcore is awesome and all, but since nobody I've contacted has the source or wants to give it up, it may just be a dream.
Another one of my ideas for XMB enhancement (with or without hostcore) is:
Better support for subfolders. I mean, come one, only one deep? I have way too many songs to just organize by CD/Artist/However. This would also be awesome for Games and homebrews. Being able to categorize it efficiently would be a plus as well.
This is apparently extremely difficult, as I would need to totally rewrite each of the modules for songs/games without the help of having Sony's code.
I dunno, you think you could break into Sony HQ and snatch it for me Mission Impossible style? :rolleyes:
Another thing I wanted to try adding to Nethost was Access Prediction, which would basically watch the pattern off access of the PSP and pre-cache the next few chunks (up to maybe 16KB) or at least use a "Continue the download" kind of command. I've explained this idea elsewhere, but what do you think? Can it be done?:confused:
Hmmm, would this link help? http://www.irshell.org/site/index.ph...&limitstart=24
I can't examine the contents of the files posted as I'm at work, but it appears that they've got the source available.
As for the Access Prediction, I really couldn't say. It wouldn't really work too well for actually RUNNING programs because you'd have to cache it somewhere, and memory on the PSP already tends to be a premium (Unless you cache on the MemStick). Being able to continue an interrupted download would be a much more useful feature, I'd think.
The Subfolder Idea would be difficult considering the nature of the XMB. Something that MIGHT work better would be say if you've got...
ms0:/MUSIC/Album/Disc 1/Song.mp3
ms0:/MUSIC/Album/Disc 2/Song.mp3
... that it would scan the nested subfolders and put it under the Group titled by the 'Album' Folder name. Manually navigating using the XMB would be tricky, as I mentioned, but this seems like it'd be feasible.
For Game/Hombrew stuff, there's AppSwitcher, but for folks like me with multiple memsticks, it was a tad dangerous and I had to remove it. ^^;
Negative, that's a custom source archive for the Host part, and I'm seeking the Client source. Thanks for looking though! :cool:Quote:
Originally Posted by Tesseract
For the caching idea, it shouldn't need to be much, If we had 16KB per socket it would be sufficient enough to steady things like music and video playback, not to mention that if 16KB of "to-be-requested" data should significantly decrease loading when 2KB blocks are requested (which seems to be the standard reading number based on diagnostic tests).
In fact, I might be able to implement the precaching idea if I had enough experience setting up the required memory buffer and cross-function variable sharing. :eek:
In my mind's opinion, all I would need to do was track up to three access locations in the currently opened file and keep the memory buffers filled with the next 16KB (up to the end of the file of course) and FIFO (that is, first in first out) the data as it is being requested, selecting the particular stream that has is, and if none of the streams contains the requested data, then select the oldest accessed stream and start precaching the file from there.
All a matter of technicality, I guess. Have any pointers for that? ;)
*laughs* I'm nowhere near having programming skills myself. I just know enough to give reasonable suggestions/be dangerous. :D In that vein, the caching Idea you've spelled out makes sense from my POV, but I'd have to let someone who knows more about the technicalities rule on that. ;)
I'll keep hunting around for the client source and let you know what I find. Isn't it generally bad form to not release the source to an update to a project that had previously been open source?
Apparently no. see hereQuote:
Originally Posted by Tesseract
Apparently, because Ahman has modified it to include Kernel patching, the closed the source. That's okay, though, since he told me that the only things he added were the kernel patches.:):confused:
So I guess I'm free to try to hack it up as much as I want then I guess ;).
Ah, so the only differences between 1.7 and 2.1 were the kernel patches that are basically just to make it play nicer with IRShell? That kinda solves your problem in a sideways manner. :D