Homebrew DS(i) Mode hacking progress thread

  • Thread starter Thread starter Billy Acuña
  • Start date Start date
  • Views Views 810,753
  • Replies Replies 4,367
  • Likes Likes 81
Will the loading time for SD loading ever improve for .nds files? Or is that basically a lost cause? Certain games with multi-screen transitions can take 3-4 seconds and it really slows the games to a halt.

Loading from SD will be almost certainly slower than loading from your flashcard.

What sort is it, anyway?
 
Well afaik it should load all the game into the RAM, so that shouldn't be a problem so far...
Huh, is that the plan?
The DS has 4mb of RAM, the 3DS has 128mb and the n3ds has 256mb. 64mb is normally reserved for the OS, but I assume the DS-mode OS needs little or none of this?
256mb games do exist, so I suppose even the n3ds can't exclusively do this... (since the game needs working RAM too) but I guess it is practical for a lot of the smaller games.

EDIT: That said, I don't actually know if we can access the full RAM in TWL mode, since TWL probably limits it to the DSi's amount, right?
 
Last edited by ~Poke~,
Huh, is that the plan?
The DS has 4mb of RAM, the 3DS has 128mb and the n3ds has 256mb. 64mb is normally reserved for the OS, but I assume the DS-mode OS needs little or none of this?
256mb games do exist, so I suppose even the n3ds can't exclusively do this... (since the game needs working RAM too) but I guess it is practical for a lot of the smaller games.

Only 16MB of that is available in TWL_FIRM. It remains to be seen if that limitation will be patched out.
 
Last edited by metroid maniac,
  • Like
Reactions: ~Poke~
So right now, if I understand well we should be able to load roms of maximum 128 MB, and this only if TWL FRIM limitation os patched?
Good bye Dragon Quest 9? xD
 
Huh, is that the plan?
The DS has 4mb of RAM, the 3DS has 128mb and the n3ds has 256mb. 64mb is normally reserved for the OS, but I assume the DS-mode OS needs little or none of this?
256mb games do exist, so I suppose even the n3ds can't exclusively do this... (since the game needs working RAM too) but I guess it is practical for a lot of the smaller games.

EDIT: That said, I don't actually know if we can access the full RAM in TWL mode, since TWL probably limits it to the DSi's amount, right?
I don't think that's the plan.
Slot-1 reads will be redirected to SD by the ARM7 CPU, since that can access SD, and the ARM9 can't.
 
Last edited by RocketRobz,
Please try to set BOOST_CPU = 0 into nds-bootstrap.ini.

Thanks a lot to you all for your feedback. It is good to see the compatibility list so much increased :)

That did the trick :D Now it is working perfectly with sound!

EDIT: Spin Master still has graphical bugs on NeoDS, but Neo Bomberman is working nice.
 
Last edited by AtlasFontaine,
  • Like
Reactions: leerz
Nitrografx works but has sound issues (missing samples) and DSision2 doesn't freeze anymore, but cannot boot homebrews, same thing with DSi4DS.
dsDoom still stuck on Welcome...
Please try as well for Nitrografx to set BOOST_CPU = 0 into nds-bootstrap.ini.
 
So right now, if I understand well we should be able to load roms of maximum 128 MB, and this only if TWL FRIM limitation os patched?
Good bye Dragon Quest 9? xD
Yeah, no. Bedel is just talking out of their ass. The current plan as I understand it is to patch the DS mode firmware to make it automatically patch DS roms, which are hardcoded to load from and write to the cartridge, to instead read and write to SD, treating the SD card as if it was the cartridge. Loading the entire game into RAM is terribly inefficient, as you've seen, and would take the same patches anyways. If the ROMs were just loaded into RAM as-is, they would still try to write to the cartridge slot unless more RAM was wasted emulating Slot-1 and redirecting all write commands, which might not even be possible without completely reverse-engineering the DS mode firmware.
 
Will the loading time for SD loading ever improve for .nds files? Or is that basically a lost cause? Certain games with multi-screen transitions can take 3-4 seconds and it really slows the games to a halt.
Try formatting and setting the allocation size to a higher size.
 
Ok, thanks for the informations. It's hard sometimes to understand everything, that's why I ask simple questions.
Good luck, programmers. I know that it's a real pain to achieve, but I believe in you!!!
 
  • Like
Reactions: smileyhead
Yeah, no. Bedel is just talking out of their ass. The current plan as I understand it is to patch the DS mode firmware to make it automatically patch DS roms, which are hardcoded to load from and write to the cartridge, to instead read and write to SD, treating the SD card as if it was the cartridge. Loading the entire game into RAM is terribly inefficient, as you've seen, and would take the same patches anyways. If the ROMs were just loaded into RAM as-is, they would still try to write to the cartridge slot unless more RAM was wasted emulating Slot-1 and redirecting all write commands, which might not even be possible without completely reverse-engineering the DS mode firmware.

Both ARM7 and ARM9 can use main RAM.
Redirecting both ARM7 and ARM9 reads to an image in RAM seems to be require fewer patches than redirecting all ARM7 reads to the SD, and then also having ARM7 run a server which can fetch data from the SD and pass it to the ARM9 on request.
 
The current plan as I understand it is to patch the DS mode firmware to make it automatically patch DS roms, which are hardcoded to load from and write to the cartridge, to instead read and write to SD, treating the SD card as if it was the cartridge.
afaik, the DS/DSi mode firmware (TWL_FIRM) isn't being patched. nds-bootstrap's SD Engine that patches homebrew to read from SD will do the patching job.
 
In other words, besides "compatibilty" considerations (you already said that it would not be 100% compatible at the beginning), it could be able to load all the roms, from 64Mb to 512 Mb? :)
 
afaik, the DS/DSi mode firmware (TWL_FIRM) isn't being patched. nds-bootstrap's SD Engine that patches homebrew to read from SD will do the patching job.

TWL_FIRM is being patched to let you do things like switch to NTR mode from TWL mode while keeping SD card access and 133MHz clockspeed.

There is also the DLDI patching done by nds-bootstrap.

In other words, besides "compatibilty" considerations (you already said that it would not be 100% compatible at the beginning), it could be able to load all the roms, from 64Mb to 512 Mb? :)

ROM size should have no bearing on compatibility.
 
TWL_FIRM is being patched to let you do things like switch to NTR mode from TWL mode while keeping SD card access and 133MHz clockspeed.
That's already possible without any patches to TWL_FIRM.
NTR Launcher and DS forwarders are examples.
 
Last edited by RocketRobz,

Site & Scene News

Popular threads in this forum