Homebrew DS(i) Mode hacking progress thread

  • Thread starter Thread starter Billy Acuña
  • Start date Start date
  • Views Views 810,435
  • Replies Replies 4,367
  • Likes Likes 81
How come it didn't work before then? It's the same rom as before, and the only demos I was able to run were the ones from Nintendo Channel.
Probably because they booted in TWL mode. Did the music sound wrong on them?
 
Probably because they booted in TWL mode. Did the music sound wrong on them?
Nothing seemed wrong on any of the demos I tested before and after dldi. I tested the two Mario vs. Donkey Kong game demos, Okamiden, and Sonic Colors.
 
Mario kart : Doesn't work
Picross 3D : Doesn't work
Super Mario 64 DS : Doesn't work
Mario Party DS : Doesn't work
 
Mario kart : Doesn't work
Picross 3D : Doesn't work
Super Mario 64 DS : Doesn't work
Mario Party DS : Doesn't work

We still can't run retail ROMs from SD yet.

QRyv0dv_700wa_0.gif
 
you can delete all the .CIA files if you've already installed them. the .3dsx files are unneeded OR could be moved to the "3ds" folder for use in the Homebrew menu later. the .app files are unneeded after you've injected FBI into the Health and Safety app. Unsure about the text files you have.
 
you can delete all the .CIA files if you've already installed them. the .3dsx files are unneeded OR could be moved to the "3ds" folder for use in the Homebrew menu later. the .app files are unneeded after you've injected FBI into the Health and Safety app. Unsure about the text files you have.
I followed a guide and this was a prepackged folder. I dumped it on my sd. Made backups of my nands and it was smooth sailing. But now i'm unsure what to get rid of..

--------------------- MERGED ---------------------------

During the installation. I was told that I had to inject fbi into sysnand to tinyformat. What if i want the h&s app back. Will it cause issues if i inject the original app or is it required? I heard it causes brick if the nands are unlinked or something..
 
No, it won't cause a brick :P Just follow the instructions on how to inject it. You'll need to inject it if you want to install CIA files. Once you've injected FBI you can install a newer version of FBI and then restore the H&S later using decrypt9, but you'll still have the new FBI installed afterward. KEEP YOUR H&S.app so you can reinject the original later. PM me if you are unsure. This isn't the thread for this :P
 
No, it won't cause a brick :P Just follow the instructions on how to inject it. You'll need to inject it if you want to install CIA files. Once you've injected FBI you can install a newer version of FBI and then restore the H&S later using decrypt9, but you'll still have the new FBI installed afterward. KEEP YOUR H&S.app so you can reinject the original later. PM me if you are unsure. This isn't the thread for this :P
I know. I've installed fbi but i installed it on both emunand and sysnand. And as i a9lh'd..theyre both linked xD is that an issue because it boots direct to emunand..and fbi is on both emu and sys..

--------------------- MERGED ---------------------------

I know. I've installed fbi but i installed it on both emunand and sysnand. And as i a9lh'd..theyre both linked xD is that an issue because it boots direct to emunand..and fbi is on both emu and sys..
Sorry for the spam but its crucial that i understand haha i get paranoid just thinking of it.

--------------------- MERGED ---------------------------
 
It shouldn't cause any issues, no. You'll be fine if you keep H&S injected with FBI on either sys or emu. It's up to you to keep it. I keep the original injected FBI incase the newer (nicer gui) build gives me issues. Have fun :D
 
Dang it. I just realised why you need to install fbi on both sys and emu. For gba/dsiware titles! Well. That took my mind off it. Ps. I also have the original fbi. Nice and simple plus it works like a treat. Thanks for the help!xD
 
Dang it. I just realised why you need to install fbi on both sys and emu. For gba/dsiware titles! Well. That took my mind off it. Ps. I also have the original fbi. Nice and simple plus it works like a treat. Thanks for the help!xD
There is no need to have a emunand if you have A9LH..
Also this is the best guide and also will tell you which files you don't need.
Bible: https://github.com/Plailect/Guide/wiki

And.. This is the DS(i) hacking thread, you shouldn't ask this here
 
I said sorry. I've installed LumaCFW, A9LH'd, installed the nds-hbmenu, now i'm waiting for the future releases..
 
I said sorry. I've installed LumaCFW, A9LH'd, installed the nds-hbmenu, now i'm waiting for the future releases..
No problem, there have been worse off topic on this thread. Maybe now you could give an hand by testing some homebrews with you brand new nds-hbmenu installed?

There is lot of homebrews to test : http://gamebrew.org/wiki/List_of_DS_homebrew_applications

Let me explain why I need this information on how I achieved the dldi compatiblity in the current version of nds-hbmenu. The dldi compatibility is formed of 4 parts :
- a bootloader : this one was taken from the original hbmenu, it loads the homebrew and all the other pieces in memory and transfert the execution to the homebrew.
- a dldi driver : this is the easy part, it detect if the execution take place in arm7 or arm9. If it takes place in arm7 it just access the sdcard. If it takes place in arm9 it writes a command for arm7 in the main memory shared between both, try to trigger some interrupts ar arm7 level then wait for arm7.
- an arm7 patcher : this is integrated in the bootloader, it modify some part of the homebrew binary (the current method target "interruptDispatcher.s" of libnds) in order to get a "parralel" exection flow to the homebrew. This can be done via the interrupt mechanism and was inspired by NitroHax code (even if the NitroHax original method only work with retail games). This is the smallest part but it is quite hard to implements and debug. Most compatibility improvement in the future should come from this part.
- a arm7 "sdengine" binary : this part is like "server" that waits command from the dldi driver (the "client"), process them (read the sd) then reply to arm9 (put the sd piece of data needed in the main memory and put some special value in memory to notify arm9 that the work is done).

The current compatibility is somewhere at 40%, I suppose that most of the freezes are due to the fact that if for some reason the arm9 dldi driver send a command the the sdengine but interrupts are not yet enabled or temporarily disabled on arm7 everything get stuck. So I will need to patch other functions in libnds to avoid that (the one that enable or disable interrupt for example) but these functions may have different signature according to the libnds versions (and there is a lot of them). The part of interruptDispatcher.s I am targeting have never changed in 10 years, it is a sort of "silver bullet" but I will not always be so lucky.

So in the end I will probably end with several patching methods configurable via the ini file according to the homebrew we are launching (I can recognize it via md5 or filename for example).

But first I need to know what is working or not now with the first method (I need also to know which version is tested) and a little explanation of what you observe (white screen, black screen, it freezes when I do that).

The retail game loading will be built on the same base and obey to the same restrictions (do not expects a full compatibility at launch, If I can get 40% of the 500 first games released to works I will be happy).

You can provide results in this thread or here : https://github.com/ahezard/nds-bootstrap/issues or if someone want to create a wiki I will be very happy as well.
 
- a dldi driver : this is the easy part, it detect if the execution take place in arm7 or arm9. If it takes place in arm7 it just access the sdcard. If it takes place in arm9 it writes a command for arm7 in the main memory shared between both, try to trigger some interrupts ar arm7 level then wait for arm7.

I'm guessing that only the ARM7 can access the SD directly, while both the ARM7 and ARM9 can read slot1 under normal circumstances. That would explain why it's necessary to use the ARM7 to fetch data on the ARM9's behalf.
How much overhead does this approach bring? Is it likely to impact performance, esp. in software that streams data from the disk?

I'd like to try some DLDI homebrews but I'm not sure how this is organised. Is nds-bootstrap simply used to perform automatic DLDI patching for homebrews launched from nds-hb-menu, so they can use the SD?
 
Last edited by metroid maniac,
  • Like
Reactions: ahezard

Site & Scene News

Popular threads in this forum