hey aabout the sd card

[samsar]

Look if i have it right then , when the we load any nds game from the sd card then i suppose the menu patches the nds rom and then the menu loads the game, right?
 
How about we patch the nds game from the beginning when we put the nds rom on the sd card(using fat) ?
It would make loading times shorter and also increase the compatibility...


Sorry for harassing you moderators with my geeky ideas...

[boblen]

I dident think that the menu patched the rom I thaught it just loaded it

[angelfly]

I personally dislike having to patch roms. Being able to run clean dumps is one of the features that sets MK2/3 above some other devices. Not having it go through patching software is also a plus for people like me who also use an OS other than windows.

[bruceg]

Look if i have it right then , when the we load any nds game from the sd card then i suppose the menu patches the nds rom and then the menu loads the game, right?
 
How about we patch the nds game from the beginning when we put the nds rom on the sd card(using fat) ?
It would make loading times shorter and also increase the compatibility...


Sorry for harassing you moderators with my geeky ideas...

It's easier for people to load clean dumps on the SD card, and have the menu do all the patching automatically (this is done transparently now). 

I don't think there would be any significant speed difference in what you are suggesting.  The slowdown/bottleneck is occuring in the ds/sd card interface.  If they ever fully resolve this issue, compatibility should go way up as well...

BruceG

[samsar]

I dident think that the menu patched the rom I thaught it just loaded it

That .... my friend is not possible.
the nds rom patches have to be patched onto the rom, then the new rom has to be loaded into the ds(or the mk3 's memory) then it has to be runned.
This takes a longer time...

It's easier for people to load clean dumps on the SD card, and have the menu do all the patching automatically (this is done transparently now). 

Hey man it's a one time task ...you can load about 15-20 nds roms on the sd (though it depends on size of roms and sd size) but once it's done, you can enjoy so many games.

I don't think there would be any significant speed difference in what you are suggesting.  The slowdown/bottleneck is occuring somewhere in the ds/sd card interface.

Bruce I think your wrong there ,
 you know  something , try to patch a 64MB rom  with the gst , it takes about 20 seconds on my laptop(hp).What is the mk3 's and ds's capacity infront of a computer? If it takes so much time on the laptop it would obviously take more time on the menu.

I mean u patch just once but... you play the game  many times
So it's worth it.

The slowdown/bottleneck is occuring somewhere in the ds/sd card interface.

This not just due to a single reason...there are many factors which influence the slowdown in the interface...

i)one is the reason i mentioned above

ii)distracted neoteam coders( in other projects)

If you think my idea is worthwile please send it to dr.neo...he doesnot respond to my PMs but he will listen to a moderator.

Iwould like any one else to debate on this

[bruceg]

I am not a coder, but I still don't see the time difference being very significant.  I tried now with gst-patcher 3.4r (on my computer, it takes a couple seconds at most, even on 128 Mb roms).  Just by this factor alone, I don't see how one can conclude that the menu patching routine is responsible for a significant portion of the slowdown.

If that were the case, then why do the roms run at full speed from the flashcart/mk3 internal memory?? (the same clean dumps are being patched by the menu).

That highly suggests to me that the interface (and how the menu is coded to utilize that interface) is basically the principle cause of the slowdown.  When you resolve this bottleneck (incorporate SDIO or whatever), you should get full speed on the roms as well (similar to the flashcart/mk3 internal memory)....

If anyone else with more specific technical knowledge would like to comment, then by all means, feel free to do so....

I do agree, though, that there are a lot of projects going on, so the coders can't be focusing their efforts as extensively as if they were only a few things happening...

BruceG

[samsar]

Quite right Bruce..but

If that were the case, then why do the roms run at full speed from the flashcart/mk3 internal memory?? (the same clean dumps are being patched by the menu).

Hey bruce , you know something, check the size of the rom after flashing it to the mk3... you will notice that the size of the rom decreases .

It is the same case when we patch a rom with the gst, it's size decreases.This size decrease indicates- a Patch on the rom.
Remember, the menu patches "on the fly"(quoting dr.neo 's words ) while flashing to cart or the  mk3. This is why roms run at full speed.

[bruceg]

Yes, the trimming function is built into the menu (so the roms should end up smaller). 

Try trimming/re-building the roms yourself and then putting them onto the SD card.  You may notice minor improvements, but I doubt they are highly significant.

So, my primary argument remains unchanged.  If you don't resolve the bottleneck/SDIO issue (or whatever is causing the slowdown in the interface), you are never going to get the roms to run anywhere close to full speed, no matter what you do with the patching.

BruceG

[cory1492]

The way I understand it SDIO is not going to happen using a serial device; with MK2/3 everything is done in serial/MMC mode, even with faster SD/MMC access there would still be similar problems.

The patches are needed only once, when the binaries are first loaded to the DS memory (incomplete or bad patches would be the root cause of whitescreens/crashes though).  That said, the FAT software (the bit of code that handles translating DS cart ROM offsets and data transfers into SD/MMC FAT offsets and data transfers) has to be running to establish file access to the SD/MMC card which creates a bit of extra load on the CPU that the origional games were not designed for.

In many games this is not an issue since they only access the card at certain points (which means longer loading screens). In some games this is an issue since they stream data from the DS card constantly.

The point I am trying to get at though in the end, is that the Menu software is not in its complete form; I am looking forward to seeing exactly how far the menu can/will be optimized to minimize such problems. Also note that the MK2 was not really designed with direct loading commercial DS roms in mind, through some great coding it is possiblem, although the code still needs to be looked at closer to see if it can be sped up or optimized.

[bruceg]

Cory,

If we won't ever have SDIO since mk2/mk3 is a serial device, are we stuck with the slower MMC mode, if this is in fact the mode it is running in now??  And you mention that, even with faster access, there still would be similar problems.  Translated, does this mean that even if the coders resolve the possible contributing factors (whether it may be a bottleneck on the sd interface, the buffering/interpretation overhead, or an unoptimized fat layer), roms still won't run full speed from the SD card??

Well, I guess this is news to me, unless I'm not interpreting what you are saying, but it doesn't sound like this hurdle will be easily overcome then, even if faster SD access is achieved....

BruceG

[samsar]

Oh no!from what you and bruce are suggesting , neoflash will never come to the level of the other nds linkers in the market??

Look i m not against neoflash , but hey can't release the source code so that the other coders can try their hand?
I mean they won't have the competitors copying their softwre(i mean g6/m3 don't have to , since they already possess better compatibility then neo flash) but atleast so many people who have invested so much  and who know coding can try and help neo.


And from what bruce said let's hope , this hurdle will not be impossible to overcome...

[bruceg]

yeah Samsar,

Wait for cory to respond since he's more technically knowledgable.  Upon reading his reponse again, I possibly misunderstood what he said at the beginning -- he also said they have to take a much closer look at it first for optimization opportunities.

Cory has always maintained that if there is a way to get it to run at full speed, he has faith that the coders will be able to figure it out, but it will take time.

At this point, it would be way too premature to release the source anyways, so that's not a viable option here.....

BruceG

[cory1492]

Honestly, hardware wise it should easily be capable of handling whatever speed the M3 and SuperCard are getting although at this point the way the FAT "layer" is working it is getting less than optimal speeds.

The only hit that the transparent patching routines should cause are when the ARM 7/9 binaries are first loaded into memory and patched. I have no idea at this point what or how much is patched into the ROM code to allow the ROM to read from the SD card wrather than from a DS card, or whether that code is optimized.

You ever hear the old saying "too many cooks spoil the broth" ? Well, the people who are working on this still have other code that they didnt write to sort through and fix up, and I personally think what has been done so far with loading from SD is excellent work, and wasnt initially thought possible at all.

I know your probably getting sick of hearing it, but they are working on it, it is getting better and I have alot of faith in the people who are doing the work on the menu. If it can be solved I am certain the people who are working on it already likely have the best idea of how to work with the hardware to solve it.

[samsar]

they are working on it, it is getting better and I have alot of faith in the people who are doing the work on the menu. If it can be solved I am certain the people who are working on it already likely have the best idea of how to work with the hardware to solve it.

yup cory I m with you.
Neoflash team, Bulk up and work hard
we r all with you!!!!!