gbadev.org forum archive

Please take a few minutes and give SLURP a try. It is available at http://dl.ndshb.com with instructions. Please post any bugs you find here or on the ndshb.com forum. As you can see, we already have a few.. I totally forgot about devices that require the .ds.gba version of homebrew.. I don't know why.. :( Just slipped my mind.

Anyway, this is really just a concept, the "final" product will not look anything like this, more of a database browser, and we are just starting to work on the web interface to allow people to create accounts so they can add homebrew to the database when it is ready.

One nice thing to note (I hope others will do it as well) is the ability to download the latest version of SLURP within SLURP. It would be nice if some of the WiFi enabled games we already have (ExplosiveGas comes to mind) would check to see if a newer version is available, and give the option to download it.

Be gentle ;)
_________________
NDS Homebrew Roms & Reviews

Last edited by Lynx on Tue Jul 17, 2007 10:59 pm; edited 1 time in total

seems like a great idea, and if you can get a good database going [and improve the speed], it could get popular too. cant wait to see what this turns into

Very cool idea, Lynx.

I don't have a card that supports dldi on me at the moment to try this out, I'll try to get one back for the weekend.

Are you thinking individual games would check if they're the latest version, or letting SLURP itself do the check? i.e. when you download a game through SLURP it stores the downloaded version number in a control file, and when you run slurp again to launch a game you have downloaded, it will notify you if a new version is available.... well that's assuming SLURP launches games from it's interface.

Jimmy
_________________
A Touch of War

As i had posted on NDSHB.com:

Quote:

Just tried it with my new-ish NDS lite and my R4DS. Patched, loaded it through R4DS loader, would not initialize the wifi. Loaded it through DSO, and the wifi worked. Tried to download MelstromDS and everything seemed to go ok, until right at the end. The last line on the display looks like it said "Closing sock: 1" and it hangs. Also, according to the main page, the bar should have turned teal, indicating it was patched? Anyway, I rebooted the DS and went to play the game, which had a size of 0, so of course it didn't load. Tried downloading Word Up! as well, and got the teal bar for about 9/10ths of the way, but still a filesize of 0.

I do get a somewhat flickery black bar at the top of the upper display, but once the program starts downloading, it disappears.

Ideas:

When downloading, make background of upper display black as to be able to see the text that scrolls by.
When downloading, float the image of the selected app/game above the progress bar.

So other than the filesizes being 0, everything seems to work so far. If you want any further testing, let me know :)

Cool Idea!
I had to patch it with supercard magic homebrew patcher to get it to work though. DLDI alone didn't work. Strangely they all booted through DSO just fine. The same goes for the games I downloaded with it except Maelstom. I double checked the DLDI file and file setup and everything was as should be.
I'm using a Supercard SD English with Firmware 1.81 on a new DSlite.

Sounds like a great idea! You should see if you can get that one program that sent one file between two DS's integrated into this one, that would be ultimate.
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

Quote:

[and improve the speed]

It's currently slow because of the debug info being written to the screen. I guess I should have turned it off prior to releasing it.

Quote:

Are you thinking individual games would check if they're the latest version

Yeah, that is what I was thinking.. SLURP was planned to only give you download access to a database. I didn't really think about it checking it's own database to see if there are newer versions available.. Good thinking.. I'm also hoping to get a DSO and Moonshell plugin setup, depending on the difficulty.

Quote:

I had to patch it with supercard magic homebrew patcher to get it to work though. DLDI alone didn't work

Yeah, that is the prepended header I forgot about (and mentioned in red) for the devices that need the .ds.gba version. DOH! Still don't know what I was thinking! DSO auto prepends the header if needed. Hopefully in the next release or so, we will auto prepend the header based on the DLDI file you are using (to know if your device needs the header or not).

Oh.. and I should mention that Phoenix Rising did all the real work on this release. Now that we have something working, we plan on more collaboration. So hopefully it will get better.. quicker.. ;)

Thanks for all the feedback.
_________________
NDS Homebrew Roms & Reviews

Is it possible to extract the DLDI file from the .nds file itself? That way it would be even easier to use.
_________________
Nintendo DS homebrew on Wikipedia

felix123 wrote:

Is it possible to extract the DLDI file from the .nds file itself? That way it would be even easier to use.

Yes, it's been done before. (Chishm's exec stub does it.)
_________________
http://licklick.wordpress.com

Quote:

Are you thinking individual games would check if they're the latest version, or letting SLURP itself do the check? i.e. when you download a game through SLURP it stores the downloaded version number in a control file, and when you run slurp again to launch a game you have downloaded, it will notify you if a new version is available.... well that's assuming SLURP launches games from it's interface.

PR had already thought about that (I didn't know). But the main problem is if you go outside the system. He was talking about checking hashes, but the current patched file would be different because of the patch. If we went with a local tracking system, if you downloaded something outside of SLURP, you wouldn't want SLURP to download an update overtop of it.

So, PR said we plan on open sourcing this when it is more stable and it is being broken up into 3 seperate parts. So anyone who would like to add an auto downloader (or whatever) for their program will be able to use parts of this application to download from the database. He is also talking about a private/public flag so that devers can use the system as private to make sure everything is working before making it available to everyone else. It might even get to the point where you can add a step to your Makefile to upload it to your account in the database.

Keep the suggestions coming and we will do our best to implement them. Main next step is to get the online stuff working so we can have something to download for the next version, which currently just displays 'All' and 'Games" for categories, and only has SLURP available for download.
_________________
NDS Homebrew Roms & Reviews

Amazing idea lynx, I'll be happy to help with this project as much as I can.

This is the kind of thing that would allow for a massive increase in homebrew popularity and end user support.

I'm with you all the way.
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia

Great idea, keep up the good work :)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.

As for updates, you could create an internal database, or even a simple flat file to associate with each homebrew image

eg.

/data/SLURP/database/<gamename>.info

Then just cycle through the .info files at boot, to check thigns like
- Did the user delete the rom? (Stop managing it)
- Is the version on file older than the current rom? (Prompt user to update)
- Store additional info (image name, description, author etc)

A feature that could be disabled too I'm sure :)
_________________
FireSlash.net

Quote:

- Is the version on file older than the current rom? (Prompt user to update)

This is the problem we are having. How do we tell the difference?

We download ThisGame 1.0 using SLURP. (SLURP thinks we have 1.0)
a month passes, I see an update post, and download ThisGame 1.1 overtop of the one downloaded by SLURP.

What happens next? Does SLURP think we have 1.0? If 1.1 is available in SLURP, is it going to tell us there is a newer version even though we have the current version already? Etc.. So, we're still unsure of a good way to do it.
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

We download ThisGame 1.0 using SLURP. (SLURP thinks we have 1.0)
a month passes, I see an update post, and download ThisGame 1.1 overtop of the one downloaded by SLURP.

What happens next? Does SLURP think we have 1.0? If 1.1 is available in SLURP, is it going to tell us there is a newer version even though we have the current version already? Etc.. So, we're still unsure of a good way to do it.

Not worth getting bogged down with - if it's not downloaded via SLURP then SLURP doesn't know and tells the user there's a new version. The same thing happens with the devkitPro installer.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

Not worth getting bogged down with - if it's not downloaded via SLURP then SLURP doesn't know

If the SHA-1 of the .nds matches, then why can't SLURP know?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Lick wrote:

felix123 wrote:

Is it possible to extract the DLDI file from the .nds file itself? That way it would be even easier to use.

Yes, it's been done before. (Chishm's exec stub does it.)

Except SLURP would have to be told where its own .nds is.
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

Why couldn't it just pull it from the already loaded into RAM and executing ARM9 binary (pardon me if that doesn't work)?

Dood77 wrote:

Lick wrote:

felix123 wrote:

Is it possible to extract the DLDI file from the .nds file itself? That way it would be even easier to use.

Yes, it's been done before. (Chishm's exec stub does it.)

Except SLURP would have to be told where its own .nds is.

chuckstudios is right, it's already in the RAM. And like I said, it's been done before and it works.
_________________
http://licklick.wordpress.com

tepples wrote:

If the SHA-1 of the .nds matches, then why can't SLURP know?

Because we are patching them? Otherwise, we'd have to keep the hash for every patched version of the .nds for every DLDI driver on the server to compare against, no?

WinterMute: We're not getting bogged down with this. Our list is plenty long before we worry about features such as this. It was more of a "neat" idea for individual homebrews to do, as it's much easier for them to keep track of their own version numbers. I'm not a programmer, but I could see this as easy as having a version.txt file available on the authors site, and a version variable in the prog. Just fetch the version.txt, compare to the version variable, and ask to pull down the latest version if needed.
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

tepples wrote:

If the SHA-1 of the .nds matches, then why can't SLURP know?

Because we are patching them? Otherwise, we'd have to keep the hash for every patched version of the .nds for every DLDI driver on the server to compare against, no?

Wouldn't it be better to patch at runtime in the loader? This was Chishm's original intent with the DLDI system.

As I've said in other places I'd love to see a standard homebrew menu & launcher that works on as many cards as possible. Chishm has an exec stub somewhere that works that way.

Quote:

WinterMute: We're not getting bogged down with this.

Cool. I just have a tendency to think way too much about stuff like this that doesn't really matter quite as much as I think it does :)
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Lynx wrote:

Because we are patching them? Otherwise, we'd have to keep the hash for every patched version of the .nds for every DLDI driver on the server to compare against, no?

This is why I suggested some kind of internal database.

SLURP can generate it's own hash after the rom has been patched, then write it to file.

SLURP then can run hash checks and determine if the user updated the file, at which point SLURP can simply stop managing that file until the user re-downloads it via SLURP.
_________________
FireSlash.net

Quote:

SLURP then can run hash checks and determine if the user updated the file, at which point SLURP can simply stop managing that file until the user re-downloads it via SLURP.

There you go.. sounds easy enough.. ;) Let's see.. feature number 2,453.. it's on the list! :)
_________________
NDS Homebrew Roms & Reviews

Its all good :)

This program is a space-elivator that will put us on another level of homebrewing...or well, something like that.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.

Lynx wrote:

There you go.. sounds easy enough.. ;) Let's see.. feature number 2,453.. it's on the list! :)

A more simple solution may exist. The main thing is that a large number of users want some kind of update checking, be it manual or not. With such a large demand, one would suspect implementing the feature would be fairly high up on the list. Without it, what real good does slurp serve over a more simple and existing solution, such as the ftp client? From what I gather, the innovation of SLURP is that it's somewhat more intelligent than a simple downloader, in which case it needs to reflect that in it's feature list.

imo.
_________________
FireSlash.net

FireSlash wrote:

A more simple solution may exist. The main thing is that a large number of users want some kind of update checking, be it manual or not. With such a large demand, one would suspect implementing the feature would be fairly high up on the list. Without it, what real good does slurp serve over a more simple and existing solution, such as the ftp client? From what I gather, the innovation of SLURP is that it's somewhat more intelligent than a simple downloader, in which case it needs to reflect that in it's feature list.

The only other similar solution is DSO's homebrew database. And it only has Official NDS demos in it. Dragonminded has more to do then worry about that homebrew database.. and what I'm sure he is finding out, is that it's a lot of work trying to keep a list up to date with all the new homebrew coming out. So, the main purpose of SLURP (name is actually going to be changed) is to not only provide a homebrew database for easy downloading and patching, but to provide an upload interface so that one person doesn't have to maintain the database. If all is a success, developers will be adding their homebrew to the database (or fans will) so that we have a large group of people helping to keep it updated.

Not only will it be an applcation, but it will have two libraries (so far) that will be available so that anyone can have their homebrew check/download/patch updated versions, not just within SLURP. Here is some of the current task list for version 0.1.

NDS Application

Website

Some is already working, some not so much. Once we get all of that stuff working, we'll start on the 0.2 features of which, we have quite a few of those as well. Once we get the new svn dev site setup (sf.net) feel free to download the source and submit changes.. The more people that help out, the faster these features will be available.

EDIT:

Quote:

Wouldn't it be better to patch at runtime in the loader? This was Chishm's original intent with the DLDI system.

Unfortunatly, at this time, it isn't going to have a loader. Just a downloader. But, we've already been discussing it, as I think it would be a lot better to be able to download and play than to have to reboot to play. So, maybe someone with more loader experience can help out with that part.

But, what would be the benefit of the loader patching at runtime? I guess if you swapped cards between devices, but you'd still need a version of SLURP patched for each device. Also, you would then be "stuck" with using a loader that was either A) SLURP, or B) supported patching at runtime. Where if the files are patched during download, you would be able to use the loader provided by the device, or any loader that didn't support patching at runtime.

EDIT2: Is it just me, or is there not an edit date/time stamp on this?
_________________
NDS Homebrew Roms & Reviews

Sounds good Lynx :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

http://grizzly.thewaffleiron.net/dualchannel/
This kind of gui would be cool....
Having some kind of information on top screen would be a bonus too
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia

Well, the project is up at SourceForge.net now. So if anyone wants to take a look, they can. I've also updated http://dl.ndshb.com to show the current RoadMap in SVN as well as a link to the sf.net project.

Thanks for all the great support. Hopefully we can get something "real" working soon.

Current progress of the project

* Displays 2 categories from server (should display 5 or 6)
* Displays 1 application avalable to download (should display 2 or 3)
* Appears to download appliction properly, but writes 0k file.
_________________
NDS Homebrew Roms & Reviews

OOPMan wrote:

Sounds good Lynx :-)

Second.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.

3rd

;-)

This is somewhat of a tangent, but was inspired by the idea of having NDSHBHive patch homebrew with its own DLDI driver. I don't mean to hijack the topic, but now I'm wondering how difficult would it be to have a stand-alone app that acts as a DLDI-patched patcher that uses its own DLDI driver in memory to patch another file? Or a DLDI extractor to take that DLDI driver from memory and save it (although this would probably piss off some of the flashcart makers that don't release their drivers)?

The reasoning behind this is for flashcarts that do auto-patching, but don't offer a driver for manual patching. The ability to DLDI patch homebrew on the DS itself then becomes rather handy for apps that act as loaders but don't autopatch at runtime. In the future, if everything works like NDSHBHive is intended to, it won't be necessary, but we still have a need for manual DLDI patching now.

I see applications for all the major OS's, but not for the DS itself, which would be the same for everyone. The idea the NDSHBHive could do it on download or even load has really made me think about this. Is it something worthwhile?
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

MechaBouncer wrote:

This is somewhat of a tangent, but was inspired by the idea of having NDSHBHive patch homebrew with its own DLDI driver. I don't mean to hijack the topic, but now I'm wondering how difficult would it be to have a stand-alone app that acts as a DLDI-patched patcher that uses its own DLDI driver in memory to patch another file?

I've wanted one for awhile, but when I posted, not very many people saw the use or seemed interested. I would do it myself, but I don't program the DS...

MechaBouncer wrote:

Or a DLDI extractor to take that DLDI driver from memory and save it (although this would probably piss off some of the flashcart makers that don't release their drivers)?

It's been done before, I think, by Chishm.

MechaBouncer wrote:

The reasoning behind this is for flashcarts that do auto-patching, but don't offer a driver for manual patching. The ability to DLDI patch homebrew on the DS itself then becomes rather handy for apps that act as loaders but don't autopatch at runtime. In the future, if everything works like NDSHBHive is intended to, it won't be necessary, but we still have a need for manual DLDI patching now.

I see applications for all the major OS's, but not for the DS itself, which would be the same for everyone. The idea the NDSHBHive could do it on download or even load has really made me think about this. Is it something worthwhile?

I think its worthwhile, sometimes I forget to patch homebrew, and I'm already on the go, or just don't want to take the trouble of going back to my PC and getting out my card reader, etc. Also, with my supercard, different SD cards will require either scsd.dldi or scsd_moon.dldi, if I wanted to swap files between cards, I could forget the correct patch more often.
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

MechaBouncer, that is partly why we started BHive to begin with. I was sick of patching homebrew just to test it out. Oh.. and SD Card swapping all day long.. but that's another topic.

If you have programming knowledge, you could easily look at the source of BHive or DS Organize and see how they patch, and write a stand along patcher if you like.

Heck, maybe solicit calcprogrammer1 to add it to his multi-slot file system browser.
_________________
NDS Homebrew Roms & Reviews

It's been a long time since I've done any programming, let alone C (which I never really had a proper introduction to and went straight to C++). I do want to get into DS programming, though. But all I have is game ideas and I don't know the basic "nuts and bolts" of DS programming yet. The most I've done for any console is reverse engineering save files for the PS2 Armored Core games (which is another project I haven't touched in years and never truly finished).

However, this does seem like a good place to start. I can't promise any actual results or anything like that and if someone did it, they would probably have it done before me. But this could certainly be a good learning experience. If something working comes out of it, I'll be sure to put it out there.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

Lynx wrote:

Heck, maybe solicit calcprogrammer1 to add it to his multi-slot file system browser.

Thats something I was thinking too...
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

gbadev.org forum archive

DS homebrew announcements > NDSHBHive (Was SLURP)

#131865 - Lynx - Wed Jun 20, 2007 8:45 pm

#131871 - Devil_Spawn - Wed Jun 20, 2007 10:32 pm

#131879 - JimmyL - Wed Jun 20, 2007 11:54 pm

#131880 - warpunk - Thu Jun 21, 2007 12:23 am

#131883 - SCPR - Thu Jun 21, 2007 1:16 am

#131891 - Dood77 - Thu Jun 21, 2007 1:44 am

#131894 - Lynx - Thu Jun 21, 2007 2:59 am

#131897 - felix123 - Thu Jun 21, 2007 3:41 am

#131913 - Lick - Thu Jun 21, 2007 10:37 am

#131952 - Lynx - Thu Jun 21, 2007 4:00 pm

#132085 - Mrshlee - Sat Jun 23, 2007 6:24 am

#132116 - Darkflame - Sat Jun 23, 2007 3:57 pm

#132568 - FireSlash - Wed Jun 27, 2007 9:40 pm

#132590 - Lynx - Thu Jun 28, 2007 12:08 am

#132596 - wintermute - Thu Jun 28, 2007 12:47 am

#132606 - tepples - Thu Jun 28, 2007 3:55 am

#132617 - Dood77 - Thu Jun 28, 2007 6:18 am

#132621 - chuckstudios - Thu Jun 28, 2007 6:42 am

#132645 - Lick - Thu Jun 28, 2007 11:03 am

#132661 - Lynx - Thu Jun 28, 2007 1:55 pm

#132676 - wintermute - Thu Jun 28, 2007 4:02 pm

#132691 - FireSlash - Thu Jun 28, 2007 6:52 pm

#132701 - Lynx - Thu Jun 28, 2007 8:35 pm

#132754 - Darkflame - Fri Jun 29, 2007 3:15 am

#132755 - FireSlash - Fri Jun 29, 2007 4:09 am

#132767 - Lynx - Fri Jun 29, 2007 5:50 am

#132779 - OOPMan - Fri Jun 29, 2007 8:50 am

#132786 - Mrshlee - Fri Jun 29, 2007 12:26 pm

#134882 - Lynx - Tue Jul 17, 2007 11:03 pm

#135015 - Darkflame - Thu Jul 19, 2007 11:24 am

#135113 - wandafritsch - Fri Jul 20, 2007 7:49 am

#137675 - MechaBouncer - Tue Aug 14, 2007 6:01 pm

#137702 - Dood77 - Tue Aug 14, 2007 9:31 pm

#137761 - Lynx - Wed Aug 15, 2007 2:16 pm

#137770 - MechaBouncer - Wed Aug 15, 2007 3:25 pm

#137803 - Dood77 - Wed Aug 15, 2007 8:54 pm