Toggle sidebar

Homebrew DS(i) Mode hacking progress thread

  • Thread starter Thread starter Billy Acuña
  • Start date Start date
  • Views Views 810,270
  • Replies Replies 4,367
  • Likes Likes 81
already tested ComicBookDS and Nitrohax, both running smoothly

but I can run miniVMac DS, always stuck loading file from vmac folder (placed on nds folder neither root SDMC not working)

EDIT:
also LoneWolf DS, stuck after character creation screen, setting equipment, music running but screen stuck
 
Last edited by carls,
  • Like
Reactions: Bedel
Much has been said about about the complexities of patching DS software to load from the SD card rather than slot-1. But, a similar situation has occurred in the past. Slot-2 GBA cards such as the EZ Flash IV were capable of playing DS games.

I know from my experience with the EZ Flash IV that DS roms needed to be patched using the EZ Flash client software before they would run. So, I guess that this patching is what enables them to load assets from GBA ROM regions and save data to GBA SRAM regions rather than using the standard slot 1 cartridge interface.

I'm just speculating if this is relevant to patching SD support into retail DS roms. Has this technology been investigated, and if so did it yield any useful information? Perhaps someone with more technical knowledge such as @ahezard would be able to provide insight here.

One thing in particular that stood out to me was the fact that the GBA ROM and RAM regions were only mapped to a single CPU at a time (GBATEK) - which reminded me of the fact that only ARM7 can use the SD card interface.
 
  • Like
Reactions: Deleted member 388912, Feryth, pelago and 2 others
metroid maniac said:
Much has been said about about the complexities of patching DS software to load from the SD card rather than slot-1. But, a similar situation has occurred in the past. Slot-2 GBA cards such as the EZ Flash IV were capable of playing DS games.

I know from my experience with the EZ Flash IV that DS roms needed to be patched using the EZ Flash client software before they would run. So, I guess that this patching is what enables them to load assets from GBA ROM regions and save data to GBA SRAM regions rather than using the standard slot 1 cartridge interface.

I'm just speculating if this is relevant to patching SD support into retail DS roms. Has this technology been investigated, and if so did it yield any useful information? Perhaps someone with more technical knowledge such as @ahezard would be able to provide insight here.

One thing in particular that stood out to me was the fact that the GBA ROM and RAM regions were only mapped to a single CPU at a time (GBATEK) - which reminded me of the fact that only ARM7 can use the SD card interface.
Click to expand...
Interesting read, didn't EZ Flash IV need something like a passthrough cart or FlashMe to make it do the DS stuff?
 
fodder said:
Interesting read, didn't EZ Flash IV need something like a passthrough cart or FlashMe to make it do the DS stuff?
Click to expand...

That's right. But a passme doesn't do very much exciting work, its only job is to boot the slot-2 flashcard without going into the GBA backwards compatibility mode.
Once it hands over control to the flashcard, you can remove it or hide it away somewhere. The passme doesn't assist in loading ROMs or anything.
 
  • Like
Reactions: pelago and fodder
carls said:
already tested ComicBookDS and Nitrohax, both running smoothly

but I can run miniVMac DS, always stuck loading file from vmac folder (placed on nds folder neither root SDMC not working)

EDIT:
also LoneWolf DS, stuck after character creation screen, setting equipment, music running but screen stuck
Click to expand...
This are rally good news! Gotta test ComicBookDS, I really used to love it.
 
The bad thing that few people will use it in the 3ds, being the mode ds. Although it comes very well, in case it spoils the slot-1 and thus is the only way to play the games of ds.
 
metroid maniac said:
Much has been said about about the complexities of patching DS software to load from the SD card rather than slot-1. But, a similar situation has occurred in the past. Slot-2 GBA cards such as the EZ Flash IV were capable of playing DS games.

I know from my experience with the EZ Flash IV that DS roms needed to be patched using the EZ Flash client software before they would run. So, I guess that this patching is what enables them to load assets from GBA ROM regions and save data to GBA SRAM regions rather than using the standard slot 1 cartridge interface.

I'm just speculating if this is relevant to patching SD support into retail DS roms. Has this technology been investigated, and if so did it yield any useful information? Perhaps someone with more technical knowledge such as @ahezard would be able to provide insight here.

One thing in particular that stood out to me was the fact that the GBA ROM and RAM regions were only mapped to a single CPU at a time (GBATEK) - which reminded me of the fact that only ARM7 can use the SD card interface.
Click to expand...

Well @_catcatcat did do quite a bit of reverse engineering on Max Overload which did exactly that with a homebrew only GBA slot device. Hopefully @ahezard is already aware of that work as while some versions required PC side patching, the last one did it all on the DS and "used libnds with its own filesystem driver".
 
Last edited by nl255,
nl255 said:
Well @_catcatcat did do quite a bit of reverse engineering on Max Overload which did exactly that with a homebrew only GBA slot device. Hopefully @ahezard is already aware of that work as while some versions required PC side patching, the last one did it all on the DS and "used libnds with its own filesystem driver".
Click to expand...

Do you have links to the results of the reverse engineering effort?
 
metroid maniac said:
Do you have links to the results of the reverse engineering effort?
Click to expand...

Yes but I don't think I can give them here since it most likely contains at least a partial disassembly which would still be copyrighted by whoever wrote Max Overload. I will say this though, catcatcat does have github.
 
  • Like
Reactions: metroid maniac and fodder
nl255 said:
Yes but I don't think I can give them here since it most likely contains at least a partial disassembly which would still be copyrighted by whoever wrote Max Overload. I will say this though, catcatcat does have github.
Click to expand...

While it might not be useful to me with my limited programming expertise, I'm sure that this github has useful contents.

I'm starting to want to learn a language that's good for Homebrew like C now.
 
Last edited by metroid maniac,
metroid maniac said:
While it might not be useful to me with my limited programming expertise, I'm sure that this github has useful contents.

I'm starting to want to learn a language that's good for Homebrew like C now.
Click to expand...

You would need to know ARM assembly for it to be of any use to you. However hopefully it will be of use to @ahezard .
 
Prolly a stupid thing to add but for the compatibility chart the DSTT firmware (I think, TTDS.nds, 128kb as opposed to typical 300+ YSMenu SD Card file) dumped with Decrypt9, gets up to the white screen with the SD card with the face and doesn't go any farther
 

Site & Scene News

Go to forum More news

Popular threads in this forum

Why did the price of 3ds shoot up ?

Hacking Homebrew Project  BlazerTube - a YouTube 3DS revival using the REAL app!

[WIP] SMW 3DS Port - Early Playable Demo by ZalgonEn

Problems getting Homebrew to appear outside of the Homebrew Launcher (homebrew won't appear on the HOME menu)

Homebrew app Emulator  [Release] 3DS-CLI - Run a real RISC-V Linux environment on the Nintendo 3DS

Website for finding alternative games for 3DS

Homebrew  [Progress update] LCE Minecraft 3ds

Gaming  any good rpgs on 3ds?