Homebrew BAGPlug (SCDS2 Entry)

  • Thread starter Thread starter BassAceGold
  • Start date Start date
  • Views Views 148,718
  • Replies Replies 584
  • Likes Likes 4
Ok, I found the solution Mr Bag! So, the reason Fat16 goes so fast for you is probably because the default Allocation Unit Size is 64KB, if you are using 4GB, which I am guessing you do use that.
So, I went and formatted my 8GB card as FAT32, my only real option, and then chose 64KB as the Allocation Unit Size, instead of the default 32KB. And suddenly, things were lightning fast.
One HUGE downside to this is every single one of those covers I have now is 64KB. Since I haven't selected specifically covers to only games I own, there is about 3500 files, give or take. This means while the size of the files is only 61MB or so, the actual space it requires is 220MB. Youch. But much more insanely faster browsing speed. I wonder why your program specifically love 64KB? 32KB runs blazing fast in the standard UI. BTW if you use a FAT16 card smaller than 4GB, you won't have 64KB allocation, and as far as I know, you can't change that. 2GB = 32KB, 1 GB= 16KB and so on...
I wonder if you used a 2GB card, or smaller, even in FAT16, if it would be really slow? In that case you still can convert it up to FAT32 with 64KB allocation.

So, even though I can't test it as thoroughly as I want, I can without a doubt say that FAT16 vs FAT32, doesn't matter. It is the Allocation Unit Size you choose.

EDIT: Wanted to point out that I have about 115 DS games, with 349 total files in the root directory. With CPU setting on 120 and pushing right to fastscroll to the bottom, it takes 6.4 seconds. CPU set to 240, it takes 4.4 seconds. Full blast at 396 takes 3.4 seconds. Thats freaking amazing. Also when you press start it doesn't take 5 seconds to open anymore, its instant. The whole thing was blooming slow even when there weren't any files on the card except the UI itself. So, something in your program absolutely loves 64KB Allocation. And doesn't like 32KB thats for sure. Now the only thing left is to add a way to change cheats!
wink.gif


2nd EDIT: Yah, I'm pretty sure the top_display_refresh variable is a big waste of time too. If you are scrolling as fast as you can, you are holding the button down, and it doesn't load pictures when you do that. So, making it take a second to load box art doesn't affect scroll speed unless you tend to scroll slowly anyways and let go of the button each time. I also just timed the "slow" scroll, holding down going through each one. With CPU set to 396, it takes 7.4 seconds. Good lord it moves fast. I really think you oughta change the first post to mention how amazing life gets if you reformat to 64KB Allocation. Haha, I went from 250 to 28MB free out of 7.59 GB. Worth it for the speed boost though.

BassAceGold said:
lex luthor said:
@OP
I own a 16gb micro sd so what do you recommend I should do to scroll roms faster?, because they scroll a little slow.

QUOTE(BassAceGold @ Mar 26 2011, 02:04 PM) Improving BAGplug Performance
BAGplug does quite a bit of random reading from the SD card for things such as icons and box art. These can cause lagging or bad performance when scrolling through files. Here are a few tips to optimize BAGplug to (hopefully) make it run smoother:

-Make sure your SD card is formated to FAT or FAT16 (for 4GB cards or smaller)

-Box art is loaded after X (5 is the default) number of program cycles without user input in the browser. You can change this value in your settings.ini with the 'top_display_refresh' variable. 60 = 1 second, 30 = half a second etc. The default value may be to fast and cause lagging when scrolling with covers.

-Last resort: Change the CPU speed in the BAGplug options menu. A reboot of the menu may be needed to get working properly after switching CPU speeds.

Another thing you could try is disabling the use of internal rom names. Other than that there is nothing much else that can be done. The icons can only be read so fast from the SD card. If things are getting really slow, maybe try breaking large directories of roms into smaller bunches ~50 files or less. I notice that file system reads are much much slower than average when reading from a directory with hundreds of files.
 
VatoLoco said:
Hey BassAce, do you think it would be possible to get a homebrew soft-reset button combo added to BAGplug,
something like a+b+r+l+down that could take you back to the menu from within a homebrew game.
If it's not do-able, that's cool, it's just a neat feature of AKAIO that'd be awesome to have on my DSTwo, too=)

I don't know how that works, so I doubt I could properly implement it.

QUOTE(aj_hix36 @ Jun 20 2011, 08:13 AM) Ok, I found the solution Mr Bag! So, the reason Fat16 goes so fast for you is probably because the default Allocation Unit Size is 64KB, if you are using 4GB, which I am guessing you do use that.
So, I went and formatted my 8GB card as FAT32, my only real option, and then chose 64KB as the Allocation Unit Size, instead of the default 32KB. And suddenly, things were lightning fast.
One HUGE downside to this is every single one of those covers I have now is 64KB. Since I haven't selected specifically covers to only games I own, there is about 3500 files, give or take. This means while the size of the files is only 61MB or so, the actual space it requires is 220MB. Youch. But much more insanely faster browsing speed. I wonder why your program specifically love 64KB? 32KB runs blazing fast in the standard UI. BTW if you use a FAT16 card smaller than 4GB, you won't have 64KB allocation, and as far as I know, you can't change that. 2GB = 32KB, 1 GB= 16KB and so on...
I wonder if you used a 2GB card, or smaller, even in FAT16, if it would be really slow? In that case you still can convert it up to FAT32 with 64KB allocation.

So, even though I can't test it as thoroughly as I want, I can without a doubt say that FAT16 vs FAT32, doesn't matter. It is the Allocation Unit Size you choose.

EDIT: Wanted to point out that I have about 115 DS games, with 349 total files in the root directory. With CPU setting on 120 and pushing right to fastscroll to the bottom, it takes 6.4 seconds. CPU set to 240, it takes 4.4 seconds. Full blast at 396 takes 3.4 seconds. Thats freaking amazing. Also when you press start it doesn't take 5 seconds to open anymore, its instant. The whole thing was blooming slow even when there weren't any files on the card except the UI itself. So, something in your program absolutely loves 64KB Allocation. And doesn't like 32KB thats for sure. Now the only thing left is to add a way to change cheats!
wink.gif


2nd EDIT: Yah, I'm pretty sure the top_display_refresh variable is a big waste of time too. If you are scrolling as fast as you can, you are holding the button down, and it doesn't load pictures when you do that. So, making it take a second to load box art doesn't affect scroll speed unless you tend to scroll slowly anyways and let go of the button each time. I also just timed the "slow" scroll, holding down going through each one. With CPU set to 396, it takes 7.4 seconds. Good lord it moves fast. I really think you oughta change the first post to mention how amazing life gets if you reformat to 64KB Allocation. Haha, I went from 250 to 28MB free out of 7.59 GB. Worth it for the speed boost though.

The fat library for regular DS homebrew (default supercard menu) is probably way more optimized than the one in the DSTwo SDK. I'd expect FAT reading to be way faster on the DSTwo with the direct access it has rather then having to send the data through the slot 1 to the DS main ram. But that doesn't appear to be the case, unless there are huge flaws in my code, or maybe an unexpected hardware flaw, that I am unaware of.

Looks like I have some testing to do.
 
I can confirm the above statement is correct. Formatting the card to 64k made my covers scrolling much faster. Now it performs like it should.
 
Burton said:
I can confirm the above statement is correct. Formatting the card to 64k made my covers scrolling much faster. Now it performs like it should.

Anyone know if iMenu also performs better with 64k clusters? If it does, then it is most likely an sdk issue.
 
BAGplug isnt lightning fast as AKAIO (I dont mind at all, as I'm usually browsing to enjoy the boxart, instead of speeding through my list of games and stuff), but the only place i personally have any real slowdown is when scrolling commercial roms.

I'd tried the 64 cluster thing a while back, and iirc that made it faster for me, but Moonshell2 hated it being allocated like that, so i went back to using the default Panasonic formatter settings.
 
Hey BassAce, thought I'd share this.
I was playing with NeoDS today and happened upon a Moonshell2 version at filetrip that can be added to the "list of some popular programs that support args + extlink.dat" =D

NeoDS - Neo Geo AES/MVS emulator


I just renamed the neo.NeoDs.nds to NeoDS.nds and made an .arg for the bagplug ext folder.
I tried it out direct booting a couple of games and it works great,.. now to git down on making some NeoGeo boxarts an icons=)
 
VatoLoco said:
Hey BassAce, thought I'd share this.
I was playing with NeoDS today and happened upon a Moonshell2 version at filetrip that can be added to the "list of some popular programs that support args + extlink.dat" =D

NeoDS - Neo Geo AES/MVS emulator


I just renamed the neo.NeoDs.nds to NeoDS.nds and made an .arg for the bagplug ext folder.
I tried it out direct booting a couple of games and it works great,.. now to git down on making some NeoGeo boxarts an icons=)

Updated the list, thanks for reporting.
 
VatoLoco said:
I googled up a full pack of NeoGeo covers and did the resize/rename thingy to 'em=)

[thumb]http://pix.gbatemp.net/113027/mslug.neo.png[/thumb]
download.gif
NeoGeo boxart

Thanks VaotLoco
toot.gif
You ever make my NDS more nice to use
yaynds.gif
 
spinal_cord said:
There isn't a GB emu that supports Argv is there?

Appy polly logies in advance for the long post and digression=P
The Moonshell2 Lameboy ext.link doesn't actually direct boot the games.
So, i went on a search. Lameboy's source isn't available, so i started looking for the DSBoy GB emulator source, and that took me on quite a journey.
From what i read, the first emu was DS_GBC made by Ethos for the 2005 Neoflash coding competition. mateom199 took the DS_GBC sourcecode and added some features and created DSBoy. Theli and GPFerror in turn tried to fix graphical glitches, and GNUboyDS was the result.
Every link to to any of the sources were dead, except one i FINALLY found for gnuboy_000.
I dunno if you (spinal, or BAG) could do anything (or are even interested in playing around with it, supposedly it sucks compared to Lameboy), but here 'tis.
http://filetrip.net/f25598-GNUBoyDS-v0-00%...-source%29.html

Also, on a side note, i noticed the source for NeoDS 2.0 is included in the DL...it'd be really cool to see if can be complied to run via Sudokuhax/DSi mode. Ive never been successful compiling crap, or Id try it =)
 
Out of wonder, what is this "screenshot" feature all about?
Can you take screenshots of the games you're playing? because that would be awesome.
 
VatoLoco said:
Hey BassAce, thought I'd share this.
I was playing with NeoDS today and happened upon a Moonshell2 version at filetrip that can be added to the "list of some popular programs that support args + extlink.dat" =D

NeoDS - Neo Geo AES/MVS emulator


I just renamed the neo.NeoDs.nds to NeoDS.nds and made an .arg for the bagplug ext folder.
I tried it out direct booting a couple of games and it works great,.. now to git down on making some NeoGeo boxarts an icons=)

Don't know if i screwed up something or what, but this version doesn't work for me, it just white screens after I select the game from bagplug. Here's my .arg:

CODEneoDS:
"/_bagui/emulators/neods.nds"//file path
[$PRGMPATH$,$FILEPATH$]//arguments are separated by commas
;

Am I missing something? Not really a big deal either way, since they work manually loading them in the original version.
 
Congratulations for winning the DSTwo Homebrew Bounty. I hope you won't leave the project now and add some more cool features.
wink.gif
 
2-bias said:
Congratulations for winning the DSTwo Homebrew Bounty. I hope you won't leave the project now and add some more cool features.
wink.gif

Thanks! I won't be leaving the project, but I honestly can't think of anything else to add that wouldn't be better off as its own program. If anyone has any ideas that aren't too ridiculous or over the top that they would like to see implemented, I'd love to hear them.
 
BassAceGold said:
2-bias said:
Congratulations for winning the DSTwo Homebrew Bounty. I hope you won't leave the project now and add some more cool features.
wink.gif

Thanks! I won't be leaving the project, but I honestly can't think of anything else to add that wouldn't be better off as its own program. If anyone has any ideas that aren't too ridiculous or over the top that they would like to see implemented, I'd love to hear them.

If you aren't using too much CPU time currently, how about some sort of 'widget' system, whereas a small scripting language could be used to display crap on the screen in reference to any DS hardware that can be accessed from the DSTwo. Like a clock or calendar, maybe some sort of animation.
 
BassAceGold said:
2-bias said:
Congratulations for winning the DSTwo Homebrew Bounty. I hope you won't leave the project now and add some more cool features.
wink.gif

Thanks! I won't be leaving the project, but I honestly can't think of anything else to add that wouldn't be better off as its own program. If anyone has any ideas that aren't too ridiculous or over the top that they would like to see implemented, I'd love to hear them.

Got some:
I am missing a internal text reader, for simple txt files like readme.txt or gameguides.
Read out internal mp3 covers and show them in the filebrowser and while playing in the internal player. I think thats hard, because you need to resize every image first.
Multi language support would be nice to.
Add the option to delete the uncompressed nds file when highlighting a nzip file.
And for the optical side: How about a "taskbar align" setting in the skin.ini. Like taskbaralign=top/middle/bottom.
Switching sides of the taskbar would be a nice option too.

And i don't know if this was mentioned before, but whats with the max. 18 letters "bug". I mean, files with more than 18 letters e.g. MoonShell 2.10 - Child Zwai will be shown as MoonShell 2.10 - C if they are not selected in the filebrowser. When selected, the name is shown correctly.
 
spinal_cord said:
If you aren't using too much CPU time currently, how about some sort of 'widget' system, whereas a small scripting language could be used to display crap on the screen in reference to any DS hardware that can be accessed from the DSTwo. Like a clock or calendar, maybe some sort of animation.

I'll see what I can think of.

QUOTE(2-bias @ Jul 8 2011, 10:07 AM) Got some:
I am missing a internal text reader, for simple txt files like readme.txt or gameguides.
Read out internal mp3 covers and show them in the filebrowser and while playing in the internal player. I think thats hard, because you need to resize every image first.
Multi language support would be nice to.
Add the option to delete the uncompressed nds file when highlighting a nzip file.
And for the optical side: How about a "taskbar align" setting in the skin.ini. Like taskbaralign=top/middle/bottom.
Switching sides of the taskbar would be a nice option too.

And i don't know if this was mentioned before, but whats with the max. 18 letters "bug". I mean, files with more than 18 letters e.g. MoonShell 2.10 - Child Zwai will be shown as MoonShell 2.10 - C if they are not selected in the filebrowser. When selected, the name is shown correctly.

txt reader - simple enough
mp3 covers - i'll see what I can do
multi language support - that's already kind of added, you can change all the text in language.ini and then create a new font for your skin with all the characters.
delete uncompressed nds when nzip file hilighted - seems like a logical inclusion
Taskbar stuff - i'll check it out, shouldn't be too hard to do

The 18 letter max isn't a bug, I can set it to a higher letter count. Any suggestion as to what it should be?
 

Site & Scene News

Popular threads in this forum